The Speed Limit
Agents can produce code faster than any team in history. That is not the interesting fact. The interesting fact is that every system that moves work forward has a hard limit on how fast it can move — and in agentic development, that limit is not the model. It is human review capacity.
Numerical simulations have exactly this limit. It is called the CFL condition, and when you violate it, the simulation does not degrade politely. It explodes. Let's see it happen to a team.
Load ratio: stable.
The review-capacity condition: work must not enter the system faster than it can be properly reviewed. A is agent output, R is honest review capacity, Q is the queue. When C ≤ 1, the queue drains and quality holds. When C > 1, no tool, no prompt, and no model upgrade saves you — because the constraint was never the model. This is the CFL condition of software teams: the hard speed limit on every agentic rollout.
The rollout — predict first, then watch
A real engineering organization adopts coding agents. Within months, merged-PR output roughly doubles. Review capacity is not changed. Your prediction: what happens to the median time a PR spends in review?
Commit to a prediction to unlock the reveal.
What agents actually deliver, by the numbers
- Net average productivity gain, across enterprises (Gartner, 2026)
- +19.3%
- Engineering leaders reporting improvement (Gartner, 2026)
- 90%
- PRs per engineer per day, adopters vs not, tens of thousands of engineers (Microsoft, 2026)
- +24% (CI +14.5% to +33.7%)
- Experienced developers on mature codebases, randomized trial (METR, 2025)
- 19% slower
- …while the same developers believed they were
- 20% faster
Read all five rows together. The gains are real — and modest. Roughly a fifth to a quarter more throughput in a well-run rollout: meaningful across 100 developers, but nothing like the 10× of the demos. And the last two rows are the reason this course keeps insisting on measurement: the felt speed and the measured speed can point in opposite directions. If you take one aphorism from this module: feelings are not telemetry.
So C > 1 — what now? Four levers, in order of leverage.
✂️ Smaller PRs
The single cheapest lever. Halving PR size nearly halves the review cost of each unit of work — R rises without hiring anyone. (This is refining the grid.)
🎯 Risk-tiered review
Not every change deserves the same scrutiny. Spend deep review on risky changes, light review on trivial ones — fine cells at the shock, coarse cells everywhere else. Module 07 is entirely about this.
🤖 Review agents as pre-filters
An agent that catches the mechanical 60% before a human looks raises effective R. Careful: it must deepen human review, not replace it — otherwise you have automated the rubber stamp.
📋 Better intent upstream
A great issue produces a reviewable PR; a vague issue produces 800 lines of plausible wrong code that takes three humans a day to untangle. Raising issue quality lowers A's review cost — Module 03 was this lever, and Module 06 shows what happens when you skip it.
One lever is deliberately last, and least: hire more reviewers. It works, it is slow, and teams reach for it first because it requires no change in how they work. Pull the other four before this one.
What does the review-capacity condition C = A/R ≤ 1 guarantee?
Your C rises above 1 and the team holds latency constant so deadlines are met. What actually happens?
The bottom line of this module fits in one sentence: your agents' speed limit is your reviewers' capacity, and crossing it fails loudly or fails quietly, but it always fails.
There is one more consequence, and it is where we go next. When review depth smears, small deviations slip through — one at a time, each too small to matter. Step by step they accumulate into something with real force: a codebase quietly solving a different problem than the one you meant. The simulation people have a name for this. So do we. Module 06: Drift, and how to clean it. →