The AI coding bottleneck nobody wants to talk about
Fast code is useless if nobody can explain why it exists.
It’s a beautiful day in the neighborhood. Picture the perfect pull request: well-scoped commits, sensible naming, passing tests, and an amazing approach that fits the architecture better than what half the team would have written by hand. Your agent opened this PR in eleven whole minutes based on a ticket that had been sitting in the backlog since April.
The singular problem with it: the implemented feature was quietly killed in a product call three weeks ago.*1 Whoops.
As it turns out, nobody updated the ticket. (And nobody thought they had to, because in the old world, a stale ticket just sat there being stale.) Previously, the work in this PR would have taken a human developer days or weeks to turn tickets into code. During that time, the opportunity for the mismatch to be caught during planning, standup, or a watercooler convo was high. Someone would have said “wait, didn’t we drop that?”
Now the ticket doesn’t sit there. It gets built.
The part everyone thinks is hard
The current AI coding tools are getting very good at producing code. This is not breaking news. You describe a feature to the best of your ability, point an agent at a repo, and get a PR back faster than you could have written the ticket six months ago.
For whatever reason, the industry keeps treating this as the hard part. We need more capable models, bigger context windows, and agents that can run longer without supervision! And to be fair, generating correct, well-structured code was the hard part for about fifty years. But the actual hard part now is knowing whether the PR is even implementing the right thing.
A PR can pass every test, follow the architecture, and still be fundamentally wrong. The context of these decisions - what gets built, what gets buried, what the shared understanding of the problem and user are all part of the premise for this work. Maybe the requirement changed, maybe the customer problem got redefined after the ticket was written. Maybe a technical decision was made in a meeting and reversed two weeks later, and the reversal lives only in a Slack thread with four participants. Or, my personal favorite, maybe the acceptance criteria were never written down at all, because everyone assumed somebody else knew them.
None of this is new. Software teams have been building on stale premises forever. What’s new now is that the natural delay between an idea and its implementation (the delay that used to catch these errors) has collapsed completely. That delay was never designed as a safety mechanism, but it sure functioned as one. When code took weeks to write, a bad premise had weeks of exposure to a lot of people who might notice it. Now an agent can turn a dead ticket into a polished PR before anyone remembers the ticket is dead. We are finding out the hard way that friction wasn’t just cost, but some serious load-bearing quality control we didn’t know we were relying on.
Speed without accountability
To be clear: this is not an argument against AI coding. The speed is real and it’s useful, and teams that refuse it will lose to teams that don’t. But speed without accountability is how you end up building the wrong product more efficiently. Your velocity is only a virtue if you’re pointed in the right direction, and the thing that tells you whether you’re pointed in the right direction — the chain of reasoning connecting this diff to an actual customer problem — is exactly the thing nobody maintains.
Here’s the question we think matters more than “how do we make agents write more code”:
How do you inspect the decision chain behind the code an agent writes?
Before a human approves an agent-generated PR, they should see what requirement it implements, what decisions it depends on, who made those decisions, and (most importantly) whether those decisions are still current. Written out like that, it sounds almost embarrassingly basic. In most startups it’s also damn near impossible.
Where the rationale actually lives
Pick a random PR from last quarter and reconstruct why it exists. Not what it does, but why it should exist at all. What problem does it solve? And for which customer?
You’ll likely find the answer sprinkled across a ticket, a Slack thread that amends it, a Notion doc that predates both, a GitHub comment from someone who has since left, and a decision from a call three months ago that was never written down anywhere. The reviewer approving that PR isn’t reviewing code against a requirement. They’re reviewing code against a reconstruction of a requirement, assembled from fragments and institutional knowledge, under time pressure.
That reconstruction work is expensive. It’s an increasingly significant cognitive load on scarcest resource on any team: the judgment of the people senior enough to know which fragments to trust. Every hour a strong engineer spends playing archaeologist on their own company’s decisions is an hour of judgment spent on logistics instead of on the actual question — should we build this?2
As agents get faster, the ratio gets worse. Implementation cost drops toward zero while verification cost stays flat. The inverse, weirdly, is also true. Verification costs can climb, because there are more PRs to verify and less context attached to each one. The bottleneck doesn’t disappear. It moves, from writing code to standing behind it.
Rationale is not exhaust
The teams that get the most out of AI coding won’t be the ones with the best prompts or the most agents running in parallel. They’ll be the ones that stop treating rationale as disposable, the ones who can answer “why does this exist, and is that reason still true?” in seconds, not an afternoon of forensics.
Decisions need to live somewhere agents and humans can both check them. Requirements need owners and timestamps and a way to go stale visibly, instead of silently. The premise of a piece of work needs to be as inspectable as its diff. AI made implementation cheap. That was the easy part, but it just didn’t look like it at the time. The teams that win the next few years are the ones that notice what got expensive instead.
Yes, I know this happens in all-human teams, too. It’s bad for everyone involved in writing code, regardless of sentience or job title.
Unless you’re like some of the engineers I used to work with who had these kinds of existential crises during every sprint planning session.