In 2007 the game studio 3D Realms hired a new creative director, Raphael van Lierop, and gave him several pieces of Duke Nukem Forever to play. It took him about five hours. He came away excited. The game was so far along, he thought, that one hard year would finish it.
No, no, the project’s head, George Broussard, told him. It was two years out.
“I thought, ‘Wow,’” van Lierop said, “‘how many times have you been here, near the finish line, and you thought you were way out?’”
The game had been announced ten years earlier, in 1997. In May 2009, with the owners’ own money running low, the studio shut down its development team, the game still not finished.
A rule that adds up to 180%
In September 1985 the computer scientist Jon Bentley filled his column in Communications of the ACM with rules readers had sent him, short enough for a bumper sticker. One came from Tom Cargill of Bell Labs. Bentley called it the Rule of Credibility:
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
The arithmetic is a joke. Ninety plus ninety is 180. The joke is how it feels from the inside: the project reaches 90% on schedule, then stays near 90% for about as long again. (Bentley added that the name beside a rule was usually just whoever sent it in, “even if they in fact attributed it to their Cousin Ralph.”)
Stuck at ninety
In 1988 Tarek Abdel-Hamid of the Naval Postgraduate School took the joke seriously. He quoted an older description of what he called the “90% syndrome.” Estimates of how much work is done rise as planned until they reach 80 or 90 percent. “The programmer’s individual estimates then increase only very slowly until the task is actually completed.”
He studied a NASA software project at the Goddard Space Flight Center. It had been estimated at 1,100 person-days of effort. It took 2,200. Half the effort it needed had never been in the estimate, and for most of the project nobody could see that.
That is where the missing time goes. “Ninety percent done” is measured against the plan you had at the start. The work nobody planned for, the odd cases, the pieces that only fail when joined together, turns up at the end, when the bar already looks nearly full. Abdel-Hamid’s diagnosis was two things together: the job was underestimated, and progress was hard to see.
Imagine a café owner who gets a new online ordering page on a Tuesday. It looks finished. Ordering a coffee works. Paying works. That afternoon she tries it the way her customers will. A discount code knocks the price below zero. An address just outside town gets no delivery fee at all. The confirmation email lands in spam. Each fix takes half an hour. By five o’clock the page is still nearly done, and her list of fixes is longer than when she started.
“Done” for an agent
AI agents get to ninety fast. In 2025 the research group METR gave an AI agent built on Claude 3.7 Sonnet 18 real issues from two large open-source projects. Its code passed the maintainers’ own tests 38% of the time. Then the researchers read 15 of its pull requests by hand. None could be merged as it stood. Tests were missing, formatting was off, the code needed cleaning up. By the researchers’ rough guess, each would have taken a person about 42 minutes to put right, an estimate they call “very rough” and “subjective,” not a measurement.
Anthropic ran into the same thing when it set Claude to build a whole web app over many sessions. A later session, its engineers wrote, “would look around, see that progress had been made, and declare the job done.”
Their fix was to write the finish line down. Before any coding, a first session turned the request into a file of feature requirements, more than 200 of them for one app. Each line started out marked as failing. The prompt told later sessions to change only that mark and never to delete or rewrite a requirement. It was an instruction, not a lock.
A list wasn’t enough on its own. Claude still tended to mark a feature complete after unit tests or a quick request to the server, without noticing that it didn’t work from start to finish. So the engineers gave it browser automation and told it to test the way a user would. That helped a great deal, but not everywhere. The agent couldn’t see the browser’s own pop-up alerts, and the features that relied on them came out buggier. They were on the list, and checked, and still not done.