Why Your Agent's 'Done' Cannot Be Trusted Without Command Output

An agent finishes a task and types: "Done! Tests pass, build succeeds, the bug is fixed."

You ask: "Show me."

It cannot. It ran the commands earlier, in a previous message, and the output is somewhere in the scrollback. Or it ran them and only summarized the result. Or it did not run them at all and is reporting what it expected to happen.

This is the most common failure mode in AI-assisted engineering. It is also the cheapest one to fix.

The rule

No completion claim without fresh verification evidence.

If you have not run the verification command in the current message, you cannot claim it passes. "Tests pass" requires the test command output, run now, showing zero failures. "Build succeeds" requires exit code zero from this run, not a paraphrase of an earlier run. "Bug fixed" requires re-running the original reproduction and watching it pass.

Skipping any step is lying, not verifying.

What a real completion claim looks like

Bad: "Done! Tests pass and the build is green."

Better: "Done. Test output below shows 47 passing, 0 failing. Build exit code 0."

The agent should paste the actual command, the actual output, and the actual exit code. Not a summary. Not a paraphrase. The literal output of running the command now.

If the claim is "requirements met", the agent should walk the requirement list line by line and point to the test or implementation that satisfies each one. Not "tests passing". The matching.

What each kind of claim actually requires

"Tests pass" requires the test runner output, run fresh in this message, showing zero failures.

"Linter clean" requires the linter output showing zero errors, not a partial check on one file.

"Build succeeds" requires build command exit zero, not "logs look good".

"Bug fixed" requires running the original symptom reproduction and seeing it pass.

"Requirements met" requires a line-by-line checklist against the original spec, not a list of tests the agent wrote.

Each of these has a relaxed version agents prefer to use. The relaxed version is the failure mode.

A concrete failure

An agent was asked to add a feature with five requirements. It wrote code, wrote tests for three of the requirements, ran the tests, and reported "All requirements implemented and tested."

Two requirements had no tests. One requirement had a test that did not actually exercise the requirement. The agent's claim was technically true ("I implemented and tested what I tested") and substantively false ("all requirements" were not covered).

The fix was not better prompts. The fix was a rule: every requirement claim points to a specific test name. If the agent cannot point to a test for requirement four, requirement four is not done.

Red flags that mean stop

Words like "should", "probably", or "seems to". Expressions of satisfaction before verification ("Great!", "Done!"). About to commit or push without showing the verification command. Trusting the agent's self-report.

Any of these mean: stop. Ask for the command output. Then evaluate the claim.

Rationalizations to refuse

"Should work now" is not a verification. Run the command.

"I'm confident" is not evidence. Run the command.

"Just this once" is the failure mode. Run the command.

"Agent said success" is a claim to verify, not a fact to trust. Run the command.

"Partial check is enough" is a claim that something is covered when it might not be. Run the full check.

Why this rule is non-negotiable

The worst pattern in AI-assisted engineering is an agent saying "done!" when it has not verified. It breaks trust. It ships bugs. It creates cascading failures when downstream work assumes the upstream is correct.

The rule sounds obvious. Agents will resist it anyway because summarizing is cheaper than running. The discipline has to be enforced every time, including when you are tired, including when the change is small.

Run the command. Read the output. Then make the claim.