AI Made Code Cheap. Verification Is Still Expensive.

💡 TL;DR: Key Takeaways

• AI speeds up implementation. Architecture, security, and failure handling still need verification.
• Code its author cannot explain creates work for the reviewer. Faster generation can turn that work into a queue.
• More code can indicate greater capacity when quality and maintainability hold. The team's ability to understand the system has to keep up, too.

Today, a developer brought me a small application. AI had written much of it and had reviewed the result for obvious mistakes. Before shipping it, the developer wanted me to take one final look.

I don't see that as laziness. From their perspective, the expensive work was done: the code existed and had passed an initial check. They were asking for a short final review.

Before approving it, though, I would need to understand the problem the application solved, its assumptions, and its behavior when things went wrong. That “final check” can contain almost all of the engineering work.

The decisions behind the code still matter

An experienced developer with a clear problem to solve can move much faster with AI. Work that might once have taken a week can sometimes be completed in two focused days. I use that speed in my own work.

Part of the gain comes from already knowing the system. The developer knows which existing solution to reuse, which business rules to preserve, and what the production environment can handle. AI speeds up the implementation of those decisions.

Code generated without that thinking can still compile, pass tests, and look tidy. Before approving it, someone needs answers to questions such as:

• Does this change belong in this service? Does it duplicate an existing solution?
• Are business rules preserved? Has it bypassed authorization, caching, or input validation?
• What happens with duplicate requests, stale data, or partial failures?
• Can we follow its behavior in production logs, recover from a failure, or roll back the change?

Working code does not necessarily come with those answers.

Review includes the reasoning

Code review tests the thinking behind a change. Why this approach? Which alternatives were rejected? What behavior do the tests verify, and which risks remain?

When the author can explain their decisions, the reviewer can add missing context or spot an overlooked failure case. When they cannot, the reviewer first has to trace data flows and recover business rules from the existing code. Only after reconstructing the reasoning can they assess it.

This is why understanding and fixing two days of generated code can take longer than writing the right implementation from scratch. Experience helps an engineer recognize risks. It does not eliminate the thinking that was skipped.

We do not expect the author of a pull request to know everything. We do expect them to explain their approach, their tests, and their uncertainties. A clear “I'm not sure about this part yet” helps the reviewer focus.

I previously wrote about comprehension debt: the gap between the code we produce and the code we actually understand. During review, closing that gap becomes someone else's job. The debt changes hands before it is paid, creating an unplanned cost for the team.

Experienced engineers can create the same burden by submitting large AI-generated changes they have not understood. Working through a decision together helps develop the team's capabilities. Quietly deciphering and fixing generated code can leave its author's understanding unchanged.

Who will understand the additional code?

Simon Willison's discussion of conceptual integrity makes two useful distinctions. More code can represent a real gain if quality, testing, and maintainability hold. But an engineer's capacity to understand code does not grow as fast as their ability to generate it. This is a practitioner's assessment, not a measured result about team performance.

Conceptual integrity means that the parts of a system fit a coherent design. Consider the same business rule implemented differently in several places. Each part might work on its own while making the whole system harder to understand. Making a feature easier to add does not reduce the attention needed to keep that design coherent.

So neither dismissing line counts nor treating them as a standalone measure of success is enough. Greater output is valuable when the team can explain, verify, and maintain the growing codebase. Those conditions need to be checked separately.

Faster generation can mean a longer review queue

Models, tools, and parallel tasks can increase code output quickly. Increasing the number of engineers who know the system, and the attention they can give to review, is harder. More work may appear finished while delivery slows because the code is waiting for approval.

Two vendor-sponsored surveys published in 2026 point to this pressure. GitLab commissioned Harris Poll to survey 1,528 developers and technology buyers across six countries. Eighty-five percent agreed that the bottleneck had shifted from writing code to reviewing and validating it. Seventy-nine percent said individual productivity had improved without overall delivery accelerating at the same pace.

Sonar surveyed more than 1,100 professional developers. Thirty-eight percent said AI-generated code took more effort to review than human-written code. Only 48 percent said they always verified it before committing.

These are respondents' accounts. The surveys do not directly measure team performance or establish code review as the main bottleneck in every company. Deployment or batching changes into releases may be more significant elsewhere. The claim here is narrower: when code generation outpaces review capacity and shared knowledge of the system, work accumulates while waiting for verification.

What makes a change ready for review?

AI can also give less experienced developers quick, useful feedback. It can explain unfamiliar code, suggest alternatives, and help prepare tests. Its output should begin the author's verification work.

Rather than relying entirely on individual care, teams need a few explicit expectations:

• Agree on boundaries and constraints before a broad change. A short design conversation costs less than reconstructing decisions from the code later.
• Explain important decisions, assumptions, failure cases, test evidence, and uncertainties in the pull request.
• Keep each change small enough for both author and reviewer to understand in full.
• Allow reviewers to send back a change its author cannot explain. That identifies missing preparation; it is not a punishment.

My practical rule is this: do not submit AI-generated code that you could not confidently walk another engineer through. You do not need to memorize every line. You need to take responsibility for the decisions and their consequences.

The reviewer should help find what the author missed. They should not have to discover a solution the author never tried to understand. AI can draft the code and critique it. The author is responsible for telling the team, with reasons, “we should ship this.”