There’s a new kind of tired going around engineering teams this year.
The old complaint was: *the code is broken, and I have to fix it.* The new one is quieter and stranger: *the code is probably fine — I still have to look at all of it, and there’s so much more of it than there used to be.*
Sit with that second one for a second. That’s basically the whole newsletter.
For two years, the entire fight over AI and coding came down to one question: is the code any good? People argued about benchmarks, hallucinated library calls, whether a model that aces a leetcode test can be trusted near a production database. That fight isn’t fully over, but it’s settled enough in practice. Teams ship this stuff daily now — not because a keynote convinced them, but because what comes out the other end is, often enough, good enough.
Which is exactly the problem.
“Good enough to ship” was never the actual bottleneck. Writing code was never the slow part of software — understanding it, trusting it, fitting it into everything else, that was always the slow part. We just never noticed, because for forty years the person writing the code and the person vouching for it were usually the same overworked human. The two problems looked like one problem. AI split them apart, and now we can finally see them separately — and one of them is a lot bigger than anyone budgeted for.
Here’s where it shows up in the data. A study that tracked tens of thousands of engineers at Microsoft found that people who adopted AI coding tools merged roughly a quarter more pull requests than they otherwise would have, and that lift held for months, not just the honeymoon week. A separate study, this one following more than ten thousand developers across a thousand-plus companies, found something less flattering sitting right next to that number: merged pull requests nearly doubled, and review time climbed by almost as much. Same rate, mirrored. And the thing that was actually supposed to go up — delivered, working, used value — barely moved. More code went in. About the same amount of finished value came out. All that extra speed went somewhere. It just didn’t go anywhere useful.
The obvious guess is traffic. Too many agents, moving too fast, tripping over each other, throwing off conflicts faster than anyone can untangle them. So: add more reviewers. Add an AI to review the AI. Coordinate the bots better. Many hands make light work, goes the thinking — just get more hands in there.
That theory is tidy. It’s also wrong.
A recent study of nearly a million AI-authored pull requests tested it directly: do repositories running several agents at once actually see more conflicts than repositories running one? The answer was no. Conflict rates in both setups came out basically the same. If anything, spreading work across more agents diluted the friction slightly instead of piling it up. Whatever’s slowing everyone down, it isn’t a headcount problem — artificial or otherwise.
What the same research found instead is quieter, and more interesting: friction sticks to the *repository*, not the agent. Some codebases just carry a tax on every contribution that touches them — slow merges, repeat rounds of review, work bounced back for rewrites — no matter who’s contributing, human or AI. And when you compare AI-written and human-written work inside the same repos, controlling for size, age, team maturity, everything you’d think to control for, the AI-authored work still concentrates that friction roughly twice as much as the human work does. Same repo. Same rules. Different weight.
I think that’s because code was always a stand-in for something else — a shared mental model, built up between people, of why the system looks the way it does. The code is just the visible residue of that understanding. When a human writes a change, that understanding usually exists somewhere: in their head, in a Slack thread, in the muscle memory of having broken this exact thing before. A reviewer can usually find it if they go looking. When an agent writes the change, that understanding often doesn’t exist anywhere at all. It has to be built from scratch, every time, by whoever’s reviewing — which is slower and heavier work than just checking whether the logic holds. You’re not reviewing code anymore. You’re reverse-engineering intent.
Which reframes the “now what.” Hiring more reviewers treats this like a capacity problem, and capacity problems get solved with capacity. But if the real cost is rebuilding missing understanding, the fix looks less like staffing and more like documentation — the kind most teams have never had to write before, because they never needed it. A durable, searchable record of *why* a change happened, sitting right next to the change itself, written so a stranger — human or otherwise — could actually use it six months out. Not a commit message. Not a prompt that scrolled off someone’s screen an hour after it did its job. Something that survives.
Measure twice, cut once was never really advice about the cutting. It was advice about the measuring — the slow, unglamorous part that’s easy to skip once the cutting gets cheap and fast. We’ve spent two years making the cutting extraordinarily fast. Nobody’s figured out yet who does the measuring, or how, or whether we quietly stopped doing it altogether.
