In systems design, there is a fundamental dividing line between two types of complexity: biological evolution and deliberate engineering.
In biology, one gene can affect several traits, and one trait can be influenced by many genes. These connections overlap, so changing one part of an organism can affect others. Biological systems are tightly connected and have emerged over a long history.
Software engineering tries to avoid that kind of tangle. Encapsulation, clear interfaces, and domain models help separate responsibilities and make dependencies visible. When one part changes, the goal is to keep the effects contained.
But as AI generates more code, we face a risk: without clear architectural guidance, a software system can grow through a series of local fixes and additions. Over time, those changes may make it harder to understand and maintain—more like an ecosystem that has evolved than a system designed around clear boundaries.
1. AI Does Not Feel the Cost of Complexity
Human developers often create clear abstractions for a practical reason: they want the system to be easier to work with later.
Imagine a developer facing a 3,000-line class where many functions change shared data. It can be difficult to understand what a change will affect. That difficulty creates pressure to reorganize the code, separate responsibilities, and make the rules clearer. A developer wants to make the next change easier—not just for a teammate, but for their future self.
AI does not experience that frustration. It can review a large amount of code and suggest a change that solves the request in front of it. But it does not feel the future cost of maintaining the result. Without architectural constraints, it may choose a locally useful fix instead of a change that improves the design as a whole.
That can lead to patterns such as:
- Changing shared state directly: Updating data in a place that is easy to reach, rather than using a clear interface or contract.
- Creating near-duplicate helpers: Adding another function that does almost the same job instead of consolidating the underlying logic.
- Adding fix after fix: Putting in another condition to handle a bug without addressing the design issue that caused it.
Any one of these choices may seem reasonable in isolation. The risk comes when they accumulate. The system can become more connected, less consistent, and harder to change safely. We can think of this as code entropy: an informal way to describe complexity building up as changes are added without enough attention to the overall design.
2. Evolution Is Not the Same as Architecture
Biological organisms were not designed from a clean blueprint. They are the result of a long history of change.
When a species adapts to new conditions, evolution works with what already exists. It does not stop and redesign the organism from scratch. New functions develop from existing structures, and older structures may remain even when they are no longer useful. The result can be a system with many dependencies and layers of history.
AI-generated code can drift in a similar direction when an AI is repeatedly asked to add features or fix bugs without clear architectural rules. Each change responds to the immediate request. It may add another path through the code rather than reshape the system around a consistent design.
Over time, these small changes can pull the system away from a clear model of the business. Components may depend on details they should not need to know. A change in one place may then have unexpected effects somewhere else.
This outcome is not inevitable, and it is not unique to AI. Human teams can also accumulate patches and dependencies. But AI can produce changes quickly, which makes it especially important to give the work clear boundaries and review how each change fits the design.
3. Why Model-Driven Design Matters More in the AI Era
Some critics assumed that the rise of AI code generators would render formal modeling and Model-Driven Design (MDD) obsolete. If AI can produce thousands of lines of code quickly, why spend time defining models, rules, and boundaries first?
The argument in this article points in the opposite direction. When code becomes faster and cheaper to produce, a clear design becomes more valuable. The key question is not only whether AI can generate code, but whether the code follows the structure and rules the system needs.
Model-Driven Design (MDD) can help by making important parts of the system explicit: its domain concepts, relationships, and rules. In an approach such as MDriven, the model can guide how the system is built and changed. It gives the team a shared reference point beyond the latest prompt or patch.
- Clear separation of concerns: The model defines important concepts and how they relate. When the development workflow enforces those definitions, they help keep responsibilities and dependencies clear.
- Boundaries for generated code: Rather than allowing every change to spread across the application, teams can direct AI to work within defined parts of the system, such as specific handlers or business rules.
- More controlled changes: When requirements change, updating the model can provide a clear starting point for updating the implementation. Where the tooling supports generation, parts of the surrounding infrastructure can be regenerated consistently instead of being changed through unrelated patches.
A model is not a magic shield. It only helps if the team keeps it current and connects it to implementation, validation, and review. But when used as part of the development process, it can make the intended design easier to see and harder to lose as the code changes.
Conclusion: Keep Software Architecture Deliberate
If software development relies only on unconstrained prompt-to-code generation, we risk producing systems that work today but become difficult to understand, audit, or change tomorrow. As features and fixes accumulate, a change in one place may trigger effects elsewhere—much like the interdependence found in biological systems.
The answer is not to stop using AI to generate code. It is to pair that speed with deliberate architecture. In the AI era, Model-Driven Design can help make the system’s structure and rules explicit, so generated code has clearer boundaries to follow.
The role of MDD is not simply to write code for us. It is to help keep software engineering intentional: with systems people can understand, reason about, and change with confidence.
