TL;DR
AI coding agents say “done” too early because they can finish the requested edit without proving the whole delivery outcome. Their stopping point usually follows the prompt, visible tests and tool feedback. Define done as observable evidence instead: acceptance behaviour demonstrated, relevant regression checks passed on the final commit, documentation updated, risks named and a human reviewer satisfied. If a requirement has no proof method, the agent can report completion while the team still has unresolved product and release work.
In this article
7 min read
An agent can modify the requested files, run a test suite and announce completion while the feature is still wrong, incomplete or unsafe to release. This is not mysterious. The agent has reached the stopping condition implied by the task, and that condition is often much narrower than the team’s meaning of delivered.
The main question is why do AI coding agents say done too early? They optimise for visible completion signals. If the prompt says “add the endpoint” and the repository has a unit test, the agent may stop when the endpoint exists and that test passes. It cannot infer every product expectation, production boundary or organisational approval that was never made explicit.
“Done” is usually hidden inside the request
Every task contains an implicit proof standard. “Fix the bug” may mean the error no longer appears locally, the original failure has a regression test, affected workflows still work and the release can be observed safely. Unless those outcomes are stated, the agent may choose the first plausible one.
Write the proof method beside each acceptance statement:
Comparison
| Acceptance statement | Proof method | Weak substitute |
|---|---|---|
| An authorised user can export a report | Integration test plus demonstrated file | Method returns a success flag |
| An unauthorised user is rejected | Negative permission test | UI hides the button |
| Existing saved filters still work | Focused regression examples | New path passes alone |
| Failure is visible to operations | Alert or log demonstrated in test environment | Exception exists in code |
The proof method forces the team to decide what it will accept before the agent writes code. It also gives the agent a concrete stopping condition.
A green check can describe the wrong job
Agents often use the available test suite as an oracle. Existing tests may be incomplete, and newly generated tests may encode the same misunderstanding as the implementation. Both can be green while the requirement is still unmet.
GitHub’s guide to writing tests with Copilot warns that generated tests may not cover all scenarios and should be reviewed and extended. That limitation is especially important when the agent writes both sides of the proof.
Challenge one critical test by breaking the behaviour deliberately. If removing the permission check or reversing the boundary condition does not make the expected test fail, the suite is not protecting that claim. Then derive at least one acceptance example from a source outside the implementation: a ticket, observed failure, contract or product decision.
Tool success is not product success
Coding agents receive strong signals from tools: a command exited zero, a linter reported no problem or a file was created. These are useful facts. They answer narrow questions about an environment the agent can access.
Product success may depend on data shape, permissions, user comprehension, connected systems or a deployment sequence outside that environment. The task must name which of those boundaries matter and how the team will check them.
Use a layered completion record:
- Change made: the intended files and configuration changed.
- Behaviour shown: acceptance examples pass and a meaningful result is inspectable.
- Regression bounded: relevant existing behaviour was checked.
- Release prepared: migration, monitoring and recovery work is complete where needed.
- Human accepted: a named reviewer understands the result and remaining risk.
An agent may complete the first three layers on a low-risk task. It should report the later layers as pending when they require access or judgment it does not have.
Ask the agent to report status, not confidence
A confident completion paragraph is easy to produce and hard to audit. Replace it with a status report that distinguishes completed, failed, skipped and unavailable checks.
Require exact commands, the final commit, a short result and a link or artifact for any visual or behavioural proof. Ask the agent to list assumptions and unverified boundaries. If a check could not run because a service or credential was unavailable, that is an explicit pending item, not a reason to soften the language.
- Restate the accepted behaviour in concrete terms.
- List the changes that implement it.
- Record each proof method and its result.
- Mark unavailable or skipped checks plainly.
- Name decisions and risks that still need a human.
This makes “done” reviewable. A human can see whether the task reached its agreed boundary without trusting the agent’s tone.
Give the agent a refusal condition
Some work should stop before code is produced. If an acceptance rule conflicts with another requirement, the repository state is unsafe, a migration has no recovery route or the task needs a product decision, the agent should ask rather than guess.
A refusal condition is useful because generated code can make an unresolved decision look settled. State conditions such as: do not invent permission rules; do not change a public contract without approval; do not run destructive migration steps; stop when tests contradict the ticket. The six moments in the delivery process show where decisions, evidence and refusals belong around implementation.
Reopen work when the evidence changes
Completion is tied to a version. A new commit, dependency resolution or conflict fix may invalidate earlier evidence. Required checks should run on the final commit, and manual demonstrations should identify the version they show.
The same applies after review. If the reviewer requests a substantive change, the task is no longer done until affected checks run again. This prevents a common failure where an agent fixes one comment and the team merges on evidence from the previous state.
A durable delivery record keeps the acceptance, checks and verdict connected. It also gives future maintainers a better answer than an expired agent transcript.
Teams do not need a longer universal checklist. They need an explicit finish line for each task and a workflow that refuses to cross it without proof. Once that line is visible, agents can be fast without redefining delivery around whatever they happened to complete.
If early completion claims are creating review and release risk, Fix this for your team. The Programme applies an evidence-based workflow to real backlog work and measures it against your starting point; it does not promise that every task becomes faster.
Teams should also separate task completion from release completion in their status system. A change can be implementation-complete while waiting for a production-like check, domain review or deployment window. One undifferentiated “done” column encourages people and agents to collapse these states. Use plain states that name the missing decision, such as awaiting evidence, awaiting review or ready to release.
This improves planning as well as safety. Leaders can see whether work is blocked by coding, environments or human review, instead of assuming every open item needs more generation. The status becomes an operational fact rather than a confidence statement.
Frequently Asked Questions
Why do AI coding agents say done too early?
They stop at the completion signals they can see: changed files, passing commands and instructions in the task. Product intent, production conditions and human approval remain invisible unless the workflow states them and supplies a proof method.
How should a team define done for an AI coding task?
Define observable acceptance behaviour, the checks that prove it, relevant regression boundaries, required release preparation and the human decision. Tie all evidence to the final commit and mark unavailable checks as pending rather than complete.
Should an agent be allowed to mark its own work complete?
It can report that assigned steps and checks finished. A human should decide whether the evidence satisfies the delivery outcome and whether remaining risk is acceptable. Separating status from approval keeps the report useful without giving the tool false authority.
What if the agent cannot run a required check?
Record the check as unavailable, explain the missing dependency or access and leave the task incomplete at that boundary. A person with the right environment can run it, or the team can explicitly revise the acceptance requirement.
Why do generated tests sometimes create false confidence?
The tests and implementation may share the same wrong assumption. A passing assertion proves consistency between them, not agreement with the product need. Derive important examples from an independent requirement and make a deliberate fault to see whether the test detects it.
When should a completed AI task be reopened?
Reopen it when code changes after evidence was recorded, a conflict resolution alters behaviour, a required check was skipped, or review reveals an untested risk. Completion belongs to an exact state, so material changes require fresh verification.
