The Dead Pareto Sketch

The Pareto Principle is one of those mental models people reach for without examining: eighty per cent of the results come from twenty per cent of the effort, so attend to the vital few and let the trivial many look after themselves. Product teams, founders and engineering managers have built whole prioritisation strategies on it. It is also, now, an ex-principle. It has stopped, expired, gone to meet its maker, and the people still propping it on its perch have not noticed that the world beneath it changed.

The principle is not wrong because it was never true. It is wrong because the ratio has moved so far that the old heuristic now misleads. The new shape is starker: something like ninety-five per cent of the results for about five per cent of the effort, and the other ninety-five per cent of effort spent on the last five per cent of results, the polish, the edge cases, the production-readiness, everything that separates a demo from a product. Almost nobody has updated the model to match.

The cost of getting to “mostly working” has collapsed. A quarter of the startups in Y Combinator’s Winter 2025 batch had codebases that were almost entirely machine-generated, by the accelerator’s own account, and these were venture-backed companies in the most competitive cohort in the industry.1 The tools that made this routine, Cursor, Bolt, Lovable, take an idea to a deployed prototype in an afternoon. Base44, built by a single founder, reached hundreds of thousands of users and $1 million in annual revenue within weeks of launch, and sold to Wix for around $80 million about six months after it was founded.2

None of this means the effort vanished. Programmers have known for forty years that it hides at the end. Tom Cargill’s ninety-ninety rule, from 1985, runs: the first ninety per cent of the code takes ninety per cent of the time, and the remaining ten per cent takes the other ninety per cent.3 The joke carried a real observation, that the last stretch, the hardening and the edge cases and the things that make software trustworthy, costs far more than the cheerful early progress suggests. AI has not repealed the rule. It has collapsed the cheap part towards zero and left the expensive part standing in full view.

The alarms about AI code are real. Veracode, testing output from more than a hundred models, found that nearly half of it carried a security vulnerability, and that newer and larger models were no safer, which makes the problem structural; the next model release will not dissolve it.4 GitClear, across two hundred million lines of change, found duplicated code rising sharply and refactoring falling away, until copy-pasted code overtook the reorganised kind for the first time on record.5 The usual verdict is that AI writes bad code. That mistakes the cause. These are not failures of the tool; they are failures of specification. AI builds exactly what it is asked, and almost nobody is asking for security, testability, maintainability or graceful failure. They ask for a dashboard, and are impressed when a dashboard appears.

The ninety-five/five split applies to the specification itself. Saying what you want built is the easy five per cent. Saying everything the result must also be, secure, resilient, accessible, compliant, maintainable, is the ninety-five per cent of the intellectual work, and it is what a capable developer used to supply silently, out of habit and hard experience, without being asked. The work is still there. It has moved, from writing code to defining what “done” means across every dimension that matters.

Two different things hide in that last five per cent, and conflating them is how teams go wrong. One is structural: security, reliability, accessibility, the integrity of the data, the behaviour under load. It is invisible when present and serious when missing, and an agent will not supply it unless instructed. The other is cosmetic: the final coat of polish, the pixel-alignment, the sixth variation on the same screen. That kind earns its effort only when the market rewards it, which is rarer than product teams like to admit. The discipline is telling them apart: investing without limit in the structural, and cutting the cosmetic without sentiment. Effort poured into polish the market never rewards is a way of hiding from it.

This resets how to think about a minimum viable product. When the build cost approaches zero, the viable version can be far more ambitious, and the lean-startup instinct, build only what you need to learn, gets sharper: the cost of being wrong has collapsed, so be wrong more often and faster, and test five ideas in the time it once took to specify one. But “viable” now turns on how well the structural dimensions have been specified. Shipping fast against a thin definition of done means shipping insecure or unmaintainable software fast. A human developer used to cover a thin specification with their own judgement. An agent will not.

The old Pareto Principle told you where to put your effort. Its replacement tells you the effort itself has changed shape. Building, the part that used to take the real work, is becoming free. Knowing what to build, specified in full across every dimension that matters, is the expensive thing now, and no tool will do it for you. The parrot is not resting. It is time to take it off the perch.

---

References

1. Y Combinator Winter 2025: about a quarter of the batch had codebases roughly 95% AI-generated, according to YC managing partner Jared Friedman, who stressed that the founders were highly technical and could have built the products by hand. YC’s Garry Tan called it “the dominant way to code” while warning that AI-generated code can struggle at scale. TechCrunch, 6 March 2025. https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated ↩

2. Base44, built by the solo founder Maor Shlomo, reached roughly 250,000 to 400,000 users and $1m in annual recurring revenue within weeks of launch, and was acquired by Wix for about $80m upfront (with performance earn-outs) around six months after it was founded. The Times of Israel and Calcalist, June 2025. https://www.timesofisrael.com/six-month-old-israeli-startup-is-bought-up-by-website-builder-wix-for-80-million/ . Vibe-coding tools such as Cursor, Bolt and Lovable take an idea to a deployed prototype in hours. ↩

3. 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, September 1985: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule ↩

4. Veracode, “2025 GenAI Code Security Report”: across 80 curated tasks run through more than 100 models, 45% of the AI-generated code introduced a security vulnerability, and larger or newer models were no safer, which points to a structural problem rather than one that scales away. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/ ↩

5. GitClear, “AI Copilot Code Quality 2025”, analysing about 211 million changed lines from 2020 to 2024: copy-pasted code rose sharply (roughly from 8% to 12% of changes) while refactored code fell from around a quarter of changes in 2021 to under a tenth by 2024, the first time on record that duplicated code exceeded refactored code. https://www.gitclear.com/ai_assistant_code_quality_2025_research ↩