Review AI-generated code changes before accepting the result
Check scope, file diffs, staged changes, test evidence and unresolved risks in Mono Code, with a practical review template and read-only Git checks.
Review the code that is actually in the repository, not only the agent’s summary. A convincing explanation can come with an incomplete fix, a test that never ran or edits nobody asked for. Before you accept the result, look separately at what was requested, what changed and what proves it works.
Mono Code lets you open project files, work with coding agents and see Git changes right in the editor. This guide is about reviewing a small finished change; the remote coding guide covers getting connected. The repository and the commands always stay on your own computer, the host. Mono isn’t out yet; you can join the waitlist.
1. Restate the acceptance condition
Take a concrete example: a made-up task form accepts a title that contains only spaces. The fix should reject that input and keep normal titles working. Before you look at the patch, write down what must stay true:
- Empty and whitespace-only titles can’t be submitted.
- A normal title still submits.
- The user sees a helpful error message.
- Other form behavior stays as it was agreed.
Keep this list next to the diff. It lets you judge the change yourself instead of agreeing with whatever the agent says. If the original request was unclear, settle the behavior before you accept a bigger change.
2. Establish the repository state
Check the host, project folder and branch. Compare the list of changed files with the state you noted before the agent started. Your own earlier edits don’t become the agent’s work just because they’re in the same file.
In a terminal on the right host, these read-only commands can help:
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileReplace the example path. Plain git diff shows unstaged changes; --cached shows staged changes compared with the last commit. New untracked files need a separate look. The Git diff documentation explains these comparisons. A clean working tree doesn’t tell you whether the agent already made a commit, so check the recent history if it might have.
3. Read the patch and its surrounding code
In Mono’s editor, the gutter marks added and modified lines, and tapping a mark opens the diff for that part. It’s a handy way to look at one change, not proof that you’ve reviewed them all. A missing or outdated mark doesn’t mean the file is unchanged.
For the title example, find the validation check and follow what happens next. Does it check the trimmed value? Is the error shown? Does the form stop submitting? Read the surrounding code, not just one new condition without the code that calls it.
Look at new files, deleted code, dependency changes and unrelated formatting. A short explanation can’t justify a large, unexplained diff. Switch to the host or a bigger screen when lines are cut off or the change is too wide to read properly.
4. Match tests to the behavior
Ask which command actually ran, what it returned and which checks were skipped. “Tests should pass” is a prediction, not a result. A passing test suite also needs a test that covers the reported bug.
| Case | What you should see |
|---|---|
| Empty title | Submission stops with the intended message |
| Spaces only | Same rejection, and no item is created |
| Normal title | Submission still works |
| Other existing behavior | The relevant existing checks still pass |
A manual check can work for visible feedback; an automated regression test can protect the validation rule. Pick evidence that shows the change works, not tests that simply repeat the code. If you can’t run tests in this environment, write that down and decide where the missing check will happen.
5. Resolve findings without losing unrelated work
Give precise feedback: “Whitespace-only input is rejected, but the error label never appears,” or “Explain why the dependency file changed for this validation fix.” Point to the behavior and the file, not just “try again.”
Don’t use broad reset or restore commands to undo one small unwanted change when other work is in the same files. Ask for a targeted fix and check the new diff. Run the affected checks again after the fix; an earlier pass doesn’t cover later edits.
Allowing a command and accepting the code are separate decisions. Approving a test command doesn’t approve committing, merging or deploying. Use the permission review guide for the command itself.
6. Leave a reviewable handoff
Write down your conclusion in a short note:
Requested behavior: Reject blank task titles.
Files reviewed: List the actual paths.
Evidence: Commands/results and relevant manual checks.
Open questions: Anything still unverified.
Next decision: Accept the change, request a correction, or defer.Keep commits and releases as deliberate steps. If you want to keep the conversation, export it to Markdown, but keep the actual project files too. The transcript shows what was discussed; the repository and your checks show what changed.
