In Code Complete Steve McConnell argues that software development is a wicked problem, one you cannot fully understand before attempting to solve it. I think most developers who have created software for a living would agree. That is, until agents.
This fundamental truth lies at the heart of the most important developments in our discipline since the late ’90s: iterative development, the agile movement, the rise of pragmatism over design by committee, the recognition of craftsmanship as a central virtue, domain-driven design and the importance of building systems humans can reason about, and the growing appreciation of skilled programmers over analysts and architectural astronauts.
Years ago, I was a fresh software engineering graduate doing research on model-driven software development. I attacked the problem naively and enthusiastically, but I didn't get anywhere. At some point, I came across this article by Martin Fowler, and it fundamentally changed how I thought about software development. It helped me understand why I was running into a dead end.
Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?
I had explored this question thoroughly, and by then the answer was crystal clear in my mind: nope.
Building software was not predictable because the problem was fundamentally wicked. And that gave rise to a set of hard-earned principles that any sensible professional software developer would recognize:
- Scope control is essential. Every feature has a cost, and every additional moving part compounds it.
- Keep feedback loops short so you have plenty of opportunity to steer as you learn.
- Restate problems to make solutions cheaper to build. Often, the smartest engineering decision is to change the question.
- Favor designs that humans can reason about, so that they can evolve them.
- Defer decisions until you know enough to make them.
- Embrace iteration over prediction.
- Value craftsmanship. Good abstractions, clear boundaries, and well-structured code make future changes affordable.
- Treat every line of code as a liability worth scrutinizing. Every line carries a cost to understand, maintain, and evolve.
Fast forward to 2025. Agents arrive, and the fundamental economics of turning ideas into working software change. AI and agents push the entire industry into a new regime. The cost of building software collapses, while the speed at which we can build it skyrockets. And all of this happens overnight.
If you've been using agents lately, take another look at the list I just posted. How much of it still applies?
To me, agents brought a resounding YES to Fowler's fundamental question. Software development has become, or will soon become, predictable. And this changes the discipline upside down.
I believe product development will remain fundamentally iterative. Figuring out what to build, what people want, and what actually works hasn't suddenly become predictable. But software development was such a central part of that process, and its economics have changed so dramatically, that it's hard to imagine the entire discipline not being turned upside down as well.
If I just consider what building software is about, I find myself in the shoes of an experienced professional who is suddenly back at the starting line. A significant chunk of what I considered my discipline no longer applies. Many of the books I studied thoroughly to develop my skills are no longer relevant. And when I look around, I get the sense that everyone else is in the same boat.
The discipline we knew is gone. It will take years of experimentation, mistakes, overcorrections, and more mistakes to set a new foundation. And we'll need pioneers who can make sense of this new reality, challenge prevailing assumptions, and chart new paths forward, just as Kent Beck did for software engineering and DHH for web application development.
Acceptance is the first step. Next is figuring out how to rebuild what we do. To me, that is an exciting prospect.