The Brief Was Always the Expensive Part

On September 23, 1999, the Mars Climate Orbiter fired its engine to slip into orbit around Mars and was never heard from again. The spacecraft had flown 400 million miles over nine months and was lost when it dropped far too low into the Martian atmosphere, aiming for a closest approach of about 226 kilometers, it came in near 57, well beneath the altitude it could have survived. The investigation found the cause, and it was not a hard problem. One engineering team had supplied a thrust figure in pound-force seconds; the navigation software expected newton-seconds. Nobody had pinned down which unit the interface used, because everyone assumed the answer was obvious. That unwritten assumption cost NASA the orbiter, part of the $327.6 million Mars Surveyor ‘98 program that also carried the Mars Polar Lander.

No one lost the orbiter by doing the production badly. The trajectory math was flawless. The code ran exactly as written. What was never actually specified was the one thing that mattered, the definition at the seam between two teams, and the failure hid inside otherwise-excellent work until the moment it became a fireball. The expensive part of the work was never the production. It was the specification, and specification has a habit of hiding inside production until something forces it into the open, which is exactly what handing production to a machine now does, at scale, in every function at once.

What follows: why trading people-hours for machine-tokens is not the linear win it looks like, why your playbooks turn out to have been unwritten all along, and what changes about the job once specification stops being free.

The strongest version of “this is a straight cost swap”

The optimistic case is arithmetic and seductive. A task takes a skilled employee ten hours. A machine does the same task in ten minutes at a fraction of the cost. Multiply across a department and the savings are enormous and obvious. Concede the arithmetic, because on the production line it is simply true: the hours a person spent drafting the memo, building the model, assembling the report, writing the first-pass contract: those hours collapse, and they collapse hard. Anyone telling you the production savings are a mirage has not watched a competent loop clear a backlog. They are real.

The swap breaks on a hidden assumption: that the ten hours were all production. They weren’t. Threaded invisibly through those ten hours was a second kind of work the employee did without noticing and without billing separately: resolving ambiguity. Which customer does “our customer” mean here. Does this clause apply to the renewal or only the new deal. The source data looks wrong for March; do I use it or flag it. A competent person hits a dozen of these forks in any real task and settles each one silently, using judgment, context, and a mental model of what the work is for. That settling is specification. It never appeared on the plan because it was smeared across the production, discovered incrementally, in motion.

So the honest version of the steelman is this: the production hours really do collapse, but they were carrying specification hours the whole time, and those do not collapse. They come due somewhere else.

The category error

The mistake is to model the org as a stack of production hours to be swapped for tokens, when a large fraction of what your good people do is silent specification you never priced. Remove the person and you do not remove that work. You relocate it, and you relocate it to the worst possible place.

Here is the mechanism, and it is specific to how machines fail versus how people fail. A competent employee who hits an ambiguity stops, notices the fork, and resolves it, often without telling anyone, which is why you never saw the work. A machine does not stop. It resolves the ambiguity too, but it resolves it by producing the most plausible-looking output, confidently, and moves on. The judgment that a person would have applied at the fork is simply absent, and its absence is invisible, because what comes back is fluent and formatted and sure of itself. The ambiguity a human would have caught mid-task now surfaces as a polished, wrong artifact that looks exactly like a right one. You have not eliminated the specification work. You have converted it from something a person did quietly and correctly in real time into something you must now do explicitly, up front, or pay for as a confident error downstream.

This is why organizations adopting AI in earnest keep making the same unsettling discovery: their briefs, playbooks, and success criteria were never actually written down. They lived in the heads of experienced people and got applied silently, thousands of times a day, at every fork. The moment the work goes to a machine, every one of those unwritten resolutions has to become explicit, or it becomes a defect. Decades of software economics prophesied this; Barry Boehm’s data from the 1980s showed that a requirements ambiguity caught early costs a fraction of what the same ambiguity costs once it has propagated into a finished product: a ratio that runs to one or two orders of magnitude on large projects, though the exact multiplier has been debated since. AI does not repeal that curve. It puts every function on it at once, because production is no longer the throttle that used to give a competent person time to catch the ambiguity on the way past.

Where the tooling comes in

The response is not to specify everything in advance; that is its own fantasy, and it stalls the work. The response is to make the unit of production small and verifiable, so that ambiguity surfaces early and against a real check rather than late and against a customer. This is the whole design intent of an AI-native harness like DevFlow, the developer platform AOCyber built to run on top of Claude Code: break the work into discrete tasks, and verify each one against whether the actual objective was met rather than whether a step was marked done. That is a software mechanism, but the principle is general and it is the point of this essay. Cheap production is only a gift if the specification it runs against is explicit enough to check. Where it isn’t, the machine will fill the gap with confident invention, and you will find out at the seam, the way NASA did.

What to do

Start by writing down one playbook you have never written down. Pick a decision your experienced people make constantly and “just know” how to handle: which deals to discount, which contracts to escalate, which support cases to refund. Try to specify it well enough that a new hire, or a machine, could apply it without you in the room. You will find it is far harder than it feels, and the difficulty is the entire lesson: that decision was real specification work, done silently for years, and you were about to hand it to a system that cannot do it silently. Writing it down is not bureaucracy. It is the recovery of an asset you didn’t know you had and were about to lose.

Then change what you reward in the work. The person who produces the fluent draft is doing what tokens do. The person who can state the definition at the seam (precisely which unit, precisely which customer, precisely what “done” means) is doing the part that was always expensive and is now the whole job. As the earlier essay on domain experts put it, the scarce skill is writing down what “good” looks like, and that skill was never a preamble to the work. It was the work, hiding.

Cheap production did not make the brief cheap. It made the brief the only thing left that costs anything. The brief was always the expensive part.