The amount of code my team can produce is no longer an interesting number.
An engineer with a good agent setup can open five pull requests before lunch. The code compiles, the tests pass, the diff is clean. Two years ago that throughput would have made someone the strongest contributor on the team. Today it tells me almost nothing — because generating the code was never the part I was worried about.
Four months into managing a team through this, the pattern I keep seeing is simple: AI moved the bottleneck. It didn’t remove it. Writing code got cheap. Understanding code did not. And most of the management advice being produced right now is optimising the part that stopped mattering.
The bottleneck went somewhere specific #
When code generation is nearly free, everything downstream of it gets more expensive in relative terms. Review. Debugging in production. Deciding whether the thing should be built at all.
I see it in the review queue first. Five agent-assisted PRs before lunch means someone else’s afternoon is gone. The team’s constraint is no longer “how fast can we write this” — it’s “how fast can a human absorb what was written and take responsibility for it.” That’s a different problem, and it responds to different management.
The uncomfortable version: a team that generates more code than it can comprehend is accumulating a new kind of debt. Not technical debt in the classic sense — the code might be fine. Comprehension debt. Systems in production that nobody on the team could debug at 2am without the agent that wrote them. We’d never accept that for infrastructure. “The config works but nobody knows why” is a finding in a post-incident review, not a workflow.
What I’m watching instead of output #
I’ve stopped paying attention to volume entirely. The signals I actually track now:
Can the author explain the diff? Not defend it — explain it. Walk me through why this approach, what breaks if the load doubles, where the bodies are buried. If the answer is a shrug and “the agent suggested it,” we have a problem that will surface at the worst possible time.
Is review getting deeper or just faster? The lazy equilibrium is agent-generated code reviewed by agent-generated approval. Two machines nodding at each other while the humans context-switch. Review is where understanding transfers between people. If it hollows out, the team stops being a team and becomes a group of individuals with the same repo access.
Are juniors debugging or just prompting? This is the one that worries me most. The engineers who are senior today got that way by being wrong in production and having to understand why. If juniors skip that loop — if every hard problem gets escalated to a model instead of wrestled with — we’re not training their replacements. We’re just consuming the last generation of debugging skill.
What I’ve changed #
Nothing dramatic. Three adjustments, all of them boring:
Review is explicitly teaching time now. I’ve told the team that a thorough review of an agent-heavy PR counts as real work — not overhead slowing down the “real” velocity. If the PR took twenty minutes to generate and two hours to review properly, the two hours were the engineering.
“Explain it back” is normal, not punitive. In 1:1s and design discussions I ask people to walk me through their own recent changes. Not as a gotcha. As the same hygiene as asking whether a dashboard actually measures what it claims to. Most of the time the answer is great. The times it isn’t are exactly the conversations worth having early.
I refuse to measure AI adoption as a KPI. Lines generated, percentage of AI-assisted commits, prompts per day — all of it optimises the cheap part of the pipeline. If leadership wants a number, the honest ones are still the old ones: incidents, time-to-restore, whether the roadmap moved. The tool is an amplifier. You don’t measure amplifiers. You measure the signal.
The part that hasn’t changed #
Here’s what four months of this has actually taught me: the job description didn’t change at all.
Protect focus. Build enough safety that people admit what they don’t understand. Give feedback before patterns calcify. Make sure the team is learning faster than it’s shipping. That was the job before agents, and it’s the job now — the boom just raised the cost of skipping it. A manager who wasn’t paying attention to whether their team understood its own systems could coast for years. Now the gap opens in months.
I don’t have the long-term data yet. Ask me in a year whether the comprehension debt I’m worried about was real or whether I was pattern-matching on fear. Both are possible. I’m writing it down now so I can check.
If you’re managing a team through the same shift and seeing something different — especially if you think I’m wrong about the junior problem — I’d genuinely like to hear it. Find me on LinkedIn.