
I know that's somewhat hyperbolic. I'll give it a second to land anyway.
I was once the code review gate for multiple development teams. Coming in cold to different languages, different codebases, trying to understand problems I wasn't close to. What I actually reviewed were the patterns I could recognize across all of them: how they handled external systems, endpoint structure, error handling, obvious procedural gaps. The friction of the gate probably made teams prepare more carefully. That may have been the real value.
Now picture that gate when AI is writing code at a pace no reviewer can match.
The models are fast. They're also pragmatic in ways that create problems. I've watched them take the shortest path to make a failing test pass rather than reconsidering the approach. The test goes green. The underlying issue is still there. Iterative review passes help: security, simplification, separation of test creation from implementation. But those are layers on top of something deeper. The AI projects that look impressive often stand on validation suites that took years of human effort to build. Those test bases give AI a way to make code that runs. Even then it sometimes runs incorrectly.
I'm actively exploring scenario based validation and user satisfaction as the foundation instead of test coverage alone. Moving from "do the tests pass" to "does this actually solve the problem a user would bring to it." I don't have it figured out yet, but if code velocity keeps improving to the point that humans are the bottleneck, the answer probably isn't more humans reviewing. At best, a human reviews the critical boundaries, the ones that impact performance or open security holes
Is human gate review wishful thinking? If so, how are you preparing for it?
Written by Duane Grey
AI Strategy & Implementation
Independent AI consultant helping companies cut through hype and deploy systems that produce real results.