Code Is Cheap. Good Software Isn't.

The Paradox

There’s an economic principle called Jevons Paradox. When a resource gets cheaper, we don’t use less of it. We use more. Demand rises to meet the abundance.

I felt this with gaming PCs. The moment I got my first higher-powered rig, I didn’t sit back satisfied. I wanted more powerful games. Better components. And as prices dropped and performance climbed, I bought more. The cheaper it got, the more I wanted.

Software is living through its own Jevons moment. AI made code generation nearly free. Features that used to take a team days get scaffolded in minutes. Code is abundant in a way it’s never been before. And just like Jevons predicted, the response isn’t contentment. It’s escalation. We don’t want less software now that it’s easier to produce. We want better software. More reliable software. Software that actually does what it says it does. The bar didn’t drop with the cost of production. It rose because of it.

The Flood

Open source maintainers are throttling contributions because PRs are flooding in faster than anyone can review them. App stores are more bloated than ever. AI wrappers multiply daily, so many that no one could catalog them, let alone evaluate them. Designers are shipping PRs. People who never called themselves developers are building and deploying software.

This isn’t a bad thing on its own. Simple apps with straightforward use cases can absolutely be built by someone with enthusiasm and a good AI tool. That’s a net positive.

But volume is not quality. The market is filling up with software that technically runs, checks the functional box, and doesn’t reliably get the user where they need to go. When everyone can produce code, everyone does. And the gap between “I shipped something” and “I built something that works” gets wider, not narrower.

Software is here. We have more of it than ever. What we don’t have more of is good software.

The Real Metric

If the flood is the problem, the feedback loop is the answer. And this is where cheap code actually becomes a weapon, if you point it in the right direction.

The real metric isn’t how fast you ship features. It’s how fast a user’s request becomes a meaningful update they can touch, react to, and tell you what they think about. That cycle, feedback to feature to feedback, is the competitive advantage now.

Before AI-assisted development, showing a user working software took two weeks minimum. Two weeks of building, reviewing, deploying, and hoping you interpreted the request right. Two weeks where the user is waiting, losing interest, finding alternatives. That waiting period isn’t neutral. It’s churn.

Today that loop can close in a day or two. A user says “I need this to work differently” and they see a working response before their frustration sets in. That changes everything. You’re not guessing what the user wants across a two-week gap anymore. You’re iterating with them in near real-time.

This ties back to Jevons. Users want more from their software because they can see how fast things move now. But teams that compress the feedback loop and let user input shape the product at speed aren’t just building faster. They’re building better. Quality and speed stop being tradeoffs when the user is telling you what good looks like every 48 hours.

Why Cheap Code Makes This Harder

Picture an airplane off course by two degrees. At low speed, the drift is manageable. You notice it, correct it, land close to where you intended. But the faster that airplane moves, the farther it goes from its destination before anyone realizes something is wrong. Speed amplifies the error.

Cheap code is the faster airplane. Teams are shipping at a pace that was unthinkable two years ago and that velocity feels like progress. But if the direction is even slightly off, if the feature doesn’t quite match what the user needs, if the architecture doesn’t account for what comes next, if the PR gets merged because it was easy to generate and not because it was right, that misalignment compounds with every commit.

This is where ignoring the feedback loop becomes critical failure. Going three sprints deep into feature development without user input isn’t a missed opportunity. It’s flying at full speed without checking your heading. Every day you build without closing that loop, the distance between what you’re building and what the user actually needs grows. And the faster you produce code, the faster that gap widens.

Speed without alignment creates drift. Drift at high velocity is expensive to correct. By the time you realize the product wandered from what users need, you’ve built weeks of work on a flawed foundation. The tools move so fast now that human judgment can’t keep up unless you deliberately make room for it.

What Winning Looks Like

Sprints aren’t dead. But what happens inside them needs to change.

At the two-week level, winning teams front-load alignment. Before anyone writes a prompt or opens an editor, they gather as much user feedback as possible and get concrete on what the next iteration needs to accomplish. Not vague priorities. Concrete alignment. Then they take off for the week and build with confidence because the direction was validated before the work started. And they build more feedback checkpoints into the sprint itself, not just at the boundaries.

At the daily level, the shift is even more counterintuitive. The work that matters most isn’t producing code. It’s planning deeply before anything gets generated and reviewing thoroughly after it does. Let agents work for longer stretches. Review in blocks instead of small iteration cycles. Reduce errors at every level by strengthening the two things that bookend generation: the planning and the review.

Think of it like archery. AI is the release of the arrow. The shot is the fastest part of the entire process. Drawing the bow takes a fraction of a second. But the aiming, reading the wind, adjusting your stance, choosing the moment, that’s where the skill lives. And after the arrow lands, you walk to the target, collect what you’ve learned, and adjust for the next shot. If the aim is off, the speed of the arrow doesn’t matter. If you never collect feedback from where it landed, you don’t improve for the next round.

Software development works the same way now. The code generation is the release. Fast, cheap, almost trivial. The planning before and the review after are where quality lives. Teams that spend their energy aiming and collecting will outbuild teams that just keep firing.

Final Thoughts

Jevons was right. Make something cheap and people don’t want less of it. They want more. Code is the cheapest it’s ever been, and now everyone wants better software. Not more software. Better.

The bar didn’t drop. It rose. And it’s going to keep rising.

The teams that figure this out won’t be the ones generating the most code. They’ll be the ones who aim before they fire. Who collect after the arrow lands. Who close the feedback loop so tight that the user is shaping the product alongside them.

Go slow to go fast. It’s always been true. It just hits different when fast is the default.

- Iverson