I

You're the owner of a pizza joint.

Around this time last year, your oven could hold 10 pizzas.

Recently your team bought a special oven. It handles 100 pizzas at a time.

Glorious! You must be rolling in extra cash!

Oh. Hm. You say you aren't.

A million-dollar question: where's your million dollars?

"My cooks are stupid. Or slow. Or sabotaging me. The point is, they're using the oven all wrong."

Many restaurant owners have fired a bunch of cooks on these assumptions.

You didn't; you know yours are solid. Or at least: you know they can use the oven to make pizzas at least as well as you can.

They prove it. Your oven's automated tests? All green. Greener than they've ever been. The 100 pizzas that come out of that thing are consistently hotter, fresher, and tastier than ever.

So why are neither you nor those other owners seeing skyrocketing revenue?

You're pacing back and forth, trying to figure it out.

Your menu hasn't changed. Your oven is 10x better. Where are your 10x customers, your 10x valuation, your 10x dollars?

It must be things happening between menu and oven. (You're no dummy.)

It's a process thing. A complexity thing.

Of course! The paths from "customer chooses item" to "oven prepares item" to "item is given to customer" — that's where things can be improved, untangled, made more efficient.

Let's look at a few minutes in the life of this pizza joint:

• A customer orders a normal pizza.
• A customer orders one with some items removed. You tell them no substitutions. They say "ok."
• A customer asks for a substitution, but the cashier has been informed that they're a food critic. Substitution made.
• A customer orders something you've run out of. Too bad.
• A customer orders a quantity of pizzas large enough to clear out an ingredient you have, but you can make half of the pizzas with the ingredient, so you go back to the customer and ask if they want half of your pizzas with that ingredient, and they say nah, they'll just go without it.
• A customer looked like they were loving their pizza, but comes back to the counter and insists their pizza was dreadfully cold, and they want another. Even though the one they got was just fine, you end up replacing their pizza.

Great. All in a day's work. Your team handles these just fine.

In fact, even better than a year ago. You can now take many more orders like these in a given few minutes. You can now have fewer humans working on the pizzas and more humans doing the other stuff: the wrangling of incoming customers.

But alas.

One day, a miscommunication happens. A misclick; a fudging of some kind. Half of a batch goes wrong.

A year ago, this would have meant 5 bad pizzas. Now it means 50. That's ten times as many customers who might say: "You know what, let's not go to this pizza joint anymore." And fixing this up is harder; you have fewer cooks, doing less of the cooking, around you, who can try to understand the issue and fix it.

All of this validates what you thought the problem was: it's the journey from order to pizza, not the oven producing the pizzas. A sufficiently well-specified pizza is practically just the pizza itself, so how do you specify it better? Specify it perfectly?

How do I get my fancy oven to help me with this?

II

Here's where everything starts to go wrong.

You can't hand the whole journey to the oven. Not yet. So your people get the scraps: the fiddly, marginal, exception-shaped work. Their jobs get harder and narrower at the same time.

And here's the trap. Because the oven owns the bulk of the work now, your people fall behind it. They lose their grip on the main system, i.e. the one running at the oven's pace. The judgment calls humans should own, the food critic or the half-batch substitution, are ones the humans are less and less able to make, because they no longer live in the system those calls come from.

It gets worse! You've pushed them into more "parallel" tasks: more customers, more edge cases, more all at once. Mistakes are prevented by deep focus and deep focus is the first thing parallelism kills. You've maximized the odds of error and stripped away the deep attention that would catch it.

That's the double bind. The more you give the oven, the less you can debug what it hands back, even when there's less to debug. And that, unreviewed output, is exactly what kills companies. Everyone feels productive, spinning on the wheel, while the thing quietly breaks, and customers nope out.

The people can't give the machines what they need, either. Starved of context, the oven can't check its own work or do it the way a person would, fluid and flexible.

That dual context problem — humans out of the loop, machines underfed — is what holds your 10x hostage, and also what stops anyone from fixing it. There is this hump, this pile of unfamiliar and paradigm-shifting work that only gets taller and less appealing the more you hand the oven.

Spend more and more on flour, wait for the profits, and all you get is a messy kitchen.

Here's the fix, in non-pizza terms. You have to make verification cheap before you make generation fast.

Fast generation is a gift but fast generation from an intern you re-onboard every morning, who insists on checking his own work, producing more than any human could ever review, is a catastrophe. That's where most of us are now.

"Cheap verification" means a lot of things at once. The essence is simple: contextualize. Turn things that were never text into text. Pull them out of Drive, Slack, Datadog, the database, JIRA, and pipe all of it into yet another model, and keep it current as the company shifts underneath you, and to the codebase add type checks, schemas, contracts (a level of rigor that was overkill before the oven showed up), and feed every bug and every operational hangnail back into the whole thing.

That's a whole second system, built and maintained forever, on top of everything already on fire. Do you have time for it? Probably not. You have to build it anyway if you use a fancy oven.

The maddening part is that humans never needed any of this. That's our whole value: we turn a vague order into a pizza without the customer nailing down every syllable. When the menu turns over, when an ingredient runs short, when the health code changes, we don't spin up a context system or a living document. We are the living document. A few of us reminding each other, when we occasionally forget these things, is literally all we need to stay on course and keep the customer happy.

This points at the real fix. It not just ("just") a context engineering system, but rather, hiring and training people again. No one wants to hear that either.

Fred Brooks knew all this in 1975. Old wisdom never sells like a new model, but he'd be shouting it today. The lever has always been bandwidth between minds. Communication, flow, a team that moves fluidly together, even if there's one Messi scoring most of the goals.

Some firms are making verification cheap, so generation can finally be fast for real. Some are protecting communication and flow even as the cognitive load climbs. They will stay afloat.

Past a point, and a point many companies have passed without feeling it acutely enough, more becomes a cancer. More tokens can sit in direct opposition to more brain cycles spent on your actual process: on the context your people translate, the mental load they carry in any given moment.

So ask: how much of your product have you encoded into something checkable? How many tangled paths have you straightened far enough to be sure you'll never blindside a customer?

The constraint was never whether AI showed up to help. Mostly, so far, AI has just gotten people fired or un-hired which leaves everyone still standing, more stressed and more alone. The consequential constraint is whether your team uses AI to work better together instead of churn out more.

Re-orient around that, not around code generation. Walk that tightrope and the results arrive.