Here’s a question. If I gave two developers exactly the same AI, why would one produce elegant, maintainable software while the other creates an unmaintainable mess?
The answer probably isn’t the AI.
It’s the process.
Over the last few years we’ve watched artificial intelligence transform software development at a pace few of us could have imagined. What began as intelligent code completion has evolved into tools capable of designing APIs, generating applications, writing tests and even explaining unfamiliar codebases. Whether you’re using GitHub Copilot, ChatGPT, Claude, Amazon Q or one of the growing number of AI-powered development environments, it’s now entirely possible to build software simply by describing what you want in plain English.
It’s an extraordinary achievement, and one that would have sounded like science fiction only a few years ago.
But beneath all the excitement, I think there’s a more important question that isn’t being asked often enough. Have we actually solved the difficult part of software development, or have we simply become incredibly good at the easiest part?
We’ve Been Optimising the Wrong Problem
When people outside the software industry imagine what developers do all day, they usually picture someone sitting in front of a computer typing thousands of lines of code. It’s an understandable assumption because code is the most visible part of the job. Yet anyone who’s spent years delivering enterprise software knows that writing code is rarely where projects succeed or fail.
The real challenges begin much earlier. Understanding what the business actually needs is often harder than implementing it. Requirements are rarely complete, stakeholders frequently disagree with one another, and many projects begin before everyone shares the same understanding of the problem they’re trying to solve. Good architecture requires making decisions that may not reveal their consequences for months or even years. Testing requires thinking about scenarios nobody initially considered. Maintenance demands that today’s decisions remain understandable long after the original developers have moved on.
Compared to those challenges, typing the code is often the straightforward part.
This is where I think AI has fundamentally changed the economics of software engineering. It has dramatically reduced the cost of implementation, but it hasn’t reduced the complexity of understanding the problem. In fact, by making implementation almost effortless, AI may have increased the importance of everything that comes before it.
Faster Doesn’t Necessarily Mean Better
For decades we’ve searched for ways to make software development faster. We’ve moved from waterfall to agile, embraced continuous integration and deployment, adopted cloud-native architectures and automated almost every stage of the development pipeline. AI is simply the latest step in that journey.
The difficulty is that speed has become the metric we celebrate. We ask how quickly a feature was delivered, how many pull requests were completed or how many lines of code were generated. AI has introduced a new set of measurements. We compare prompts, tokens and code generation speed, but we’re still measuring exactly the same thing – output.
Very little attention is given to whether we’re producing the right output.
If AI allows a developer to generate twenty thousand lines of perfectly valid code before lunch, is that necessarily an achievement? Or have we simply made it possible to create technical debt at a speed that was previously unimaginable? That’s an uncomfortable question, but it’s one worth asking.
The quality of software has never been determined by how quickly it can be written. It’s determined by whether it continues to solve the right problem six months, two years or even ten years after it was first deployed.
The Rise of Prompt-Driven Development
Most AI-assisted development today follows a remarkably simple pattern.
There’s nothing inherently wrong with this approach. In fact, it’s incredibly effective for prototypes, proof of concepts, learning a new framework or automating repetitive development tasks. GitHub Copilot has become a natural part of many developers’ workflows precisely because it removes friction without forcing them to change how they work.
The problem is that software engineering has never really been about generating code. Good software starts with understanding. It starts with conversations, diagrams, whiteboards, sketches, arguments, trade-offs and questions that often don’t have obvious answers.
A prompt can describe what to build.
It rarely captures why you’re building it.
A Return to Software Engineering
Perhaps the most interesting change I’m seeing isn’t that AI is becoming better at writing software. It’s that some of the latest tools are encouraging us to slow down before we ask AI to generate anything at all.
Instead of following the now familiar workflow of idea, prompt and code, they introduce additional stages that many experienced software teams have always considered essential. Requirements are discussed before implementation begins. Technical designs are created before architecture becomes embedded in code. Large features are broken into manageable implementation tasks, and testing is considered from the outset rather than being bolted on at the end.
The workflow begins to look something like this:
At first glance this appears slower. In reality, it may prove significantly faster because mistakes made in a design document are inexpensive to correct. Mistakes discovered after thousands of lines of generated code have been committed are considerably more costly.
This philosophy sits at the heart of AWS’s new AI development environment, Kiro. Rather than encouraging developers to immediately generate code, it promotes what AWS describes as Specification-Driven Development, where requirements, technical design and implementation planning become first-class citizens alongside the code itself. Whether Kiro ultimately succeeds or not is almost secondary. The more interesting point is that it represents a shift in thinking about what AI should actually be helping developers to do.