Outrunning Oversight (Intro)
A single agent shipped more diffs last week than our whole team could actually read.
That should be impossible. It wasn’t.
Not “review carefully.” Read.
That line made me stop and rebuild how our team ships.
Here’s the scale we’re talking about. 66% of enterprises already permit some production AI deployment without human review (Value Add Pulse). Microsoft reports 15x year-over-year growth in active agents within Microsoft 365 (Microsoft Work Trend Index).
The volume is real. And it is accelerating.
This is the piling problem: AI agent output accumulates faster than downstream human review can process. Unlike a machine that slows the whole line, the agent keeps producing regardless.
For years, the honest answer to “why isn’t this shipped yet” was implementation capacity. Not enough engineers, not enough hours, too much in flight. Story points, sprint capacity, velocity charts, every planning ritual we built, were ways of rationing one scarce resource: people who turn description into working code.
That was the constraint. For decades.
Coding agents broke that assumption.
It’s tempting to stop there: agents implement fast, so now the bottleneck must be writing clear specs. Writing clear intent has always been the hard part of software, and it still is, but it’s not the only bottleneck anymore. Now there are two human bottlenecks:
- Spec shaping: ensuring the intent is clear enough for an agent to produce something correct.
- Review: verifying the output well enough to be accountable for it.
Both are human cognitive loads. Neither scales with compute.
What actually changed: agents can now produce implementation volume that scales past what a team can understand, verify, and stay accountable for. Not past what they can type, but past what they can read, hold in their heads, and put their name on when it’s in production.
That’s a different problem than “the spec was unclear.” A bad spec makes an agent produce the wrong thing faster and forces the reviewer to reverse-engineer intent instead of checking output against a clear target. Good specs ease review but do not eliminate it. Both sides are human capacity constraints the system must protect.
A 2025 METR randomized controlled trial measured this same effect from the other direction: developers using AI coding tools ran about 19% slower on net. Agoda’s engineering team reached a related conclusion from production data: coding was never the real bottleneck to begin with. Addy Osmani named the drag comprehension debt: understanding less of your own codebase as AI-written code accumulates in it. That’s the piling problem showing up as a velocity number instead of a backlog.
Agent Output vs Human Comprehension Capacity
==============================================
Time -> 1 2 3 4 5 6 7 8 9 10
Agent: 1 2 3 4 5 6 7 8 9 10 (scales with compute)
Human: 5 5 5 5 5 5 5 5 5 5 (flat)Agent output grows with compute; human comprehension capacity stays flat.
I built a delivery model around that constraint and called the series Outrunning Oversight: the failure mode where agent output quietly runs ahead of a team’s capacity to shape it well and verify it afterward. This post is the thesis; the following posts work through the mechanics of keeping agent throughput inside what your team can actually stand behind.
The old model did not have a name for this problem
Let’s talk about why the old model couldn’t even see this coming.
Traditional agile treats delivery as one continuous backlog worked by one kind of capacity. That makes sense when a human writes the ticket and a human implements it: the two activities move at roughly the same speed, so someone is always in the loop reading every line as it’s written. Spec-shaping and comprehension happen in the same person, at the same time, and the bottleneck is simply “not enough people.”
Once an agent can implement dozens of well-specified slices a day, that assumption breaks in two directions at once.
First, the person shaping the spec must produce enough clarity to guide an agent that never asks clarifying questions. Second, the person reviewing the output must absorb enough to be accountable for it. Output volume detaches from review capacity, and spec quality becomes a gate that protects the reviewer, not just the agent.
Track it all as one backlog and you cannot see either problem until it’s already real. Velocity looks great. Cycle time looks great. And somewhere in that pile of green checkmarks is a change nobody actually read closely, that nobody could explain if it broke in production next month.
The real question is not “which bottleneck is worse.” It’s “are we seeing both?”
Here’s the thing. The failure mode this framework catches has two faces.
On the spec side: an ambiguous spec produces output that’s technically correct against a wrong or incomplete target, and the reviewer either cannot see the gap or cannot articulate it.
On the review side: a clear spec produces correct output, but the volume is so high that review depth erodes until it’s a rubber stamp.
Both are human capacity problems. Both produce unaccountable code in production. And they feed each other: bad specs make review harder, and overwhelmed reviewers stop catching spec problems early.
Intent quality is a contributing factor, not the headline constraint. Getting intent right is still necessary, but not sufficient.
Here’s the structural problem: implementation capacity is now effectively elastic (add compute, add agents), while both spec-shaping capacity and review capacity are fixed. Every mechanism in this framework, slicing, risk tiers, WIP limits, review gates, exists to keep implementation from silently outrunning spec-shaping and review.
What this series covers
I’m not going to cram the whole framework into one post. It has real structure, and cramming would do it a disservice.
- Part 1, Two Backlogs, One System: the dual-backlog structure that emerged when agents could implement faster than humans could shape specs, and how to keep them aligned.
- Part 2, The Five Gates: the five cognitive and process gates that protect review depth as agent throughput scales, and when to pass or pause through each one.
- Part 3, Measuring the Machine: the handful of numbers that tell you whether agent output is still inside your team’s comprehension capacity, and the ones that keep looking fine right up until they do not.
None of this is theoretical. It’s the system I use to decide, concretely, whether a spec is clear enough to hand to an agent, whether what came back is something a human can actually stand behind, and whether the team is shipping faster or just accumulating unreviewed volume that looks like progress.
I wrote this framework because my team hit the wall first, and figuring out how to get back up was a team effort, not a solo one. Every gate and every metric in this series got shaped by someone on that team pushing back on a version that did not hold up in practice.
If “we’re shipping more than we can actually vouch for” sounds like a problem you’re already living with, the next posts are the mechanics for doing something about it.
Up next: Part 1 (Two Backlogs, One System) hash: sha:4f9021dc