Why The Software Development Process Must Change When Code Becomes Cheap

Ronni Holmvig Strøm · 2026-01-17

Most development frameworks assume code is expensive and humans are the bottleneck. We're entering a world where code is cheap and evaluation, governance, and clarity are the bottlenecks.

The Core Argument

Teams still sometimes spend half an hour debating whether a ticket is a "3" or a "5." The product manager makes a careful argument. The tech lead pushes back. Someone invokes a past sprint for precedent. Eventually they settle on "5" and move on, satisfied that rigor has been applied.

Meanwhile, somewhere else, a founder has already shipped a working prototype of roughly the same feature that morning. She described what she wanted, watched it appear, tested it, adjusted, and deployed. No points. No sizing ritual. Just: intent, generation, evaluation, ship.

Both approaches felt normal to the people doing them. That's the strange part. We're living through a phase change in how software gets made, and half the industry hasn't noticed yet because the old rituals still technically function.

Here's the thesis:

Most development frameworks assume code is expensive and humans are the bottleneck. We're entering a world where code is cheap and evaluation, governance, and clarity are the bottlenecks.

That single shift is what forces process to evolve.

Agile won't die dramatically. Its values (iterate, learn, adapt) become more relevant. But its ceremonies—story points, sprint planning, velocity tracking—were designed to manage human coding throughput. When that's no longer the constraint, the ceremonies start to feel like theater. Expensive, time-consuming theater that everyone performs because nobody wants to be the first to ask why.

Call it a migration of where the hard problems live.

---

What Actually Changes

Waterfall solved for: "Change is expensive, so lock requirements early." Agile solved for: "We can't predict the future, so learn in short cycles."