7 Versions of a Spec, 4 Sections Became Code: the $327M Loss of Mars Climate Orbiter and a Mechanism for Reconciling Spec with Build

On 23 September 1999, people sat in the control center of the Jet Propulsion Laboratory and waited for a signal. Mars Climate Orbiter was supposed to enter Mars orbit — fire the engine, brake, catch the planet's gravity at an altitude of 226 kilometers. Engineers watched the screens. The signal didn't arrive at the calculated time. It didn't arrive later either. The spacecraft entered the atmosphere at 57 kilometers — three times lower — and burned up like a match dropped into a furnace.

The cause wasn't a broken engine or a faulty navigator. Two teams — Lockheed Martin, which wrote the onboard software, and the JPL navigators — shared one common document. Software Interface Specification. An agreed spec that in black and white demanded SI units: newton-seconds. The Lockheed program silently output pound-force-seconds. The discrepancy was exactly 4.45. Nobody broke a rule. It's just that what became code was not what was in the specification. The price of that silence between "written" and "built" — $327.6 million. That money could have hired an army of people to do one thing for the entire flight: check that the code contained newtons. Nobody hired them. Burning up was cheaper.

I keep this story in my head every time I open my own repository with three versions of a technical specification across twenty-nine sections. Because I was that Lockheed team. And the JPL team simultaneously. I wrote the spec — and I quietly violated it with the agent's hands. My Mars just costs less, so I can afford to lose it more regularly.

The Spec Speculator

I have an antagonist, and he has a face. I see it every morning in the bathroom mirror, but I'll call him a separate person so it doesn't hurt as much. Meet the Spec Speculator — also known as the Architect of the Twenty-Nine Sections.

The Speculator confuses one thing for another, and his whole tragedy lives in that substitution: he mistakes the volume of a spec for its quality. Let me translate his illness into laboratory language, because there it has a precise name. A good spec is experimental design: a falsifiable hypothesis and a procedure that will test it. The Speculator, instead, writes not a protocol but a review article — lush, erudite, with an exhaustive list of references and zero methodology. He writes a spec the way a medieval monk copied the Bible: devoutly, richly, with illuminated margins. Section 7: "Architectural Principles." Section 12: "Error-Handling Philosophy." Section 19: "Glossary of Terms Appearing Nowhere Else in the Document." Every section delivers a physically palpable dose of control. The document gets heavier — and the Speculator feels like an engineer. He's not building a spacecraft. He's writing about a spacecraft in such detail that there's no time left to build it — and he calls this the design phase.

A scientist would recognize the genre from the doorstep. Seven spec versions is the laboratory's "further research is needed": the phrase written when there's no result but the grant keeps running. Each new version adds pages and subtracts decisiveness. The Speculator doesn't sharpen the hypothesis — he blurs it, because a blurred hypothesis can't be falsified and therefore can't be lost. Twenty-nine sections without a single falsifiable criterion isn't a specification. It's a preprint the author never dared submit for review, because the reviewer would ask the one question that collapses the whole tower: what experiment would show you were wrong?

The problem is that the feeling of control and control itself are different things, and the difference has been measured in a lab with a control group. In spring 2025, the research group METR did what the Speculator spends his life avoiding: it put feeling against the stopwatch and split them into different columns. Sixteen experienced open-source developers, 246 real tasks from their own repositories, each with an average of five years of experience. Half the tasks were allowed with AI tools, half without; randomization like a clinical trial where one group takes the pill and one takes chalk. Before starting, developers predicted AI would speed them up by 24%. The stopwatch showed AI had slowed them down by 19%. And here's the key point — the one that justifies having a control group at all: even after the experiment, having seen their own numbers, developers still believed AI had sped them up by 20%. Not slowed. Sped up. The data was in front of them — they believed the feeling.

The gap between feeling speed and the fact of speed — almost forty percentage points. People were flooring the accelerator in neutral, heard the engine roar, and sincerely took it for velocity. The most expensive part of that scene is that the speedometer was inside their heads while the wheels were outside, and nobody was watching the wheels. A scientist would call this a clean placebo speedup: the pill doesn't work, but the patient feels better and demands it be put into production.

That is the Speculator. His twenty-nine sections are that same roar in neutral. He's written three spec versions and feels +20% productivity while he's actually standing still with a minus. The document's thickness is his tachometer, detached from the wheels: needle in the red zone, car not moving, driver delighted.

Why 29 sections are technically worse than 4 lines

At this point most people stop at the moral — "don't write too much, write to the point" — and that's empty advice, because everyone gives it and nobody follows it. Instead I want to show the physics. Because in the post-AI era a bloated spec doesn't hurt aesthetically. It hurts mechanically.

Researchers at Stanford described an effect they called "lost in the middle." A large language model holds attention at the beginning of its context and at the end, tightly — the way a person remembers the first and last sentence of a speech. Everything in the middle falls through: accuracy drops by 30% or more when the needed information sits somewhere in the center of a long text. Context isn't read evenly. It's read the way we read a mortgage contract — first paragraph, signature page, and twenty pages in between on autopilot. The difference is that in a mortgage the middle hides the bank's commission, while in your spec it hides the condition that determines whether the spacecraft lands or burns.

Now overlay that on twenty-nine sections. The Speculator buried the critical condition — the one that decides whether the system works or burns — in section 14. Exactly in the model's anatomical blind spot. He didn't do it maliciously. He did it out of thoroughness: an important condition deserved its own section, and its own section ended up in the middle. The Speculator personally carried the most important sentence to the single place in the document where it's guaranteed not to be read — and was proud that he'd given it its own chapter. And the agent, generating code, physically didn't see that condition — not because it's dumb, but because that's how its attention works.

He personally carries the most important sentence to section 14 — the one place it’s guaranteed not to be read — and is proud he gave it its own chapter. The silverfish has already figured this out: fat and comfortable, it settled right in the middle of the stack, in the blind spot of “lost in the middle.”

That's why the phrase "three spec versions on twenty-nine sections and only four became code" is not a story of loss. It's a story of signal survival. The four lines that became code are not 4 out of 29 that somehow squeezed through. They are the four lines the agent could actually hold in view simultaneously. The remaining twenty-five sections didn't "fail to be implemented." They were never specifications — they were therapy for the author. A paid session with a psychoanalyst that also compiles with an error.

Parameter	The Speculator's spec (29 sections)	Spec as contract (4 lines)
What it gives the author	Feeling of control (+20%, as in METR)	Control (verifiable)
Where the critical condition is	Section 14 — in the "lost in the middle" blind spot	Line 2 of 4 — in the attention window
What the agent sees	Start and end; middle — 30% worse	Everything, simultaneously
Verification mechanism	Absent ("but I wrote it all down")	One test: built = written
1999 analogue	Software Interface Specification that everyone signed	SIS + unit check before launch
Result	Mars Climate Orbiter	Spacecraft in orbit

Note the last row. The Mars Climate Orbiter teams had a perfect document. Twenty-nine sections of specification, if you like. Agreed by all. The problem wasn't a bad spec. The problem was that nobody verified the code against the spec before the spacecraft launched. The conclusion of the NASA mishap investigation board is the most important sentence in all of this, and I'll quote it verbatim:

«The problem here was not the error; it was the failure of NASA's systems engineering, and the checks and balances in our processes, to detect the error.»
— Edward Weiler, NASA Associate Administrator for Space Science

The problem was not the error. The problem was the absence of a mechanism to catch the gap between specification and implementation. The error is not a diagnosis; the diagnosis is that nobody was tasked with finding it. Remember that formulation — it will return.

Who profits from your section 14

But why does the Speculator exist in such numbers in the first place? This isn't personal choice or weakness of character — it's a rational response to an incentive system that rewards the thickness of a document because clients see sections, not orbits. Three parties feed off this blindness, each in their own white coat of seriousness. The AI-tools vendor sells you a "governance platform" with two hundred features: he's the colleague who shows not the result but a fat apparatus with buttons, and the price is justified precisely because the dashboard looks complex, even though it measures satisfaction rather than orbit. The "AI implementation strategy" consultant bills you for weeks of reconciling section 7 with section 12 — publishing a paper per meeting, growing their h-index of footnotes, and never once running a control group, because the control group would show things were the same without them. The corporate software integrator wins the tender on proposal thickness: procurement has been trained to equate volume with seriousness, like a reviewer who accepts a forty-page paper because a two-page version would look flimsy. All three are selling you the p-value of their own existence — and none of them will let you test it.

Who pays for this game: the solo founder with a four-day deadline, and the three-person startup team that has neither a lawyer to parse twenty-nine sections nor the time for an illusion of control. They either copy the corporate template (and drown in section 14) or write no spec at all (and drown sooner). Spec bloat isn't a system bug. It's the product.

The counter-argument worth hearing

Here it's worth stopping honestly. Not all twenty-nine sections are neurosis. There's a real class of systems where four lines are a death sentence, not discipline. Distributed microservices with five teams across different time zones. Medical software under FDA 21 CFR Part 11, where every requirement must be traced to a specific line of code and signed by two engineers. Avionics, where formal verification isn't bureaucracy but the only way to prove the absence of errors. For these contexts a full specification isn't spec for spec's sake — it's a real coordination mechanism between people who can't read each other's minds, and for a regulator who needs an audit trail.

But here's what this counter-argument doesn't explain: the vast majority of projects that today produce twenty-nine-section specs are not avionics and not FDA-regulated software. They're MVP SaaS products that two hundred people will use. An internal dashboard. An automation script with a three-month lifespan. Here a thick spec plays the role a scientist knows as cargo cult: repeat the external rituals of real discipline — requirements traceability, formal verification, two engineers' signatures — in hopes that the ceremony alone will make the plane fly. Avionics writes a hundred sections because one bug costs coffins. Your dashboard writes a hundred sections because avionics did it. The first is methodology. The second is an imitation of methodology that confused rigor with thickness and decided: if you put on a white coat, the analysis becomes valid. Complex systems genuinely need more structure. But structure is not volume, the reviewer is not a security guard at the entrance, and the glossary in section 19 has saved no orbits.

Six anti-patterns of the Speculator

I've catalogued my own sins. The system rewards the thickness of these documents — the client sees sections, the customer sees seriousness, the board sees "process." But not as a reproach to you — more as a dissection protocol for yourself: if you recognize at least three, you also have your own budget Mars, and you've already bought it a one-way ticket.

#	Anti-pattern	How the justification sounds	What's actually happening
1	Volume instead of thesis	"I wrote everything out in detail"	+20% feeling with −19% output (METR)
2	Burial in the middle	"The critical condition is in section 14"	"Lost in the middle" blind spot, −30% attention
3	Spec without verification	"But I documented everything"	Lockheed software: pounds instead of newtons
4	Raw prompt without contract	"The agent is smart, it'll figure it out"	19.7% of generated dependencies are non-existent
5	Versioning of anxiety	"This is already the third spec iteration"	Three refactors of anxiety, zero decisions
6	Gloss instead of thinking	"It looks professional"	"Looks right but doesn't quite work"

I'll linger on the fourth, because it's the most frightening of all — and the funniest. When you throw a raw prompt at an agent without a spec of allowed dependencies, it will write the imports itself. Sounds like convenience. Research by Spracklen et al. (USENIX Security 2025) analyzed 576,000 generated code samples from sixteen models and found that 19.7% of suggested dependencies are packages that don't exist. Over two hundred thousand unique fake names, conjured from thin air with the absolute confidence of intonation. The agent doesn't say "I don't know that library" — it says "import" and places a period, because doubt is not part of its grammar.

And this is not theory. Researcher Bar Lanyado from Lasso Security noticed that models persistently hallucinate a package called huggingface-cli (the real one is installed differently). He registered an empty dummy with that name on PyPI — just to see what would happen. In three months it was downloaded over 30,000 times. Among those who swallowed the hallucination and pasted it into their README was Alibaba. Imagine the scale of the irony: a hundred-billion-dollar corporation installs a package that exists solely because a neural network dreamed it up, and a helpful person decided to materialize the dream.

The worst part is the stability of the lie. Of the sixteen tested models, 43% of hallucinated names repeated on the same prompt across all ten runs — not random noise but a reproducible result with an error approaching zero. That means an attacker can predict what exactly your agent will invent and register the fake in advance. The phenomenon already has a name — slopsquatting. The attacker doesn't even need to hack you: they just listen to what your machine mutters in its sleep and set the trap precisely where it will confidently step tomorrow. An allowlist of dependencies in your spec isn't bureaucracy. It's a firewall against the machine's confident lies. Four lines of specification where one says "no dependencies outside this list" are worth more than twenty-nine sections of architectural poetry.

And now the sixth anti-pattern — gloss — because it's the most lovable and therefore the most treacherous. "Looks right but doesn't quite work" isn't the agent's negligence. It's a p-hacked result in pure form: a beautiful graph, a convincing caption under the figure, and zero reproducibility under the hood. A scientist has seen thousands of papers like this — the one where the conclusion shines because the author quietly threw out three failed runs and kept the one lucky one. The agent does exactly that: generates code that compiles, passes the demo, and collapses at the first edge case that wasn't in the showcase sample. Gloss is a spec polished to the point where it's pleasant to show the board and impossible to verify by test. It's publishable. It's just not reproducible.

Brooks knew this 50 years before agents

Here one wants to exhale and say: "Well, AI broke everything — it was simpler before." A lie. It's just that Mars used to fall more slowly — and we had time to look away while it burned.

The original Standish Group CHAOS Report from 1994 — long before any agent — counted the fate of software projects. Successful: 16.2%. Cancelled before completion: 31.1%. The remaining 52.7% crawled to the finish line with budget overruns averaging 189%. And here's the key point: the number-one reason projects were killed in that report was "Incomplete Requirements," 13.1%. Not bad programmers. Not weak hardware. A leaky spec. This is historically the leading cause of project death — a decade before anyone uttered the word "prompt." We were killing our own projects with a hole in the spec long before AI could even hallucinate packages — we just did it slowly and manually, with dignity.

And even earlier, in 1986, Fred Brooks in the essay "No Silver Bullet" (collected in the anniversary edition of "The Mythical Man-Month") wrote a sentence that deserves tattooing on the back of every keyboard:

«The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements...»

The hardest part of building a system is deciding what to build. Brooks said that four decades before agents. Structured programming promised to make writing code trivial — and revealed that the complexity lives in the decision of "what." OOP promised the same — and revealed the same. Agile, frameworks, low-code — each wave stripped another layer of plaster and showed the same load-bearing wall: deciding what to build is all the work. For forty years the industry bought ever more expensive tools to avoid looking at that wall, and kept marveling at why the building always collapsed in the same place.

AI stripped the last layer. When writing code is delegated to an agent approximately 80% of the time — the figure Karpathy cited on stage at Sequoia in 2026, adding that he hadn't typed a single line himself since December 2025 — the decision of "what to build" stops being part of the human's work. It becomes the only work of the human. All the complexity that had been hidden in syntax for forty years surfaced into one question — and it turned out to be a question of experimental design, not text entry. Spec discipline in the post-AI era is not about writing the perfect document; it's about having one ruthless mechanism that checks what was built against what was written. The thing that was absent at NASA on 23 September 1999.

The man who buried his own child

The irony of this era is best embodied by one person in two scenes exactly one year apart.

Scene one. February 2025. Andrej Karpathy leans back in his chair, dictates code by voice through a transcription app, barely touching the keyboard, and writes a phrase that instantly racks up millions of views: "fully give in to the vibes... forget that code even exists." The term vibe coding is born. Chaos blessed from Olympus itself.

Scene two. The same man, one year later, on stage at Sequoia AI Ascent 2026. He says he's never felt more "behind" as a programmer, and declares vibe coding obsolete. The replacement: "agentic engineering" — you don't write code directly 99% of the time, you orchestrate agents and play a supervisory role. Vibe coding raises the floor — anyone can build anything. Agentic engineering maintains the ceiling of quality — you are not permitted to introduce vulnerabilities for the sake of vibes; you are still responsible for your software.

The same man who blessed the absence of rules, one year later, personally signed its death warrant and called "oversight" exactly what he had previously disdained. He didn't betray the idea — he was simply the first to see the bill it presents, and decided to pay it with the word "discipline." And the industry behaved as always: canonized discipline retroactively and started selling the rules back. On 2 September 2025, GitHub released Spec Kit — a tool where specification is explicitly called "a contract for how code should behave and the source of truth by which agents generate, test, and validate code." First, euphoria over the absence of rules. Then, institutions selling rules back in attractive packaging. The spec returned — only now as an executable interface to the machine, with a price list.

The tool: an AI-friendly spec that fits inside attention

Enough diagnosis. Here is the scalpel I now use to cut my own twenty-nine sections down to four. This is a specification template designed around the physics of a model's attention — so the signal lives at the beginning and end, and doesn't die in the middle.

Block	Question it answers	Why here
1. Intent (1 sentence)	What does this system do and for whom?	Beginning of context — zone of firm attention
2. Hard constraints	Allowed dependencies; what must NOT be done	Firewall against hallucinated packages (19.7%)
3. Behavior contract	Input → output, in concrete units	"Newtons, not pounds" — literally
4. Verification criterion	What test proves that built = written?	End of context — second attention zone; what NASA lacked

Four blocks. Not twenty-nine. Everything that didn't fit was not cut from the spec — it was exposed as what it always was: your anxiety dressed up as a section. Block 4 is not optional. If you can't formulate a test that proves the code matches the specification, you don't have a specification. You have an essay about intentions. And that essay burned at 57 kilometers altitude — along with the author who was confident until the last moment that he'd documented everything.

What the verification mechanism looks like when it's not abstract

I've said "ruthless verification mechanism" twice and never once shown it in practice. That is the same sin I'm charging the Speculator with, so let me correct that: here it is, in one line of code. Because a scientist knows one thing that the author of a review article doesn't: a hypothesis without a falsification procedure is not a hypothesis — it's a mood.

Take Block 3 from the template above: "given input thrust in pound-force, the function returns thrust in newtons." The Speculator would have written a paragraph of units philosophy in section 8. Verification is different. It's a precondition: what is the minimal experiment that will break the code if the code lies? The answer fits in one line:

assert convert_thrust(1.0) == 4.45  # pound-force → newton; otherwise — Mars

Let's unpack why these twenty symbols are stronger than twenty-nine sections. First, it's falsifiable: there is exactly one number that either matches or doesn't; the third state — "roughly seems right" — doesn't exist, and that third state is precisely where the Speculator lives. Second, it's a control group in the form of code: the Lockheed software would have output 1.0 instead of 4.45, the test would have gone red on the very first second, and nine months of flight wouldn't have been needed to learn the price of the discrepancy. Third, this line sits at the end — in the second zone of firm attention, not in the anatomical blind spot of section 14. The agent, while generating, sees the criterion last — and writes the code toward it, not past it.

Here is the operating rule to which everything reduces. Before opening the IDE, write not the specification but the test that will falsify it. If you can't write the test — you don't yet know what you're building. And that's not a reason to add a thirtieth section. It's a reason to stop and formulate a hypothesis that can actually be lost. Twenty-nine sections is a way to never reach the line where it becomes visible that the emperor has no clothes. One assert proves it in a millisecond — which is exactly why the Speculator instinctively doesn't write it.

And one caveat against the opposite extreme — so you don't confuse discipline with neurosis. On the set of "The Shining" in 1980, Stanley Kubrick forced actors to repeat one take dozens of times consecutively — the axe-through-the-door scene reportedly ran more than a hundred times — holding in his head the exact specification of each frame and driving people to breakdown. That too is spec discipline — taken to pathology, where the specification is so complete that the implementation becomes only its suffering. Kubrick got his perfect shot and a broken crew; the Speculator gets a perfect document and an undelivered task — both overpaid for completeness nobody asked for. Four lines are not about knowing everything. They're about knowing exactly as much as will survive the transfer to the machine — and not one section more.

Finale: everyone has their Mars

Return to that JPL control room on 23 September 1999. Engineers stare at a screen where the signal was supposed to appear, and it doesn't. The spec was approved by everyone. All twenty-nine sections of it, if there were that many. The document was flawless. It's just that something different became code, and between those two facts stood no mechanism to shout "stop" before launch.

The post-AI era didn't give you that mechanism. It took away your time to do without it. Previously the gap between "written" and "built" accumulated over months, and could still be accidentally spotted in code review. Now an agent generates that gap fast, confidently, a thousand times a day — inserts a non-existent package, ignores the condition in section 14, outputs pounds instead of newtons, and reports to you that the task is complete. Looks right. Doesn't quite work. The spacecraft is already in the atmosphere, and the logs show a green checkmark.

Discipline is not the thickness of your spec. The Spec Speculator died on the same hill as Mars Climate Orbiter: with a perfect document that nobody verified. On his headstone they'll engrave twenty-nine sections in fine print, and nobody will read to section fourteen. Discipline is four lines the machine can hold in view simultaneously, and one ruthless test that catches the gap before the spacecraft launches.

Code got four lines — not the ones that squeezed through, but the only four the agent could hold in view at the same time. The machine shredded the remaining twenty-five sections into confetti, and even the silverfish was left with nothing: therapy for the author isn’t something you can eat.

Right now you have a repository open with three spec versions. Don't re-read them — that will only stroke the feeling of control up another 20%. Instead, run the single experiment the Speculator spent his whole life fleeing: find the most critical condition and ask whether there's a line of code that will go red when it's violated. If there's no such line — you don't have a specification, you have a hypothesis without a falsification procedure, which is to say, a mood. And a mood burns at 57 kilometers altitude regardless of how many sections it was laid out in. The only question is at what altitude you notice — and whether there's still time to look at the wheels instead of the speedometer.