AI code review that fixes instead of flagging

The review loop has a known shape: the implementer sends work for review, the reviewer flags a problem, the task goes back to implementation, someone fixes it, it comes back for another pass. Repeat until the reviewer stops finding things.

For issues that actually warrant that cycle — the wrong abstraction, a security hole, a logic bug that touches several files — the loop is correct. Stopping progress is the point. The cost of another round is cheaper than shipping the wrong thing.

But most review findings are not those. Most are: a variable that could be named better, a comment that got stale, a hardcoded string that should be a constant, a missing null check, a formatting inconsistency the linter almost caught. These are not "back to implementation" items. They are three-line edits. The value of catching them is real. The value of sending them through a full loop is not.

An AI reviewer that can only flag and never fix has one mode: kick it back. And so for every small, obvious, low-risk finding, you run the full cycle anyway — re-queue the task, start another implementer pass, wait for it to finish, come back for re-review — not because the problem demanded it, but because that is the only tool the process offers.

the cost of a loop on a trivial change

The direct cost is latency. A fix that could be applied in two seconds requires a full implementation round-trip: re-establish context, confirm the scope of the change, make the edit, run tests, return for review, re-read the diff, approve. On agent time, that is minutes and API spend. On human attention, it is a context switch — you go from "almost done" to "back in progress."

There is also a subtler cost. When every finding — major and minor — routes through the same re-implementation gate, review becomes noise. Teams learn to expect that a review means more work regardless of significance. The gate gets treated as a formality. A process that makes trivial findings expensive is one that trains people to skip review to avoid the tax.

The goal of review is for significant findings to land. That is harder when the process makes even trivial findings expensive.

what "safe to apply" actually means

The distinction is not between small and large changes. A small change in the wrong place can introduce a regression. The right question is: is the finding unambiguous, is the fix bounded, and is the risk of applying it inline lower than the risk of a full round-trip?

A variable renamed to match a naming convention. A missing return type annotation. A comment referencing a function that no longer exists. A guard clause explicitly requested during the review. These share three properties: the correct change is obvious (no design judgment required), the scope is bounded (one or two lines, no ripple effects), and the fix carries no meaningful risk of introducing new bugs.

Contrast that with: the service is abstracted incorrectly and needs restructuring; the caching strategy is wrong and touches the data layer; the test setup does not cover the critical path and requires new fixtures. These are not review-time fixes. They require the context, time, and deliberation of an implementation pass. Sending them back is the right call.

when the builder requests a fix during review

There is a second case: the builder reads the reviewer's output and says "and also can you change X?" — a specific, bounded request while the review is open, not a new concern surfaced later.

In a manual workflow this is natural. In an agent workflow it is awkward. The reviewer is a separate process that already ran, so "also change X" means either re-opening implementation (expensive) or asking the reviewer to handle it (only possible if the reviewer can act, not just report).

An agent reviewer that can apply requested changes inline makes this case clean. The request is small and specific — same criteria as before — so the reviewer applies it, and the review concludes without a round-trip. The builder's intent is respected without a full loop.

keeping the loop for what it is for

Inline fixing is not a way to skip review discipline — it is an extension of it. The reviewer still gates. Major findings still block. The distinction is between findings that warrant escalation and findings that can be resolved at the point they are found.

The failure mode to avoid is a reviewer that applies fixes beyond its authority: refactoring an approach because it "could be cleaner," resolving ambiguous requirements by picking one, expanding scope to handle edge cases that were not requested. That is a reviewer doing implementation work, and it undermines both stages. It is also exactly the failure an agreeable AI agent is prone to — smoothing things over rather than stopping.

The criterion has to be narrow: the correct change is unambiguous, the scope is bounded, and any reasonable person would agree it is the right one. If any judgment involved goes beyond "fix the literal problem," the reviewer stops and loops back.

This is also why the reviewer needs to be a distinct context from the implementer. A reviewer that carries the implementation context is just the author reviewing its own work — anchored to the same assumptions, inclined toward the same conclusions. Inline fixing only has value when the reviewer genuinely has independent judgment. Without that separation, "applies the fix" is indistinguishable from "rationalizes its own output." For more on that dynamic, see why AI coding agents need hard stage boundaries — the stage discipline problem and the review-loop problem are the same problem in different forms.

in practice

For what it is worth, this is the model defract uses for the review stage, so treat it as one implementation rather than a universal recommendation. The reviewer agent handles small, low-risk fixes directly — including ones the builder requests during review — without looping back to implementation. Major findings block and loop. The gate holds; it just does not loop on things that do not need it.

If you are building your own review flow with Claude Code or another orchestrator, the mechanics here apply regardless of tool: define what counts as inline-safe, define what escalates, and build both paths into the process rather than defaulting to flag-and-loop for everything. The test is the same as the one for running parallel agents — every piece of the process should have a clear lane and stay in it.