blog ·
Reviewing agent changes safely: live diffs, keep or undo, and receipts
Agents write code faster than anyone can read it, so review has to be designed. These habits keep changes small and checkable, and this post shows how Muster Agent’s diffs, per-file undo and Ledger receipts support them.
The problem
Speed moves the bottleneck to review.
When an agent can produce a few hundred changed lines in a few minutes, the limiting step is no longer writing but understanding. The risk is predictable: a large diff that looks plausible, gets approved quickly and hides a subtle problem. Good review for agent output is mostly about shaping the work so a human can actually check it.
Habits that work
Make the diff small, then read it in the right order.
- Keep tasks small. One goal per task gives a diff you can hold in your head. If a change grows, split it.
- Read the summary, then the tests, then the code. Start with what the agent says it did, check that the tests express the intended behaviour, then read the implementation against them.
- Look for what is missing. Agents often leave out error handling, edge cases or cleanup. Ask what happens on empty input, on failure and on retry.
- Check for scope creep. Unrelated edits, reformatting and renamed files are signs the agent wandered. Undo them.
- Run it. Do not rely on the agent’s claim that tests pass. See the output, or run the command yourself.
- Keep a rollback. Work on a branch or worktree so discarding the whole attempt is one step.
Evidence
Prefer a record to a recollection.
Review is easier when the work leaves a trail: which files were read, what was edited, which commands ran and what they returned, and what the turn cost. A record also lets you answer later questions, such as why a file changed, without re-running anything. The more tamper-evident the record, the more you can trust it when something has gone wrong.
With Muster Agent
Review built into the conversation.
Live diffs with Keep and Undo
Each file the agent edits appears as a diff inside the conversation as it lands. You can review hunk by hunk or file by file, view whole-file inline diffs, and keep or undo one change or the whole file. Nothing is final until you decide, so you can let the agent take bigger steps and still stay in control.
One turn, opened up
Open a turn to see the reasoning, the files read and searched, each edit with its added and removed line counts, and the test run with its output and exit code. Long output folds to its tail until you ask for more, so even a long session stays readable.
The git tab
The git tab lists uncommitted files colour-coded by status, with the chat that changed each one, plus the commit graph with branches and tags, and you can compare any two refs. Chats can run in a new worktree so a parallel task never edits your checkout.
Ledger receipts
Every agent turn in a project gets a receipt with files changed, tests, tokens, time and cost, recorded in a tamper-evident Ledger with Receipts, Timeline, Activity and Costs views. Imported history from earlier tools stays outside the verified chain and is labelled as imported. On a Muster Server, an audit command verifies the server’s audit chain and the turn Ledger chain, and editing or deleting a past entry breaks the chain and reports where.
Going deeper
Tests, large diffs and disagreement.
Review the tests as carefully as the code
An agent told to make the tests pass may change the tests. Read test edits first. A weakened assertion, a removed case or a mocked-out dependency can turn a failing suite green without fixing anything. If the tests changed, ask why, and prefer changes that add coverage over changes that remove it.
When the diff is large anyway
Sometimes a large diff is unavoidable, such as a rename across a codebase. Review it by category rather than line by line: confirm the mechanical part with a command, such as a search that shows no old names remain, then read the handful of non-mechanical edits closely. Ask the agent to separate the mechanical change from the logic change into two steps so you can keep one and inspect the other.
When you disagree with the result
Undo the part you dislike, state the principle you want applied, and ask for a second attempt rather than editing around the first. If an agent repeatedly misses the same convention, write that convention down where it will be recalled every time, instead of correcting each run.
Reviewing as a team
A reviewer who did not watch the agent needs the same evidence you had: the summary, the tests and the cost. A receipt attached to the task lets a teammate see what ran without reconstructing it, which is much of the value of a record over a recollection.
Know when to stop reviewing and start again
If you find three or four unrelated problems in one diff, the prompt or the task was probably wrong, not just the code. Undo the lot, rewrite the goal with the constraint you were missing, and run it again. Fixing a flawed attempt line by line takes longer than a clean second run from a better brief, and the second diff is usually smaller.
A review routine
What to do each time.
- Read the agent’s summary and the opened-up turn to see what it actually did.
- Undo anything outside the scope you set, one file or hunk at a time.
- Check the test output and exit code. Run extra checks yourself if the change is risky.
- Keep what passes review, commit in small steps, and glance at the receipt so cost does not surprise you.
Pair review with containment: sandboxing coding agents limits the damage a bad change can do before you see it, and better prompts make the diff smaller in the first place.