A practical review workflow for AI-generated code

Define success in terms of behavior

‘Improve the uploader’ leaves the agent to decide what matters. ‘Retrying an interrupted upload resumes the existing job and shows progress without a duplicate’ gives both implementation and review a target.

Include the important boundaries: which files or systems may change, which behavior must stay compatible, and whether deployment is part of the task. For a small visual adjustment, a browser check may be enough. A change to job ownership needs a focused behavioral check.

Trigger: upload interrupted, then retried.
Expected: the same job resumes and progress becomes visible.
Edge case: the old ownership token has expired.
Compatibility: completed uploads still open normally.
Evidence: focused retry check plus a browser walkthrough.

Read the diff before the summary

Start with the changed files and look for changes outside the task. Then follow the actual path from input to result. A plausible summary does not tell you whether an error path is reachable or whether an old caller still uses the previous format.

Check the handling of empty state, failures, repeated actions, and stale state where they matter. For a UI change, look at keyboard access and the narrow screen layout. For a migration, consider how old and new data coexist. Review effort should follow the consequences of a mistake.

• Does the change address the reported trigger?
• Are callers and persisted data still compatible?
• Does the failure path leave the user able to recover?
• Are dependencies, permissions, or configuration changes justified?

Use checks that could catch a real mistake

Ask for the exact checks run and what they establish. A test that repeats the implementation can pass alongside the same bug. Prefer a check that exercises the reported behavior and an important failure or boundary case.

Type checking can catch an incompatible shape; it cannot establish that a button works. A screenshot can show layout; it cannot prove that a retry resumed the right job. Use a small combination of evidence that matches the change, and disclose checks that could not run.

When two agents made separate changes, verify the combined result after integration. Passing checks on separate branches are useful evidence, but they do not cover every interaction between the changes.

Use Lattice’s run evidence as a review starting point

On supported platforms, Lattice’s verified runs let you define a goal, boundaries, and checks, then review the changes and results from work in an isolated branch. Runs begin when you press Start. A finished turn alone does not prove success.

Unattended runs are unavailable in the Windows beta. You can still apply this review process to work in terminal sessions. Keep the human decision clear: read the evidence, resolve material gaps, and decide what to keep before merging or deploying.