For most of the last two decades, the expensive part of software was the building. You hired engineers, you waited, you shipped late. The idea was cheap and the execution was dear, so the people who could execute captured most of the value.
That ratio is inverting. When a competent operator can stand up a working product in an afternoon, the labor of construction stops being the bottleneck. What remains scarce is everything that construction used to obscure: knowing what to build, for whom, in what order, and when to stop.
When the cost of building approaches zero, the cost of building the wrong thing approaches everything.
The bottleneck moves upstream
A bottleneck never disappears. It moves. Drop the cost of one stage and the constraint relocates to the next least-automated stage. For years that next stage was distribution. Now distribution is being automated too, and the constraint is climbing higher still — into the pre-verbal work of deciding.
Deciding what to build is not a prompt. It is an accumulated sense of which problems are real, which are loud but shallow, and which look small but compound. That sense is expensive to acquire and slow to transfer. It does not fall in price when GPUs do.
Judgment is leverage, not labor
The mistake is to treat judgment as a slower kind of labor — something that will also be automated on a delay. But judgment is not labor that happens to be done by a person. It is the selection function over everything labor could produce.
- Labor answers can we build this?
- Judgment answers should this exist, and is it the version worth our only life-hours?
When labor is abundant, the value of a good selection function goes up, not down. A team that can build ten things a week and choose the right one beats a team that can build a hundred and chooses at random.
What this means for operators
Three things get more valuable as building gets cheaper:
- Taste — the compressed prior that lets you reject ninety options without testing them.
- Sequencing — knowing which thing to build first so the second thing becomes possible.
- Restraint — the discipline to not ship the easy thing just because it is now trivially easy.
None of these are visible in a demo. All of them are visible in a roadmap six months later, in what got built and — more tellingly — in what didn’t.
What gets cheap, what stays scarce
A rough ledger of where the leverage is moving:
| Getting cheap | Staying scarce |
|---|---|
| Writing the code | Knowing what to build |
| Spinning up a prototype | Sequencing the roadmap |
| Generating ten options | Choosing the right one |
| Copying a competitor | Earning a reason to exist |
The pattern is consistent. Anything that can be specified precisely — a function signature, a CRUD endpoint, a landing page — trends toward free. Anything that needs judgment under ambiguity does not.1 For the company-building version of this argument, see The Thin Idea Is Dead.
The operators who win the next cycle will not be the ones who can build the most. Everyone can build now. They will be the ones whose judgment about what to build was good enough that the building was worth it.
Footnotes
-
Less a prediction than an observation about every prior automation wave — the bottleneck always relocates to the least specifiable step. ↩