AI moved the constraint, it did not remove it
When implementation gets cheaper, the binding constraints move toward judgment, context, distribution, trust, and organizational adoption. Teams that only get faster at producing will produce more of the wrong thing.
Cheaper implementation does not remove the constraint. It relocates it.
Text equivalent. Work whose cost is collapsing: boilerplate, first drafts, glue code, migrations, prototypes. Constraints that do not move with implementation cost: judgment, context, distribution, trust, adoption. The bottleneck shifts from the first list to the second, which is why output volume is a poor measure of progress.
The honest version of what changed: producing a plausible artefact — code, a document, a design, an analysis — got dramatically cheaper. That is a real change and I would not undersell it. My own output profile has shifted; I build things now that I would previously have skipped on cost grounds, and this site’s tooling is partly evidence of that.
The mistake is inferring that the constraint disappeared. It moved. And the direction it moved is uncomfortable, because the new constraints are harder to buy.
What actually got cheaper
Specific and observable, from my own work:
- Boilerplate and scaffolding, which used to consume the first day of anything new.
- First drafts of almost everything, including drafts that turn out to be wrong but are useful for finding out.
- Glue code — adapters, format conversions, one-off scripts that were never worth writing before.
- Mechanical migrations where the rules are known and the volume was the obstacle.
- Prototypes convincing enough to test an idea with real users instead of describing it.
- Working in unfamiliar languages. The seven MCP servers I maintain are mostly Rust; I would have chosen differently three years ago.
The common thread: work where the target was already known and the cost was mechanical.
What did not get cheaper
Definition
The new scarcity is the set of constraints whose cost does not fall when implementation cost falls: judgment about what is worth building, context that only exists inside a specific business, distribution to the people who need the thing, trust sufficient for adoption, and the organizational change required to actually use it.
Judgment. Deciding what deserves to exist. This got harder, not easier, because the option space expanded. When building ten things costs what one used to, the discipline of building three and killing seven becomes the whole job — and nothing about the tooling helps you choose.
Context. The specific, unwritten knowledge of a business: why a customer segment behaves oddly, which constraint is regulatory versus habitual, why last year’s obvious solution failed. Models are strong on general patterns and blank on your particulars. This asymmetry is now the main source of engineering leverage, because everything general is commoditised.
Distribution. Reaching the people who need the thing. If anything this got worse: cheaper production means more supply competing for the same attention, so the average new thing is now less likely to be found, not more.
Trust. For a user to hand over a decision, they need confidence in reversibility and correctness. Trust accrues slowly and breaks fast, and it is the actual gate on most agent-shaped products right now.
Adoption. The gap between a capability existing and a workflow changing. This is the largest and least discussed constraint in the companies I see, and it is organizational, not technical.
What this changes by role
For product managers. Less time producing specs and documents, more time on problem selection and evidence. The differentiating skill is subtraction: killing work that is now cheap enough to be tempting. A PM whose main output was documentation is in a much weaker position than one whose main output was decisions — and the difference is now visible where it used to be hidden by shared workload.
For developers. Less typing, more reviewing, and much more judgment about structure. Reading and evaluating code you did not write becomes the core skill, which is uncomfortable because it was previously the least-rewarded part of the job. Meanwhile the value of genuinely understanding a system — not generating plausible additions to it — goes up, because someone must be able to tell correct from convincing.
For CTOs. Two new obligations. First, deciding where generated code is acceptable and where it is not, and defending that line: I hold a much stricter bar on anything touching money movement, provisioning, or customer identity than on internal tooling, because the failure cost is asymmetric. Second, protecting the organization from its own new throughput. A team that can produce three times as much can also produce three times the surface area to maintain, and nobody notices until the maintenance arrives.
For teams. The dangerous shift is that volume becomes an easy proxy for progress precisely when it is least informative. If learning speed does not improve alongside output, the extra output is inventory, not progress.
Reversible and irreversible decisions diverge
This is the sharpest practical consequence.
Cheap implementation is a genuine gift for reversible decisions. You can now test three approaches instead of arguing about one, and let evidence settle it. That is a real upgrade in how teams should work, and most teams are underusing it.
It is a genuine hazard for irreversible decisions. Data models, external API contracts, identity and permission structures, anything a partner integrates against. These cost the same to get wrong as before — arguably more, because you can now generate a great deal of code on top of a bad foundation before anyone notices the foundation.
So the allocation rule I use: spend the newly cheap capacity on reversible experiments, and spend the time saved on slowing down irreversible decisions. The failure mode I watch for is the opposite — using new speed to make foundational decisions faster.
The risk of producing more without learning more
The failure mode is not “AI writes bad code.” It is a team that ships more, learns nothing new, and mistakes the first fact for the second.
Symptoms worth watching, in rough order of how early they appear: nobody can articulate what the last three shipped things taught anyone; the backlog grows faster than it did, because adding is now trivial; review has become a formality because reviewers cannot keep pace with generation; maintenance load rises with no corresponding rise in customer outcomes; and decisions get made faster with no more evidence behind them than before.
The counter-practice is boring and effective: keep the evidence threshold fixed while production cost falls. If a bet needed a defined result to be judged successful, it still does. Cheaper implementation is permission to run more bets, not permission to stop judging them.
Where I might be wrong
Observed The productivity shift in mechanical work, and the adoption gap in organizations, from running a technical organization through this transition and building tooling on top of it.
Inferred That judgment and context stay scarce. This is a bet on the current shape of the technology, and it is the claim most likely to age badly if models get substantially better at acquiring business-specific context.
Opinion That most organizations are currently limited by workflow and trust rather than capability, and will stay there longer than vendors expect.
The strongest counterargument is that the boundary between “general” and “specific” keeps moving, and my confidence that context stays scarce may just be a statement about today’s tools. If systems become reliably good at acquiring and applying business-specific context, the judgment premium narrows, and this argument needs revising rather than defending. I would rather update it in public than pretend I called it.