Agentic coding / 2 MIN READ
Review the diff, not just the demo
A practical checklist for checking an agent’s work before it becomes part of your project.
A working demo is one piece of evidence. A useful review also checks the scope of the change, its behavior under failure, and whether another person can maintain it.
Read the change in context
Start with the file list. Unexpected dependency changes, deleted files, or unrelated rewrites deserve an explanation. Then read the changed lines alongside the surrounding implementation.
git diff --stat
git diff
git status --short
The status command matters: ordinary git diff does not show the contents of new, untracked files. Open those files too. Use git diff --cached to review staged changes.
Check the actual requirement
Walk through the original acceptance checks. Does the implementation solve the stated problem? Does it preserve the existing behavior that still matters?
For a form, try a valid submission, missing fields, an invalid value, and a failed request. For a layout, try narrow and wide screens, long content, and keyboard navigation.
Check the boundaries
Look at how input enters the system and how errors leave it. Check that user-provided text is rendered as text, that private configuration stays on the server where required, and that failed operations produce an understandable state.
For changes involving permissions or sensitive data, use the project’s established review process and an appropriate human reviewer.
Ask for evidence
Summarize the behavior you changed.
List the checks you actually ran and their results.
Explain any checks you could not run.
Identify assumptions and remaining limitations.
Run the relevant checks yourself when possible. A test should be capable of catching the failure you care about; a green result from unrelated tests is not enough.
Keep the result maintainable
Prefer a change that follows the project’s existing conventions. Ask whether new abstraction, configuration, or dependencies are necessary for this task. Smaller changes are usually easier to understand and undo.
Commit the work only after you understand its behavior and can explain why it belongs in the project.