The shift
Polish stopped being a signal.
Open a pull request from an AI-assisted build and the obvious mistakes are mostly gone. Off-by-one errors, missing null checks, unhandled exceptions — the things review used to catch are rare now. That feels like progress, and in one narrow sense it is.
But the polish that used to be a signal of care is now free, which means it’s no longer a signal of anything. Clean formatting and tidy abstractions tell you the model was confident, not that the code is right. The reassurance you used to read from well-organized code is exactly the reassurance you can no longer trust.
The relocation
The errors didn’t disappear. They moved up.
AI didn’t remove mistakes; it relocated them. The new failure category looks like this:
- Flawed architectural decisions, implemented flawlessly.
- Well-abstracted solutions to problems you didn’t have.
- Thoroughly tested implementations of the wrong design.
Each of these passes a casual read. Each is harder to spot precisely because the execution is competent. The bug isn’t in a line — it’s in the decision the lines faithfully carry out.
The new job
Review moved from "is this correct?" to "should this exist?"
When implementation quality is free, the valuable questions are upstream of it:
- What assumptions is this built on, and do they hold?
- Does the architecture match the actual need, or a guessed one?
- Who owns this data, and where are the responsibility boundaries?
- How does it behave under stress, and how does it recover when it fails?
None of those are answerable by reading for syntax. They’re judgment calls, and judgment is the one thing the model can’t hand you for free.
Why it matters
Wrong decisions don’t cost hours. They compound.
Fixing an implementation takes hours. Fixing a wrong decision costs far more, because a decision accumulates dependencies, data structures, and downstream code that all assume it was right. AI made producing implementations cheap without making decisions cheap — which means a poor foundational choice is now more dangerous, not less, because it arrives wrapped in professional-quality code that invites no scrutiny.
That’s the whole case for a review before launch. The bottleneck was never typing the code; it was deciding whether the code should have been written that way at all. A launch-readiness review is that second read — the judgment pass — delivered as a short, prioritized list of what to fix first.
More reading