The Next Software Crisis Won't Be About Writing Code

In this article, I propose to look back on the last thirty years of software engineering evolution. The capacity of generative AI and LLMs has reached a mind-blowing stage, transforming daily developer life in ways that are here to stay. Behind this new incredible productivity power (making code production cheaper than ever) how is it reshaping our engineering craft? How do we project ourselves into a world where we no longer write code ourselves? Let's look back through our history to understand the changes, the software development crises, and anticipate the one that is coming.

Twenty years ago, starting my career as a developer in Toulouse, I was already being told that code was on its way out. UML and Model Driven Architecture would change everything: model your systems, and the code generates itself. At Paul Sabatier University, I studied under Claude Aubry, a pioneer of the agile movement in France, and crossed paths with Pascal Roques, one of the country's leading UML experts. Two complementary visions of the same quest: taming the complexity of software. One through a new way of working, the other through modeling discipline.

Twenty years later, we're still coding. And I'm hearing the exact same promise, but this time with artificial intelligence. French philosopher Éric Sadin, one of Europe's sharpest critics of technology's impact on society, in his recent essay "Le Désert de nous-mêmes" (2025), criticises the "cognitive dispossession" brought about by AI. Reading him brought it all back. Thirty years of crises and returns to fundamentals. And this question: if we no longer produce code, what is the essential value of our craft? What about the people and values behind it?

The tools have changed, and the gains are real. But the software industry has a deeply rooted habit: it moves forward through crises. Not spectacular ones, but slow drifts where we stop delivering the right value, where things become meaningless. And every time, it takes a collective wake-up to bring us back to what truly matters.

I'm convinced we're on the edge of a new cycle. And this time, the threat doesn't come from too much process or bureaucracy. It comes from too much ease.

A History of Returns to Fundamentals

To understand what we have ahead, we need to look at where we've been. The history of software engineering is defined by moments where the industry lost sight of what it was doing. Then found its way back.

We Had Forgotten the « Why » 
In the 1990s, software development was dominated by approaches inherited from industrial engineering. V-model, waterfall, specifications frozen months before the first line of code. The results spoke for themselves. In 1994, the Standish Group's CHAOS Report revealed that 84% of IT projects are failing: that only 16% of software projects were delivered on time, on budget, and within scope. The rest? Massive delays, blown budgets, products delivered that no longer matched any real need.
The problem wasn't technical. The problem was that we'd forgotten why we build software: to serve users whose needs change.
During that same decade, several engineers were independently developing radically different approaches. Kent Beck was formalizing Extreme Programming (XP), perhaps the most audacious of them all. XP didn't just propose an alternative process. It challenged the industry's fundamental assumptions. Where consensus said "plan more to risk less," XP answered: short iterations, continuous feedback, systematic pair programming, and above all … writing tests before code. Test-Driven Development, born with the rise of XP, inverted the very logic of development: start by expressing intent, then implement just enough to satisfy it. 

Meanwhile, Ken Schwaber and Jeff Sutherland were shaping Scrum, others were exploring Lean Software Development inspired by Toyota. In February 2001, a group of people gathered at a ski lodge in Snowbird (US, Utah). Among them: Kent Beck, Martin Fowler, Robert C. Martin, Ward Cunningham. They produced the Agile Manifesto. Four values, twelve principles that fit on a single page.Those four values were framed as trade-offs:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

The power of the manifesto lies in that nuance. It doesn't say "no documentation" or "no plan." It says: when you have to choose, choose the human, the concrete, the relationship, and adaptation. Not a denial or rejection, more a clear hierarchy of what matters. Agile was never intended to be a methodology. It was a reminder: stay connected to reality.

We Had Forgotten the «  How » 
Agile was massively adopted. But as often happens, the industry absorbed the form more than the substance. Companies embraced Scrum, sprints, daily standups, and sticky notes on walls. The full ceremonials. Except the code itself wasn't getting better. We were shipping more often, sure … but mediocre code more often.
And finally, we ended up forgetting about XP's technical practices. The ones that hurt the most and demand the most discipline were sacrificed on the altar of adoption. Pair programming? "Too expensive, two developers on one workstation." TDD? "Too slow, we have features to deliver." Continuous refactoring? « That’s fine, we'll do that later." Companies wanted the agility of the process without the technical rigor that made it possible.

In 2009, the Software Craftsmanship manifesto emerged in response. Championed by Robert C. Martin, Sandro Mancuso, and others, it added a complementary demand: not just working software, but well-crafted software. Alongside it, Clean Code (Robert C. Martin, 2008) became an essential reference. Built on the foundational idea that reading code matters more than writing it. That code is an artifact read dozens of times for every time it's modified. That clarity isn't a luxury; it's an (economic) necessity.
Craftsmanship brought back to center stage what XP had established from the start: TDD, refactoring, and pair programming aren't optional practices. They're fundamental disciplines. And abandoning them in the name of velocity is sawing off the branch you're sitting on.

We Had Forgotten the « What »

Then another realization set in: you could write clean code, ship regularly, be agile in process … and still build incoherent systems. Monoliths where everything depended on everything. Architectures where adding a simple business feature meant touching fifteen unrelated modules.
This is the ground on which Eric Evans' Domain-Driven Design, Robert C. Martin's Clean Architecture, and Alistair Cockburn's Hexagonal Architecture took root. Their shared message: the fundamental complexity of software isn't technical, it's in the business domain. If you don't model that domain with intention (bounded contexts, ubiquitous language, clear separation between core business and infrastructure) you're not building a system. You're stacking features.

Loss of Meaning

Step back from these thirty years, and a pattern emerges. In every era,  the industry confused producing with building. Producing code, producing deliverables, producing features. And every time, a movement had to remind us that building software is, before all, an act of understanding, modeling, and care.
Agile restored the sense of purpose. XP and Craftsmanship restored the sense of technical discipline. DDD and Clean Architecture restored the sense of structure.

And now?

AI Enters the Scene
Let's be clear: generative AI is a real advancement for our daily work as developers. I see it in my own work on Koin open-source framework and at Kotzilla: intelligent completion, boilerplate generation, rapid solution exploration, and debugging assistance. The productivity gains on many tasks are undeniable.

But here's the trap: when producing code becomes nearly free,  the temptation is immense to produce more rather than build better.
An LLM can generate 1000 lines of code in seconds. But if your bounded context is poorly defined, if your responsibilities are blurred, if the business value you're solving for is unclear, you simply get bad code faster. It's technical debt at the speed of light.

It's the same promise as MDA twenty years ago, only more convincing. And that's precisely what makes it more dangerous. Model Driven Architecture failed visibly (UML generators produced code so rigid and verbose that everyone could see the problem). AI, on the other hand, produces code that looks correct. It compiles, it passes nominal cases, it resembles what a developer would have written. « Good enough » has become invisible. And that's far harder to fight than obvious failure.

The Coming Crisis Isn't Technical

The next software crisis won't be "AI writes buggy code." Models will keep improving; generated code will become increasingly correct syntactically and functionally.
The real problem lies elsewhere.  Code generated without design intent doesn't form a system. It forms a heap. Without clear architecture, each generation goes in its own direction. Without a shared domain model, AI invents its own abstractions with every prompt. Without clean code principles, readability collapses. And remember, code is read far more often than it's written.

Testability, maintainability, and overall coherence. Everything that makes software hold up over time aren't properties AI adds spontaneously. It optimizes locally, function by function, prompt by prompt.  The global vision is ours!

And here's where it becomes critical: if an entire generation of developers learns to code with AI without first internalizing the fundamentals of design, architecture, and craft. Who will be able to detect that the system is drifting?

The Pillars of the Next Manifesto

History repeats itself. Every crisis in the software industry has produced its manifesto, its return to fundamentals. If the pattern holds, the next one will be about meaning. A reminder that being a software developer was never just about writing code. It's an act of human intelligence, and AI is a tool in service of that intelligence. Not a substitute.

This manifesto doesn't need to be invented. Its pillars are already here, forged by thirty years of hard-won lessons: TDD as a design and specification discipline (where a well-written test becomes the best prompt you can give a machine). Pair programming as a permanent posture (where the developer navigates and the AI executes). DDD as the central creative act (because AI doesn't understand your business domain, you do). Clean Architecture as a guardrail for coherent code generation. Clean Code as a reading discipline, because reviewing code you didn't write is now everyone's job.
The tools are catching up with this mindset. AI "plan" modes, iterative prompting, specification-driven workflows. These are the early signs of a development process built around thinking first, generating second, and refining until the code truly reflects the intent. The fundamentals aren't obstacles to AI adoption. They're what make it work.

It's this conviction, that architecture remains fundamental to software and perhaps more than ever, that drives what we build at Kotzilla. After years of developing Koin within the Kotlin ecosystem, I've seen the same pattern: the developers who succeed aren't the ones who write the most code, they're the ones who make the best structural decisions. That's why we're building tools to help engineers drive their architecture and make the right decisions at scale. Especially now, when AI makes it easier than ever to generate code, but not to understand it.

Éric Sadin warns of a « cognitive dispossession », a gradual surrender of our intellectual and creative faculties to AI. His critique is radical, but it touches something essential: if we delegate not only the writing of code but also the thinking that precedes it (understanding the problem, modeling the domain, making architectural trade-offs), then we are walking toward a « desert of meaning ». The loss of meaning he describes is not inevitable. It's what happens when we forget to put the right values at the center.

Kent Beck wrote that courage is a fundamental value of software development. Today, we may need a new kind: the courage to not generate code. To design and model before prompting. To say "we don't understand the problem well enough yet" in a world that pushes for answers in few seconds.
Twenty years ago, I was told I'd never code again. I've spent two decades learning that the value was never in the lines of code, but in the understanding that precedes them. AI doesn't change that truth. It makes it more urgent than ever.

The next software crisis won't be about writing code. It will be about what we build together, and why. The fundamentals are already here. Now we need to put them to work in the age of AI.