The first screen comes quickly. The rest is harder.
Describe an idea to an AI tool and you can get a screen and code quickly. Then you add sign-up, preserve data, and prepare for real users. The same pieces may need several rounds of repair. Starting has become easier, but the work between a working demo and a product people can keep using remains.
The four sources below are different kinds of evidence: a developer survey, an experiment measuring task time, an analysis of GitHub pull requests, and one production incident. They cannot tell us the overall failure rate of AI-built projects. They do show specific points where work can stall.
Case 1. Code that looks right until you use it
The 2026 Stack Overflow Developer Survey asked which AI mistakes had cost respondents or their teams the most time in the past year. Among 13,648 respondents, 69.3% selected plausible but wrong code, 54.2% hard-to-review generated code, and 49.3% missing context. This was a multiple-choice self-report question, not a measure of project failure.
Imagine a sign-in screen that looks fine but loses the session after a refresh. A screenshot suggests the feature is done. Closing and reopening the browser, signing in on another device, and checking error states reveals what is missing. This is an illustration of the survey's problem, not a case reported by a specific respondent.
Sources Stack Exchange Inc. · Stack Overflow Developer Survey 2026
Case 2. Faster code generation, longer task completion
In early 2025, METR compared the time 16 experienced open-source developers needed for 246 tasks in their own projects. Tasks where AI use was allowed took 19% longer on average. Participants expected AI to speed them up both before and after the work. The speed of generating code and the time to finish a task can differ.
That result does not apply to every developer or today's AI tools. In a 2026 follow-up, METR said newer tools may have improved productivity, but selection effects made the size of any speedup difficult to estimate. The practical lesson is to measure progress by finished, checked work rather than by how quickly the first demo appears.
Sources METR 2025 experiment · METR 2026 follow-up
Case 3. A change too large to review easily
In 2026, researchers analyzed about 33,000 GitHub pull requests authored by five coding agents. Unmerged PRs tended to change more files and lines of code and had more failing CI checks than merged PRs. In a closer review, the researchers also found duplicate work, unwanted features, and implementations that missed the project's intent.
An unmerged PR is not necessarily incorrect code. Some were abandoned without meaningful review, and others duplicated existing changes. Still, a small feature with a clear scope and test result is easier to assess than asking an agent to finish an entire app in one pass.
Case 4. Development work reached live data
SaaStr's Jason Lemkin publicly described how a database was deleted while he was building his first app with a Replit agent in 2025. Replit said its apps had used one database for both development and live data, then announced separate development and production databases. One incident cannot stand for every AI tool.
It does show why telling an agent to be careful is weaker than limiting what it can reach. Keep development and live data separate, maintain a recovery point, and require review before destructive changes run.
Sources Jason Lemkin's account · Replit's database separation announcement
Different cases, similar sticking points
Three questions recur across these sources. Did the team agree on what 'done' means? Was each intermediate result compared with the original request? Were verified facts separated from assumptions? This is a synthesis of the evidence, not a formula proven to explain every failed project.
A longer prompt alone does not answer those questions. You need criteria for checking the result and a record of what you actually checked, so the next revision does not return to the same uncertainty.
How to finish one useful slice
For a sign-up feature, write the definition of done as user actions: 'An unconfirmed account cannot sign in; a confirmed account can; the session survives a refresh; a wrong password shows an error.' This makes omissions easier to spot than checking whether the screen renders. It is an example for readers, not a requirement from a project in the cited research.
Move to the next feature after this slice passes its checks. Small completed steps make the remaining work visible.
- Pick one user action to finish this week. For example: 'After signing up, I can return and still see my records.'
- Write a definition of done for the screen, stored data, and error cases.
- Give the AI one bounded change at a time. Ask for the changed files and checks it actually ran.
- Test more than the happy-path screen: refresh, sign in again, failure responses, and a phone-sized display.
- Separate access to live data and secrets, and confirm how to roll back before release.
Keep the reasoning for the next session
When you switch AI tools or start a new session, the reason behind a fix can disappear. Keep the reviewed artifact, checks that actually passed, and remaining issues together so the next task has a reliable starting point.
Wellnote lets you save selected artifacts and prompts from Codex and Claude Code and find them later. Record one change you checked today and why you accepted it. Tests and access controls still need to be set up in the development environment.