you can build anything now. that's the new bottleneck.

For about a decade, the constraint on shipping software was the same one: implementation capacity. You had more ideas than you had hours to build them. The roadmap was a queue, and the queue was long because writing the code took time. Every prioritization meeting, every "we can't get to that this quarter," every founder who learned to code so they could ship without waiting on a contractor — all of it traced back to one bottleneck. Building was expensive, so building was where the friction lived.

That constraint has largely come off. AI agents now write a meaningful share of the implementation, and they do it fast enough that the cost of producing a working feature has fallen by an order of magnitude for the kind of work most small teams do. The thing that used to take a sprint takes an afternoon. And when the cost of building collapses, the interesting question is no longer "how do we build faster." It's "what happens to the bottleneck when the old one is gone."

The bottleneck doesn't disappear. It moves.

A constraint never really vanishes; it relocates to the next-tightest point in the system. When implementation stops being the limit, the limit moves to the front of the funnel — to the decisions that happen before a line of code gets written. Which thing to build. How to scope it. Whether it's worth building at all. For years those decisions were cheap relative to the build, so we under-invested in them. Get it roughly right, then spend the real effort in implementation. That math has flipped.

A builder I was talking with put it plainly: once you can build fast, the friction just moves to sales and market fit. You ship the thing in two days and then you're standing in front of the actual hard problem — does anyone want it, can you reach them, is this even the right thing. The "now what" problem. Building was never the hard part of building a product. It was just the part that was slow enough to feel like the work.

Building anything is now cheap. Building the right thing is the scarce skill — and it always was. We just couldn't see it under the cost of building at all.

The skill that got undervalued

The code-only worldview treated product and business judgment as something downstream of engineering — nice to have, but secondary to the ability to ship. When shipping was the constraint, that ranking made sense. The person who could turn an idea into working software was the rare one, and "what to build" felt like the easy half of the job.

Invert the cost structure and the value inverts with it. If anyone can build anything, then the differentiated skill is no longer the build. It's the taste to know which idea is worth a week and which one should die in a sentence. It's scoping a feature so it answers a real question instead of producing a plausible-looking artifact. It's the judgment to kill the wrong direction before it costs a sprint, not after. These are product and business skills, and they're exactly the muscles a decade of "just ship it" left underdeveloped in a lot of builders.

This is good news for people who own a product end to end — founders, very small teams, anyone working at the seam of code, product, and business. The skill that's now scarce is the one you were already exercising. The skill that just got commoditized is the one you used to have to hire for or grind through yourself.

The wrong answer is "build faster"

The instinct, when build cost drops, is to point all that new throughput at the same backlog and ship more. That's the trap. More throughput against an unexamined backlog just produces more wrong things, faster. You can now generate a quarter of features in a week — and if the scoping was loose, you've just manufactured a quarter of cleanup in a week. Speed multiplies whatever decision it's pointed at. Point it at a bad one and you get the bad outcome sooner and at scale.

The same dynamic shows up one level down, inside the build itself. Running several agents at once raises raw output but quietly moves the constraint onto the person holding the decisions in their head — a problem I get into in keeping context and decisions consistent across parallel AI agents. The pattern rhymes: cheaper production doesn't reduce the need for judgment, it concentrates it. The fewer hours you spend building, the more each upstream decision is worth, because it now governs a larger blast radius of cheap, fast output.

Tighten the loop before implementation

If the bottleneck moved to the front, that's where the work goes. Not faster building — sharper deciding. Concretely, that means treating the pre-build phase as the real work instead of a formality you rush through to get to the fun part:

• Sharper scoping. Write down what this is actually for and what question shipping it answers. If you can't state the outcome in a sentence, the agents will happily build the wrong version of it.
• A real design step. Decide the shape of the thing before you generate it. Cheap implementation makes it tempting to skip design and "see what comes out" — but a wrong shape produced quickly is still a wrong shape.
• Ruthless prioritization. When building is cheap, the cost of a feature is no longer the build — it's the maintenance, the surface area, the attention it pulls forever. Kill more ideas. The bar should go up as building gets easier, not down.

The loop you want is short and it lives upstream: decide, scope, design, then let the cheap implementation run against a target you actually chose. The cheap part is a force multiplier. It multiplies a decision. Make the decision first.

A structural take

This is the problem defract was built around — owning your product story from idea to shipped — so treat this as one approach rather than the answer. defract front-loads the lifecycle: it puts a story stage and a design stage, with a gate between them and implementation, ahead of any code generation. The point is that the decision of what to build is made deliberately, by you, before agents start producing. The cheap part still runs cheap; it just runs against a decision you actually made instead of one the tooling inferred from a one-line prompt.

That's the whole bet, and it's a modest one. When implementation was expensive, front-loading a design step felt like overhead. Now that implementation is cheap, the design step is most of where the leverage is — it's the part that decides whether all that fast, cheap output is pointed at something worth building. You can build anything now. The work is choosing, and then building the thing you chose.