When one developer runs a dozen coding agents, the scarce thing is no longer typing speed but attention. Our bet is that by 2030 a normal day means directing a planner, several implementers in separate worktrees, a reviewer and a docs agent, while people keep the judgement, taste, accountability and final review. That day needs tools that show every agent at once, group them by repo and worktree, let you search and link them, fork side questions away, and pair with other people's agents. Today this is early, and Synapse's canvas and Mac app are one first attempt.
Where we are today
Today many developers already run more than one agent. A Claude Code session implements a feature while a Codex session reviews it. Someone starts a third agent in another worktree to chase a flaky test. Tools like worktree managers and agent workspaces exist because people kept doing this by hand.
What has not caught up is the developer's own position. Most setups still assume one person, one agent, one terminal. With three agents you can keep it in your head. With a dozen you cannot, and the failures are dull: an agent waits for an answer for an hour because you did not see its question, two agents make opposite decisions about the same interface, a reviewer reviews code that was already rewritten.
Our view is that the bottleneck has moved. It used to be producing code. It is becoming directing work, reviewing it and deciding where to look next.
A plausible day in 2030
This section is speculation. It is the day we are building toward, described as concretely as we can.
08:30. Planning. The developer opens the team's issue for the week: move invoice generation off a nightly batch and onto events. They talk it through with a planner agent, which reads the code, lists the services involved and proposes four pieces of work: a new event schema, a producer in the orders service, a consumer in billing, and a backfill script. The developer cuts the backfill (the data team owns that) and asks for a rollback plan instead.
09:15. Fan out. Each remaining piece gets its own worktree and its own implementer agent. One is Claude Code, one is Codex, one is whichever agent the team prefers for that language. A reviewer agent is linked to all three and reads what they are doing as they go. A docs agent follows the schema work, because the schema is the part other teams will consume.
10:40. The first real decision. The producer agent and the consumer agent disagree about whether an invoice event carries the full line items or just an ID. Both have reasons. Neither has the authority to choose. The developer looks at both sessions side by side, picks the ID plus a version field, and tells both. This takes five minutes and is the most important thing that happens all morning.
11:30. A side question. The developer wonders whether the old batch job has a retry behaviour that someone depends on. Asking the consumer agent directly would fill its context with an unrelated investigation. So they fork the session, ask the question in the fork, get the answer, and send a two-line summary back. The main session never sees the detour.
14:00. Another team's agent. The consumer needs to know how the payments team plans to version their own events. A colleague on that team has an agent that has been working on exactly that. The developer's agent sends a request, the colleague approves sharing that one session, and the consumer reads the plan instead of guessing.
16:00. Review. The reviewer agent has flagged eleven things. The developer reads the diff for the schema closely, skims the consumer, and rejects one of the reviewer's suggestions because it would make a later migration harder. They merge the schema and leave the rest for tomorrow.
Notice what the developer did all day: chose scope, settled a disagreement, decided what not to build, read the riskiest code carefully, and said no to a plausible suggestion. They typed very little code.
Where people stay essential
We do not think the developer becomes a manager who only approves things. The opposite: the parts left to people are the hardest parts.
- Judgement. Choosing between two reasonable designs, given things agents may not know: what the business will ask for next year, which team is short of people, which customer is fragile.
- Taste. Knowing when an API is ugly, when an abstraction is premature, when a test suite tests the wrong thing. Agents can produce many options. Picking well is still a human skill.
- Accountability. Someone has to own the outage. A team can delegate the typing, but it cannot delegate being responsible for what ships.
- Review. Reading code you did not write was always part of the job. Now it is a larger part of it, and doing it well across many agents is a real skill.
- Talking to other people. Most hard problems in a company are agreements between teams. Agents can carry context between those teams, but people still make the agreement.
What that day needs from tools
Walk back through the day and list what the developer actually relied on. Our bet is that every serious setup will need these, whoever builds them:
| Need | Why it matters in the day above |
|---|---|
| See every agent at once | Spot the agent that has been waiting, and the two that are working on the same thing |
| Frames per repo and worktree | A dozen agents only make sense grouped by where they work |
| Search | Jump to "the consumer agent" without remembering which terminal it is in |
| Links between agents | The reviewer reads implementers as they go, the docs agent follows the schema |
| Forks for side questions | Answer a detour without polluting the main session's context |
| Pairing across people | Read a colleague's relevant session after they approve it |
| Diff review and PR flow | The day ends in review and merge |
| Push and wake-up | An idle agent should notice a message without the developer prompting it |
Some of this exists in different tools today. Worktree managers and agent workspaces handle running agents in parallel, and some already have mature diff and PR flows. The connective parts, seeing everything, linking, forking and pairing across people, are newer.
One early take: Synapse
Synapse is what we build, so read this section with that in mind. It started from the connective column of that table.
The open-source core puts every live coding agent on your machine on one canvas, grouped by git repo in labelled frames. Working agents pulse and idle ones breathe, which turns out to be a quick way to see who is stuck. You drag a link from one agent to another and the second gets the first's recent conversation on every prompt. Linked agents can message each other across CLIs, Claude Code to Codex included. ⌘F does fuzzy search across agents.
The Synapse Mac app is newer and earlier. It puts workspaces, worktrees, real agent terminals, forks and the canvas in one window, and on the canvas each worktree is framed inside its repo's frame. Forks are started with /sfork <question> or ⇧⌘F and stack on their parent, so a side question never enters the main context. Today forks work for Claude Code and Codex only. Requests let your agent ask a trusted colleague for read-only access to agents they choose.
Plenty is missing. Synapse has no diff review UI and no PR creation, so it runs alongside tools that do. Messages are pulled, so an idle agent does not wake on a message, though push delivery is planned. It is macOS first, and the project was started in October 2026. It is a first attempt at the tooling that day needs, not the finished version.
FAQ
Will developers stop writing code by 2030?
We do not think so. Our bet is that they write less of it by hand and spend more time planning, deciding between options and reviewing. Writing code by hand will still be the fastest way to settle some questions, and good review needs people who can write it.
How many agents can one developer actually manage?
We do not have a number, and we are wary of anyone who does. The limit is attention, not tooling alone. It depends on how independent the tasks are, how much review they need, and how well the tools surface which agent needs you.
What is the most important skill for a developer working with many agents?
Review, closely followed by scoping. Breaking work into pieces that agents can do in parallel, and reading their output critically, are what make many agents useful rather than noisy.
Does Synapse run the agents itself?
The open-source core does not: it finds agents wherever they already run and connects them. The newer Synapse Mac app can also start agents in real terminals inside workspaces and worktrees. Either way, Synapse has no diff review or PR flow, so most people pair it with their existing tools.