Technology

AI Coding Agents Have a False Completion Problem

By Aftab Ahmad

Posted on August 25, 2026

AI Coding Agents Have a False Completion Problem

Generated code is cheap. The risk begins when a plausible final message becomes the system’s record of what was actually verified.

By Sergey Sheleg, software engineer, product builder, and author of The Proof of Done Manifesto

Proof of Done treats completion as a claim that must carry evidence.

AI coding agents can turn a requirement into a working patch before a team has finished discussing it, then write the tests, update the documentation, and report that the task is done. The speed is real. So is the new failure mode: the final message (the output most reviewers actually see) sounds complete even when the work isn’t. An agent may say that tests passed without naming which tests ran, update one implementation while a test observes another, change a configuration file but skip the environment where that configuration matters, or document the code it remembers instead of the code now in the repository. Each sentence is plausible, and none gives the next engineer enough information to decide what can be trusted.

What does done mean when the person receiving the work can’t tell what was checked? It means the code may be useful, while the completion claim has outrun its evidence. I call this the false completion problem.

Why fast generation changes the economics of review

Software teams have always shipped bugs, and AI agents didn’t invent that problem. They change its volume and shape because one developer can now request a feature, migration, tests, and documentation in a single run, creating a review surface that grows faster than the time available to inspect it. When code was expensive to produce, implementation naturally limited the number of changes a team could review. That limit is disappearing. The hidden cost moves downstream, where someone has to reconstruct what the agent saw, what it changed, which command it ran, which environment that command covered, and what it never checked (often after the original chat has already been summarized or discarded).

If the only record is a confident paragraph, the reconstruction starts from prose generated by the same system whose work is under review. That isn’t a control loop I would trust for a payment flow, a production migration, or any change where one missed assumption can cost several engineering days. The practical answer is not another test generator. AI software development needs a proof layer attached to the completion claim itself, so the claim and the evidence can’t silently separate during the handoff (a very different asset from a transcript).

A green check can observe the wrong thing

The easiest mistake to miss is not a failed test. It is a passing test with the wrong subject. Consider a team that asks an agent to change an export path. The agent edits the new implementation, runs an older unit test, sees green, and reports completion. The test exists, the command ran, and the output is successful, but the claim is still unsupported because the check did not observe the changed path. What did green actually prove? Only that one check passed (and the failure stays quiet).

A passing check is useful only when it observes the changed subject.

I have seen the same shape in less obvious forms: a staging smoke test presented as production evidence, a CI run attached to an earlier commit, generated tests repeating the same mistaken assumption as generated code, a link that resolves to stale information, or documentation describing a configuration the shipped binary doesn’t load. None of these failures is fixed by asking the model to be more careful. If you cannot identify the subject of the check (including the version it observed), you cannot use its green result as proof of the changed system.

Four fields are enough to change the conversation

I wrote Proof of Done: The Agentic Software Development Manifesto after repeatedly finding this gap in agent-assisted work. The smallest version replaces a bare done with four fields:

DONE states what became true.
PROOF names what was executed or observed and where the result lives.
SCOPE records the commit, environment, requirements, and surfaces covered.
NOT VERIFIED states what wasn’t checked, couldn’t be checked, or remains uncertain.

The last field matters most. Coding agents are optimized to produce a useful answer, which means uncertainty tends to disappear from a final summary unless the protocol gives it a permanent place. NOT VERIFIED: none within the stated scope is a valid result. Silence isn’t.

The four-field report turns a completion story into an inspectable claim.

The protocol doesn’t make an agent infallible, and it doesn’t promise that hallucinations disappear. It makes unsupported certainty harder to pass off as completed work because you can follow the proof, challenge the scope, and see what still requires judgment (without asking the original agent to reconstruct its own run or explain what its summary omitted).

Proof must be scoped, versioned, and perishable

Proof of Done is not a mathematical proof that software is correct. It is a bounded engineering claim supported by evidence another person or mechanism can reach, and that boundary matters because every result belongs to a particular commit, environment, policy version, and observation time.

Change any of those and part of the proof may expire. A successful run against commit A does not silently cover commit B, a staging check does not become production evidence by repetition, and a document that was correct before a migration doesn’t stay correct because its URL still opens. When you reuse old evidence, the first question is therefore simple: does this proof still cover the current state?

I ran into this while building the reference implementation for the manifesto. Public links to backlog rows continued to resolve and showed the requirements as open after those requirements had been implemented. The receipts were reachable, but they had stopped describing the current system for more than 2 days. Resolution alone wasn’t enough, so I added currency checks rather than claiming that a permanent link was permanent proof.

That incident changed how I treat evidence in agentic software development. A proof record is part of the system, not decoration in the agent’s last message, and it needs the same versioning and invalidation rules as any other state you expect the team to maintain.

What changes for engineering leaders

The business case for a proof layer is not that every line becomes safe. That promise would be false. The gain is control over uncertainty at the point where work changes hands.

Handoffs become inspectable because a reviewer doesn’t need the chat history to learn what ran. Risk can set the depth of proof because a reversible copy edit that takes 10 minutes should not carry the same verification burden as a payment migration, while a production deletion may deserve 2 hours of checks. Maintenance starts from a known boundary because a later change can invalidate one claim and rerun its checks instead of repeating everything or trusting old green results (where the original evidence has expired).

The management question changes too. Instead of asking how many lines the agents generated, you can ask how many requirements have no evidence path, which proofs expired, which checks abstained, and how long work remains between implementation and acceptance. Those measures describe delivery risk. Generated line count doesn’t. If you can’t trace a requirement to an observed result, more output only makes the uncertainty larger.

How to introduce Proof of Done without slowing the team

Start with the four-field report in every coding-agent instruction. Don’t build a governance platform first. Require proof addresses another person can open, such as a test name, CI run, commit, rendered artifact, log entry, screenshot, or live URL, and make the address specific enough that the reviewer doesn’t need the original agent to explain it.

Then test the checks themselves. A gate that always returns green is another source of confidence, not evidence, so feed important checks a known failing fixture, planted defect, or recorded historical failure and confirm that they can reject it (you don’t need to repeat the negative control on every run, but you do need to know that green has an opposite state).

Finally, connect proof depth to risk and automate the mechanical fields. How much proof is enough? If an edit that takes 5 minutes creates 20 minutes of manual proof work, I would treat the implementation of the proof layer as wrong. Computation should carry what it can. People should be asked for judgment only where computation ends.

The manifesto and its source are public at podmanifesto.org and GitHub. I also published a reference implementation as installable agent skills. These artifacts let you inspect the method and disagree with it. They aren’t a claim that the method removes every failure (and you can rerun the checks rather than take my word for it).

AI coding agents will keep getting better at producing code. That makes the record attached to the code more important, not less. The agent may write the code. The system must carry the proof.

Suggested publication metadata

SEO title: AI Coding Agents Have a False Completion Problem

Meta description: AI coding agents can generate code faster than teams can verify it. Proof of Done adds evidence, scope, and explicit uncertainty to every completion claim.

Suggested slug: ai-coding-agents-false-completion-problem

Suggested categories: Artificial Intelligence, Software, Technology

Suggested tags: AI coding agents, AI software development, agentic software development, software verification, software maintenance, Claude Code, Proof of Done

Author bio

Sergey Sheleg is a software engineer and product builder. He is the author of The Proof of Done Manifesto, a public standard for building software when AI agents write the code. His work focuses on product delivery, agent instructions, and evidence-based engineering systems.