AI Makes Engineers 5x Faster. It Doesn't Make You a 5x Manager.
Google’s CEO said publicly this year that AI now writes over a quarter of the new code at the company. Numbers like that are why the same question comes up in every engineering leadership meeting I sit in: if one engineer can now do the work of five, why is a manager still capped at eight direct reports? Shouldn’t they be able to run forty?
It’s tidy math. 8 × 5 = 40. More output per head should mean more heads per manager.
It’s also wrong, and it took me longer than I’d like to admit to figure out why.
In an earlier post, I argued the direct-report ceiling doesn’t jump to 40 in the AI era — it drifts from the old 6–8 up to something like 10–15. This post is about why it stops there, and what happens to coaching and performance reviews once it does.
The Headcount Fallacy
Picture how a manager without AI actually spends a week. Not with a stopwatch — nobody’s measuring this precisely — but roughly:
- Coordination (~40%): standups, status checks, unblocking people, chasing dependencies, reviewing PRs
- People development (~35%): 1:1s, coaching, feedback, hiring
- Context work (~15%): turning business goals into direction, writing specs, planning
- Everything else (~10%): meetings, admin, the usual overhead
Hand that team coding agents and the first bucket collapses. Nobody needs to ask if a ticket moved — the agent is three commits in. Nobody’s unblocking someone stuck on a broken staging environment — the agent provisioned its own. Anthropic’s study of roughly 400,000 Claude Code sessions backs this up structurally: people still make about 70% of the planning calls, but only 20% of the execution calls now. The busywork didn’t get faster. It got handed off.
Here’s the part that breaks the 40-reports math: the people-development bucket doesn’t shrink to match. It grows.
Your engineers haven’t stopped working — they’ve started doing a different job. They’re writing specs an agent has to execute correctly. They’re catching the moment an agent’s output looks right but is quietly wrong. And per Anthropic’s Economic Index, a meaningful number of them are quietly worried whether the job they trained for still exists. None of that gets easier to coach just because a machine writes the code now. If anything it’s harder — you’re coaching judgment instead of output, and judgment doesn’t show up in a diff.
Run the numbers again, loosely: coordination drops from ~40% to ~10%. People development climbs to ~45%, because coaching someone’s judgment takes longer than checking their status. Context work — the shared conventions a dozen agents are all quietly drawing from — grows to ~25%. Overhead stays flat.
Net gain: something like 10% more capacity per manager. Not 500%. The time AI frees up doesn’t get banked as extra headcount. It gets spent making the humans you already have better at a harder job.
Figure: roughly where a manager's time goes before and after AI. The gains don't stack into headcount — they stack into depth.
That’s the real reason the ceiling moves to 10–15 instead of 40. The premise that engineers get several times more productive isn’t crazy — a16z’s rundown of the AI development stack puts credible estimates in that range, and none of the serious ones argue engineers are being replaced outright. But a manager’s job was never a direct function of team output. It’s attention. And AI doesn’t hand you more of that.
The Ladder Changed Shape
If the people-development bucket is growing, what’s actually filling it?
In the old model, engineering growth followed a path everyone understood: learn the codebase, fix small bugs, take on features, own a module, design a system, mentor others. A manager’s coaching tracked that ladder — at each rung, you helped someone take on a slightly bigger problem.
The rungs still exist. They just measure something different now.
| Old growth ladder | New growth ladder |
|---|---|
| Fix a bug independently | Write a spec an agent can execute correctly |
| Own a module | Review agent output for a module, with a low error rate |
| Design a system | Set the conventions a dozen agents draw from, so their output stays consistent |
| Mentor junior engineers | Coach other people on their own spec-writing and review instincts |
Every rung on the new ladder is judgment, not speed. You can’t pair-program someone through a good spec the way you could pair-program them through a tricky bug — you have to help them develop taste, and taste doesn’t transfer in a single session.
Google’s own internal research on management — Project Oxygen — found years ago that “being a good coach” was the single strongest predictor of a great manager, well before any of this was about AI. The AI era isn’t inventing a new job requirement. It’s making an old one much harder to fake.
A 1:1 used to sound like: “How’s the migration going? Anything blocking you?” Now it sounds more like:
“Walk me through the spec you gave the agent last week. What did it get right? Where did it drift? What would you write differently next time?”
You’re coaching a thought process, not a status. And thought processes don’t compress — they take the same 30 minutes they always did, just spent on a craft that barely existed five years ago. Add in a team that’s quietly anxious about whether the job still exists, mid-shift from “I build things” to “I direct things that build things,” and this is exactly the wrong moment to cut back on attention.
What We Should Stop Counting
A lot of the management rituals from the last decade are about to go quietly obsolete — not because they were wrong, but because they were built to measure a world where humans wrote code one line at a time.
| Stop tracking | Track instead |
|---|---|
| Story points / velocity | Spec clarity — what share of specs produce correct output on the agent’s first pass |
| Burndown charts, sprint completion % | Outcome achievement — what share of the actual goal got hit, regardless of how many “sprints” it took |
| Raw PR count / lines of code | Verification effectiveness — how many real issues get caught in review per 100 agent outputs |
| “Are you blocked?” | “Was the spec ambiguous?” — and whether the team’s shared context is current enough to prevent it |
To be clear, this isn’t “agile is dead.” Working software, responding to change, valuing people over process — none of that expired. What’s expiring is the metrics layer bolted on top of it, which was built for sequential human execution. DORA’s own 2025 research found something worth sitting with here: AI acts as an amplifier — teams with good practices get dramatically better, teams with bad ones get dramatically worse. Point a bad metric at a faster machine and you just get the wrong answer faster.
Judging the Judgment
Two engineers, same team, both directing agents. Engineer A ships 30 PRs a week. Engineer B ships 8. Old model: A is obviously carrying the team.
Then you look closer. Engineer A accepts about 70% of what the agent hands back without touching it. Engineer B redirects or rejects 60% of agent output before it ever reaches review — and what does ship has a near-zero defect rate. A is shipping volume. B is shipping judgment.
Who’s actually performing better? The old scoreboard says A. Reality says B. And now the manager has to defend that call in a calibration meeting, to a room that’s still thinking in PR counts.
The four things I actually look at now, roughly in order of how easy they are to measure:
- Spec quality — how often this person’s specs produce correct output on the first pass. Directly measurable.
- Verification effectiveness — what share of real issues they catch in review. Measurable with the right tooling.
- Domain judgment — how often they make the right call, the right tradeoff, the right “no.” Only visible over time, through track record.
- Context curation — how much their shared conventions and docs improve other people’s agent output, not just their own. This is close to what Team Topologies calls reducing cognitive load, applied to a team of agents as much as a team of humans.
The first two are quantifiable with decent tooling. The last two require the manager to have the same judgment they’re trying to evaluate — which is exactly why management occupations show up with the highest verified-success rate working with agents in Anthropic’s data. Managers who can recognize good judgment when they see it will evaluate their teams accurately. Managers who can’t will fall back on counting PRs, and reward exactly the wrong engineer.
That’s the uncomfortable part: AI doesn’t make a mediocre manager neutral. It makes them actively harmful, because they’ll keep rewarding volume over judgment right up until their best people leave.
What Doesn’t Change
None of this is as dystopian as it might sound. A lot survives — probably more than people expect.
The 1:1 survives, for one. It used to be anchored on execution because that was the only thing a manager couldn’t see directly. Now the execution is fully visible — the agent’s work is right there in the diff — so those questions disappear, and what’s left is harder: what did you learn, where’s your judgment still weak, what would you do differently. Writer Rands has always described the 1:1 as preventive maintenance rather than a status meeting. That logic gets stronger here, not weaker — you’re not checking if someone’s stuck, you’re catching bad judgment before it ships.
A few other things that hold:
| Survives | How it shifts |
|---|---|
| Retros | Still the only ritual built to fix the process — and process is what’s changing fastest |
| Performance reviews | Same format, different question: not “what did you ship,” but “how well did you specify, verify, and judge” |
| The manager role itself | Companies have tried deleting it before — Zappos and Medium both walked back holacracy after finding out someone still has to develop people and hold the outcome |
The thread through all of it: the human layer doesn’t shrink. Twenty years before any of this, DeMarco and Lister argued that software problems are mostly sociological, not technical. AI hasn’t disproven that. It’s just changed what the sociological problems look like.
The 5x intuition breaks because a manager’s job was never a simple multiple of team output. It’s coordination, which AI shrinks. It’s development, which AI grows. And it’s judgment, which nothing has touched yet. The gains don’t stack into headcount — they stack into depth: better specs, sharper reviews, richer shared context, performance reviews that finally measure the thing that matters instead of the thing that’s easy to count.
The managers who work this out will be busy — not because they’re overloaded with reports, but because the reports they have need a kind of attention nobody’s written the playbook for yet. The ones who don’t work it out will keep counting story points, and keep being baffled when their best people quit.
If you want the fuller history behind that 6–8 → 10–15 number, the companion post on the 50-year evolution of software management is where it comes from.
What’s the one metric your team should stop tracking? Drop it in the comments — I’m curious how far outside “story points” people are willing to go.
References
- Anthropic, “Agentic coding and persistent returns to expertise” (June 2026) — the 70%/20% planning-vs-execution split; management occupations’ verified-success rate with agents
- Anthropic, Economic Index: Cadences (June 2026) — worker anxiety about AI-driven job change
- a16z, “The Trillion Dollar AI Software Development Stack” (Oct 2025) — productivity estimates behind the “5x” premise
- DORA — Software Delivery Metrics — the 2025 finding that AI amplifies existing team practices, good or bad
- Google re:Work — Project Oxygen — “be a good coach” as the top predictor of manager quality
- Rands, “The Update, The Vent, and The Disaster” — the 1:1 as preventive maintenance, not a status check
- Team Topologies — Key Concepts — cognitive load as the resource a manager is really allocating
- Holacracy (Wikipedia) — Zappos and Medium’s experiments in deleting the manager role, and what happened next
- Ars Technica, “Google CEO says over 25% of new Google code is generated by AI”
Comments