An agent says the tests passed. The screenshot is green. But the result could be from yesterday's commit, and the test for the behavior you requested might not even be in the suite anymore.
A green check tells you about the checks that ran. It says nothing about the behavior nobody checked.
Start with a claim you can inspect
Suppose you ask a coding agent to add a settings toggle. Before it edits the app, write down what you'd expect to see: the default value on first load, the saved value after reopening settings, and the state after reset. These are proposed acceptance checks for an example change, not a test of any particular product.
After the agent finishes, inspect the running behavior or stored state, not just the final message. A description of a file move is not evidence that the file ended up at its destination. The same gap applies to a toggle that looks right in a screenshot but does not persist. Independent checks needn't be elaborate; they need to touch the thing the task was meant to change.
Letting the agent write the acceptance test after implementing the toggle is risky. If it misunderstood the default, it can put the same mistake in the code and the test. Keep at least one expected outcome outside that loop, even if it's a human-reviewed assertion written before the edit.
Tie the receipt to the revision
A test result without a revision could belong to different code. Record the commit or immutable diff, the command and its output. Then inspect whether relevant checks were skipped, removed, or weakened. A focused test may pass while the broader suite remains unknown. Say both things.
Here is a proposed review card for that hypothetical settings change. Fill it with actual evidence from your own repository rather than copying these placeholders into an approval:
Intent: default off; saved choice survives reopening; reset returns to default
Revision reviewed: <commit or immutable diff identifier>
Files changed: <reviewed file list>
Checks expected before editing: <default / persist / reset checks>
Command and result on that revision: <command + captured output, or NOT RUN>
Checks changed or skipped: <list, or explicitly none after inspection>
Behavior inspected outside tests: <observation, or NOT CHECKED>
Verdict: accepted / needs work / incomplete
If the reset path was never exercised, the verdict on that requirement is incomplete. It does not become accepted because the other tests passed. If a test disappeared in the same diff, investigate the removal before taking the surviving green tests at face value. This is a review protocol, not a claim that any particular agent or tool automatically enforces it.
A functional pass says little about side effects
The toggle might work while the agent logs a token, touches an unrelated file, or requests access it did not need. Those are different acceptance questions. Check the diff for scope; for sensitive flows, use non-real planted credentials and watch the paths the agent actually takes. Keep a record of the paths the check never reached.
A clean result on an exercised path is worth recording. It is not a certificate that every possible path is safe. Likewise, a tool that compares a completion claim to session evidence cannot infer an unobserved user requirement. The evidence has to match the question you are asking.
Skip the card for a one-word documentation edit. For stored preferences, permissions, or production data, write the assertion down and keep the test receipt with the review.
If a path wasn't checked, mark it incomplete. The next reviewer can run that check; they can't recover it from a confident closing paragraph.
Source notes
- DEV.to discussion: How do you check that an agent actually did what it says it did? — practical question about independently checking changed state; discussion, not prevalence data.
- backcheck — project-described approach to checking claims against session evidence and qualifying unsupported results; not an independent efficacy study.
- weir — project-described planted-credential testing and explicit incomplete coverage; no claim of universal leak detection.
Top comments (1)
Tying the receipt to a revision is the part I see skipped most often, and the review card makes it hard to skip. Your point about checking whether tests were removed or weakened in the same diff is a good one: I'd turn it into an automatic gate that compares the set of test IDs and assertion counts before and after the agent's change, and fails if either drops without an explicit note. The idea of keeping one expected outcome outside the agent's loop also works well when the agent proposes both code and test, since a wrong default then can't hide in both places. For flaky agent runs, I'd also repeat the same task several times and require the card to come out the same each time, because one lucky green run is still weak evidence. Have you tried the card with an agent that fills in the Behavior inspected outside tests field itself, and if so, how often did it write something it hadn't actually checked?