Domain-Driven Design and AI: the problem is not the code, but the meaning

Why Meaning Becomes the Real Problem in the Era of AI-Generated Code

In recent years, we have witnessed a radical transformation in the way software is produced. With the arrival of LLMs, writing code has never been faster or more accessible. Functions, APIs, tests, refactoring operations and even entire services can be generated in a matter of seconds, turning tasks that once required hours of work into almost instantaneous operations.

It is easy to get carried away by this acceleration and conclude that the main challenge of software development has finally been solved. If we can produce code at an ever-increasing speed, it may seem natural to imagine a future in which software design gradually loses importance, replaced by the ability to orchestrate increasingly sophisticated generative tools.

However, a closer look at what happens in real-world projects reveals a very different problem.

The primary risk is not producing incorrect code. It is producing semantically incorrect systems.

This distinction is crucial.

Many discussions about the use of AI in software development focus on so-called hallucinations: non-existent APIs, syntax errors, vulnerabilities or inefficient implementations. These are real issues, of course, but they do not represent the most critical aspect of AI-generated code.

An LLM can produce code that compiles perfectly, aligns with widely adopted architectural patterns and is even elegant from an implementation perspective, while still modeling the business domain incorrectly. Not because it “doesn’t work,” but because it lacks a genuine understanding of the concepts it is manipulating.

Language models do not understand the domain. They statistically complete incomplete semantic spaces.

When human language is ambiguous, AI tends to fill in the gaps using probabilistic correlations. This is precisely where the problem becomes amplified: the speed of automated generation dramatically increases the speed at which we can produce implementations that are plausible, yet semantically incorrect.

The Real Innovation Is Not Coding Automation

In reality, the idea of reducing the cost of software production is far from new.

The history of software engineering has always been a history of abstraction. High-level programming languages, frameworks, code generators, CASE tools, model-driven development and low-code platforms: for decades, we have built tools with the goal of progressively moving away from manual code writing.

In this sense, LLMs do not represent a complete break from the past. Rather, they represent an extreme acceleration of a direction that already existed.

The real innovation introduced by generative AI is therefore not coding automation itself, but the speed at which we can obtain plausible implementations.

And it is precisely this shift that moves the center of the problem.

If generating code becomes extremely inexpensive, then value can no longer be concentrated solely in the production of implementations. The primary risk progressively shifts toward the meaning of the system we are building.

The ambiguity inherent in human language does not disappear. It is simply amplified by the speed of automated generation.

And this is where many architectural practices, long considered merely modeling disciplines or organizational tools, suddenly become central once again.

Domain-Driven Design as a Semantic System

For a long time, Domain-Driven Design has primarily been described as an architectural modeling methodology. Aggregates, Entities, Repositories, Domain Events and Value Objects have often been interpreted as technical patterns or implementation conventions.

In the era of AI-assisted development, however, this interpretation risks becoming reductive.

The real value of DDD is not the structure of the code it produces, but its ability to make domain knowledge explicit.

Ubiquitous Language and Bounded Contexts do not simply help “organize software better.” They establish clear semantic boundaries within which terms, behaviors and rules maintain a shared and consistent understanding.

A well-named command does not merely represent a technical action: it makes a domain intention explicit. A Domain Event is not simply a message exchanged between components, but the representation of something that has happened in the business. A Value Object is not just an elegant data structure, but a way to preserve semantic consistency around a concept.

In this sense, DDD reduces the space for interpretation.

And that is exactly what we need when part of software production is delegated to statistical systems.

Reducing Context Means Reducing Entropy

One of the main limitations of LLMs concerns context management. The broader, more ambiguous and more semantically inconsistent the context becomes, the higher the probability of obtaining incorrect or inconsistent implementations.

For this reason, the concept of a Bounded Context is even more important today than it was in the past.

A Bounded Context is not simply an architectural or organizational partition. It is a semantic boundary. Within that boundary, language retains precise meanings, rules remain consistent and responsibilities are clearly defined.

This separation does more than improve the quality of software design. It directly improves the quality of AI-assisted code generation.

Reducing context means reducing semantic entropy. It means decreasing the amount of interpretation left to the language model and increasing the likelihood that the generated code truly reflects the domain we are modeling.

The Role of Ubiquitous Language

If language is the entry point through which AI accesses the domain, then the quality of that language becomes a critical design factor.

An ambiguous term used in requirements, documentation or prompts can generate different and inconsistent implementations.

Conversely, a shared language drastically reduces the space for interpretation and allows models to operate within clearer semantic boundaries.

For further insights, I invite you to read my article Ubiquitous Language as a Control System for LLM-Assisted Development, published on this blog.

When Code Becomes Volatile

For a long time, we have treated code as the primary repository of a system’s architectural knowledge. Design decisions, domain constraints and even parts of the business language inevitably became embedded within the implementation.

Generative AI fundamentally changes this dynamic.

Code produced by an LLM is, by its very nature, volatile. It can be regenerated, replaced, automatically refactored or reinterpreted by different models within a matter of minutes. In such a context, relying on code as the sole custodian of architectural knowledge becomes increasingly fragile.

Domain knowledge must therefore move elsewhere.

Specifications, living documentation, Architecture Decision Records and shared semantic models cease to be mere supporting tools. They become the true memory system of the architecture.

If code can be continuously regenerated, then what must survive is not the implementation, but the meaning.

The Future Is Not Less Architecture

Many people imagine that AI will gradually make software design less important. The opposite is more likely to happen.

As the cost of generation approaches zero, the value of consistency increases dramatically. The challenge will no longer be producing code, but ensuring that the system continues to represent the business domain correctly as it evolves at ever-increasing speed.

In this scenario, the role of the software architect changes profoundly. No longer is it simply the person who defines technical structures or oversees implementations. Instead, the architect becomes the designer of the language, constraints and semantic boundaries that allow the system to remain consistent over time.

Domain-Driven Design, therefore, ceases to be merely a modeling methodology. It becomes a semantic operating system for AI-assisted software development.

This article does not aim to propose a new methodology, nor to suggest that AI will replace software design. On the contrary, its goal is to show how automated code generation makes the problem of knowledge even more central. In upcoming articles, I will explore specific aspects of this transformation: the role of ambiguity in AI-driven systems, DDD as a semantic system, living documentation as architectural memory, and fitness functions as a mechanism for automated governance.