Field guide
How to review AI-generated code.
Review generated code as untrusted implementation, not as a trusted answer. Recover the intended contract, inspect the surrounding system, build counterexamples, and require evidence before merge.
By Łukasz Szafrański · 7 min read
Why ordinary review is not enough
Generated code is optimized to look locally coherent. The difficult failures live outside that local view: an unchanged caller, a lifecycle transition, a configuration edge, or an assumption encoded in another repository. A diff-only skim is therefore weakest exactly where the output is most persuasive.
The six-step review workflow
- 01
Recover the intent
Write down the behavior the change is meant to preserve or introduce. If the contract is unclear, review cannot distinguish an implementation bug from a requirements gap.
- 02
Inventory the blast radius
List changed files, public interfaces, schemas, configuration, dependencies, state transitions, and unchanged callers affected by the change.
- 03
Check the boundaries first
Prioritize authorization, path handling, serialization, lifecycle, concurrency, resource cleanup, and error behavior. Plausible happy-path code is the easiest output for a generator to imitate.
- 04
Turn claims into counterexamples
For each suspected defect, construct the smallest input or state that should break the proposed behavior. Prefer repository-native tests and tools.
- 05
Separate discovery from publication
A suspicion can guide investigation; it should not become review feedback until source and consequence support it.
- 06
Bind the decision to the head
Record the exact commit, what was executed, what was unavailable, and whether later commits made the review stale.
A compact review checklist
Contracts
Inputs, outputs, errors, compatibility, and serialization still match callers and documentation.
State
Transitions remain valid under initialization, retries, partial failure, and reordered events.
Security
Trust boundaries, authorization, secrets, paths, parsing, and dependency changes receive explicit attention.
Resources
Files, sockets, locks, memory, transactions, and background work close on every path.
Concurrency
Shared state, cancellation, ordering, idempotency, and stale reads have a defined outcome.
Build and tests
The changed contract compiles and representative tests fail for the counterexample before the fix.
Do not ask the authoring model to certify itself
Self-review can find superficial mistakes, but shared blind spots remain shared. Independent prompts and models help discovery; deterministic tools, exact source, and project-native checks provide a different kind of evidence.
Automate the evidence, not the decision
Veridical applies this workflow to GitHub pull requests and keeps the exact-head review receipt beside the code. Maintainers still decide what ships.
See how AI code review works