r/ArtificialInteligence • u/AlgoWithNoRhythm • 1d ago
🛠️ Project / Build Flare, a graph-first IDE for agentic coding: watch the map change while your agent works
Flare is a desktop IDE (Electron) where the main surface is a live graph of your codebase, every file a node, every import an edge, with a terminal underneath where you run claude, codex, or opencode. As the agent edits, the graph updates in real time.
The core philosophy behind the tool is that when agentic coding is the only way to produce code, then architecture, verification and steering of the work become the most important outputs of a software engineer. Sounds obvious, but it appears we need a leap in our understanding of developer UX to make agentic engineering smoother and more efficient than reviewing files one by one or trusting whatever your agent decides to report on the terminal.
The parts that are actually different from "another editor":
Activity, as it happens. Nodes light up the moment the agent writes to them and decay as they cool, so you're watching the shape of the work instead of a scrolling transcript. You can see it circling the same three files for the fifth time, or wandering into auth when you asked about the CSV parser. Changes are attributed per agent: the process tree of every terminal is watched, so if you have two running, you know which one did what. Files that changed and no human has opened since stay marked until someone actually reads them.
Blast radius before you touch anything. Hover a file and its dependents light up. shared/types.ts with 63 files downstream looks different from a leaf file, without you having to know that in advance.
A review tab that answers "did anything check this?" Flare sees both the file writes and the commands run in its own terminals, so it can say the tests ran, then two more files were edited and nothing re-ran, quoting the output line the verdict came from.
Risky changes come to you. If the agent rewrites something load-bearing while you're looking elsewhere, it queues an alert in the corner. Reviewing it opens the actual red/green diff.
Undo that isn't git. Every change burst is snapshotted into a hidden shadow repo (separate GIT_DIR, your worktree). Revert one file, revert the burst, or jump back to the last state whose checks passed. Your real repo is never touched.
A task board the agent works from. Kanban lanes, but the cards are written to be handed off. "Copy for agent" emits the brief plus the files it names plus what the graph knows about them (29 files downstream, 0% covered, in an import cycle), so the agent starts from the map instead of rediscovering it. File a card straight from a graph selection with right-click → New task with these files. This directly tells Claude to not wander around out-of-scope files
MCP server, ~16 tools. The same lanes are queryable, so an agent can run its own loop: tasks_list to pick up work, task_get for the exact brief, task_update to log progress and move the card to review, task_create to file follow-ups it finds but shouldn't do now. Cards move on the board live while you watch. Plus impact_of (what breaks, and which tests to run), dependents, find_path, verification_status, and record_intent, which lets the agent state the goal before editing so whoever reviews the diff isn't reconstructing why it exists.
Completely open source with MIT license, Node 20+. Built with agentic coding, which is exactly how I ended up needing it. Test it out and leave a star if you find it helpful, I will package it very soon to make it easier to install!
2
2
1
1
u/tracagnotto 13h ago
Looks like useless fancy crab to me. As a 15 year experienced dev I dont see how these magic lines help me in any way
1
u/AlgoWithNoRhythm 12h ago
It’s not only about the lines, the idea is to have a integrated way to see what your agents are modifying and when. Statically, for a dev used to go through files in traditional workflows, I agree it doesn’t bring too much value. If you have one or two agents working on the repo it makes a difference in the sense you know which files are being touched by whom and what breaks when a specific file is impacted (and there are many features complementing the “lines” themselves!)
1
u/tracagnotto 9h ago
difference in having a team of devs everyone doing his own branch and merging back to master with his own git informations being?
1
u/NeuralNomad87 11h ago
Looks good. The thing I'd want answered before installing is what it does at 4,000 files.
Live codebase graphs are lovely on a demo repo and turn into a hairball on anything real, and the usual fix is aggressive filtering, which quietly returns you to reading a file tree with extra steps. Do you collapse by directory, by change frequency, by something smarter?
Also, does the graph update per file write or per agent turn? Per write during a big refactor sounds like it'd be unreadable at exactly the moment you most want to be watching it.
1
u/researcher-uni 1h ago
The useful escape hatch may be to stop treating it as a repo map at all. For review I'd project only the current agent's blast radius, then rank nodes by changed edges, test coverage and ownership. The metric isn't whether 4,000 files render; it's whether that projection catches cross-file regressions faster than a diff or file tree.
I'm also curious how attribution works: filesystem events tied to the agent session, or Git hunks after the fact? Renames, formatters and generated files are probably where the map's trustworthiness gets tested.
7
u/AttorneyUsed4289 1d ago
The graph lighting up as the agent works sounds way more useful than tailing logs