The Ratios Shift, But the Real Work Stays
"Coding is 20% of the work. Testing and everything else is 80%." Most engineers will nod at this and then act like closing a PR means the job is done. AI is making that self-deception harder to maintain.
When code generation gets 10× faster, it doesn't make software delivery 10× faster. It makes the 20% faster. The 80% is still there: alignment, planning, scoping, code review, validation, debugging, and the ongoing work that doesn't stop once a feature ships. Speed up one part of a pipeline and you don't accelerate the whole thing. You surface where the next constraint lives.
This isn't a new observation. DORA research has shown for years that the teams that improve most aren't the ones that type faster. They're the ones that invest in deployment pipelines, review culture, and test coverage. What's changing is that the implementation gap is closing fast, which means those other factors are increasingly what separates high-performing teams from the rest.
The downstream pressure is real and specific. More code is being produced, but the processes for checking it haven't scaled with it. Review queues back up. A senior engineer I worked with described it plainly: the time AI saves in initial implementation often gets consumed in extended review, fact-checking, and remediation. Net zero, or close to it.
Some of this is a temporary adoption problem. Teams haven't yet built the habits and tooling to validate AI-generated code efficiently. But some of it is structural. The model doesn't know your system. It doesn't know why something is the way it is, or what other parts of the codebase depend on a given assumption. Catching those mistakes requires the same judgment it always did.
There's a version of this that lands wrong: "AI doesn't actually help because it creates review overhead." That's not the point. The point is that you don't get the gains by treating AI as a code vending machine and skipping the parts that were always expensive. The gains come when generation speed and validation quality move together.
One line from a Pragmatic Engineer reader thread stuck with me: "It's not Claude's fault you don't do adequate planning or design." Good software engineering was never mostly about writing code. AI didn't change that. It just made the gaps harder to ignore.
Part 3 of 14 — What I Think About AI Engineering**
← Where AI Helps (and Where It Doesn't) Faster Output Demands a Higher Quality Bar →