Sample content: This article exists to exercise the publishing system. It is not presented as Patrick’s writing.
Using AI in Code Review Without Outsourcing Judgment
A sample workflow for using automated review to widen attention while keeping engineering intent and accountability with the team.
Automated review is good at sustained attention. It can look for repeated patterns, missing branches, naming drift, and familiar hazards without getting tired. That does not make it the owner of the decision.
The useful role is a second set of tireless eyes, not an oracle and not a replacement for authorship. A reviewer—human or automated—needs the intent of the change, the local conventions, and a way to distinguish a real risk from a generic preference.
Give the reviewer the contract
Copy link to section “Give the reviewer the contract”Review quality improves when the change includes its intended behavior and constraints.
change:
outcome: "Search results update after a short pause"
must_preserve:
- keyboard navigation
- no index download on article pages
evidence:
- browser interaction test
- generated index size reportThe contract does two things. It helps the automated reviewer focus on what matters, and it gives the human reviewer a standard for evaluating the findings. Without it, both can spend time debating code style while missing that the implementation violates the product behavior.
Repository guidance should supply durable context such as test commands, security boundaries, naming conventions, and generated-file rules. The change description should supply what is unique to this patch.
Separate findings from decisions
Copy link to section “Separate findings from decisions”An automated reviewer can report that a function has no timeout. A person still needs to decide whether the operation has a meaningful deadline, what failure should look like, and whether the extra machinery improves the system.
Ask the tool to label confidence and evidence separately. A finding supported by a specific call path and failing test deserves different attention from a broad statement that “timeouts are a best practice.” Plausible language is not evidence.
A practical review queue might separate findings into:
| Category | Human question |
|---|---|
| Contract violation | Does this contradict required behavior? |
| Demonstrated defect | Can we reproduce the failure? |
| Maintainability risk | Is the local complexity worth the benefit? |
| Suggestion | Does this improve the code without needless churn? |
This prevents a long list of low-value suggestions from obscuring one consequential issue.
Review the review
Copy link to section “Review the review”Treat generated findings like any other external input: reproduce the concern, inspect the relevant context, and record why the team accepted or rejected consequential advice.
Reviewers should also inspect what the tool did not mention. Does the change match the architecture? Are the tests meaningful rather than merely present? Is a new dependency justified? Does the interaction work with a keyboard? Those questions require a model of the whole product.
Tune the reviewer with real misses
Copy link to section “Tune the reviewer with real misses”When the team finds a defect after review, ask whether a durable rule could have caught it. Add project context, a focused test, or a validation step when the pattern is likely to recur. Do not respond to every miss with a longer universal checklist.
Also remove guidance that produces noise. A reviewer that flags dozens of irrelevant preferences trains people to ignore it. Precision builds trust; volume does not.
The accountable person remains the person who approves and ships the change. AI can widen attention and reduce repetitive review work. Judgment is the act of deciding which evidence matters in this system, for these users, under these constraints.
