Skip to main content
Post categories: Learn

Artificial intelligence does not eliminate ambiguity: it makes it faster, more scalable and harder to detect.

16 June 2026 - 5 minutes reading

Many discussions about AI in software development focus on the quality of generated code — correctness, security, performance and reliability — but risk overlooking a deeper problem.

Language models do not understand a domain the way humans do. They interpret language through statistical correlations and fill in missing information based on context. If that context is ambiguous, incomplete or inconsistent, the ambiguity does not disappear; it becomes amplified.

In this article, we will explore why the real risk of AI-driven systems is not the automatic generation of code, but the attribution of the correct meaning to domain concepts. We will examine how plausibility can be more dangerous than obvious errors, and why practices such as Ubiquitous Language and Bounded Context are more important today than ever before.

For a broader and more general perspective on this topic, I invite you to read my previous article, “Domain-Driven Design and AI: the problem is not the code, but the meaning”.

Why the problem with AI-driven systems is not code generation, but meaning interpretation

When discussing AI in software development, much of the conversation revolves around the quality of generated code. We ask whether an LLM produces correct implementations, introduces vulnerabilities, uses appropriate patterns, or is reliable enough for production environments.

These are legitimate questions, but they risk focusing attention on the wrong level of the problem.

The real challenge of AI-driven systems is not their ability to generate code. It is their ability to correctly interpret domain semantics. Consider an e-commerce system where the term “order” is used in multiple scenarios: to represent a completed purchase, a reservation, or a quotation request. An LLM may generate perfectly functional code, yet build rules and workflows around different meanings of the same concept. The result is not a technical error, but a domain interpretation error.

This distinction may seem subtle, but it fundamentally changes the way we should view the evolution of AI-assisted software development.

A language model does not “understand” a domain in the human sense of the word. It has no business experience, does not build an intentional representation of the system, and cannot truly distinguish between what is semantically correct and what is merely plausible.

An LLM completes linguistic sequences based on statistical correlations. And this is precisely the most important point to understand.

The problem is not the syntax error

Whenever a compiler reports a syntax error, the problem is usually obvious. The code does not compile, a test fails, or the behavior is immediately inconsistent.

Semantic problems are far more insidious.

A semantically incorrect system can appear correct from almost every technical perspective. The code may be clean, well organized, aligned with widely adopted architectural patterns, and even covered by automated tests. Yet the underlying conceptual model may still be wrong.

This happens because much of the information we rely on in software development is not truly explicit.

Many decisions depend on context. Others depend on the language shared by the team. Still others rely on implicit assumptions built over time through conversations, meetings, domain experience and business knowledge.

Human beings are able to manage this ambiguity thanks to their ability to continuously interpret context. Language models, on the other hand, tend to fill in missing information using probabilistic correlations.

The more ambiguous the context, the greater the space left to statistical interpretation.

Plausible code is the real risk

One of the most dangerous aspects of AI-generated code is its ability to produce plausible implementations.

In the past, immature tools tended to generate outputs that were obviously incorrect. This made the problem relatively easy to identify: the system would fail immediately or be clearly unusable.

Modern LLMs operate differently.

The code they generate often appears correct, readable and consistent with widely adopted technical conventions. It is precisely this plausibility that dramatically increases the risk of accepting semantically incorrect interpretations as correct.

The focus shifts from recognizing an obvious error to distinguishing a correct model from one that is merely plausible.

And this is where one of the most underestimated aspects of AI-assisted development emerges: AI does not eliminate the interpretive gaps inherent in human language. It amplifies them.

The focus shifts from recognizing an obvious error to distinguishing a correct model from one that is merely plausible.

And this is where one of the most underestimated aspects of AI-assisted development emerges: AI does not eliminate the interpretive gaps inherent in human language. It amplifies them.

Human ambiguity, artificial speed

In public discussions about AI, there is often a tendency to view hallucinations as a kind of “defect” of language models.

Development teams also continuously interpret incomplete concepts, vague requirements and partial domain definitions. The difference is that human beings possess continuous mechanisms for semantic realignment. Discussions, feedback, interactions with the business and peer review gradually help correct inaccurate interpretations.

AI dramatically accelerates this process, but it does not automatically introduce the same realignment mechanisms.

As a result, an ambiguity that in the past might have generated a small local misunderstanding can now produce entire coherent application workflows in a matter of minutes… yet built around an incorrect conceptual model.

The risk does not grow linearly with the speed of generation. It grows exponentially.

Why language becomes central again

For many years, a significant part of software engineering focused primarily on the structural aspects of systems: modularity, performance, distribution, resilience and scalability.

These are all fundamental concerns, of course. But AI-assisted development is bringing a much deeper issue back to the forefront: the precision of the language we use to describe and share domain knowledge.

When a team uses ambiguous, inconsistent or overlapping terms, the language model inherits that same ambiguity.

If “order,” “shipment,” “request” and “reservation” are used as synonyms in different contexts, AI will inevitably begin to mix responsibilities, rules and semantic boundaries.

This does not happen because the model is “stupid.” It happens because the language we are providing is semantically unstable.

And it is precisely here that many Domain-Driven Design practices take on an entirely new meaning.

Ubiquitous Language is not only a way to improve communication between developers and the business. It becomes a mechanism for reducing semantic ambiguity in AI-driven systems as well.

Likewise, Bounded Contexts cease to be merely architectural tools and become true linguistic boundaries that limit the interpretive space left to the model.

AI does not replace design

One of the most common mistakes in how we interpret AI-generated code is assuming that automated generation reduces the need for software design.

In reality, the exact opposite is happening.

As code production becomes less expensive, the value of semantic precision increases. When implementing a solution takes only a few seconds, the real challenge is no longer producing software, but ensuring that the system correctly represents the domain it is intended to model.

Software design does not disappear. Its focus changes.

Less and less attention will be devoted to manually writing implementations, while more and more effort will be invested in defining the language, constraints, semantic boundaries and architectural validation mechanisms.

In this sense, AI is not reducing the importance of software architecture. Rather, it is making visible a problem that has always existed but remained hidden behind the cost of manually producing code.

Article written by