The Review Protocol: The 80% Work

Before reviewing the code, it helps to understand why bad AI output slips past people so easily. The model does not just generate code. It also triggers predictable human habits that make rushed approval more likely.

1. Looks Right Fails Engineering

We naturally associate clean-looking output with correct logic. Because AI usually produces neat formatting, confident naming, and polished comments, our skepticism often drops too early. But a function can look professional and still contain a serious logic flaw.

2. The Automation Bias

People often give too much weight to suggestions from automated systems. If the AI produces a complex regex, a clever query, or an optimization trick, it can feel as if it knows something we do not. In reality, it may simply be producing something that looks statistically common, not something that is correct for your specific system.

3. The Sunk Cost of Review

Reading code carefully is mentally harder than pasting code quickly. When the AI gives you a large block of output, it is tempting to look for reasons to accept it so the productivity win feels real. That is exactly when discipline matters most.

A strong review should not happen in one blurry pass. Break it into three deliberate layers so you are not trying to check logic, system fit, and security all at the same time.

The order matters. Start with local correctness, then check whether the code fits the real system, and finally ask how it could fail under misuse, hostile input, or production load. This keeps the review focused and prevents shallow approval.

Pass 1: Logic Audit

In the first pass, ignore style and presentation. Walk through the code step by step like a debugger and ask whether the logic is actually correct for normal input and edge cases.

Start with boundary conditions. What happens when a list is empty, a value is null, a number is zero, or a loop reaches its last item? These are small cases, but they are exactly where AI-generated logic often breaks.

Then move to the unhappy path. AI tends to generate the successful case first and can quietly skip the else branch, the catch behavior, the retry path, or the loading and error states in a UI. If you only read the happy path, the code will often seem better than it really is.

Finally, inspect state transitions carefully. In frameworks like React or Vue, AI often mishandles stale state, closures, effects, or update timing. A useful question to keep asking is simple: if I run this line by line in my head, does every branch still make sense?

Pass 2: Integration Audit

The second pass checks whether the code belongs in your real system. AI output often looks correct on its own but still clashes with the stack, conventions, or architecture around it.

Start by checking dependency fit. Is the code using packages, helpers, or APIs that your project does not actually use? AI will often reach for the most common pattern it has seen, even if your codebase has already made different technical choices.

Then check architectural alignment. Does the code follow your project structure, naming style, error handling pattern, and data flow conventions? Code that works but ignores local architecture still adds maintenance cost, because the next engineer now has to understand both the feature and the inconsistency.

This is also the pass where hidden side effects matter. Look for duplicate requests, extra re-renders, unnecessary database calls, global mutations, or N+1 query patterns. The system-level question here is: even if this code works, does it work the way this codebase expects things to work?

Pass 3: Security and Adversarial Audit

The final pass asks how the code behaves under pressure, misuse, or hostile input. This pass matters most in high-hazard areas, but it is useful everywhere because AI often ignores consequence even when the syntax looks clean.

Begin with trust boundaries. Where does user input enter, and is it validated, sanitized, escaped, or authorized correctly before it reaches something sensitive? This is where unsafe queries, unsanitized HTML, or unchecked request data often slip through.

Next, check permissions directly. If the AI generated a route, controller, or mutation, does it actually verify that the user is allowed to perform the action? Missing authorization is one of the easiest ways for polished-looking code to become dangerous code.

Finally, think about abuse and scale behavior. Could this code trigger resource exhaustion, retry storms, memory growth, or poor performance under large input sizes? The most useful question in this pass is the adversarial one: if someone tried to break this on purpose, where would they start?

How do you know whether you truly understand the generated code? Use the Blind Spot Test.

The idea is simple: if you cannot explain the code clearly without looking at it, then you probably do not understand it well enough to approve it. AI-generated code often creates a false sense of familiarity because the formatting looks polished and the names sound reasonable. The Blind Spot Test breaks that illusion.

While explaining it, do not summarize vaguely. Be specific. Which branch handles invalid input? What state changes after the API call returns? What happens if the dependency throws? What values are returned in each path? The goal is to prove that your understanding is concrete, not impressionistic.

This test is especially useful for code that seems easy to accept at first glance, such as utility helpers, controller methods, transformation functions, or generated React logic. These are exactly the places where developers often think I get the idea without noticing the missing branch or hidden assumption.

Human review is necessary, but it is not enough. In AI-assisted engineering, automated tests are one of the strongest defenses against believable but incorrect output.

Do not let the AI generate both the implementation and the tests in the same prompt. When both come from the same assumptions, the tests may only prove that the output is internally consistent, not that it is actually correct.

A safer workflow is asymmetric. The human starts by writing a failing test based on the requirement, not on a guessed implementation. That anchors correctness in intent. Then the AI can generate code to satisfy that test. After that, the human reviews the result line by line. Only once the implementation is understood should the AI be brought back in to suggest destructive tests, unusual inputs, and edge cases that try to break the logic.

For example, imagine you need a function that applies a discount code only when the code is active and the cart total is above a minimum threshold. A weak workflow is to ask the AI for both the function and its tests at the same time. A stronger workflow is to first write a failing test such as: given an active code and a cart total of 120, apply a 10% discount and another such as: given an inactive code, do not apply any discount. Once those expectations are clear, the AI can generate the implementation against something concrete instead of inventing its own rules.

AI often solves small problems with too much code. It may introduce extra abstractions, unnecessary helpers, verbose logging, and generalized patterns that the problem does not need. Every extra line increases the amount of code you have to understand, test, and maintain.

A good default is to prefer boring, explicit code over clever code. In production systems, readability usually ages better than generated cleverness.

A small example makes this easier to spot. Suppose you ask AI to format a user display name. You may only need a simple function that joins first name and last name when both exist. But AI might generate a formatter class, multiple helper functions, extra fallback branches, and logging that no one asked for. In that case, the better version is usually the smaller one: a plain function with the minimum logic needed, easy to read and easy to test.

Production consequences still belong to the engineer, not the model. That is why review must be treated as a real technical process, not as a quick approval step.

“

The Review Protocol closes the responsibility gap. By the time you hit merge, you should understand the code well enough that it feels like something you could have written and defended yourself. If you do not feel that level of ownership, the review is not finished.”