How to review AI-generated code: from diff to a working user journey
Neaptide · September 20, 2026 · 8 min read
Review AI-generated code through diffs, meaningful checks and user journeys, with review prompts and a completion-report template.
On this page
“All tests passed” answers only part of the question. You need to know which tests ran, whether they covered the original problem and whether the agent changed anything outside the task. Acceptance starts with conditions you can compare against the code and application behavior.
Review AI-generated code at three levels: file changes, automated checks and the user journey. This is a proposed workflow, not a guarantee of bug-free software. It helps identify missing evidence.
Write acceptance criteria first
“Fix submission” is too vague for an enquiry form. Describe observable behavior:
If the server returns an error, keep the field values and show a clear message. While submission is in progress, do not create a duplicate request. After success, show confirmation.
Separate requirements from preferences. An elegant refactor must not substitute for the bug fix that prompted the task.
For complex work, ask the agent to locate affected areas and existing checks first. Explicit verification is also part of Anthropic's recommendations.
Level 1: read the diff
Look through the changed filenames and explain each file's role to yourself. A small form fix should not quietly modify authentication, dependencies and deployment configuration.
Check that:
- Existing access rules and error handling remain intact.
- A real check has not become unconditional success.
- Tests that detected the problem have not disappeared.
- No secrets, unnecessary logs or temporary bypasses were introduced.
Use `git diff` and `git diff --stat`. If the agent committed its work, compare the appropriate commits; the ordinary uncommitted diff may now be empty. git diff reference.
Level 2: run appropriate checks
Ask for the commands and each outcome. Distinguish “started,” “finished” and “passed.” An environment failure may end a process without proving or disproving the fix.
| Check | What it establishes |
|---|---|
| Type checking | Compliance with checked type constraints |
| Function test | Expected output for selected inputs |
| Integration test | Compatibility between interacting components |
| Build | Whether this configuration builds |
| Browser scenario | Whether the observable user journey works |
No row replaces all the others. A successful build does not prove that an email reached its recipient.
For a reproducible bug, check that the relevant test catches the old behavior and passes after the fix. Otherwise, it may merely test a convenient property of the new implementation while missing the original defect.
Level 3: follow the user journey
For the form, check empty input, invalid values, server failure and successful submission. Use test data and a test destination so you can observe the outcome without real customer enquiries.
In browser automation, check visible behavior and stable interface landmarks. Playwright recommends isolated tests and locators aligned with what users perceive. Playwright best practices.
A screenshot proves a visible state, not the whole chain. Also check that the handler receives the correct fields, the record appears in the test system and repeated clicking does not create a duplicate.
Use a second agent for review
Give it the original assignment, diff and available check results. Ask it to find violated requirements and explain how to reproduce them. Do not prime it by saying the first agent fixed everything correctly.
A useful prompt:
Review these changes against the task requirements. For each finding, provide the file, conditions that trigger the bug and a way to verify it. Avoid generic recommendations unrelated to this diff. Separately identify what the available evidence cannot confirm.A second agent is another source of questions. Correctness must still rest on code and checks. Reproduce a disputed scenario instead of taking a vote between models.
Write a completion report
Keep a short record that can be checked later:
Change: what was fixed and in which files.
Checked: commands, conditions and outcomes.
Scenario: actions performed in the application.
Not checked: environment limitations and open questions.
Decision: accept, revise or request more evidence.Do not hide uncertainty behind “generally works.” If the test service is unavailable, state that end-to-end delivery is unconfirmed. That supports an informed decision about the next step.