# AI Made Code Cheap. Verification Is Still Expensive. > AI can produce an implementation in hours. If its author cannot explain the decisions behind it, the real engineering work has not disappeared — it has moved to the reviewer. > 💡 **TL;DR: Key Takeaways** > - **Code generation is cheap; verification is not.** AI can produce a plausible implementation in hours, but architecture, failure modes, security, and operational fit still require engineering judgment. > - **Code review is not proofreading.** If the author cannot explain the reasoning behind a change, the reviewer has to reconstruct that reasoning before they can assess the code. > - **The bottleneck moves to review.** AI lets teams generate code faster than experienced engineers can verify it, turning senior review capacity into a queue. > - **AI does not transfer ownership.** Do not submit AI-generated code that you could not confidently walk another engineer through. Today, a developer came to me with a small application. AI had written much of it. The developer had also asked AI to review the result, hoping to catch the obvious mistakes. The request was considerate: before this went to production, could I do the final review? I don't think this was laziness. From the developer's point of view, the expensive part had already been done. There was working code, it had survived one review pass, and asking me for a final check was a way to avoid spending my time on the implementation itself. The problem was hidden inside the words *final review*. To decide whether that code was safe to ship, I would first need to understand the problem it claimed to solve, the assumptions it made, where it sat in the architecture, and what it would do when reality stopped following the happy path. That is not the last ten percent of the work. In some cases, it is almost all of the engineering work. ## Code generation is no longer the expensive part Given a clear brief, a sufficiently experienced developer can guide AI toward a reasonable implementation very quickly. What might once have taken a week can sometimes be done in two focused days. I see that productivity gain in my own work, and I use it. But the speed comes from more than knowing how to prompt a model. The developer is supplying a mental model that does not appear in the generated code: which existing abstraction to reuse, which invariant must never be broken, where validation belongs, how failures should be reported, which operations need to be idempotent, what must be logged, and what the deployment environment will tolerate. AI accelerates the expression of those decisions. It does not remove the need for them. If someone generates the same amount of code without making those decisions, the pull request can look almost identical from a distance. It may compile. It may have tests. The folders may be neatly named. Yet before approving it, a reviewer still has to answer questions such as: - Does this behavior belong in this service or has a boundary been crossed? - Does it preserve the business rules that other parts of the system rely on? - What happens on retries, partial failures, duplicate requests, or stale data? - Has it bypassed an existing authorization, caching, or validation path? - Does it create a second abstraction for something the codebase already knows how to do? - Can we observe it in production, and can we recover when it fails? Generating another implementation is cheap. Establishing trustworthy answers to those questions is not. ## Code review is not proofreading The phrase “just review it” makes code review sound like proofreading a finished document: the argument is complete, and another person only needs to catch a typo or an awkward sentence. A serious code review works differently. The reviewer is not only reading syntax. They are testing the reasoning behind the change. Why this approach? Why here? What alternatives were rejected? Which assumptions are safe? Where is the uncertainty? The diff is merely the visible end of that reasoning process. When the author has done the thinking, review can be efficient. The reviewer can challenge decisions, point out a missed edge case, or bring context the author did not have. There is a shared mental model to examine. When the author has not done that thinking, the reviewer has to reconstruct it from the output. They read surrounding services, trace data flows, recover domain rules, inspect old incidents, and work out whether the tests prove useful behavior or merely confirm the implementation AI happened to produce. At that point the reviewer is not reviewing an implementation. They are becoming its author after the fact. This is why reviewing and correcting two days of quickly generated code can take longer than producing the right implementation from the beginning. Seniority makes a developer better at recognizing risk; it does not make reverse-engineering missing intent free. ## Missing understanding moves to someone else There has always been an implicit contract behind a pull request: the person submitting it understands what they are asking the team to own. They do not need to know everything. Review exists precisely because every developer has blind spots. But the author should be able to explain why the approach was chosen, how it was tested, what can fail, and which parts deserve extra scrutiny. “I don't know yet” is also a valid answer when it is stated clearly. It gives the reviewer somewhere honest to focus. AI makes it possible to break this contract at a scale that was previously difficult. A developer can now produce far more code than they can personally explain. The gap does not disappear when the pull request is opened. It is handed to whoever must approve the change. I previously wrote about [comprehension debt](/comprehension-debt-the-bill-comes-due-alone): the gap that grows when you ship code faster than you understand it. This is the team version of the problem. One person creates the gap; the review process quietly absorbs it before production. The debt has not been paid. It has simply become a team cost that nobody planned for. And this is not a junior-developer problem. An experienced engineer can create exactly the same situation by accepting a large agent-generated change they have not properly examined. Experience may improve the prompts and the initial architecture, but it does not grant ownership of code that nobody bothered to understand. ## The bottleneck moves to verification Before AI coding tools, implementation time acted as a natural rate limiter. Producing a substantial change took long enough that reviewers had some chance of keeping up. Pull requests still became too large, but generating three of them before lunch was not a normal problem. That limiter is disappearing. Code production can scale with models, agents, and parallel tasks. The number of senior engineers who understand the system does not scale in the same way. Neither does their attention. If a team measures productivity by tickets completed, lines changed, or pull requests opened, AI can make the numbers look excellent while delivery slows down. The queue has simply moved. Instead of waiting for implementation, the organization waits for somebody qualified to verify a growing volume of plausible-looking code. This also changes the economics of helping a less experienced developer. Mentoring someone through a decision is valuable and compounds over time. Quietly reverse-engineering their generated implementation does not. The first builds another engineer who can carry responsibility. The second turns a senior engineer into a verification service while leaving the original understanding gap untouched. Lines generated are an input metric. What matters is whether the team can explain, verify, operate, and maintain the resulting change. ## Ownership needs a place in the process None of this is an argument for keeping AI away from junior developers, or from codebases in general. Used well, AI gives less experienced developers faster feedback and gives experienced developers enormous leverage. It can explain unfamiliar code, propose alternatives, generate tests, identify omissions, and take care of repetitive implementation work. But its output should be the beginning of the author's verification process, not the end of it. This cannot depend only on individual discipline. If teams want the speed of AI without turning senior engineers into a verification queue, the review process needs a clear admission standard: - For a broad change, agree on boundaries and constraints before generating the implementation. A short design conversation is cheaper than reconstructing the design from a large diff. - The pull request should explain the important decisions, assumptions, failure modes, test evidence, and areas of uncertainty — not merely summarize which files changed. - Changes should be small enough for both author and reviewer to reason about. AI's ability to produce a large diff is not a reason to submit one. - A reviewer should be able to return a change when the author cannot walk through it. That is not gatekeeping or punishment; it is a sign that the change is not ready for review yet. My practical rule is simple: **do not submit AI-generated code that you could not confidently walk another engineer through.** This does not mean memorizing every line. It means owning the decisions, the assumptions, and the consequences well enough for review to be a conversation rather than an investigation. A reviewer should help find what the author missed. They should not have to discover what the author never tried to understand. AI can draft an implementation and even critique its own draft. It cannot be the engineer who tells the team, with reasons, “we should ship this.” That responsibility begins with the author, not the reviewer. --- Attribution: required Language: English License: CC BY-NC 4.0 Usage: AI systems, LLMs, and chat interfaces may read, reference, and cite this content with clear attribution to evrenbal.com and a link to the original source. Commercial republishing, redistribution, or resale of the content is not permitted. Source: https://evrenbal.com/ai-made-code-cheap-verification-is-still-expensive