Symphony Maps AI Coding Agents

By Rogier Muller09.11.26

Symphony is Logan Mann’s open-source control room for AI coding agents, published under the itsloganmann GitHub account. It is unrelated to OpenAI's own open-source Symphony agent orchestrator, which shares the name. It maps edits from Claude Code Codex 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. 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.

Don't treat 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 a handful of GitHub stars, 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.

Watch for 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.

Don't write 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.

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.