TL;DR— Coding assistants have collapsed the cost of writing code, but the actual bottleneck in software engineering was never typing speed— it's verification. Most tooling still optimizes for generation speed, which quietly shifts cost onto review, and review doesn't scale the way generation does. The teams getting real value are the ones who've redesigned their review process around this shift, not the ones with the fastest autocomplete.
Every pitch for an AI coding assistant leads with the same number: lines of code generated, time saved typing, tickets closed faster. It's the wrong number. Typing was never the bottleneck in professional software engineering. Reading, understanding, and verifying code was. Coding assistants have made the cheap part of the job nearly free and left the expensive part almost untouched. That mismatch is why so many teams report both huge individual productivity gains and no visible change in delivery speed at the team level.
The bottleneck moved, the tooling didn't
Before assistants, the rate-limiting step in shipping a feature was usually the engineer's own thinking: designing the change, recalling the right API, remembering the edge cases. Assistants collapsed that step. You can now generate a plausible implementation of almost anything in seconds. But someone still has to confirm the implementation is correct, fits the existing architecture, and won't break something three services away. That step didn't get faster. If anything it got slower, because there's more code to check and it wasn't written by the person checking it.
This is the part of the story that gets lost in productivity benchmarks. A benchmark that measures "time to first working solution" rewards generation speed. It says nothing about the cost of the reviewer who has to reconstruct the author's reasoning from scratch, because the author is a model with no memory of why it chose one approach over another. Reading unfamiliar code has always been harder than reading your own. Assistants have quietly made almost all code unfamiliar code.
Why verification doesn't scale like generation does
Generation is embarrassingly parallel. You can have a model produce ten implementations of a function in the time it takes to write one by hand. Verification is not parallel in the same way— a human still has to read each candidate, hold the relevant invariants in their head, and check them one at a time. The gap between how fast we can produce candidate code and how fast we can validate it is the actual constraint on throughput now, and it's growing, not shrinking, as generation gets cheaper.
There's a second, subtler problem: AI-generated code tends to be locally correct and globally naive. It compiles, it passes the obvious test, it looks like code a competent engineer would write— because it's trained to look that way. It's less likely to account for a load-bearing assumption that exists only in a teammate's head, a rate limit negotiated with another team, or a legacy quirk that has no comment explaining it. That kind of tacit context is exactly what's expensive to verify against, because it isn't written down anywhere the reviewer or the model can check.
Where assistants genuinely earn their keep
The wins are real, and they cluster in a specific shape: tasks with a small blast radius and a fast, legible feedback loop. Writing a unit test for a pure function. Translating a script from one language to another. Filling in a repetitive CRUD handler that follows an established pattern. Drafting a regex, a SQL query, a config file. In all of these cases, correctness is cheap to check— the test either passes, the output either matches, the query either returns the right rows. Verification cost stays low because the surface area is small and the ground truth is close at hand.
This is also why assistants feel transformative in greenfield prototypes and demos, and merely convenient in mature production systems. A prototype has no legacy invariants to violate. A ten-year-old billing service has dozens, most of them undocumented. The assistant isn't worse in the second case— the verification cost of the surrounding system is just much higher, and no amount of generation speed changes that.
Where they quietly lose
The failure mode isn't usually "the code is wrong." It's "the code is right in isolation and wrong in context." A refactor that changes an internal API's behavior in a way that's technically backward-compatible but violates an assumption three call sites rely on. A dependency bump suggested because it fixes the stated problem, ignoring that it also drops support for something the team quietly depends on. A generated migration that's correct SQL but wrong for the actual data distribution in production. None of these show up in a linter, a type checker, or a passing test suite. They show up in an incident report weeks later.
This is architectural coherence, and it's the thing assistants are structurally bad at, not because the models are unsophisticated but because coherence lives in context the model rarely has: design docs that were never written down, decisions made in a meeting, the reason a workaround exists. Feeding more of the codebase into the context window helps at the margin. It doesn't solve the problem, because a lot of the relevant context was never text in the first place.
What verification-first tooling would actually look like
If verification is the real bottleneck, that's what the next generation of tooling should optimize for, and mostly it doesn't. Useful directions look less like "generate faster" and more like "make correctness cheaper to check." Diff-sized, single-concern changes instead of sprawling multi-file rewrites, because small diffs are verifiable diffs. Generated tests that exercise the specific edge cases the model claims to have handled, submitted alongside the code, so the reviewer isn't starting from zero. Explicit surfacing of assumptions the model made— "I assumed this function is called synchronously"— so a human can confirm or reject them in seconds instead of inferring them by reading call sites. Sandboxed execution against realistic data before a human ever sees a diff, so obviously broken candidates never reach the review queue.
None of this is exotic. It's the same discipline good engineers already apply to their own code— small changes, explicit assumptions, tests as proof, not habit. The teams getting durable value from AI coding assistants are the ones who've imposed that discipline on the tool instead of trusting the tool to have it already. Everyone else is just generating code faster than they can trust it, which is not a productivity gain. It's a review backlog with a head start.
Top comments (0)