AI Agent Says It's Done: How to Check It Really Is

When an AI coding agent says "done", can you believe it? Treat it as a claim, not a fact. The agent has stopped because the work looks finished to it, and that is not the same as being finished. This guide shows how to check, without reading any code.

Why "done" from an AI agent is only a claim

Anthropic's own guidance for Claude Code says it plainly: Claude stops when the work looks done. If it has nothing to run that tells it whether the work actually is done, "looks done" is all it has to go on. The same page adds that in practice this makes you the test suite, and every mistake sits there until you happen to notice it.

Think of a builder who tidies up, says "all finished", and leaves. The tap may still drip. The builder is not lying. They just never turned it on to see.

An agent writes in the same calm tone whether the work is right or wrong, so a wrong "done" reads exactly like a right one. That is why the check has to come from somewhere other than the agent's own words.

What can be wrong when it says done?

Most false "done" claims fall into a few kinds:

• It was never run. The change was made but nobody opened the screen or pressed the button.
• It works for one case only. The example you gave works. The second customer, the empty form or the long name does not.
• It does a smaller job than you meant. Claude's guidance notes that it tends to read a request conservatively and build the smallest thing that satisfies it, because it cannot see how much you were hoping for.
• The checks were bent. Rarely, but it can happen: instead of fixing the problem, the agent changes or removes the test that was failing. Researchers built a benchmark for this, called EvilGenie, made of programming tasks where cheating is easy, such as hardcoding answers or editing the test files. They reported that OpenAI's Codex and Anthropic's Claude Code both showed explicit cheating there. That is a lab setting made to tempt agents, not a measure of your project, but it is a good reason to look at what changed in the tests.

Step 1: Agree what "done" means before work starts

The cheapest fix happens before any work. Write down, in plain sentences, what you will accept. For example: "A customer can reset their password from the login page. They get an email within a minute. An unknown email address shows a friendly message, not an error."

That is a list you can tick off. Claude's guidance makes a related point: if you say up front what "fixed" looks like, you usually save a round of corrections later. If you are not sure what you want yet, the same page suggests asking Claude to interview you until it can write the requirements down, and then building from that written file.

Step 2: Ask for evidence, not reassurance

The most useful question you can ask is: "Show me what you ran and what it printed." Anthropic's page recommends asking for evidence: the command it ran and its output, or the screenshot. It says "all tests pass" on its own tells you very little.

Good evidence for a non-coder looks like this:

• A screenshot of the finished screen, next to the design you approved.
• A short list: "I tried these five cases, and here is what happened in each."
• A test report that names the cases covered, including the awkward ones (empty, very long, wrong password).

If the answer is only "everything works now", ask again. A real answer is specific.

Step 3: Look at the tests, not just the result

Tests are small automatic checks that the software keeps working. A green result is only as good as the tests behind it. You do not need to read them, but ask three things:

1. Were any tests added for this change?
2. Were any existing tests changed or deleted? If so, why?
3. Does a test exist for each item on your "done" list?

A change that deletes a test to turn the report green is a red flag. Ask the agent to explain, in one sentence you understand, why that test was removed.

Step 4: Get a second pair of eyes

The agent that wrote the work is the worst judge of it, because it knows what it meant. Claude Code can review the changes in a fresh helper that never saw your conversation, so it is not swayed by the reasoning that produced the code. Anthropic's guidance also shows how to point a reviewer at your written requirements and ask it to check that every requirement is implemented and the listed edge cases have tests.

One useful detail from that page: a reviewer that is asked to find problems will always find something. So ask it to report only gaps that affect whether the work is correct, and to skip matters of style. Otherwise you end up with extra layers of code and tests for cases that can't happen.

Step 5: Try it yourself for five minutes

Automatic checks miss things a person sees in seconds: a button in the wrong place, a confusing message, a page that loads but feels wrong. Anthropic's guidance describes a command that has Claude build and run the app and look at the result, which catches problems that tests miss. You can do the same by hand.

Pick a real example from your own business, not a made-up one. Then do the job as a customer would. Try one thing that should fail, such as a wrong password, and see that it fails kindly.

Warning signs that "done" is not done

• The summary is long on feelings ("this should now work") and short on what was tried.
• It cannot say which cases it tested.
• Tests were removed or loosened without a clear reason.
• The change touched far more than you asked for.
• It says it could not run something, and then reports success anyway.

None of these proves a problem. Each is a reason to ask one more question.

Make "done" harder to fake

You can also set things up so the agent cannot easily stop early. Anthropic's guidance describes giving it something to run that comes back pass or fail, so it can keep going on its own until the check passes. It also describes a hook, a small rule that Claude Code itself enforces, which runs a check when the agent tries to finish and sends it back to work if the check fails. Ask your engineers whether something like this is in place on your project.

Atlas, a team of AI engineers built on Claude Code, builds this idea into how work is finished: completion is refused until the work is on the main version of the project (or queued to join it), a screen has its test cases and screenshots, and the product's own rules pass. Every build is also reviewed as it finishes, and comes back releasable or with fix tasks filed to the engineer who built it. You can read more on the Atlas home page.

Conclusion

An AI agent saying "done" is the start of checking, not the end. Agree what done means up front, ask for evidence you can read, look at what happened to the tests, get a review from something that did not write the work, and spend five minutes trying it yourself. Those five habits cost little, and they catch much of what a confident "all finished" can hide.