From developer to agent orchestrator: the job is moving, not ending
The debate asks the wrong question. Not 'will AI replace developers' but 'what is a developer when writing code stops being the main activity'. A field account from someone running agent fleets in production, plus the part nobody's pricing in: agents are recreating the org chart, and a new layer of the internet underneath it.
tsukumo
Last week I watched four agents deadlock.
One was waiting on a piece of information a second agent was supposed to produce. The second was blocked on a result from a third. The fourth had been handed the job of working out why the first three were stuck, and was busy reading their logs. Nothing was on fire. Nothing had crashed. The system was just sitting there, politely waiting on itself.
I stared at it for a minute before the obvious landed: that looked a lot like a sprint. Not a bug, not a model failure. A standup where everyone is blocked on someone else and the manager is reading tickets to find out why. I had built, without meaning to, a small dysfunctional organization out of software.
That moment is the whole article, so let me unpack what it told me.
I'm not writing this as a forecast. We run a fleet of agents in production, and I spend more of my day directing and reviewing them than writing code myself. What follows is the field, not the brochure.
For fifty years, a developer's value was the ability to write code#
Every generation of this job has been a story about giving up writing something by hand.
The assembly programmer stopped writing raw machine codes and started expressing logic. The next generation stopped tracking registers and memory by hand and started thinking in algorithms. Frameworks took the plumbing. The cloud took the racking of servers. Infrastructure as code took manual ops and turned it into a file you declare. Each step, someone insisted the craft was dying. Each step, the craft moved up a level, and the people who moved up with it came out ahead of the ones who clung to the old one.
The ladder we've been climbing the whole time
Era
What you stopped doing by hand
What became the actual skill
Assembly
Writing machine codes
Expressing logic
High-level languages
Tracking registers and memory
Algorithms and structure
Frameworks
Plumbing and boilerplate
Composing systems
Cloud
Racking and wiring servers
Designing for scale
Infrastructure as code
Manual, click-by-click ops
Declaring the system
Copilots
Some of the keystrokes
Describing intent precisely
Agents
The implementation itself
Directing and verifying the work
Read that bottom row slowly, because it's different in kind. Every prior step automated a layer beneath writing code. Agents automate writing the code. For the first time, the thing being abstracted away is the activity the whole profession organized itself around. That's why this one feels existential when the others felt like tooling.
What changes when code stops being the main activity#
The shape of the work changes in three moves.
It used to be human → code: you held the whole thing in your head and typed it out. Then it became human → prompt → code: you described a piece and a model drafted it, and you were still in every loop, accepting line by line. Now, increasingly, it's human → objective → agents → code: you set a goal and a boundary, hand it to agents that read the repo, plan, write, test, and open a PR, and you step in to direct and verify.
The center of gravity moves from producing the code to deciding what should be built and checking that what came back is right. Generation gets cheap. Being sure stops being cheap. And the moment you're running more than one agent, a new problem shows up that has nothing to do with how good the model is.
Agents recreate every problem a human org already has#
Here is the part that surprised me, and the part most "AI will/won't replace you" takes miss entirely: the hard problems in a fleet are not intelligence problems. They're coordination problems. The exact ones every engineering organization has been fighting for decades.
The failures aren't new, the substrate is
The failure
In a human team
In an agent fleet
Information silo
The answer lives in one person's head
Each agent reads a different, stale file
Dependency stall
You wait on another team's ticket
Agent B blocks on agent A's output
Context lost in handoff
The spec degrades through three people
The task degrades through three prompts
Escalation
"Who actually owns this?"
A fourth agent reading logs to find the deadlock
Bottleneck
One reviewer for everything
One human gate the whole fleet funnels through
Conway's Law said that systems end up shaped like the organization that builds them. Run a fleet for a week and you watch a sharper version: the system becomes an organization, with all the politics of one, minus the coffee. The silos, the stalls, the lossy handoffs, the bottleneck at the one reviewer. None of it is fixed by a smarter model. It's fixed by coordination: shared memory so agents stop re-deriving each other's work, explicit contracts so a handoff doesn't degrade, a real source of truth so everyone reads the current answer instead of guessing.
If you're not writing most of the code, what are you doing all day? Concretely, this:
Setting objectives an agent can't misread. The first failure is almost always an ambiguous goal, not a weak model.
Governance and contracts. Who is allowed to do what, and how agents hand work to each other. Protocols like MCP exist precisely because "agent talks to tool" needs a contract, not a vibe.
Managing context. Making sure each agent reads the current truth, cheaply. On our own fleet about 60% of the tokens on a documentation lookup go to re-finding which doc is current before any real work happens; fixing that is most of the battle, and it's a real number, not a slogan.
Verification. Reading diffs you didn't write, for the things agents get wrong: confident code that solves the wrong problem, an edit to the wrong file, a test that passes for the wrong reason.
Observability and risk. You can't operate what you can't see. If you don't know what the fleet did overnight, you're not running it, you're hoping.
These are not new skills exactly. They're the skills of a good staff engineer or an EM, applied to a system that behaves like a team. What's new is that they're now the whole job rather than the part you did between commits. The person who can describe intent precisely, design the controls, and verify output at the right altitude is worth more than the person who types fastest. That inversion is already underway. I've described the role itself in more depth in what agentic operators actually do.
We're quietly building a new layer of the internet#
Step back from your own repo for a second, because the bigger thing is easy to miss from inside it.
Once agents don't just generate text for a human to read but produce work for other agents to consume, you get something new: an ecosystem where software writes, reviews, requests, and passes information to other software, mostly without a person in the loop for any single exchange. The "Dead Internet" idea, that more and more of the network is machines talking to machines, gets used as a doom meme. Strip the doom and it's just an accurate description of where the plumbing is going. The interesting question isn't whether it happens. It's who designs it, and how accountable it is.
That's the part that should occupy a CTO. Not "will my developers have jobs," but "we are about to operate systems where most of the activity is agents transacting with agents, and almost nobody is building the governance, the observability, or the source-of-truth layer that keeps those systems honest." The risk in a machines-talking-to-machines layer isn't the machines. It's the absence of the boring infrastructure, contracts, audit trails, a canonical truth, that we already know human organizations fall apart without. We're going to rebuild all of it, one layer up, for agents. The teams that start now will own the operating layer of that internet. The teams that wait will rent it.
Engineers stopped doing arithmetic by hand a long time ago. Nobody mourns the slide rule, and nobody thinks the engineer was replaced by the calculator. The engineer moved up: to deciding what to compute, modeling the problem, and judging whether the answer is sane.
Developers are at the same hinge. We will, gradually, stop writing most of the code ourselves. The value won't be in the typing. It'll be in the ability to orchestrate systems that produce the code, and to stay accountable for what they produce. The craft doesn't die. It relocates, to a level where judgment, design, and verification are the entire job.
If your agents produced 90% of your code tomorrow, what would your team's added value actually be? If the honest answer is "writing the other 10%," you have time, but not as much as you think. If it's "deciding what to build and making sure the machines built it right," you're already an orchestrator. Worth knowing which, before the question is rhetorical.
A field account of a fleet in production, the failures included.
Common questions
Does 'agent orchestrator' just mean fewer developers?
No. It means the same engineers operating at a higher level of abstraction, the way cloud didn't shrink ops teams so much as change what they do. The work that disappears is the typing; the work that grows is judgment, verification, and system design, which is more of your senior engineers' time, not less of them.
Isn't this just a rebrand of 'senior engineer'?
It overlaps, but the failure modes are new. A senior engineer reviewing juniors doesn't deal with five agents deadlocking on each other's output, context that degrades through a chain of prompts, or a fleet that silently optimizes for the wrong goal. Orchestration is senior judgment applied to a system that behaves like an organization, not a person.
What's model collapse, and why should an orchestrator care?
Model collapse is what happens when models increasingly train on, or work from, the output of other models instead of ground truth, and quality quietly degrades. In a fleet, the everyday version is agents consuming other agents' summaries until the original facts blur. Keeping a canonical source of truth in the loop is how you stop it.
How is this different from just giving everyone Copilot?
Copilot keeps the developer writing every line with faster suggestions. Orchestration is agents owning whole tasks while the human directs and reviews. Same starting tools, a different operating model. We wrote the long version of that distinction in the copilot-operator gap.