A practical review guide
How to review an AI-generated pull request
A clear summary and green tests are useful inputs. A reviewer still needs to establish whether the change meets the agreed requirements, and which risks remain unresolved.
This checklist is for engineers reviewing another author’s AI-assisted change. Use it alongside your existing code review, security checks, and CI. It does not establish that a change is correct or safe by itself.
1. Recover what the team agreed
Start with the task, relevant discussion, and acceptance criteria. Write down the intended behavior and constraints that could change your decision. If two sources disagree, ask which is authoritative. Keep missing or disputed requirements visible instead of silently choosing an interpretation.
2. Pin the change and its evidence
Identify the commit you are reviewing. Check that test results and screenshots apply to that revision and the relevant environment. A passing run on an earlier commit is useful history, but it does not automatically cover later edits.
3. Compare each requirement with a concrete check
For each important requirement, record the supporting code, test, or observation, what it establishes, and what it leaves open. Read the assertion and test setup. A test name can promise more than the test actually exercises.
Example: retries and duplicate invitation emails
Suppose the requirement is “retrying an invitation must not send a second email.” A test sends two requests in sequence and observes one email. That supports the sequential case. It does not establish what happens when two requests arrive concurrently, or when delivery succeeds but the response times out.
The useful review question is specific: where is concurrent admission controlled, and what evidence exercises that boundary? Ask for a check tied to the mechanism and failure mode. Do not treat the absence of a concurrency test as proof that the implementation is broken.
4. Inspect failure behavior and affected callers
Trace the paths that could invalidate the agreement: retries, partial failure, permission changes, and unchanged callers of a modified contract. Prioritize cases by the consequences of failure. Avoid an unlimited list of hypothetical questions unrelated to the change.
5. Record the decision and what remains unknown
Separate supported behavior, identified discrepancies, missing evidence, and tradeoffs requiring judgment. State whether you need another check, a code change, or an explicit acceptance of a limitation. Keep the decision attached to the revision reviewed.
Keep the preparation cost visible
A review worksheet is only useful if its benefit justifies the work. Count the author’s preparation, the reviewer’s time, and any assistance. Reuse information already present in the task and PR. A consequential finding or a better-supported decision matters more than the number of questions produced.
Orneos is testing this workflow through a founder-assisted pilot. The product example uses fictional data; reduced effort and recurring value are hypotheses being tested, not measured results we can promise.