The Shifting Bottleneck
There’s a question our engineering org keeps circling back to, and it came up again in a thread this week: where’s the real bottleneck now that AI writes so much of the code? The prevailing answer, made by people I respect, goes like this: AI has compressed the distance from idea to pull request so dramatically that manual PR review is now the choke point, because we can’t yet trust AI-written code at a glance. It’s a sharp observation, and it’s half right. I want to spend this post on the other half, because I think we’re about to spend a lot of energy optimizing the wrong constraint.
I’ve written before about what productivity even means in this era, and about how my own role shifted from writing most of the code to conducting the work. This post isn’t a rerun of either. This one is about the economics of where the queue backs up now, and about the single most dangerous sentence in AI-assisted development: “the tests are green.”
The binding constraint has moved
There’s a boring truth from manufacturing that applies cleanly here: a system has exactly one binding constraint at a time, and improving anything that isn’t the constraint buys you nothing. You just pile up inventory in front of the real bottleneck.
For years the constraint in software was, roughly, typing the code. The translation of intent into working syntax. AI didn’t nudge that. It collapsed it. A well-scoped feature that used to be a week of implementation is now a couple of hours of generation and shaping. So the constraint jumped. The question is where to, and this is where I part ways with the hallway consensus.
Saying “PR review is the bottleneck now” is describing the symptom, the place inventory is visibly piling up. But review is where you discover the problem. It’s not where the problem is created. If reviewers are drowning, it’s usually because the thing they were handed was underspecified going in, or because nobody can cheaply confirm it actually behaves correctly. The real constraint sits one step upstream and one step downstream: idea→spec quality at the front, and verification and trust at the back. Both of those are human-capacity problems. Neither is a tooling problem.
Spec quality is now the highest-leverage artifact
Here’s the part that surprised me most once I started measuring it. When I hand the AI a genuinely good spec, real acceptance criteria, the edge cases enumerated, a performance budget, and an honest attempt to represent what the actual user is trying to do, a SwiftUI feature comes back roughly 70 to 85% right on the first pass. Not “compiles.” Right. The structure is sound, the state management is defensible, the naming is close to what I’d have chosen.
When I hand it a vague spec, I get vague code, fast. And now I’ve got a large, confident, well-formatted diff that’s subtly wrong in ways that take longer to find than they would have taken to prevent. The AI faithfully amplifies whatever clarity, or fuzziness, I gave it. That’s the leverage point. The spec is no longer paperwork you write to satisfy a process. It’s the highest-leverage artifact in the whole pipeline, because it’s the last place a human’s understanding of the problem is still cheap to change.
And writing a good spec is hard, senior/architectural work. Enumerating edge cases, deciding what “correct” means at the boundaries, representing a user who is not you, that’s judgment, not throughput. You cannot generate your way out of not understanding the problem.
Green checks are necessary but not sufficient
Now the downstream half, and the humbling one.
I built an end-to-end, AI-orchestrated feature recently, CoordinatedEvents, a recognition-only “poker run” event mode, developed entirely behind a feature flag. By every dashboard I had, it was pristine: 314 passing tests, zero lint findings, a clean build. Green across the board. If green were trust, I’d have called it done that afternoon.
It came back green and riddled with UI bugs the tests could not see. A blank screen when you deleted an item. A dead navigation path on iPad that simply went nowhere. A screen that, under one entry condition, never presented at all. None of those are exotic. They’re the kind of thing you catch in ninety seconds of actually using the feature, and exactly the kind of thing a green test suite will happily certify around, because the tests assert what I thought to assert, not what a user will actually do.
That’s the trap I want to name plainly: a clean, passing, well-reviewed build can still be confidently wrong. Green checks are necessary. They are nowhere near sufficient. The most expensive failure mode in this new world isn’t slow code or buggy-looking code, it’s plausible code that everyone, including the reviewer, including the test suite, agrees looks fine, and that ships confidently wrong. AI is very, very good at producing plausible.
The scarce resource is senior human judgment
So put the two halves together and the economic argument writes itself. If the binding constraint is spec quality plus verification and trust, then “make the model faster” and “generate more code per hour” optimize the exact thing that is no longer scarce. You’re speeding up the conveyor belt feeding a line that’s already backed up. All you get is more inventory, more plausible diffs, queued in front of the humans who have to specify and verify them.
The scarce resource is senior human attention, and it’s needed at two specific stations: writing the spec correctly at the front, and verifying real-world behavior at the back. You add capacity there or you don’t actually go faster, you just feel faster while the queue grows. This is the same argument I keep coming back to about measuring value delivered rather than hours or lines logged: a thousand plausible lines that no one has verified against reality is not progress. It’s unpriced risk wearing a green checkmark.
I owe you the strongest pushback I got, because it’s legitimate and it kept me honest. The strongest version of it: specs, in practice, get written after the fact, reverse-engineered to match what got built, and the whole “spec is king” framing quietly assumes greenfield code. On brownfield, the real danger isn’t a fuzzy spec at all. It’s regression: the confidently-wrong change that breaks something three modules away that nobody thought to spec, or to test, or to look at.
Everything I’ve said about spec leverage is easiest to believe when you’re building something new behind a flag. The moment you’re editing a decade of load-bearing code, “70–85% right on the first pass” starts sounding naive, and verification gets exponentially harder because the blast radius is invisible.
AI didn’t remove the bottleneck. It relocated it, and it relocated it squarely onto the two things machines are worst at handing you: a correct spec, and earned trust. A correct spec requires understanding the problem and the human it’s for. Earned trust requires someone to actually verify that plausible behavior is real behavior. Neither comes out of a model. Both come out of judgment.
Which is the part I find genuinely reassuring. The reflex read on all this is that AI makes senior engineers less necessary. What I’m watching happen is the opposite. It moved the whole job to the part that was always the actual job, deciding what “correct” means, and confirming we got there, and it made that part more valuable, not less. Green isn’t trust. It never was. It just used to be easier to pretend.