What is the 70 percent problem?
Engineering culture and software practice
The 70 percent problem is the observation that AI coding tools carry a non-expert quickly to something roughly seventy per cent finished, while the last thirty per cent, the part that makes software correct, secure and maintainable, still needs the expertise the tool appeared to remove. Engineering leader Addy Osmani named it in a December 2024 essay and developed it in his 2025 O'Reilly book Beyond Vibe Coding. Seventy is a rhetorical figure, not a measurement.
What this means
Give a modern AI coding tool a clear description and it will produce a working first draft in seconds. It looks finished. It may pass a few basic tests. You feel most of the way there, and it cost almost no effort. Then you meet the rest of the work: the input that arrives empty, the fault that only appears under load, the accessibility rule the generated screen ignores, the security hole hidden behind plausible code, the point where this piece has to meet everything else.
The 70 percent problem names that gap. The first stretch is fast and genuinely useful. The last stretch is a different kind of work, and it needs judgement the tool cannot reliably supply. The number is illustrative, not measured; Osmani himself later published an 80 percent problem follow-up, noting the percentage moved as tools improved but the shape of the difficulty did not.
The pattern has a name because it repeatedly surprises people. Software that compiles and looks right is not the same as software that is safe to run, easy to change and correct under pressure. The name gives non-engineers a way to spot the difference between a demo and a delivery.
Why it matters
For a small or mid-sized organisation, this is the difference between a demo that works on Friday and a product that cannot ship on Monday. A non-engineer can now assemble something that looks like a finished internal tool. That is a real gain for exploring an idea. The risk is mistaking the demo for the delivery and staffing, budgeting and promising on that basis.
The last thirty per cent is where cost concentrates: error handling, security, data handling, tests, accessibility, deployment, and the plain ability of a second person to change the thing later without breaking it. None of that is visible in a working demo, which is exactly why it is so easy to under-price. The gap is widest for the person who cannot evaluate the output, because they cannot see what is missing.
This reframes hiring. The scarce skill is no longer typing code; it is reading, testing and judging code, and knowing which corners are load-bearing. It also reframes the build-or-buy question. A tool that stays inside a team, has low stakes and can be thrown away is a fine candidate for AI-assisted building. Anything that touches customer money, personal data, safety or a legal duty needs the full last stretch, and the demo tells you almost nothing about whether you can finish it.
How it works
Where the term came from
The phrase was popularised by Addy Osmani, an engineering leader at Google, in an essay published on 4 December 2024 titled "The 70% problem: Hard truths about AI-assisted coding". He opens by noting that while engineers report being far more productive with AI, the software people use daily does not seem to be getting noticeably better. He developed the argument in his O'Reilly book Beyond Vibe Coding: From Coder to AI-Era Developer, published in 2025, and returned to it in a 2026 follow-up on what he calls the 80 percent problem, where the figure rose but the last-mile difficulty remained.
The idea has stuck beyond the coiner's own channel: it has been discussed in developer press and analyst writing, and Osmani maintains a glossary entry defining it. That said, the specific figure of seventy is rhetorical. Treat it as a shorthand for "most of the easy part, none of the hard part", not as a percentage anyone measured.
The anatomy of the last thirty per cent
The first stretch is structure, boilerplate, happy-path logic, standard patterns and basic screens, all of which current tools handle well. The remainder is the work that separates something that compiles from something you can run in front of real users: edge cases, failure handling, performance under load, security, integration with existing systems, tests that pin the behaviour down, accessibility, and deployment. This work is not a smaller version of the first stretch. It is qualitatively different, and it is where experienced engineers earn their keep.
The relationship to the ninety-ninety rule
This is the AI-era restatement of much older folklore. The ninety-ninety rule, attributed to Tom Cargill of Bell Labs and popularised by Jon Bentley's "Programming Pearls" column in Communications of the ACM in September 1985, holds that the first ninety per cent of the code takes the first ninety per cent of the time and the remaining ten per cent takes the other ninety per cent. The percentages add to 180 as a joke about how badly the tail of a project is underestimated. The 70 percent problem makes the same point about the last stretch, but adds a twist specific to AI: the tool hides the tail from the very person least able to see it.
What the evidence says, with its dates
The honest state of the evidence is mixed and moving. In a randomised controlled trial published on 10 July 2025 by the non-profit METR, authored by Joel Becker, Nate Rush, Beth Barnes and David Rein, sixteen experienced open-source developers completed 246 tasks in repositories they knew well, using primarily Cursor Pro with Claude 3.5 and 3.7 Sonnet. Tasks took nineteen per cent longer with AI allowed, with a wide confidence interval; the same developers had forecast a twenty-four per cent speedup and still estimated a twenty per cent speedup afterwards. METR now treats that figure as historical and, in a 24 February 2026 update, reported changing the experiment design after finding late-2025 tools produced roughly an eighteen per cent slowdown for returning developers but only about four per cent for newly recruited ones, citing selection effects. On benchmarks, the SWE-Bench Pro paper from Scale AI (arXiv, September 2025) found the best models resolved 23.3 per cent of long-horizon tasks in its first version; a revised version dated 14 November 2025 reported the best model, Claude Sonnet 4.5, at 43.6 per cent. Both are far below the seventy-plus per cent those models score on easier benchmarks, which is the point: the hard tail resists.
How experienced teams handle it
They treat the AI draft as a starting point, not a delivery. They keep tasks small enough to review, use tests as the contract the code must meet, and spend most of their time evaluating rather than generating. They decide up front whether a given piece needs the full last stretch or can safely stay a rough internal aid. Public-body guidance reinforces this: the joint Guidelines for Secure AI System Development from the UK's National Cyber Security Centre and the US Cybersecurity and Infrastructure Security Agency stress security across the whole lifecycle, not just at the first-draft stage.
Examples
A professional services firm asks an operations manager to build a client intake form with an AI tool over a weekend. By Monday it captures names and sends emails, and everyone is delighted. Then someone asks what happens when two people submit at once, where the data is stored, whether it meets the firm's confidentiality duty, and who fixes it when it breaks. Those questions are the last thirty per cent, and none of them were visible in the working demo.
A charity with no engineers uses an assistant to generate a small dashboard that reshuffles spreadsheet data for trustees. Because the stakes are low, the data is not personal, and the thing can be rebuilt or abandoned at no cost, the first seventy per cent is genuinely enough. This is the case where AI-assisted building is the right call, and recognising it saves money.
A retailer's eight-person software team uses agents to draft a payment-handling change. The draft is plausible and fast. The team treats it as seventy per cent done, then spends the bulk of their effort on the edge cases, the security review, the tests and the integration, because money and customer data are involved. The AI accelerated the start; it did not remove the obligation to finish.
Common misunderstandings
The first misconception is that seventy per cent is a measured statistic. It is not. It is a rhetorical figure that captures "most of the easy part, none of the hard part". Osmani has used seventy and later eighty; the number is a shorthand, and treating it as a metric misreads the whole idea.
The second is that the remaining part is just polish. In fact the last stretch is where correctness, security and maintainability are decided. It is different work from the first stretch, not a tidy-up of it, and it usually takes longer.
The third is that the 70 percent problem is a criticism of AI tools or a claim they do not work. It is neither. The first stretch is real value delivered fast. The point is about where the difficulty sits, not about whether the tool is good.
The fourth draws the line against the ninety-ninety rule, the closest existing idea. The 70 percent problem is not simply the ninety-ninety rule renamed. Unlike that older, pre-AI observation about estimation, this one is specifically about AI hiding the hard tail from the person least equipped to evaluate it. The ninety-ninety rule explains why the tail is underestimated; the 70 percent problem explains why AI makes that underestimation easier to fall into.
The fifth is that anyone who can prompt a tool can now finish the software. The gap is widest precisely for the person who cannot judge the output, because they cannot tell what is missing until it fails.
Risks and boundaries
This is a recent term, coined in December 2024, and its usage is still shifting; this article was written in September 2026. The coiner has already revised his own figure upward, and the evidence base is young and contested. The METR trial is one study of sixteen experienced developers on mature codebases, with a wide confidence interval, and its authors now label the headline figure historical. Benchmark numbers such as SWE-Bench Pro move version to version and measure a narrow slice of real work. Treat all of these as snapshots, not settled fact.
The term is misapplied when it is used to dismiss AI-assisted work entirely, or stretched to mean any unfinished project. It is specifically about the AI-assisted case where a fast draft conceals the hard part. It does not cover ordinary scope creep or bad planning, and it is not a claim that the tools cannot improve. The live debate is exactly how much the last stretch shrinks as tools get better, and the honest answer as of September 2026 is that it narrows for greenfield work and remains stubborn for large, existing, shared systems.
What to do next
First, separate the demo from the delivery in your own head and in your planning. When something built with AI looks finished, ask what happens when it fails, where the data lives, who is accountable and who can change it later. If those answers are missing, you are looking at the first stretch, not a product.
Second, decide the stakes before you decide the method. Low-stakes, throwaway, non-personal-data tools are good candidates for AI-assisted building and may never need the full last stretch. Anything touching money, personal data, safety or a legal duty needs it, and the demo will not tell you whether you can get there.
Third, budget and staff for the last thirty per cent explicitly. That is where the cost and the risk live, and it is the work AI does not remove. Assume review, testing and integration will dominate the effort.
Fourth, value the ability to read and judge code over the ability to produce it. The scarce skill in an AI-assisted team is evaluation. When hiring or assigning, prize the person who can tell good output from plausible output.
Fifth, treat productivity claims, including your own team's, with care. People consistently feel faster with AI even when measurement disagrees, so ask for evidence in delivered work rather than in perceived speed.
FAQs
Who coined the 70 percent problem and when?
Addy Osmani, an engineering leader at Google, popularised it in an essay published on 4 December 2024 and developed it in his 2025 O'Reilly book Beyond Vibe Coding. He later wrote an 80 percent problem follow-up in 2026.
Is seventy per cent a real measurement?
No. It is a rhetorical figure meaning "most of the easy part, none of the hard part". The coiner has used both seventy and eighty; the number is a shorthand, not a statistic.
What exactly is the last thirty per cent?
Error handling, edge cases, security, data handling, performance, tests, accessibility, deployment, and the ability of a second person to change the code later. It is where correctness and safety are decided.
How is this different from the ninety-ninety rule?
The ninety-ninety rule, from Tom Cargill at Bell Labs and popularised in 1985, is a pre-AI point about underestimating the tail of any project. The 70 percent problem adds that AI hides that tail from the person least able to see it.
Does the evidence show AI makes developers slower?
One randomised trial by METR in July 2025 found experienced developers nineteen per cent slower on familiar code, though they felt faster. METR now calls that figure historical and changed its design in February 2026. It is a snapshot, not a settled conclusion.
Should a small firm build with AI or buy instead?
Build with AI when the stakes are low and the thing can be thrown away. Buy or commission properly when it touches money, personal data, safety or a legal duty, because those need the full last stretch.
Does this mean AI coding tools are not worth using?
No. The first stretch is genuine value delivered fast. The point is about where the difficulty sits, so you plan for the hard part rather than being surprised by it.