Why Your AI Agent Says "Done" When the Work Isn't
You ask an agent to add a feature. It writes the code, runs something, and types: "Done! The feature is implemented and working."
You move on. Two days later you discover the function it added is never called, the test file it claimed to update does not exist, and the build is broken.
The agent was not lying. From its perspective, the work looked done. It wrote the code. It ran a command. The command produced output that included the word "pass". So it reported success.
This is the most common failure mode in AI-assisted engineering. It is also the most expensive one, because nothing in your workflow catches it. The agent does not re-check. You trust the report. The bug ships.
The structural problem
Agents are not lazy or careless. They are missing a step. Between "I ran a command" and "the work is complete" there is a verification gap that nobody told them to fill.
Look at what an untrained agent does when it claims success:
It says "tests pass" without showing the test runner output. It says "build succeeds" based on log text matching, not exit code. It says "bug fixed" without re-running the reproduction. It says "requirements met" by listing tests it wrote, not by checking against your original ask.
Each of these is a small omission. Together they produce a steady stream of work that looks complete and is not.
The rule that closes the gap
The fix is one rule, applied ruthlessly: no completion claim without fresh verification evidence.
"Tests pass" requires the test command output, run in this message, showing zero failures. "Build succeeds" requires exit code zero, not "logs look good". "Bug fixed" requires running the original reproduction and watching it pass.
This sounds obvious. In practice, agents resist it. They want to say "should work now" because that is what they have been rewarded for in training. The discipline has to be enforced as a workflow, not suggested as a preference.
That is what Superpowers is. It is a set of composable skills that enforce the boring disciplines agents skip: brainstorm before code, plan before implement, test before pass, verify before claim, review before merge. None of the skills are clever. All of them are gates the agent cannot route around.
When the discipline is too much
For a one-line typo fix, full TDD plus two-stage review plus verification is theater. The cost of the ceremony exceeds the cost of the bug.
The judgment call is risk, not size. A typo in a README does not need verification. A change to a payment flow does. Calibrate the discipline to the blast radius, not to the line count.
What to do today
You do not need Superpowers to fix this. You need one rule your agent cannot override: every completion claim includes the exact command you would run to check it, plus the output of running it now. Not a paraphrase. The actual output.
If your agent resists, that resistance is the signal. The work it was reporting as done was never actually verified.
Recommended for you
- VerificationSuperpowersClaude Code
Why Your Agent's 'Done' Cannot Be Trusted Without Command Output
The most expensive failure mode in AI-assisted engineering is the agent reporting success without verifying. The fix is one rule: no completion claim without fresh command output.
- VerificationSuperpowersClaude Code
Why Your Agent's First Fix Attempt Is Usually Wrong
An agent hits a bug, guesses a fix, reports done. Two hours later the same bug reappears because the first fix treated a symptom. Random fixes add bugs. The fix is the iron law: no fixes without root cause.
- VerificationSuperpowersClaude Code
The One Rule That Stops Agents from Inventing Tests
An agent writes code, then writes a test for it. The test passes immediately. It proves nothing. The fix is one iron law: no production code without a failing test first.
Enjoyed this article?
Subscribe for new articles. No spam. Unsubscribe anytime.
By subscribing you agree to receive the newsletter. See the Privacy page.