Anyone can do anything now.

AI has made execution fast and accessible. A single builder can design, build, market and analyse in a single day. And because of that, something unexpected happens: teams produce more, but lose track of what the output is actually for.

For a long time, skill was the constraint. Execution depended on specialists, coordination, and time. That is no longer true.

Once execution becomes abundant, what limits progress doesn’t disappear, it shifts. What limits progress is no longer whether something can be built, but whether the system knows what it’s trying to achieve.

A different way to see it

Take a restaurant.

The Head Chef designs the menu, the kitchen prepares the food, front of house serves it, and management reviews performance at the end of the week. Each part focuses on its role, and together they produce a consistent experience. The system works because it’s built for coordination. When execution is difficult, dividing work across specialists is what makes delivery possible, so the structure itself becomes the solution.

Now imagine the restaurant wants to improve something simple: more guests returning.

That outcome touches everything — food quality, speed of service, attentiveness, atmosphere — but it isn’t defined in a way that makes the outcome visible day to day. So when something slips, no one in the restaurant can locate it clearly, even though everyone is doing their job.

A guest hesitates before ordering dessert because their main meal took too long to arrive. Front of house notices the hesitation, but the kitchen doesn’t see it, and management only recognises the pattern at the end of the week, when it shows up in reviews and a drop in dessert orders. The signal exists, but it’s fragmented across the restaurant, so no one can act on it with confidence.

The restaurant still works, but it slows and stutters because no one can see clearly where things are going wrong. The signals are spread across the floor, the kitchen, and the end-of-week reports, so nothing looks obviously broken, and nothing changes.

Clarity

Clarity starts by making the outcome visible.

In the restaurant, that means one thing: meals arrive within 15 minutes, and satisfaction is tracked daily. Everyone can see it as it happens, so they can respond immediately instead of waiting to stay aligned.

For that to work, two things have to exist at the same time: 1. the outcome must be defined as a contract 2. the restaurant must be able to adjust towards it continuously.

If either is missing, the restaurant can still deliver, but it won’t improve, because there’s nothing concrete to act on.

Seams

In the restaurant, the Head Chef defines the outcome properly: • guests receive their meals within 15 minutes of ordering, • guests are asked about their experience before they leave

This isn’t a goal or an aspiration, it’s a contract, which means it can be measured and, because it can be measured, it can be improved.

The shift isn’t in the wording, it’s in what becomes impossible to ignore once the contract exists. Not as opinions but as signals, hesitation becomes visible, delays become visible, trade-offs become visible.

The kitchen misses the 15-minute mark, so the delay is visible immediately. Front of house sees the consequence: a guest hesitates before ordering dessert and mentions the wait. Management can see both during service instead of piecing it together later.

Roles, in practice

Once the outcome is defined, roles stop being descriptions and start becoming contributions to a shared result. The Head Chef turns belief into something testable. The kitchen adjusts until the outcome holds. Front of house sees where it breaks first, which means the loop begins with them, not management.

A guest mentions the wait felt long, that signal moves back to the kitchen, prep changes, timing tightens, and the next table moves faster. No meeting is required because the system itself carries the signal, and no escalation is needed because the adjustment happens where the problem appears.

What looked like separate roles becomes a continuous loop of observation and response, held together by the visibility of the outcome rather than coordination between people.

How work moves

Once the outcome is clear, the focus shifts from who missed the table to what caused the delay. Orders are taken quickly, which exposes where delays actually occur, and once those delays are visible, the kitchen stops asking who missed the table and starts asking where the delay is coming from.

Prep is reorganised, table flow is adjusted, and each change reveals the next constraint, so improvement becomes continuous rather than something deferred to reviews or retrospectives.

Work no longer moves step by step between people, it moves against the outcome, and because the outcome is visible, progress can be seen and adjusted in real time.

Where AI fits

The restaurant analogy only goes so far, but the same pattern holds: if the outcome isn’t clear, making the system faster doesn’t fix it, it just scales the lack of visibility.

AI only behaves differently when the outcome is defined, because now AI isn’t executing steps, it’s operating against a result. When success is explicit, the system can test, adjust, and improve, not because it’s been instructed to, but because it can see what it’s moving towards.

Nothing about the capability changed. Only the target did. And that’s what makes improvement possible.

The shift

For a long time, companies were designed around execution, so that’s what they learned to manage. Execution is no longer the constraint, but the systems built to manage it haven’t changed so they’re no longer fit for purpose.

What matters now is whether the system can see what it’s trying to achieve.

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.

It sounds aggressive, but he’s right. Most requirements are wrong because they are inherited, assumed, or added “just in case.” Over time they pile up until nobody knows what actually matters, so the only way forward is to cut and see what breaks.

That works, but it reveals a deeper problem. Companies are not failing to cut. They are failing to know what they’re allowed to cut.

So everything stays, and as it grows, clarity disappears.

Not because it’s all necessary, but because nothing feels safe to remove. Every requirement might matter. Every detail might be important. Without a clear boundary, there is no way to tell the difference between what drives the outcome and what simply surrounds it.

A Restaurant Already Knows What Matters

You can see the difference in a restaurant.

When you place an order, you don’t describe the cooking process or explain how the dish should be made. You say what you want: ribeye, medium-rare, fries, sauce on the side. The kitchen figures out the rest.

That order works because it is already clear about what matters. It defines the outcome without carrying unnecessary detail, so there is nothing to debate and nothing to interpret.

You Can Feel a Bad Specification Instantly

Now imagine the same order written the way most companies write specifications.

“I’d like a steak, medium-rare but not too red, slightly pink, fries but not too crispy, sauce on the side but warm, unless that makes it soggy.”

The problem is obvious. It is not just longer, it is confused. It introduces contradictions, hedges, and conditions that don’t change the outcome but make execution harder.

That is what most specifications become. Not because people are careless, but because they are trying to reduce risk. They add detail to feel safe, but in doing so they remove clarity.

Why Cutting Works (And Why It’s Not Enough)

This is why Musk’s rule works. When you don’t know what matters, removing things is the only way to find out. If the steak still arrives correctly without a requirement, that requirement was never needed.

But in a restaurant, you don’t need that rule. Nobody says “delete 10% of the order” because the structure already makes it obvious what belongs and what doesn’t.

A Seam Makes the Cut Obvious

In Clarity, that structure is called a seam.

A seam defines what must happen and how success is measured. In the restaurant, it might be this: serve a hot, medium-rare steak within 20 minutes, with at least 80% of guests rating it four stars or above.

Once that is clear, every requirement can be tested against it. If it doesn’t affect time, temperature, or guest satisfaction, it doesn’t belong in the order.

“Don’t overcook it” goes. “Make it look premium” goes. Anything that does not move the outcome is removed.

Two Ways to Reach the Same Place

Musk cuts to discover clarity because the system doesn’t provide it. Clarity defines it first, so the cut becomes obvious.

Both approaches remove the same things, but one relies on force while the other relies on structure.

Why This Breaks at Scale

Most companies try to improve specifications by adding more detail, more edge cases, and more safeguards. This increases the distance between what is written and what actually matters.

In a restaurant, that would be like expanding the order instead of refining it, adding instructions the kitchen doesn’t need and conditions that don’t change the result. Execution slows, but the dish doesn’t improve.

Systems that depend on interpretation do not scale. AI does not interpret intent. It executes what is written.

Clarity Removes the Need to Guess

That is why restaurant orders feel natural. The system forces clarity by keeping the focus on the outcome, so anything unnecessary falls away before it reaches the kitchen.

Companies don’t have that system, so they rely on effort instead. More thinking, more writing, more alignment meetings, all trying to compensate for something that structure should have solved.

It doesn’t work.

A specification is not finished when everything is included. It is finished when everything unnecessary has been removed.

What success looks like

In a restaurant, the Head Chef does not cook every dish. Their role is to define what a great dish is, in a way that others can aim for without needing constant instruction.

A steak might be described as deeply flavoured, consistently medium rare, and something guests would order again without hesitation. That is not a method. It is a target that shapes every decision that follows.

Outcome seams define the result without prescribing the path. When they are clear, teams align naturally because everyone is aiming at the same thing. When they are vague, people stay busy but drift, and activity replaces progress.

Constraint Seams

The boundaries that shape how success is achieved.

Alongside the outcome, there are limits that cannot be crossed. The beef must be sourced a certain way, the cost must stay within range, and the presentation must meet a specific bar.

These constraints do not define success, but they define the space within which success can exist. They protect the identity of the restaurant while leaving room for judgement and skill.

Without them, teams optimise locally and the experience fragments. With them, creativity is focused rather than restricted.

Operational Seams

How work moves through the system.

A dish does not go straight from idea to table. It moves through a series of transitions, from kitchen to pass to waiter to guest, and each of those moments either preserves clarity or distorts it.

Operational seams define those handoffs so that what is created can actually be delivered. They remove hesitation at the edges, where most friction appears.

When these seams are weak, teams compensate by checking, rechecking, and slowing each other down. When they are strong, the system moves with pace and confidence because each part knows exactly what to expect from the next.

Trust seams

What proves it actually happened

Once the dish reaches the table, intent no longer matters. The only question is whether the outcome was delivered.

Trust seams answer that question with evidence. Plates come back empty, guests give consistent feedback, and quality checks happen before a dish leaves the kitchen.

Without this, performance becomes a story people tell. With it, performance becomes something everyone can see.

Feedback seams

How clarity evolves

A restaurant that only delivers will plateau. The difference between good and great is the ability to learn from what actually happens and update what “good” means.

A guest sends a dish back because the meat is slightly over. Another says it is perfect but heavier than expected. Over time, patterns begin to emerge, but only if they are captured and acted on deliberately.

A feedback seam is a contract to learn. It defines what feedback counts, how it is collected, how quickly it moves, and when it leads to change.

The waiter notices the pattern, the kitchen tests adjustments, and the Head Chef refines the definition of success. The system improves not by chance, but by design.

The System Working Together

A single dish is shaped by all five seams at once. The outcome defines what success looks like, constraints define the boundaries, operational seams carry the work forward, trust seams prove the result, and feedback seams update the definition over time.

Nothing is left to interpretation, and nothing depends on individual heroics to hold it together. The system itself creates alignment.

Why This Matters Now

Most companies operate with fragments of this system. Outcomes are vague, constraints are implicit, operations rely on informal knowledge, trust is based on reporting, and feedback is collected but rarely used.

This doesn’t break immediately because people compensate. They fill the gaps with experience, judgement, and constant coordination, holding the system together through effort rather than structure.

As complexity increases, that effort stops scaling. The gaps turn into failure points.

Introduce AI into that environment and the problem becomes visible. The system can no longer rely on interpretation. It needs clarity that can be executed, measured, and refined without guesswork.

Give an AI the job of running this restaurant and it will not compensate for ambiguity. It will follow what is defined, expose what is missing, and amplify the gap between intent and reality.

The Real Shift

Clarity is not about adding process. It is about increasing learning speed.

When all five seams are in place, the company becomes a system that improves itself. Humans define what matters, AI helps execute and explore, and the system uses real evidence to refine its direction over time.

Clarity stops being something written down and ignored. It becomes how the organisation actually works.

AI is coming for the kitchen, not slowly or politely, but directly. And this time, it can actually cook.

Companies are looking at systems like the Moley Robotic Kitchen or Robby AI and seeing one clear benefit: cost reduction. A robot doesn’t call in sick, doesn’t need training, and produces the exact same dish every time. So the decision seems obvious: replace the chef.

What usually happens next

The kitchen doesn’t disappear, it degrades. The chef becomes a machine operator — refilling ingredients, pressing start, serving whatever the machine produces.

There’s no creativity, no ownership, and no growth. They’re not cooking anymore, they’re maintaining a machine they don’t own.

This is what people are actually afraid of when they talk about AI. It’s not the job they’ll lose, it’s the future.

Overnight, the skills, judgment, and pride that once defined them stop mattering. Even the belief they could one day open their own restaurant goes with it.

So what exactly is left for them?

The Clarity shift

Now imagine the same restaurant. The same machines, the same investment, but a different system.

This time, they use Clarity. The chef isn’t defined by cooking each dish by hand. They’re defined by a single outcome: create the best stir-fry in the area, stay within food cost, and increase repeat orders week after week.

That’s a seam — a clear contract that defines what success looks like.

When that’s clear, the incentives line up. Improving the outcome improves everything else — the food, the business, and the person doing the work.

That’s alignment — when improving the system improves the people inside it.

What changes

The machine handles consistency, and the chef handles results. With execution handled by the machine, what’s left is deciding what improves. The chef sources better ingredients and experiments with flavour, but the real shift is what they pay attention to.

What do customers actually reorder? What gets left on the plate? What brings people back?

The job moves from making food to shaping the experience. They’re not further from the kitchen, they’re closer to the customer than ever.

The role evolves

Before, getting better meant repetition. Cook the same dish again, refine the motion, improve the timing.

Now, getting better means reading what happened and deciding what to change. A dish comes back half-eaten. Another gets reordered three times in one night. So they adjust – balance the sauce differently, change the cut of meat, try brining and velveting to improve texture.

Each change is intentional, and each result feeds the next decision.

The difference

Without Clarity, the job is to operate the machine. With Clarity, it’s to own the outcome.

Why it matters

AI doesn’t replace people. Misaligned incentives use it to strip jobs of meaning and ownership.

What’s missing is clarity. When the outcome is clear, machines take execution, and people own the outcome.

The restaurant doesn’t just become faster, it becomes more alive. Better food, more engaged staff, tighter feedback loops.

So the question isn’t whether people are replaced. It’s whether incentives still make sense once AI is introduced.