Review
/receive-reviewReceive review: verify, then act.
The reflex that feels like collaboration
Agreement is not yet understanding
A review comment arrives: “Good work, but cache this result.” An agreeable agent may acknowledge it and change the code immediately. A person can do the same when speed, hierarchy or a desire to look receptive takes over. The risk is not politeness. It is acting before anyone has checked whether the cached value is allowed to become stale.
Feedback is an input to judgement, not a transfer of responsibility. The person or system receiving it still has to understand the concern, inspect the relevant evidence and decide what action follows. Agreement can be the right result, but it should be earned.
A comment is a claim
Put a verify step between hearing and changing
First classify the comment. It may identify an objective defect, express a design preference, reveal a misunderstood requirement or enforce an organisational constraint. Then reproduce the concern where possible. Read the requirement, inspect the current behavior and test the proposed change against adjacent cases. This is the same principle as treating completion as a scoped claim: evidence must fit what is being asserted.
The check does not need to become a research project. A naming preference may need only alignment with the codebase convention. A security concern may require a focused test, a threat review and an accountable owner. Scale the response to the consequence.
Receive review without surrendering judgement
A comment becomes action only after it is classified and checked against evidence.
- Classify the comment Defect, question, preference, policy or new requirement.
- Inspect the evidence Reproduce the issue or examine the cited source.
- Choose a response Accept, adapt, decline or escalate.
- Implement deliberately Do not bundle unrelated fixes into the response.
- Re-verify the combined result The change can create a new failure even when the comment was correct.
Respect the reviewer by investigating the claim, not by obeying it automatically.
When the answer is no
The highest respect is taking the point seriously
Return to the caching example. Inspection shows that the value is a live account balance and the requirement says the screen must reflect every posted transaction. The proposed cache would violate that rule. A useful response is: “I tested the suggestion against the freshness requirement. The cached value remains stale after a new transaction, so I have not applied it. The repeated query is real, though. I propose batching the underlying reads and will verify both freshness and query count.”
Now take a second comment: “This service request accepts an account ID without checking whether the current user may access that account.” A focused test confirms that another user's ID can be supplied. Add the missing access check and keep the test so the defect cannot quietly return. After the change, the unrelated user receives a forbidden response while an account member still succeeds. One comment is declined with reasons; the other earns a correction. Both were taken seriously.
Why this is a harness problem
Make verification part of the review workflow
For an AI workflow, encode a small gate between “comment received” and “change made.” Restate the concern. Locate the requirement or convention. Gather evidence. Propose an action and rerun the relevant checks. This is a practical use of harness engineering: the surrounding process makes careful reception the default instead of hoping the next response contains good judgement.
Receiving review is the mirror of requesting it well. A precise request gives the reviewer a useful target. A disciplined response shows what the comment changed, what evidence supports the decision and what remains unresolved.
Where the cost lands
Update your view without surrendering your judgement
A reviewer can still hold authority under team policy. Regulated work may require a change even when the author prefers another design. If evidence does not resolve a disagreement, name the trade-off and escalate to the person who owns the requirement rather than turning review into an endless debate.
The student discipline is to let good feedback change your model of the system. The professional discipline is to keep responsibility for the evidence and the consequence. Verify, then accept, adapt, decline or escalate. Respect for review is not measured by how quickly you agree. It is measured by whether the work becomes more correct and the reasoning remains inspectable.