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.
What is the CFL condition?
It is a rule from numerical simulation, named after three mathematicians who wrote it down in 1928: Courant, Friedrichs and Lewy. Picture simulating a wave by chopping space into a grid and time into steps. The rule says one thing: in a single time step, the wave must not travel further than one grid cell. Step too far and the simulation has to guess at values it never computed. Those guesses feed the next step, the error doubles, and within a few steps the numbers run off to infinity.
Swap the terms and you have a software team. The wave is work arriving. The grid cell is what your reviewers can actually look at. Push work in faster than they can look at it, and the system starts running on things nobody checked. Same rule, same failure, different units.
To watch the original version of this happen to an actual simulation, push the Courant number past 1 in the plasma lab on this site: see the difference for yourself. Same condition, real physics, and you can watch the pulse smear before it explodes.
What am I choosing here?
When more work arrives than your reviewers can properly handle, something has to give. There are only two things it can be, and every team picks one, usually without ever deciding to.
Hold review depth
The queue grows
- What the team does
- Every pull request still gets a full, honest review. Throughput stays at your real capacity, so the surplus waits its turn.
- What you see
- The queue climbs, and time in review climbs with it.
- What it costs
- It fails loudly. Work stops shipping on time and everyone can see it.
Hold latency
Review depth collapses
- What the team does
- Everything that arrives today gets reviewed today. To make that fit, attention per pull request is cut to whatever is left: at twice your capacity, each one gets half the attention.
- What you see
- Nothing. The queue stays short and time in review stays flat.
- What it costs
- It fails quietly. Defects escape into production while the dashboard stays green.
Both are the same overload. Only one of them warns you.
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. →