More Code Doesn’t Guarantee More Value
Originally published in our newsletter.
In Extreme Programming Explained (right at the start of Chapter 5, “Cost of Change”), Kent Beck asked a deceptively simple question: “What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote?”
The question holds profound economic implications. If a change tomorrow costs essentially the same as a change today, there is no penalty for delaying a decision. You can start with the simplest thing that could possibly work, and only make further investments when signals from actual customers—not just opinions—show that it’s needed. Whenever additional complexity starts creeping in, you can invoke the principle of YAGNI: You Aren’t Going to Need It. You don’t have to commit to an approach; you can learn as you go.
That was back in 1999. Today, the promise of AI opens a new line of questions about software economics: What if the time and cost of writing code shrinks to almost nothing?
Yes, we’re in the middle of a hype cycle and actual outcomes have been mixed. You might be skeptical, and rightly so. Perhaps you’ve seen too many instances where AI took indefensible shortcuts, and obsequiously responded “You’re right to challenge this…” when called out on its mistakes.
But suspend disbelief for a moment. What if the promises were real? What then?
If 1K lines of code costs just pennies in tokens, experimentation becomes absurdly cheap. Can’t figure out how to crack that gnarly technical problem? Take 100 runs at it in parallel. Unsure what features real users will actually use? Build them all and collect telemetry. Historically struggled with a flood of demands on engineering’s incredibly limited capacity? Code isn’t a constraint anymore.
And then what? There’s the rub.
Just because experimentation becomes incredibly cheap doesn’t mean your customers will appreciate the thrash of a rapidly changing user experience. Just because you can collect near infinite telemetry data doesn’t mean you’ll be able to turn all that data into actionable insights. At a certain point, an overwhelming amount of data makes even legitimate signals feel like noise. For that matter, just because initial development costs pennies doesn’t mean that maintenance or operations are cheap. Keeping production systems up and running can be expensive.
Every solution—no matter how powerful or good—brings new problems. Software delivery remains a non-linear, socio-technical system. You poke the system and the system pokes back. More code doesn’t guarantee more value.
When we wrote Signals & Levers, we avoided talking about AI. It gets a short mention at the beginning of the book and again at the end of the book. But in between? No mention. Our editors and early readers asked us about that: Why would we ignore the thing that is radically transforming software development right now?
The answer is that we believe systems thinking is evergreen, and we didn’t want premature declarations about the nature of AI’s impact to limit the shelf life of our book. And we were right. When we started this book two years ago, AI was essentially a powerful auto-complete. Now you can unleash fleets of agents to build entire systems nearly unsupervised, and those systems actually work. (There are some big caveats about what has to be true in your system to see those kinds of results, but that’s a topic for another day.)
The thing that hasn’t changed, and won’t change, is that if you want to take advantage of the full power of AI, you have to understand your system. AI is poking the system. Systems thinking tools can enable you to see how to get the most out of it within your context, and anticipate the ways in which your system will poke back.