Human Review in an AI Workflow

A reviewer on a recent PR said the quiet part out loud:

"What's the point of writing review comments if you'll just feed them to the AI? How does that change anything?"

The same reviewer added a second discomfort:

"I wasn't part of the planning. This looks like a big feature, not a field change through the UI — a feature like this needs written requirements and a presented plan. It feels strange to write a comment about decoupling when I'm not even sure I agree with the approach."

As the platform pushes more AI into the SDLC, this feeling spreads: if the AI absorbs every comment and regenerates the code, does the human reviewer's judgment still matter, or has review become theatre? This document answers that — directly, because the anxiety is reasonable and the answer is not obvious.

The two complaints are one root cause

They look like two problems. They are one: the design conversation never happened before the code, so it is now trying to happen — late, and through a lossy channel — in PR comments.

PR comments are an excellent medium for fixes. They are a terrible medium for deciding an approach, because by the time the code exists, the approach is a fait accompli and the reviewer is reduced to objecting after the fact. The "strange feeling" of commenting on decoupling you're not sure you agree with is the symptom of using the wrong channel for the wrong job.

So the answer has two halves:

• Move the approach decision earlier — to a design doc and the PR that introduces it, before the code. That is what the Product→R&D handoff, planning docs, and the feature-needs-design policy exist to force. A reviewer who co-signs the approach in a design doc is never blindsided by the implementation.
• Make the comment channel safe for the comments that remain — by never letting a disagreement be silently applied as if it were a fix. That is the rest of this document.

Convergent vs divergent comments

The reviewer's two sentences hide a distinction the platform must name, because the AI must treat the two kinds of comment in opposite ways.

	Convergent comment	Divergent comment
Example	"Extract this into a helper." "Handle the null case." "This variable should be const."	"I'm not sure I agree with this decoupling." "Why a queue here and not a direct call?" "This whole approach feels wrong."
What it is	A clear correction with one obvious right answer.	A disagreement about the approach — a decision, not a fix.
Feeding it to the AI is…	…exactly right. Zero friction, no loss of meaning. The reviewer's judgment produced the comment; the AI just typed the fix fast.	…the failure mode. It converts a design decision between two humans into a code change without the humans ever deciding. The AI will comply — it will restructure the code to satisfy the comment — and the real question (is decoupling right here?) is never debated.
Correct handling	Draft the fix, get the author's sign-off, apply.	Stop. Escalate to a human decision. Never silently apply.

The reviewer's bird is pecking for a precise reason: a comment about decoupling is divergent, and the mechanism they fear treats it as convergent. The discomfort is correct. The fix is not to remove the AI from the feedback loop — it is to build a layer that classifies the two and protects the human decision boundary.

A review comment is worth more in an AI workflow, not less

The intuition "the AI absorbs my comment, so my comment is cheap" is exactly backwards.

When implementation is expensive, the bottleneck is typing the fix, and the reviewer's judgment is one input among many. When the AI makes implementation nearly free, judgment becomes the scarce resource and the bottleneck. A well-reasoned review comment is now the highest-leverage artifact in the loop: it is an instruction the AI will execute faithfully, consistently, and immediately. The reviewer stopped being a bottleneck on throughput and became the gate on correctness.

The danger is never that the AI absorbs the comment. The danger is a mechanism that blurs the line between "the human decided X" and "a comment got applied." The platform's job is to keep that line bright: human judgment is the gate; the AI is the executor. Under that rule, every convergent comment is applied with zero friction and every divergent comment forces a human decision — which is the most leverage a reviewer's time has ever had.

How to disagree with the AI

The divergent path is the one that matters, and it has a shape:

1. The reviewer raises a divergent comment ("not sure about this decoupling"). They are questioning an approach, not requesting a change.
2. The AI does not apply it. It classifies the comment as divergent and escalates it back to the PR author as a question, surfacing the disagreement, the reviewer's point, and the options.
3. The author decides — keep the approach (with a reason) or change it.
4. The loop closes back to the reviewer. The author's decision is posted as a reply on the reviewer's own thread, stating the human decision and its rationale — not a silent edit. If the decision is "the reviewer is right," the change is then applied. This is the code-reviewer agent's existing rule generalized: "explain the disagreement inline, don't just close it. Future reviewers — human or AI — read those threads to learn."

Step 4 is what restores the reviewer's sense of agency. They see their comment produced a human decision, visibly, on the thread — not an AI edit that silently appeared in the next force-push. The review mattered, and they can see that it mattered.

Where this connects to the rest of the platform

This is not a new philosophy bolted on — it is the explicit statement of a boundary the platform already defends structurally:

• The plan pause (/continue step 6) is the single place the loop always stops for human approval. Catching a wrong approach there is dramatically cheaper than litigating it in PR comments later. The reviewer's "I wasn't part of the planning" is a request to be present at this gate.
• The gatekeeper checks completeness, not wisdom. As gatekeeper states, it does not judge "whether the design choice is the best one — architect owns that judgment." The design judgment is deliberately reserved for a human (and the architect agent advising one). The AI never adjudicates a divergent design comment on its own.
• The Hard Floor (autonomy-model) reserves the irreversible decisions for explicit human approval. Divergent design comments are the day-to-day, reversible cousin of the same principle: the AI does not unilaterally resolve a disagreement a human raised.

The strategic doc already says the platform is "not trying to replace human judgment" (ai-engineering-strategy.md §1.5). This document is the operational form of that promise for the review surface.

The mechanism

The operational complement to this document is the /address-review skill. It implements /continue step 11 — "read the review comments, address what you can, ask the developer about ambiguous requests, do not auto-merge" — which until now was documented prose, not a wired capability. The skill:

• pulls all review comments on the PR, reviewer-agnostic (human and bot, not just CodeRabbit);
• classifies each as convergent or divergent;
• drafts the fix for convergent comments and applies it after the author signs off;
• escalates divergent comments back to the author as questions and never applies them silently;
• closes the loop by replying on the reviewer's thread with the human decision.

It replaces the earlier approach of applying a bot's comments without classification — the precise shape this document warns against when the comment is divergent. A bot-only PR still flows through it (every comment classifies convergent and applies in one batch), so there is one safe door, not two.

Anti-patterns

• Applying a divergent comment because it was phrased as an imperative. "Use a direct call here" may be a fix or a design argument. If it changes the approach, it is divergent — escalate, don't apply.
• Treating reviewer silence on the approach as agreement. If the approach was never presented before the code, silence is absence, not consent. The design-doc-before-code gate exists so the approach is reviewed when it is cheap to change.
• Closing a divergent thread with an edit instead of a reply. The reviewer must see the decision and its reasoning, not infer it from a diff.
• "The AI will handle the comments, so I'll skip the design review." The review surface is the last line, not the first. Skipping the design conversation pushes every approach decision into the lossy late channel.

Cross-references

• autonomy-model — the Hard Floor + configurable gates; the structural form of "humans own the irreversible and the contested."
• deterministic-ai — principle 4, manual workflows are first-class; the LLM is a teammate, not a replacement for judgment.
• product-rd-handoff and planning-docs — moving the approach decision earlier, so the reviewer is present at the plan, not blindsided by the PR.
• code-reviewer agent — the platform's own pre-merge review; the "explain the disagreement inline" rule generalized here.