The Principles of Decision Engineering

Execution is becoming free. These are the rules for building when the only scarce thing left is judgment.

Execution is going to zero. As the models improve, the cost and time of producing code, designs, and docs collapse toward nothing — so the thing that was scarce and expensive for fifty years is about to be neither. What stays scarce is judgment: knowing what to build, whether it's right, and what to do next. When the bottleneck moves from execution to decisions, building software becomes a different discipline. Call it decision engineering. (The first two pieces in this series made that case; this one is how it actually works.)

A discipline isn't a slogan — it needs principles you can build on. These eight all come from one key idea: stop optimizing execution, start optimizing decisions. Every practice we have — how we staff, how we tool, how we measure — was tuned to squeeze more execution out of scarce, expensive human hands. Agents make execution cheap. Keep optimizing it and you're polishing the thing that no longer costs you anything. Everything below is what happens when you take that seriously.

1. Put your best people on decisions, not execution.

The scarce resource is judgment, so spend it there. Your strongest people shouldn't be writing the code or the docs; they should be deciding what's worth building, judging what comes back, and setting direction — while agents do the producing. This feels wrong at first, because for decades the mark of a great engineer was that they shipped. The new mark is that they choose well. If your best people are still generating the content, you're spending your rarest resource on your cheapest problem.

2. Let agents assemble each decision and route it to the right person.

Once execution is instant, your decision rate is the bottleneck — the only thing between an idea and a shipped product is how fast the humans can decide. So the biggest lever you have is preparation. Stop making people hunt for context, chase down data, and reconstruct what an agent just did. Put agents on that work instead: have them gather the facts, lay out the options and the tradeoffs, and assemble a decision that's ready to make — then route it to the person whose judgment best fits that call, at the moment it's ripe. The scarce hour goes to deciding, not to getting ready to decide.

3. When building is cheap, build first and decide after.

For fifty years the order was fixed: decide, then build. You had to — building was expensive, and you couldn't afford to build the wrong thing. Cheap building reverses that. When a thing takes an afternoon, the fastest way to decide is often to build it and look; a real prototype beats a week of arguing about a hypothetical. So stop assuming the decision has to come first. For anything cheap to build and easy to undo — most things, now — build it, see it, then decide. For the one-way doors — the irreversible calls you can't take back — always decide first. Debating for a week what you could have built in an hour is the expensive mistake now, not the careful one.

4. Spend tokens like they cost less than people — because they do.

Every operator is trained to ration compute: it's a cost line, keep it down. Invert that. Set against the cost of a person — or the cost of a decision made too slowly — tokens are astonishingly cheap. If spending ten times the tokens buys a better answer, a faster loop, or a call made an hour sooner, that isn't waste; it's the best trade on the board. This is not "replace people with tokens." It's "stop rationing the cheapest resource you have as if it were the most expensive." The constraint was never compute. It was judgment. Spend the cheap thing freely to protect the scarce one.

5. Context is the only moat.

The models are a commodity. Your competitor rents the same ones you do, at the same price. So the model is never your advantage. What you know that they don't — your customers, your data, your history, the hard-won judgment of your people — is the only thing that doesn't commoditize. Much of decision engineering is the work of turning that private context into something your deciders and their agents can actually use. Ask it of any edge you think you have: could a competitor buy it this week? If yes, it isn't a moat. Your context is what's left.

6. Build the feedback loops.

When agents can iterate for almost nothing, optimization stops being a scarce, careful act and becomes something you run constantly — but only ever against a signal. So the work moves to building the loops: instrument the outcome, connect the result back to the change that caused it, and let agents grind against it.

The trap here is the sharpest in the whole discipline. Cheap optimization against the wrong signal doesn't drift toward the wrong thing slowly — it sprints there. Point a swarm of tireless optimizers at a bad metric and they'll maximize it brutally, at the expense of everything you actually care about. Goodhart's law, at agent speed. So the human job isn't the optimizing anymore. It's choosing what to optimize, and noticing when the number has started to lie.

7. Documentation is for agents. Explanation is for humans.

This is where teams get confused. The complete record of what was built and why — every decision, every dependency, every edge case — is written for agents now. Let it be dense, exhaustive, and machine-first; no human will read all of it, and that's fine. What humans need is the opposite: a short, honest explanation at the right altitude, telling them what they have to judge and why it matters. Two artifacts, two audiences. Conflate them and you get documents too shallow for the agents and too long for the people. (There's enough here for its own piece — and it'll get one.)

8. Trust but verify.

When you can't read the work — and increasingly you can't — trust has to rest on something other than having personally checked every line. That something is verification: proving the outcome holds by its results, its properties, its behavior under test, instead of by a human reading the source. The discipline is to engineer that proof on purpose — agents checking agents, adversarial review, checks that run on their own — so that a human's approval actually means something. An approval you can't back with verification isn't a decision. It's decision theater. (Also its own piece, later.)

These aren't a menu. You don't adopt the ones you like and skip the rest, because they hold each other up. Private context is a moat only if your decision rate is high enough to exploit it. Your feedback loops are worthless unless you can verify the signal is real. And none of it matters until you've pulled your best people off execution to do the deciding in the first place. Take one principle out and the rest sag.

Taken together, they're the operating system for building when execution is free. Get them right, and a few people can out-decide an organization ten times their size. Get them wrong — optimize the execution, ration the tokens, trust what you can't verify — and all the agents in the world just help you do the wrong thing faster.