When Every Engineer Is a Manager

Every new engineering manager experiences what I call The Backseat Driver moment. You know the feeling: someone else is driving, and you…

---

When Every Engineer Is a Manager

Hershey, Pa

Every new engineering manager experiences what I call The Backseat Driver moment. You know the feeling: someone else is driving, and you instinctively press an imaginary brake pedal. You spot the turn they should take, your body reacts before your mind does, but you’re not in control anymore. Management feels the same. When someone describes a bug, your fingers itch for the keyboard, and your mind starts working on the fix. Then you realize that’s no longer your job. Now, you’re a manager.

I’ve written about that transition before. But I didn’t expect to write about the reverse.

It’s 2026, and your engineers, the ones who chose to stay individual contributors and said, “I don’t want to manage people”, are now managing teams. Not teams of people, but teams of AI agents. And the skills they need for this job look a lot like management skills.

The Sixteen-Agent Compiler

Earlier this year, a developer at Anthropic tasked sixteen Claude agents with building a C compiler from scratch. Not a toy compiler. A real one, capable of compiling the Linux kernel. The project ran across nearly two thousand sessions, cost about twenty thousand dollars in API time, and produced over a hundred thousand lines of Rust.

One person. Sixteen agents. A hundred thousand lines.

Take a moment to think about that. The impressive part isn’t just the output, but what the developer was actually doing during those two thousand sessions. They weren’t writing Rust code. Instead, they broke down problems, reviewed results, and resolved conflicts between agents that made different assumptions about type systems. They sorted tasks, set priorities, and decided when to let an agent continue or when to step in and redirect.

They were managing.

What Multi-Agent Actually Looks Like

If you haven’t seen it yet, here’s the shape of things. Tools like Claude Code now support what the industry is calling “agent teams”, multiple AI instances, each with its own context window, working in parallel on different parts of a problem. VS Code 1.109 shipped with multi-agent orchestration as a first-class feature. Microsoft called it “the home for multi-agent development.” This isn’t experimental anymore.

The basic workflow: you describe a large task. The system spins up several agents, each assigned a piece. One might be refactoring the authentication module. Another is writing tests for the payments service. A third is migrating the database schema. They work simultaneously, in separate context windows, and report back to a coordinator, which, increasingly, is you.

Here’s another way to look at it. For the past few years (or months), engineers worked with AI one-on-one, just you and Copilot, or you and ChatGPT. It was a conversation. Now, it’s one-to-many. You’re working with a team. The relationship has shifted from having a dialogue to delegating tasks.

And as anyone who has managed people will tell you, delegation is a different skill from doing the work yourself.

The Cursor Lesson

Cursor, the AI-powered code editor, learned this the hard way. When they first tried multi-agent systems, they gave all agents equal status and used file-level locking to prevent conflicts. Agent A is editing auth.js? Agent B has to wait. Simple, right?

It didn’t work. Agents held onto locks for too long, so twenty agents ended up working as slowly as two or three. Adding more agents actually reduced productivity. If this sounds familiar, it’s because it’s Brooks’ Law in action—not with people, but with machines.

Their second attempt used optimistic concurrency; let everyone work freely and resolve conflicts later. Also a disaster. Agents became risk-averse. They avoided hard tasks that might touch shared files. The system gravitated toward trivial, safe changes while the difficult work sat untouched.

What finally worked was a role-based architecture with three types of agents: Planners that continuously explore the codebase and create tasks. Workers that execute assigned tasks independently and push changes when done. And Judges that evaluate the output at each cycle and decide whether to continue.

Planner, Worker, Judge. If you look closely, that’s similar to a tech lead, an engineering team, and a code reviewer. When left to coordinate on their own, the machines ended up recreating the organizational chart.

n(n-1)/2 Strikes Again

There’s a formula that every engineering manager should know: n(n-1)/2. It calculates the number of communication lines in a team of n people. Two people have one line of communication. Five people have ten. Ten people have forty-five. It’s the mathematical reason small teams outperform large ones; every person you add doesn’t just add work capacity, they add communication overhead that grows quadratically.

What no one expected is that this formula also applies to agents.

An engineer orchestrating five agents doesn’t just have five tools. They have five entities that can make conflicting assumptions, write incompatible code, and step on each other’s work. That’s 5(4)/2 = 10 potential conflict lines between agents, plus 5 lines between the human and each agent. Fifteen total communication channels for one person to manage.

Add the human’s regular communication lines, their manager, their teammates, their product owner, and a single engineer orchestrating five agents has the communication complexity of a traditional eight-person team. Except they’re the only human in the room.

This explains why Cursor’s locking approach didn’t work. It was a blunt attempt to reduce n(n-1)/2 to zero by stopping all communication between agents. But that also stopped parallel work. The approach that succeeded, using Planners, Workers, and Judges, focused on structuring communication instead of removing it. The same idea applies to human teams: you don’t get rid of communication, you design it carefully.

Everything You Know About Agile Is Wrong (Again)

Let’s be precise about what multi-agent engineering breaks. Not in a hand-wavy “things are changing” way, but in a concrete, assumption-by-assumption way. Because Agile wasn’t built wrong. It was built for a world that no longer exists.

The Sprint Is a Human Construct

The two-week sprint exists because of human cognitive cycles. People need a rhythm. They need a planning horizon short enough to feel concrete and long enough to ship something meaningful. The sprint boundary gives teams a moment to breathe, reflect, and recalibrate.

Agents don’t need any of that. They don’t get tired on Thursday afternoon. They don’t lose focus after a long meeting. They don’t need a Friday retro to process their feelings about the last two weeks. An agent that finishes its task at 3 AM on a Tuesday starts the next task at 3:01 AM.

So what’s the purpose of a sprint in a multi-agent world? It’s for the humans. The sprint becomes a review checkpoint, a time when the human orchestrator stops the process, checks what the agents have produced, makes decisions about quality and direction, and plans the next round of delegation. The sprint is no longer about production; it’s about verification.

Velocity Is Meaningless

Story points were created to measure human throughput, as a rough estimate of how much mental work a team could handle in a sprint. But now, one engineer can launch five agents and finish in a morning what used to take a whole sprint. So, the idea of velocity doesn’t make sense anymore. It’s like trying to measure a car’s speed in footsteps per hour.

But the problem is deeper than just the numbers being wrong. Velocity was a planning tool. You’d look at the last three sprints, see that the team averages 40 points, and plan the next sprint around that number. With agents, throughput is elastic. An engineer might complete 200 “points” of work in a sprint where they orchestrate well, and the tasks decompose cleanly. In the next sprint, they might complete 30 because the work involved tightly coupled components that agents kept stepping on each other to modify. Velocity becomes so variable it’s useless for prediction.

What replaces it? I think the answer is decomposition quality metrics. How many agent tasks were completed without human intervention? What percentage of agent output passed review on the first pass? How often did agents produce conflicting work that required manual resolution? These measure the skill that actually matters: the engineer’s ability to set agents up for success.

User Stories Were Written for Humans

“As a user, I want to reset my password so that I can regain access to my account.” That’s a good user story. It gives a human developer enough context to make informed decisions about implementation. A good engineer reads that and knows they need a reset flow, an email service, a token system, and an expiration policy.

An agent reads that and has questions. Lots of them. What email provider? What token format? Where does the token get stored? What’s the expiration window? Does the old password get invalidated immediately, or only after a successful reset? What happens if the user requests two resets? What error states need handling?

User stories were effective because human developers used their context, experience, and judgment to fill in the blanks. Agents don’t have that ability. They might guess the answers or create something technically correct but wrong for the system’s design. The user story format, which is intentionally vague and focuses on what to build instead of how, is not detailed enough for delegating to agents.

This is why spec-driven development isn’t a nice-to-have in the multi-agent world. It’s the replacement for user stories. A spec doesn’t say “as a user, I want to reset my password.” A spec says: here’s the API contract, here’s the data flow, here’s the state machine, here are the error cases, and here are the architectural constraints your implementation must respect. That’s what agents need. Not a story. A blueprint.

Sprint Planning Becomes Systems Design

The old sprint planning question was: “How many story points can this team handle?” The new question is: “How should we decompose this work so that agents can execute it in parallel without stepping on each other?”

That’s not planning. That’s systems design. You’re looking at a feature and asking: What are the independent components? Where are the interfaces between them? What contracts need to be agreed upon before any agent starts work? Which pieces have shared dependencies that will create conflicts if worked on simultaneously?

Poor decomposition is the new version of poor planning. If you split a feature into five agent tasks and three of them work on the same database migration, you’ll end up with three conflicting migration files and a bigger mess than if a human had done it alone. Good decomposition means finding the natural divisions in the work, where you can set clear boundaries and well-defined interfaces.

Sprint planning, in the multi-agent world, starts to look more like an architecture review than a task assignment. And the engineer who’s best at decomposition, who can look at a feature and instantly see the parallel execution plan, becomes the most valuable person on the team.

Standups Are Asking the Wrong Questions

“What did you do yesterday?” doesn’t capture the right information when an engineer’s work is orchestrating six agents across four different features. Yesterday, they reviewed fourteen pull requests, resolved three merge conflicts between agent outputs, rejected two implementations that were technically correct but architecturally inconsistent, and made a judgment call to restart an agent from scratch because it had gone down a rabbit hole.

Traditional standups don’t capture any of that. Standups were meant to highlight blockers and keep individual contributors accountable for their own tasks. In the multi-agent world, the engineer becomes the blocker—they are the review bottleneck, the decision-maker, and the quality gate. The important questions now are: What decisions did you make? What did you reject and why? Where do you see patterns in agent failures? Which decompositions worked well and which didn’t?

The standup becomes a decision review, not an activity report.

Estimation Is Dead. Long Live Decomposition.

“How long will this take?” is a question about human effort. With agents, the production time is almost irrelevant; an agent can write a service in minutes. The real-time cost is in review, integration, and iteration. And that time is almost entirely a function of decomposition quality.

A well-decomposed task, clear boundaries, explicit interfaces, no shared state, runs cleanly in parallel, and produces output that integrates smoothly. An engineer might review and ship it in an hour. A badly decomposed task creates conflicts, requires multiple rounds of revision, and might take longer to untangle than it would have taken to write manually.

Estimation doesn’t go away; it changes. Instead of guessing how much effort something will take, you now estimate how complex the integration will be. How connected are these components? How likely are agents to make conflicting choices? How much extra review will this decomposition require? The skill of estimation is now about breaking down problems effectively.

Retrospectives Need a New Focus

“What went well? What didn’t? What should we change?” The retro format still works. But the content is completely different.

Old retro topics: communication gaps, unclear requirements, testing bottlenecks, deployment issues. New retro topics: Which decomposition patterns led to clean agent output? Which patterns created integration nightmares? Are our specs detailed enough, or are agents filling in too many gaps on their own? Where did we waste time reviewing agent work that should have been caught by automated checks? Are we burning out our reviewers?

The retrospective turns into a bigger conversation about how well we orchestrate. It’s no longer about “how do we work better as a team of humans,” but instead, “how do we work better as people managing teams of agents.” It’s really management training, just wrapped in a sprint ceremony.

Specs Are the Management Layer

There’s a movement gaining traction called spec-driven development, the idea that specifications, not code, should be the source of truth. Tools like GitHub’s spec-kit and AWS Kiro have built entire workflows around this: specify intent, plan implementation, and generate tasks.

In a world with just one agent, specs are a good habit. In a multi-agent world, specs are essential; they’re the foundation everything runs on.

Think about what happens when you send five agents to work on a feature without a spec. Agent A makes an assumption about the API contract. Agent B makes a different assumption. Agent C builds a UI that expects data in a shape that neither A nor B produces. You’ve created a three-way merge conflict that isn’t a merge conflict; it’s a design conflict. And design conflicts can’t be resolved by Git. They require a human to look at the whole picture and make a judgment call.

A spec stops this from happening. When you write a specification that spells out the API contract, data formats, expected behaviors, and architectural rules, you’re not just recording your intentions; you’re managing your agents. The spec is like the team lead’s design document that everyone reads before coding. But now, “everyone” means a group of AI agents.

Kiro’s structure and requirements.md, design.md, and tasks.md, start to look less like a developer workflow and more like a management protocol. The requirements define what success looks like. The design defines the constraints agents must operate within. The tasks define the parallelizable units of work. That’s not a development methodology. That’s a delegation framework.

The Review Bottleneck

Here’s the uncomfortable data. If five agents can produce in a day what a team of engineers produced in a sprint, someone still has to review all of it. And that someone is human.

The review bottleneck is the fundamental constraint of the multi-agent era. It’s the new rate limiter. Not how fast you can produce code, but how fast you can verify that the code is correct, secure, maintainable, and aligned with the system’s architecture.

This is why the Cursor team landed on the Judge role. You need agents whose job is not to produce code but to evaluate it. Quality agents. Review agents. Agents that run the tests, check for security vulnerabilities, verify architectural consistency, and flag anything that doesn’t match the spec. The human engineer becomes the final reviewer, the appeals court, not the beat cop.

But even with Judge agents, the human is still the final quality check. Agents can check syntax, find bugs, and enforce patterns. But they can’t ask, “Is this the right thing to build?” Answering that takes understanding the customer, the business, the team, and what’s ahead. It takes real human judgment.

The Intern Analogy, Scaled

I like to think of AI as a brilliant intern. Smart, fast, eager to help, but lacking the context and judgment that come from experience. You wouldn’t let an intern make architectural decisions. You wouldn’t let an intern deploy to production unsupervised. But you’d let an intern write code, run tests, and research solutions, as long as you reviewed their work.

Multi-agent orchestration is the intern analogy at scale. You’re no longer managing one intern. You’re managing a cohort. Five interns. Ten interns. Each working on a different part of the project, each producing work that needs to be reviewed, each capable of making mistakes that compound when combined with the mistakes of the others.

Here’s the key point: managing a group of interns is very different from managing just one. With one intern, you can review everything they do. With ten, you need systems and processes. You need clear specs from the start so they don’t go off in different directions. You need regular check-ins instead of constant supervision. You have to spend time on delegation and documentation instead of doing the work yourself.

You need, in other words, management skills.

What This Means for the Manager’s Manager

If you’re an engineering manager reading this, you might be thinking: “Great, so my engineers are all becoming managers. What does that mean for me?”

It means your job is changing too.

When your engineers wrote code, you managed the people who created the software. Now, as your engineers orchestrate agents, you’re managing people who manage teams. In effect, you’re a skip-level manager, and that calls for a different approach.

You can’t evaluate output by counting lines anymore. An engineer orchestrating five agents might produce ten thousand lines in a day. That number tells you nothing about whether the work is good, whether the decomposition was clean, or whether the agent outputs were properly integrated. You need to evaluate decision quality, not production quantity.

One-on-ones shift from “what are you working on” to “how are you orchestrating.” The interesting questions become: How did you decompose that feature? Why did you assign it to three agents instead of five? Where did you have to intervene? What patterns are you seeing in agent failures? These are the same questions a VP asks a director. They’re strategic, not tactical.

Team sizing becomes complicated. If each engineer manages a group of agents, a team of five engineers could produce as much as a traditional team of twenty-five. But the coordination effort between those five people stays the same. There are still 5(4)/2 = 10 lines of communication between humans. Now, the n(n-1)/2 formula applies both to the human team and the agent team. It’s like managing a fractal.

Hiring criteria flip. You’re no longer hiring for coding speed; agents handle that. You’re hiring for decomposition skill, review quality, specification clarity, and judgment under ambiguity. In other words, you’re hiring for the skills we used to call “senior” or “staff”, the skills that are about directing work, not doing it.

The New Agile

So if sprints, velocity, stories, estimation, standups, and CI all need rethinking, what replaces them? I don’t think anyone has the complete answer yet. But here’s what I’m seeing work, and more importantly, why it works.

Spec sprints replace code sprints. Now, the main unit of work is the specification, not the user story. The goal of a sprint is to create clear, reviewed specs that agents can use. Coding happens between sprints or all the time, since agents don’t need breaks. The sprint boundary shifts from “how much can we build” to “how much can we design and check.” This might sound like waterfall, but it isn’t, because the specs are small, iterative, and updated based on what agents produce. It’s more like architectural TDD: you write the spec (the test), agents write the code (the implementation), you check the output, and then you repeat.

Decision logs replace standups. Instead of what-I-did-yesterday, engineers maintain decision journals. What did I delegate? What did I review? Where did I override an agent’s output? What conflicts did I resolve? What decomposition approach did I try, and did it work? This gives managers visibility into the quality of orchestration, not just the fact of it. A good decision log is also a training document; other engineers can learn from your orchestration patterns the same way they used to learn from your code.

Review velocity replaces development velocity. The metric that matters is how quickly a team can verify and ship agent-produced work to a quality standard. This is where the bottleneck is, so this is what you measure. Not story points completed, review cycles completed. Not lines of code written, lines of code verified. A team that reviews faster, without sacrificing quality, ships faster. Everything else is noise.

Architecture reviews become the heartbeat. In the old world, architecture reviews happened before big projects. In the multi-agent world, they happen constantly because every decomposition decision is an architecture decision. How you break a feature into agent-sized tasks determines whether the agents produce coherent output or a mess of conflicting code. The architecture review becomes the most important meeting on the calendar. Not the retro. Not the standup. The architecture review.

The Definition of Done now needs an update. It used to mean code was written, tests passed, code reviewed, and deployed. Now, it also means that the agent output has been checked for architectural consistency, integration conflicts have been resolved, automated quality checks have passed, and a human has confirmed that the combined work of multiple agents actually functions as a whole. This last step is important; each agent’s output might be correct on its own, but together they could still break the system. The Definition of Done must now include these new risks.

Pair programming becomes pair orchestration. The XP practice of two people at one keyboard made sense when the bottleneck was writing code. In the multi-agent world, the bottleneck is code review and integration. Pair orchestration means two engineers overseeing the same agent fleet, one focused on reviewing output, the other focused on decomposition and delegation. They swap roles. They catch each other’s blind spots. And critically, they prevent the single-human-bottleneck problem that makes agent orchestration fragile.

The Starfish and the Spider

Brafman and Beckstrom wrote a book called The Starfish and the Spider about two types of organizations. A spider has a central brain; crush the head and the whole thing dies. A starfish is decentralized; cut off an arm and it regrows. The most resilient organizations, they argued, look more like starfish: distributed leadership, emergent coordination, no single point of failure.

Multi-agent engineering works like a starfish. No single agent is a bottleneck. If one agent fails, the others keep going, and the planner can give the failed agent’s tasks to someone else. The system is strong because no single part is essential, except for the human.

The human is the spider.

This is the central tension of multi-agent engineering, and it’s one that managers need to think carefully about. Your agents are a starfish: distributed, resilient, redundant. Your human engineer is a spider: a single point of failure whose judgment, context, and decision-making can’t be distributed or replicated.

The management challenge is to protect that single point of failure. It means preventing burnout in engineers whose mental workload has shifted from coding to making constant judgment calls. It’s about making sure the human doesn’t become the bottleneck that brings the whole agent team to a stop. You need systems that let engineers take breaks without everything coming to a halt.

That might mean pair orchestration, two humans overseeing the same agent fleet, the way pilots have copilots. It might mean shift-based orchestration for large projects. It might mean investing heavily in Judge agents so that the human reviewer only sees the 10% of output that the automated judges couldn’t confidently approve.

Whatever the solution, it begins with realizing that the human in the loop isn’t just a supervisor watching things go by. They are the most important part of the system, and they need to be managed with that in mind.

The Irony

There’s an irony in all of this. For decades, the career path in software was: write code, get promoted, manage people, stop writing code. Engineers became managers and mourned the loss of their craft.

Now the path is splitting. Engineers who stayed on the technical track, the ones who said “I just want to build things”, are discovering that building things at scale with AI agents requires everything we put in the management curriculum. Communication. Delegation. Specification. Quality review. Decision-making under uncertainty. The ability to decompose a problem, assign the pieces, trust the execution, and verify the result.

The engineers didn’t become managers; management found them.

And if you’re an engineering manager who’s been wondering whether your skills will matter in a world of AI, here’s your answer: they matter more than ever. Not because you’ll manage agents directly; your engineers will do that. But because someone needs to teach them how. Someone needs to build the culture of specification, review, and judgment that makes agent orchestration work. Someone needs to manage the humans who manage the machines.

The imaginary brake pedal is gone. Your hands are on a different wheel now, and it’s got more torque than you ever imagined.

By Joshua McDonald on March 4, 2026.

Canonical link

Exported from Medium on August 26, 2026.