Flare: The Graph-First IDE That Watches Your AI Coding Agent

By Prahlad Menon 8 min read

Most agentic IDEs focus on what the agent produces. Flare focuses on what you need to verify it.

Flare is a graph-first IDE for agentic coding — a desktop app (or browser-served tool) where the main surface is a live dependency graph of your codebase. Every file is a node, imports are edges, and as your agent edits files, the graph updates in real-time.

Below the graph sits a full terminal where you run Claude Code, Codex, OpenCode, or Aider. Above it sits something most agentic tools don’t have: a review cockpit that tells you what actually got tested, what’s at risk, and what the agent was trying to do.

The Oversight Problem in Agentic Coding

Anyone who’s let an AI coding agent run for 10 minutes knows the feeling: you come back to 30 changed files with no clear order, no context, and no idea whether the tests that passed actually cover the changes.

The agent edited utils.ts. Great. But:

  • How many files import utils.ts?
  • Did any test run after that edit?
  • What was the agent trying to accomplish?
  • If this is wrong, what’s the blast radius?

A file-by-file diff can’t answer these questions. You’re reconstructing the agent’s reasoning from the wreckage.

Flare’s Solution: Graph + Burst Review + Intent

Flare attacks this from three angles.

1. Live Dependency Graph

The graph isn’t decoration — it’s the primary interface. Three views:

  • Canvas — dependency cards on a pannable board, ordered left-to-right by dependency depth. Foundations left, entry points right. Hover a file to see what imports it (amber) and what it imports (blue). Shift-click two files to trace the path between them.

  • Wheel — every node on a ring, dependencies as bundled chords crossing the middle. The one view that answers “what talks to what across the whole repo at once.” A file whose chords fan across the entire disc is load-bearing whether or not anyone documented it that way.

  • Districts — a treemap where area is lines of code and color is the active lens. The fastest read on where the mass sits.

2. Lenses for Different Questions

Switch the graph’s coloring to answer different questions:

  • Activity — what just changed (heat decay on modified nodes)
  • Hotspots — churn × complexity (where bugs live)
  • Risk — blast radius + coverage gaps
  • Cycles — import cycles highlighted
  • Coverage — drop an lcov.info and see real test coverage per file
  • Unread — files that changed this session that no human has opened

That last one is key: comprehension debt, measured. Approving a file doesn’t clear the Unread flag. Opening it does.

3. Burst-Based Review Cockpit

Changes are grouped into bursts — one batch of writes by one author. Each burst shows:

What actually checked it. Flare watches both file writes and terminal commands. It knows “the tests ran, then two more files were edited and nothing re-ran.” States are: verified / failed / checked, then edited again / never checked.

What it was trying to do. Agents call Flare’s record_intent MCP tool before editing. If they don’t, the burst says so plainly — because reviewing an agent’s diff shouldn’t require reconstructing why the code exists.

Which files deserve attention. Every file is tiered: read carefully / read / skim, based on blast radius, coverage, cycles, and complexity. A 30-file change doesn’t get 30 equal glances.

Agent smells. Rules for shortcuts agents take and humans don’t:

  • Test edited in the same burst as the code it covers
  • Assertions deleted
  • .skip/.only added
  • Lint or type suppressions introduced
  • Coverage thresholds lowered
  • Files left with no importers

4. Shadow History (Git for Local Changes)

A hidden git repo (separate GIT_DIR, your worktree) auto-commits every change burst. Timeline panel lists snapshots. Diff any file against any snapshot, revert one file, or restore the whole tree.

Your real repo is never touched. This is the “oh no” button for agentic coding.

MCP Server: Give the Agent the Map

Flare runs an MCP server so your agent can query the codebase structure instead of rediscovering it. Tools include:

  • graph_overview — repo structure at a glance
  • file_info — details on one file
  • dependents / dependencies — what imports this, what this imports
  • find_path — how two files connect
  • impact_of — what breaks + which tests to run before changing files
  • verification_status — did my changes actually get checked?
  • record_intent — state the goal before editing, so the human reviewer isn’t reconstructing it

Plus task board tools (tasks_list, task_get, task_update, task_create) so agents can work from a kanban and file follow-up work they find but shouldn’t do now.

This is the “give the agent the map” philosophy we’ve covered in Graphify and Codebase Memory MCP. Flare makes it native to the IDE.

Desktop or Browser

Flare works both ways:

Desktop: npm start launches an Electron app with real terminals (xterm.js + node-pty).

Browser-served: npm run serve on a VM, dev container, or remote machine. Open the URL and you get the same IDE in your browser — graph, editor, review cockpit, and a real terminal on the remote machine. One port serves multiple projects; agents connect via /mcp/<slug> on the same port.

The review cockpit works by watching the process tree under its own terminals, so the backend has to run on the machine the agent runs on. That’s why browser mode exists — your agent runs on the VM, Flare runs there too, you review from your laptop.

How This Connects to What We’ve Covered

Flare sits at the intersection of several patterns we’ve written about:

Codebase-as-graph: Graphify and Codebase Memory MCP both argue that agents should query structure, not rediscover it. Flare’s MCP tools embody this.

Two-stage review: Superpowers mandates spec compliance review, then code quality review. Flare’s burst review with risk tiers is the same idea, automated.

Think before coding: Karpathy’s four rules include “state assumptions explicitly.” Flare’s record_intent tool forces this — the agent has to say what it’s doing before it does it.

Constraints-first architecture: AI Genie Factory argues that AI generates code, not architecture. Flare doesn’t generate code — it provides the structural constraints and oversight layer.

Agent oversight: We’ve covered OpenClaw’s approach to agent governance and Agent Safehouse for sandboxing. Flare adds IDE-level oversight to the stack.

Getting Started

git clone https://github.com/AlgoNoRhythm/Flare
cd Flare
npm install
npm run build
npm start

For remote/browser mode:

npm run serve
# Opens http://127.0.0.1:7345/?token=...

Add Flare’s MCP server to your agent:

claude mcp add --transport http flare http://127.0.0.1:7345/mcp/<slug>

The test suite is solid: 350 vitest unit tests plus 73 Playwright tests (49 driving the Electron app, 24 driving the browser).

The Bottom Line

Agentic coding tools have optimized for agent output. Flare optimizes for human oversight.

The live graph shows you blast radius at a glance. The burst review tells you what got tested and what didn’t. The shadow history lets you revert anything. And the MCP tools mean your agent starts from the map instead of spending half its context rediscovering structure.

If you’re running Claude Code, Codex, or OpenCode on anything larger than a toy project, Flare is worth trying.

Links:

Frequently Asked Questions

What is Flare IDE?

Flare is an open-source, graph-first IDE designed for agentic coding. It displays your codebase as a live dependency graph while you run AI coding agents like Claude Code, Codex, or OpenCode in an integrated terminal. As the agent edits files, the graph updates in real-time, showing you exactly what changed and what’s at risk.

How does Flare help with AI coding agent oversight?

Flare provides burst-based review that groups agent changes into logical batches and shows: what actually got tested (verified vs never checked), what the agent was trying to do (via record_intent), which files need careful review based on blast radius and complexity, and “agent smells” — patterns that indicate shortcuts like deleted assertions or skipped tests.

What is a graph-first IDE?

A graph-first IDE uses a visual dependency graph as the primary interface rather than a file tree. In Flare, you see every file as a node and every import as an edge. This lets you instantly see which files depend on each other, trace the blast radius of changes, and identify load-bearing code that touches everything.

Does Flare work with Claude Code and Codex?

Yes. Flare runs Claude Code, Codex, OpenCode, Aider, or any terminal-based coding agent in its integrated terminal. It watches the process tree to attribute changes to the correct agent and tracks which commands ran as verification steps.

What is the Flare MCP server?

Flare exposes an MCP (Model Context Protocol) server that lets AI agents query the codebase structure directly. Tools include graph_overview, file_info, dependents, dependencies, impact_of (what breaks if I change this), and record_intent (state the goal before editing). This means agents start with the map instead of spending tokens rediscovering structure.

Can Flare run in a browser?

Yes. Run npm run serve on any machine (VM, dev container, cloud workstation) and access Flare through your browser. The graph, editor, review cockpit, and terminal all work over a single websocket connection. This is ideal when your agent runs on a remote machine.

What is shadow history in Flare?

Shadow history is a hidden git repository that auto-commits every change burst without touching your real repo. You can diff any file against any snapshot, revert individual files, or restore the entire tree to a previous state. It’s an “undo everything” safety net for agentic coding.

Is Flare open source?

Yes. Flare is available on GitHub at AlgoNoRhythm/Flare. It includes 350+ unit tests and 73 Playwright end-to-end tests covering both desktop and browser modes.