Verification Is the Bottleneck in AI-Assisted Development

About half of what AI generates for me is usable. Some days I can’t tell whether augmentation is faster than just doing the work myself.

That’s an uncomfortable thing to publish when the prevailing story is that these tools are an unambiguous multiplier. But I’ve been running augmented development daily for long enough to have a felt sense of the ratio, and I’d rather start from the honest number than the marketing one.

The number splits, though, and the split is where it gets interesting.

Ninety-five percent, and fifty

Pipeline work lands close to 95% right on the first pass. YAML, GitHub Actions, agentic workflows driving the GitHub CLI to update and test workflows once they’re on main — that has been genuinely excellent. I revise, but I’m revising details, not architecture. It’s the same category of work where I finally got CI/CD running after three years of failed attempts.

Web application code runs somewhere between 50% and 75%. None of it is shippable immediately. All of it gets revised. Some of it is completely wrong.

The obvious reading is that the tools are better at one thing than another. The more useful reading is that I’m measuring two different systems.

What the accept rate actually measures

The wrong-but-useful category is the one I don’t discard. When the generated code is mostly wrong, it still tells me what to correct. It collapses the search space. It gives me something to argue with, which is faster than an empty file and a blank stare.

So the accept rate isn’t measuring correctness. It’s measuring direction. A 50% draft that points the right way can beat a blank editor — and it can also be worse than one, if I can’t tell which half I’m holding.

That “if” is the whole thing. It isn’t a model problem. It’s a verification problem. I suspect a lot of people reporting that these tools underperform are counting the wrong stock — how much output survived, rather than how fast a cheap wrong answer got them to the right one.

The rule, and the test I ran against it

Here’s the pattern I think I’m seeing: AI leverage is proportional to how cheaply you can verify its output.

Pipeline work verifies itself. The workflow runs or it doesn’t. The test passes or it fails. Feedback arrives in seconds, it’s automated, and it’s unambiguous. That’s why the accept rate is 95% — not because the model knows YAML better, but because the wrong answers get caught for free and never reach my judgment at all.

Application code has no such loop. Correctness depends on intent, on context the model can’t see, on decisions made ten years ago for reasons that aren’t obvious in Git history or wiki documentation. Verification is human, slow, and bounded by expertise.

Except there’s a competing explanation I can’t wave away. Pipeline YAML is also short, highly conventional, and enormously well represented in training data, and my application code is idiosyncratic. Both explanations predict exactly the same split — and “use it where the problem is conventional” is a much weaker claim than “use it where verification is automated.” So I went looking for cases where the two come apart.

The Tailwind v3 to v4 upgrade on this site is one. That’s application code — my own markup, forty pages of it, idiosyncratic in exactly the way a training set doesn’t reward. But verification was almost free: render every page before, render every page after, diff. Nearly all of them came back byte-identical, and the handful that moved surfaced immediately. Unconventional problem, automated check, and I shipped it — not because I trusted the output, but because the diff did the trusting for me.

The mirror case is schema markup and meta tags across the archive. That’s boilerplate, about as patterned as output gets, and the model produced it fluently. But none of it could be checked locally. Correctness meant waiting on a crawler and on Search Console, and search visibility is precisely where I’ve been burned by a problem I couldn’t see — so fluent-looking output was the last thing I could take on trust. Conventional output, expensive verification, and work I sat on because I couldn’t confirm it.

Conventionality didn’t predict the outcome in either case. Verification cost did. That’s two data points, not a law, and you should run the same test against your own work rather than take my split as one. But it’s enough that I’ll stop hedging.

Where it breaks down: code review

AI code review is the clearest case of the constraint moving.

It works. It catches real things. It also produces substantially more findings than a human reviewer — we have more than one AI reviewer configured, at whatever depth you point it at — and each finding is individually plausible. That combination is worse than fewer findings, because triage cost goes up while signal density goes down. What we thought would help turned into a volume of information we weren’t equipped to validate, sitting on top of the code we already had to review ourselves.

We relieved the constraint we thought we had. Generation capacity scaled. Review capacity didn’t, because review capacity is bounded by human expertise and attention, and expertise doesn’t improve on a weekly release cadence. In the 20/60/20 split I’ve written about before, the human’s value concentrates at the edges — planning and review. These tools made the middle enormous without widening either edge.

The failure mode most worth instrumenting against is hallucinated causality. Ask why something keeps recurring and you’ll get a mechanism: fluent, plausible, untested. Systems narratives are the highest-risk output category precisely because they’re the hardest to falsify — it’s the same fluent-confident-wrong failure I’ve written about when a model answers from the one page it happened to index, just wearing different clothes. Pair every generated causal claim with what observation would disconfirm this, or you’ve automated astrology.

Framing doesn’t delegate either — where the boundary sits, what the system is for, what counts as done. Ask a model to set those and it will hand your existing frame back to you in more confident prose than you’d have used yourself. That’s an argument I’ve already made and won’t re-run here.

The team problem is an information problem

We’re aligning on an AI augmentation strategy right now, across cross-functional teams and contractors in several time zones. My instinct was that the answer is training — certifications, office hours, share the good patterns, level up the technique. In practice those sessions are show-and-tell: I learn about a new tool every time and never about a shared standard.

I think that instinct is wrong, or at least low-leverage.

I know my accept rate by feel. I don’t know anyone else’s, and nobody knows mine. Everybody using these tools believes they’re the careful one, which means the whole team is operating on private, unverified impressions of its own effectiveness. That’s not a skill gap. It’s a missing feedback loop.

The higher-leverage move is making the accept/revise/reject decision visible — a shared record of what got taken clean, what got rewritten, and what got thrown out, by task type. It converts a suspicion into data. It also turns individual technique into something transferable, instead of something each person has to rediscover.

Donella Meadows ranks intervention points by leverage, and the ordering is counterintuitive: adjusting numbers sits near the bottom, while changing information flows and rules sits considerably higher.

Remember, always, that everything you know, and everything everyone knows, is only a model. Get your model out there where it can be viewed. Invite others to challenge your assumptions and add their own.

— Donella H. Meadows, Thinking in Systems: A Primer

Buying more licenses is a parameter. Changing what gets verified and who reviews what is a rule. Making the accept rate visible is an information flow. Only two of those move the system, and most enterprise AI programs are pure parameter — buy seats, count usage, report adoption — and then wonder why nothing structural changed.

The part I’d rather not write

Some of the code reviews are above my head. Not hypothetically. Now. I’m a senior technical lead with twenty-plus years in this, and there are AI-generated review comments I cannot independently evaluate — I have to ask other developers whether a finding is even true.

At some point — I don’t know when — it’s going to write code I can’t review at all. I don’t have a resolution for that, and I’d be suspicious of anyone who claims to. But I know which direction the answer isn’t. It isn’t more generation. Every increment of generation capacity we add makes the verification gap wider, and verification is the thing that was actually scarce the whole time.

The models keep getting better. The question that decides whether that helps is whether we’re building the capacity to know when they’re wrong.

Don’t Automate the Rube Goldberg Machine — The pipeline work the 95% is measured on, and why eliminating beats automating.
Outsource the Task, Never the Thinking — What delegates and what doesn’t, argued at length.
If Humans Are a Rounding Error, Who Is Your Website For? — The same failure at the data layer: a fluent, confident, wrong answer with no signal anything was missed.
The Contractor Nobody Signed Off On — What happens when the spend on generation capacity finally gets counted.
Choosing the Right AI Coding Tool — For the tool sprawl problem this post declines to solve.
Innovation Breaks Things. Culture Eats Strategy. — Why the org-level version of this is never a training problem.