Back to blog
Verification
Superpowers
Claude Code

Why Your AI Agent Says "Done" When the Work Isn't

Thang Doan
Thang Doan

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

Enjoyed this article?

Subscribe for new articles. No spam. Unsubscribe anytime.

By subscribing you agree to receive the newsletter. See the Privacy page.