Symphony Maps AI Coding Agents

Symphony is Logan Mann’s open-source control room for AI coding agents, published under the itsloganmann GitHub account. It maps edits from Claude Code, Anthropic’s coding agent, Codex, OpenAI’s coding agent, and opencode, the terminal coding agent from SST, so you can see who or what is touching a repository right now. Symphony is a live repo map for agentic coding: it turns file edits into shared situational awareness. The useful takeaway is simple: before you add heavier process, make parallel agent work visible.

Watch the repo, not the chat transcript

Symphony’s bet is that agent observability has been looking in the wrong place for many coding workflows.

A lot of LLM observability traces the agent you built: prompts, tool calls, token cost, session replay, latency, and model behavior inside your own orchestration code. That is valuable, but it does not answer the question a working repository asks at 4:37 p.m.: is another agent editing the same file as mine?

Symphony watches the repository instead. The project describes a hook-based setup where edits stream into one shared map, without instrumenting the application being edited.

That distinction is why the project landed as an interesting Show HN signal. It is not promising to make an agent smarter. It is trying to make several agents less invisible.

The trap is treating this as a replacement for review. A map can show that two agents are near the same file, but it cannot tell you whether the change is correct, secure, or aligned with your architecture.

Why the live map idea feels newly useful

The old version of this problem was two humans editing the same part of a codebase. The new version is stranger: one developer can have multiple coding agents moving in parallel, each with its own task window, local context, and confidence.

That makes file collisions feel less like a rare mistake and more like a normal failure mode. One Codex session refactors a React component. Another updates the data contract. A Claude Code session changes the test fixture. Nobody notices until Git gets grumpy.

Symphony maps that activity while it is happening. As of September 2026, the repository is small — mainly Python, MIT licensed, with 2 GitHub stars in the verified snapshot — but the idea is bigger than its current footprint.

The Hacker News interest makes sense because the project names a problem many agentic coding users already feel. The hard part is not always prompting. Sometimes it is knowing that your automation is quietly crossing streams.

The objection is also fair. A live map can become another dashboard nobody watches. The useful version has to be close to the workflow: visible during parallel edits, boring when nothing risky is happening, and easy to ignore when the repo is quiet.

Catch collisions before Git has to explain them

The cleanest mental model is a pre-merge conflict radar.

Imagine a repo with this work happening at once:

• Codex updates apps/web/src/routes/billing.tsx for a pricing experiment.
• Claude Code edits packages/api/src/billing/limits.ts to change entitlement logic.
• opencode rewrites packages/api/test/fixtures/accounts.ts for a failing test.

Git will eventually tell you when text overlaps. It will not tell you early that three agents are changing one product surface from three angles.

Symphony’s map gives you a chance to pause one session, split the task, or move an agent to tests before the changes harden into conflict. That is the practical version of agentic coding governance: not a ceremony, just timely visibility where the work is happening.

The trap is overreacting to proximity. Two agents touching nearby files is not automatically bad. A frontend and backend edit may be exactly the point. The signal is strongest when two agents edit the same file, the same generated artifact, or the same narrow domain boundary.

If you work in dense UI code, this same coordination problem shows up fast around generated tables, grids, and shared components; we covered a related angle in JavaScript Grids Built for Coding Agents.

Try it when parallel agents are real

Symphony is worth trying when you already run more than one coding agent against the same repository, or when several developers run agents locally against a shared branch family. It is less useful if your agent work is mostly single-threaded and isolated to short-lived feature branches.

A good first experiment is one busy repo, one afternoon, and one risky surface. Pick something with shared files: routing, schema migrations, test fixtures, generated clients, or design-system components.

Codex users can pair a live map with a small repository rule. Put the rule where the agent will actually read it, usually close to the code it governs.

# AGENTS.md

When changing billing, check whether another agent is editing files under:

- apps/web/src/routes/billing
- packages/api/src/billing
- packages/api/test/fixtures

If another agent is active in the same path, stop before writing and leave a short handoff note in the task summary.

Before finishing, run:

- npm test -- billing
- npm run typecheck

That is intentionally small. The point is not to build a command center. The point is to give Codex a local rule that matches the collision pattern Symphony can reveal.

The trap is writing a huge root instruction that says be careful with all files. Agents ignore vague safety posters just like humans do. A scoped AGENTS.md rule tied to a real path is much harder to miss.

Try it safely checklist

Use this when you want to test Symphony without turning the whole repository into an experiment.

• Pick one repository where parallel AI edits already happen.
• Start with non-production branches or normal feature branches, not emergency fixes.
• Choose one collision-prone path, such as migrations, shared fixtures, generated clients, or a UI component library.
• Add a short AGENTS.md boundary for that path.
• Run two agent sessions on related but separable tasks.
• Watch for same-file edits, repeated rewrites, and agents modifying generated files by hand.
• Pause one agent when the map shows overlap, then write a handoff note before resuming.
• Verify with the repo’s normal loop, such as npm test, npm run typecheck, ruff check, or the command your CI will run anyway.
• Keep it if it catches a real conflict earlier than Git or code review would have.
• Drop it if nobody looks at the map, or if your branch discipline already prevents overlap.

A small MCP boundary can help here too. MCP is a protocol for connecting AI applications to external tools and data sources. If you expose repo metadata or issue context through an MCP server, make the first version read-only unless the write path is absolutely necessary.

# MCP boundary note

The agent may read issue status, branch ownership, and file ownership metadata.
It may not update issue state, assign reviewers, or write repository files through MCP.
All code changes must happen through the normal working tree and review flow.

That keeps the live map as a visibility layer, not a second mutation channel.

Common questions

• Is Symphony an observability tool or a code review tool?

  Symphony is closer to observability than code review. It shows live edit activity across coding agents, but it does not judge whether the resulting code is correct. Treat it as an early-warning layer before review, tests, and CI do the deeper verification work.

• Does Symphony replace merge conflict prevention in Git?

  No, Symphony does not replace Git. Git detects conflicts when changes meet; Symphony tries to show risky overlap while edits are still happening. The useful number is not stars or dashboards, but how many same-file collisions it helps you catch before a branch is ready for review.

• When is Symphony overkill?

  Symphony is overkill when one developer runs one agent on one isolated task at a time. It starts to make sense when multiple agents touch shared code, generated artifacts, schemas, fixtures, or design-system files. If your team already avoids overlap through small branches, the map may add little.

• What should Codex users pair with Symphony first?

  Pair Symphony with scoped AGENTS.md instructions and a boring verification loop. For example, add a path-specific collision rule and require npm test -- billing plus npm run typecheck before handoff. The map shows overlap; the commands prove the repo still works.

• Can this work with Codex and other coding agents?

  The Symphony README names Claude Code, Codex, and opencode as target agents. Codex, Anysphere’s AI code editor, has its own agent workflow, and the same file-collision problem applies when edits are written to the working tree. Check the project’s current hook support before assuming every editor is covered.

Best ways to use this research

• Best for: Developers running parallel coding agents in one repository and wondering where collisions actually happen.
• Best first artifact: A scoped AGENTS.md rule for one risky path, plus the exact test and typecheck commands required before handoff.
• Best comparison angle: Compare live repo maps with LLM trace tools. One explains what an agent did internally; the other shows where edits are landing in shared code.
• Best failure signal: Same-file edits, hand-edited generated files, and repeated rewrites in fixtures or schemas are stronger signals than broad activity across unrelated paths.

Further reading

• symphony — source
• Codex — Agent
• Model Context Protocol — specification
• OpenAI Codex — documentation

Next step

Try Symphony on one collision-prone path before you try it everywhere. If it catches one conflict before review, keep the map close to the agents that create the risk.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.