AI was meant to simplify work. You describe what you want, and the machine produces it faster and cheaper than a team ever could, which is why so many companies rushed to adopt it.
So why are teams producing more, but delivering less?
The system looks like it’s working, yet the outcome says it isn’t. In a restaurant, two tables can order the same steak and still receive something slightly different. One asks for no butter, another swaps the side, a third sends it back because it’s overdone. The process runs, the dishes arrive, but the experience drifts just enough to create friction.
Something is off. It just isn’t obvious where.
Most teams assume the issue sits with execution, because that is where the differences show up. If the output is wrong, then the tool failed or the instruction was unclear, so the natural response is to tighten control by adding more detail.
Specifications get longer. Prompts get heavier. Documents expand in an attempt to cover every possibility, as if precision in instruction will guarantee consistency in outcome. It doesn’t, because more detail does not fix unclear intent.
The problem is not variation. It is unclear expectations about what must be true when the work is done. That is the shift most companies have not recognised, because their systems were built for a world where execution was the hardest part. Now that execution is cheap, the difficulty has moved upstream.
Where work once failed in the building, it now fails in the instruction.
This is where specifications—what most teams call specs—quietly break. They are written to remove ambiguity by describing everything in advance, but what they actually produce is a record of effort rather than a definition of outcome.
AI does not need more detail. It needs the right kind of clarity.
A good spec is not a wall of instructions. It is a way of fulfilling a promise.
Which raises the real question.
What is the promise?
Start with the seam, not the spec
In a restaurant, the promise exists before any order is placed. Food should arrive hot, within a reasonable time, cooked as requested, and leave the guest satisfied. That standard holds whether the order is simple or complex, and it defines what “good” looks like before any individual request is made.
That is the seam.
It defines what must be true, without describing any specific dish, and it remains stable even as every table orders something slightly different. The spec only appears when a customer orders.
“Ribeye, medium-rare, no butter, fries instead of salad.”
This is not the promise itself. It is a request that must be fulfilled in a way that still satisfies the promise. You can execute the order perfectly on paper and still fail the outcome if the seam is unclear or ignored.
Clarity does not come from the spec. It comes from the seam.
And once that is clear, something else becomes unavoidable. The request will change.
A good spec is disposable
Every order in a restaurant is different, even when it looks the same. The details shift, the context changes, and what worked for one table may not work for the next. The system handles this naturally, because it is not built around preserving past instructions but around fulfilling the promise each time.
A spec exists for the moment it is needed. Once the dish is served, it is gone.
In most companies, specs are treated as permanent artefacts and defended long after they stop reflecting reality. In an AI-native system, that creates drag, because understanding improves as soon as execution becomes cheap and feedback becomes immediate.
The seam stays stable. The spec changes with every request.
But if the spec is constantly changing, it cannot rely on fixed steps to hold everything together. Something else has to remain consistent.
A good spec defines intent before steps
In a kitchen, you do not succeed by following instructions blindly. The same steak behaves differently depending on thickness, heat, and timing, so rigid steps produce inconsistent results. What matters is the outcome, not the sequence.
The order defines what must be delivered. The chef uses judgement to get there.
This is what a good spec does. It defines intent clearly enough that execution can adapt without losing direction, describing what must be true when the work is done rather than every step required to get there.
The plan will fail. The goal must survive it.
But survival is not enough. You still need to know if it worked.
A good spec is testable
In a restaurant, success is not debated. It is observed. Did the dish arrive on time? Was it cooked correctly? Did the guest enjoy it or send it back?
The order is only successful if it fulfils the promise.
This is what makes a spec meaningful. It connects to a way of proving whether the outcome was achieved. Without that, work becomes activity without feedback, and improvement becomes guesswork.
A good spec does not describe success. It makes it measurable.
Clarity is what can be tested.
But not everything that matters can be reduced to steps, and trying to do so creates a different problem.
A good spec leaves room for craft
Most companies respond to uncertainty by specifying more, as if ambiguity can be eliminated through detail. In a kitchen, that would mean removing judgement from the chef entirely and replacing it with rigid instructions that must be followed regardless of context.
The result is consistency, but not quality.
A good spec defines boundaries rather than steps. It makes clear what must be true, while leaving room inside those limits for adjustment and improvement. This allows the outcome to remain stable even as the method adapts to real conditions.
When everything is specified, the only option is compliance. When the outcome is clear, there is room to improve.
But space without structure introduces inconsistency, which leads to the next problem.
A good spec is structured for machines
Specs are no longer written only for humans. They are read, interpreted, and acted on by AI systems, which means they must be structured in a way that reduces ambiguity and supports consistent execution.
In the restaurant, this shows up as clearly defined orders, timing, and expectations, so that both people and systems can coordinate without confusion. Without that structure, even a clear intention can be interpreted in different ways.
A messy spec forces interpretation, and interpretation creates variation. A structured spec reduces that variation and makes execution more reliable.
Structure is what makes clarity usable.
But even a well-structured spec is only one part of the system it operates within.
A good spec connects to the system
A restaurant improves because it connects orders to outcomes. Guest feedback, kitchen timing, and patterns in returns all feed back into how the system operates, shaping how future orders are handled.
If those signals are ignored, the same mistakes repeat.
A good spec sits inside that loop. It is connected to the seam, to the mechanisms that verify it, and to the feedback that refines it. This turns the spec from a static instruction into part of a system that learns over time.
Work does not just get done. It gets better.
And that points to the real purpose of the spec.
A good spec accelerates learning
In traditional systems, specifications are used to reduce risk by trying to prevent mistakes before they happen. In practice, this slows everything down while still failing to eliminate error, because it assumes the plan can anticipate reality.
In an AI-native system, the advantage comes from how quickly you can learn. Each order is an opportunity to refine the process, adjust the approach, and improve the outcome based on what actually happened.
A good spec makes that loop faster. It defines what to deliver, how to judge it, and how to respond when it falls short.
Learning, not control, is the point.
Which makes the shift clear.
The shift
Most companies write specs to reduce risk, because their systems are built around avoiding failure.
AI-native companies use specs to increase speed, because their systems are built around learning from failure quickly.
One approach tries to prevent mistakes. The other is designed to expose them early and correct them.
The one line to remember
A good spec is not a perfect plan.
It is a clear, testable, and disposable way to fulfil a seam.