The speed at which AI generates code has officially surpassed our capacity to review it. For decades, the bottleneck in software engineering was writing the code. Today, the bottleneck has shifted entirely to trusting that the code can run effectively in production and actually solve the business problem.

But let's be honest: humans never truly scaled code review anyway.

Throughout my career, I have observed developers approving PRs or MRs that contain critical bugs. When they do engage in the review process, they often focus on stylistic issues. Why does this happen? Because reviewers are overloaded with their own backlogs to manage, and often choose the path of least resistance by saying, "Looks good to me."

Now, we are trying to solve this by throwing AI at the problem!

The Missed Reality: Code Review Wasn't Built for the AI Era

Code review - whether conducted by a human or an LLM - was not designed for this era of autonomous coding. Code review does not actually verify whether the code accomplishes what was prompted, nor do they confirm that the code aligns with its intended specification or that an agent’s "task completed" claim is deterministically true. Even a well-conducted review adhering to the 5-axes best practices (correctness, architecture, security, readability, and performance) falls short. Rarely does a code review verify that the original acceptance criteria were met or that the AI agent didn't deviate from the scope just to finish the PR. LLMs notoriously defer hard, multi-step, or dependent tasks, which means that the intent itself has diverged. Furthermore, reviewers rarely verify that test coverage was maintained or check if the AI agent quietly weakened the tests along the way to secure a passing PR.

This leads to a critical question: Even if a human reviewer or an LLM could effectively manage all these new checks, can they realistically and deterministically do so given the massively increased speed of AI code generation?

The solution? We have to move from opinion-based review to evidence-based verification.

This means building guardrails (what I call the claim checker) that bind the original intent to deterministic evidence: ACs (intents) checks, the builds, the tests, the five-axis code review, the scans, the blast radius of the code change, the docs coverage, requirements are complete and don't contradict each other, and the monitoring coverage in the code.

AI can advise. But only evidence should decide whether to merge or not!

It’s a shift we probably should have made years ago. But with agent loops writing code at machine speed, it is now the only way forward.