Why AI Projects Stall Near the Finish: Completion Is a Self-Report

Three self-reports check the claim. Nothing checks the system.

On 29 July 2026 someone posted this list to r/ClaudeAI: "so many bugs / missing features / things aren't wired correctly / UI/UX issues / new imporvments" (sic), under the line "everything feels broken at once and I don't know how to prioritize." The post opens with "Going from idea to 70-80% is easy. Finishing is the hard part," and ends with "i have a graveyard of unfinished projects at this point." When I read the thread on 2 August it carried 95 points and 66 comments. [1]

Nothing measures that 70 to 80. It is one builder's read on their own project. What has been measured is the texture of the work underneath: among 33,662 respondents to Stack Overflow's 2025 survey, the biggest frustration with AI tooling was "AI solutions that are almost right, but not quite" at 66 percent, and 45.2 percent said debugging AI-generated code is more time-consuming. [4] That is why this article treats a near-miss as the hardest defect class to catch from the inside: it can do everything you asked except the part you never thought to check.

In this context, percent complete is not a measurement of the running system. It is a self-report, and three ways of judging completion have been checked at separate levels and found wanting. By the end of this you should be able to say what would count as proof that the item currently blocking your build is finished.

TL;DR: The stall at the end of a build is not new; the ninety-ninety rule described it in 1985. The argument here is that the person shipping the code may not have written it, so the evidence has no clear owner. Three ways of judging completion have been measured independently, and each has a limit: the agent's status claim can be wrong, the builder's sense of progress can diverge from measured outcome, and a reviewer model's judgment can sit near chance. The standard I would put in their place is a written definition of done, one line per item, checked against observed system state by something that did not build it. That is a proposed operating rule, not a measured fix, and it does nothing for taste.

The objection is obvious: none of this is new. Correct.

The Wall Is Older Than the Tools

The ninety-ninety rule, attributed to Tom Cargill of Bell Labs and popularized in Jon Bentley's September 1985 column in Communications of the ACM, holds that the first 90 percent of the code accounts for the first 90 percent of the development time, and the remaining 10 percent accounts for the other 90 percent. Bentley originally filed it under the "Rule of Credibility." [9] Four decades ago, with no model in the loop, the last mile already cost as much as everything before it.

So the honest version of the premise is narrow. AI did not create the last-mile stall. It changed two things about arriving there.

The first is a ratio. Code appears faster than anyone can establish that it is correct, so a cost that used to be spread thinly across slow authorship now lands in one lump at the end with no structure attached to it.

The second is custody, and it is the one that matters. In the development model this article is comparing, the person standing at the wall had typed every line and read all of it. Whatever completion evidence they held was informal and unwritten, but it lived in the same head that had made the decisions. With AI-assisted work, that head is optional, and when you did not write the code, the evidence may exist only inside an agent's account of its own work. This is my reading of what changed rather than a research finding, and the rest of the article argues for it.

The gap is old. The evidence vacuum is new. Which turns the fight about the last 20 percent into a fight about where the evidence went, and the people actually having that fight do not agree on the answer.

Three Camps In One Thread, And Only One Has Research Behind It

That thread holds three explanations. They are worth separating because most advice chooses one and misses the others.

The top reply, at 48 points, treats it as sorting: "the 70% wall is usually a triage problem, not a coding problem" [1]. Its method is one sweep that logs every defect into a FIXES.md, with "no fixing allowed during the sweep," because "fixing-while-discovering is why it feels endless." Then sort the file by one question: "does this block the core path?"

A dissenting reply, at 6 points, says the premise is wrong. "I barely ever have those issues… 97% of the time things just work" [1]. For this builder the remaining cost is not defect work at all. It is making the product feel right, which they consider the part AI is mostly incapable of doing.

The third explanation is the one this article builds on. "Claude has no real oracle," one commenter wrote. "It's not shipping broken code, bugs or features because it sees them and doesnt care. It's shipping those because it doesnt see them." [1]

Read in that order, the first two camps turn out to be downstream of the third. Triage stalls because you cannot sort items you cannot assess; the sweep hands you a tidy list of things whose status you still do not know. Taste is real and is a genuinely different category of work; it gets tangled with defects precisely because neither has anything written down that says what would settle it.

"No real oracle" is a hunch. It also has numbers behind it.

Why An Agent Reports Done When It Is Not

A June 2026 preprint calls it false success: an agent asserting that a task is complete when the environment state shows otherwise. It is not a crash or refusal. It is a confident status claim that is wrong. [2]

The measurements are specific about how much of agent failure takes that shape. On tau2-bench, across 9,876 trajectories from eight frontier model families, false success accounts for 45 to 48 percent of failures in single-control domains, and 3 percent in the dual-control telecom setting. On AppWorld, among 1,879 self-assessing coding-agent trajectories that emit an explicit status claim, it accounts for 75.8 percent of failures. [2]

Read these as shares of failures, not tasks, and as benchmark behaviour rather than a statement about your repository. This preprint measures controlled agent environments, not side projects. The mechanism is the useful part: when this failure happens, it arrives wearing the same words as success.

There is a second trace of the same shape outside the benchmarks. GitClear, which sells code-quality analytics and is therefore vendor research, analysed 623 million code changes between 2023 and 2026 and reports error-masking constructs up 47 percent and code block duplication up 81 percent, from 40.3 to 73.0 per million changed lines. [8] Those are trends measured alongside AI adoption, not a causal finding. Error-masking still deserves attention, because such a construct can let code run while suppressing the signal a completion check would go looking for. A green checkmark with the wire cut.

The obvious escape hatch is a second model. The same paper tested that.

The Second Opinion Is Near Chance. Your Gut Can Be Wrong Too

It does not work well. Across five judges and five prompt strategies, handed the full task specifications, no configuration exceeded 0.65 AUROC at detecting false success on tau2-bench. On AppWorld API-call traces the same judges reached 0.54. Chance is 0.5. [2]

An AUROC of 0.54 means the judge ranks a genuinely finished trajectory above a false-success trajectory only slightly more often than a coin would. That is the measured ceiling with the specification in hand.

That leaves the third self-report, which is the uncomfortable one. METR ran a randomized trial with 16 experienced open-source developers on 246 issues in mature repositories, each over 22,000 stars and a million lines. With AI tools allowed, they took 19 percent longer. Afterwards they estimated that AI had made them 20 percent faster. [5] I am citing that for exactly one thing, the distance between what was measured and what was felt, because METR itself has since moved: its February 2026 update says developers are likely more sped up now than the early-2025 numbers suggested and calls its own newer data "only very weak evidence" for the size of the change. The original authors also declined to generalize the slowdown beyond their setting. [5] The speed question is open. The perception gap survives the update.

Three ways of judging completion, three separate limits. The agent's status claim is wrong in a substantial share of the benchmark failures above. A reviewer model asked to catch that sits near chance. And the builder, on the one occasion someone measured feeling and outcome together, had the sign of the effect backwards. No single study tests all three at once, so reading them as one argument is mine to defend rather than a finding to cite.

Put that on your Tuesday. If none of those signals can be trusted, the list that keeps growing is not a discipline problem. It is what a list looks like when nothing in it has a status.

Four Kinds Of Work Are Hiding In One List

Read the original list again: "so many bugs / missing features / things aren't wired correctly / UI/UX issues / new imporvments" [1]. It mixes at least four kinds of work, each needing a different decision before it can be sorted.

Here is the split I would use. I built it from one practitioner's list, and no study underwrites it.

1. Defects. It was supposed to work and it does not. Decision: fix.
2. Wiring. The parts each work alone and were never connected. The upload succeeds and nothing writes the row. Decision: integrate.
3. Experience. It works and it feels wrong. Decision: judge.
4. Newly discovered scope. It was never specified, and it arrives disguised as a bug. Decision: defer.

The fourth lane is the one that can make a project feel endless. "new imporvments" sits in the same list as a broken login and inherits its urgency, because both showed up in the same session and both feel like things standing between you and finished. What separates them is not how important they feel but whether anyone ever wrote down that the product was supposed to do it. If nobody did, that is not incomplete work. It is a new requirement, and the decision is defer, even when it is a good idea.

The third lane is where I owe the dissenting commenter something. Experience work is judgment, and no acceptance line captures it. You can write down that a first-time user completes the core path without asking you a question. You cannot write down that the product feels good, and pretending otherwise gets you a checklist that certifies a joyless app as done. Separating that lane out is not an attempt to make it checkable. It is to stop it hiding inside the lane that is.

Sort all four cleanly and you still cannot say which items are finished, because sorting was never the missing piece. Nobody wrote down what finished would look like.

The Completion Contract Solo Builders Never Inherited

The artifact already exists. The Scrum Guide defines the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures required for the product," and then does the part that carries the weight: if a backlog item does not meet it, the item "cannot be released or even presented at the Sprint Review" and returns to the backlog. [6]

Solo AI builders inherited the speed of a team and none of its completion contract. The useful part is the mechanism: a written statement of what must be observably true, agreed before the work and enforced by refusing to call anything finished that does not meet it.

I should be exact about what kind of claim that is. The three unreliability findings above are measured; this is not. Nobody has tested whether writing done bars changes time-to-ship, defect rate, or how many projects get abandoned. It is the standard I would argue for from those findings, and it should be read as a proposed operating rule rather than a demonstrated fix.

The smallest version that still does any work is one line per item, written before the work starts and phrased as observed system state rather than as a description of what the agent did. Three illustrations, not case studies:

• Defect: "A user whose session expired mid-form signs in again and lands back on that form with their input still in it."
• Wiring: "Uploading a file from settings produces a row in the uploads table, and the file downloads from its stored URL in a browser that has never seen this app."
• Experience: "A first-time user reaches the confirmation screen without asking me a question. Whether the flow feels good is not something this line settles, and I decide that separately."

The obvious objection is process ceremony for a team of one, and it is fair: advice like this can become bureaucracy. Keep the cost to one sentence per item. It turns into ceremony when it acquires a template, a per-commit checklist, or a document nobody reads back. If you maintain done bars instead of using them, the artifact has turned on you.

Writing the bar and having the authority to accept it are different jobs, and the second is where responsibility sits. The human role in agentic coding workflows works through who is allowed to accept the evidence once it comes back.

There is still a flaw sitting in the plan. A written bar is worth nothing if the thing checking it is the thing that wrote the code, and by default that is precisely what checks it.

Who Checks, And Against What

The check has to come from outside the work. The thread has a simple version: "review with a fresh session instead of the one that built it" [1]. Another commenter describes a per-feature acceptance plan that a reviewer agent uses to accept a coder agent's output, reopening the task when it finds gaps. A third offers a ship bar with no ambiguity in it, "a stranger can finish the core path without you explaining anything," which they summarise not as pretty or complete but as "completable." [1]

Fresh context matters because the building session carries its own account of what it did, the same self-report measured above. Checking that narrative is not an independent check. Start the review with the acceptance line and running system, then add only the context needed to interpret the result. The more of the builder's narrative serves as proof, the closer the review comes to repeating the self-report.

The contract should not live in the session. Sessions end, get compacted, and shed what you needed them to hold; why AI coding agents lose context works through what belongs in durable task state instead.

"Just write better tests" is the standard objection here, and it is half right, so it deserves sharpening rather than swatting. The same thread has a builder whose agent does write tests and who still finds drift and bugs on manual use that the tests never touched [1]. That is not an argument against testing. It is a statement about what a test is: evidence for the claim it encodes, and silent on every claim nobody wrote down. A suite can be green and complete for the assertions inside it while the acceptance claim, the one about what a user can actually do, was never written anywhere. Tests are how you check a done bar. They do not save you from having to write one.

Widen that a notch and it is a control system: a written standard, a check performed by something independent, and a rule for what happens when the check fails. Small enough for one person to run. That is roughly where the industry evidence points, and also where its limits start to show.

What A Done Bar Does Not Fix

DORA's 2025 report, drawn from nearly 5,000 technology professionals, found AI adoption positively related to throughput and to product performance, and still negatively related to software delivery stability. Thirty percent of respondents reported little or no trust in the code AI generates. DORA's framing is that AI amplifies whatever an organisation already is, and its prescription is control systems: automated testing, mature version control, fast feedback loops. [3] I would treat a done bar as the smallest control system on that list that a solo builder can run. It is one item among several; the others do not become optional because you are working alone.

Microsoft's 2026 Work Trend Index reports that 86 percent of 20,000 workers across 10 countries treat AI output as a starting point, and 50 percent name quality control as a rising skill. [7] It covers general knowledge work, not software specifically, so treat it only as a signal about where attention is moving.

Here is what this article has not established, since the whole argument is about unearned confidence and it would be a poor look to end on some.

• No source here measures a 70-to-100 gap. The 70 to 80 percent in the opening is one person's framing of one project.
• Nobody has measured whether written done bars reduce time-to-ship, defect rate, or abandonment. The two sections above are an argued standard, not a demonstrated fix.
• No source here compares agents and humans at self-assessment. I am not claiming agents are worse at it.
• GitClear reports correlation over time and sells code-quality analytics. It corroborates a direction; it does not establish a cause.

The recommendation remains untested. It is still the smallest check this article proposes for the next feature.

Write One Done Bar Before The Next Feature

Pick the one item currently blocking your core path. Not the list. One item. Write the single sentence that would prove it finished, phrased as something you could go and observe in the running system, and write it before you touch the code. Then have something that did not build it check that sentence against the app: a fresh session, another person, your own eyes on a device you have not been developing on.

That is the practice: no template, process, or tooling.

A completion percentage is a progress claim. A definition of done is an evidence contract. That framing is mine rather than a finding, and it is the one sentence in this piece I would ask you to keep.

Write the one line that would prove your blocking item is finished, then send it to the first person who tests your build and ask them to check it against the running app, not against your summary.

References