Coding agents can write a lot of code quickly. The part that is easy to skip is the review: what actually changed, and does it match what you asked for?
Here is a short checklist to run before moving on to the next task. (Disclosure: BOMTOBE builds orke, a desktop workspace for coding agents, so we have an interest in this topic. The checklist itself works with any tool.)
1. Look at the list of changed files first
Before reading any code, check which files were touched. If you asked for a change in one module and the diff also touches configuration, lockfiles, or unrelated folders, stop there. A wide file list is a signal to ask the agent why.
2. Read the line-by-line diff, not the summary
An agent's summary says what it intended to do. The diff says what it did. Read the added and removed lines directly, and pay attention to:
- deleted code that the summary never mentions
- new dependencies or changed version numbers
- error handling that was removed rather than fixed
Reading a diff is slower than reading a summary, but it is the step that catches surprises.
3. Run the change in the same project context
A diff can look correct and still fail when it runs. Keep the terminal session, the local web page, and the Git changes for the same project close together, so you can run the change, see the result, and compare it with the diff without switching between unrelated windows.
Why this matters for solo developers
When there is no teammate reviewing your pull requests, the agent's output goes straight into your project. A five-minute review at the end of each task is cheap insurance.
If you try a workflow like this, I would like to hear what checks you added. Which steps do you skip, and which ones have caught real problems for you?
Product page: orke
