Point of view

Product is the bottleneck now

THEN engineering a trickle ships NOW decisions ships as fast as you decide
the bottleneck moved up the stack

For decades the constraint on software was engineering capacity. That constraint is dissolving — and when it goes, the scarce resource becomes deciding what to build, and deciding well.

The old bottleneck

Engineering was the throttle. There were always more ideas than people to build them, so product management became the art of rationing: cut scope to fit the team, sequence a roadmap that was really a capacity plan in disguise. Every backlog was a queue in front of a narrow neck, and the defining question — "can we afford to build this?" — usually answered itself: no.

What changed

AI collapses the cost of building. One person can now direct a full R&D operation: parallel work, specialist agents, output verified before it lands. The wall between an idea and a working version is much lower, and still dropping. Capacity is no longer the scarce thing.

When you can build almost anything quickly, the quality of your decisions becomes the whole game.

The new bottleneck

So the constraint moves up the stack — to product. What should exist? In what order? Which trade-offs are we willing to live with? These were always the important questions; they were just hidden behind the louder one of whether we could build the thing at all. Now they're exposed. Decision-making is unbound by capacity — which means it's also unprotected by it.

That cuts both ways. The upside is enormous leverage: a good decision becomes working software almost immediately. The risk is symmetrical: a bad one does too, at the same speed. The job shifts from rationing to driving — and driving well.

What that asks of the tools

If decisions are the bottleneck, a tool for this era has to treat them as first-class. It has to make them legible — you can see what was decided and why. It has to remember them, so the reasoning doesn't evaporate between sessions. And it has to make them reversible, so you can decide fast without betting the project on every call.

That's the bet underneath Doric: every decision captured, the map and the memory kept true, rolling back free. Not because building is hard anymore — but because deciding is now the part that matters, and the part worth protecting.

You stay in command — not by reading code, but by owning the decisions, while a complete R&D team proves every feature it claims.


← Back to all engineering notes

Decide fast. Build the real thing.

Start building