"You keep using that word. I do not think it means what you think it means."
— Inigo Montoya, The Princess Bride (1987)
Two people using the same word while meaning completely different things has been a staple of comedy for centuries.
Lewis Carroll built an entire scene around it in 1871:
"When I use a word," Humpty Dumpty tells Alice, "it means just what I choose it to mean - neither more nor less."
Now imagine what happens if you give Humpty Dumpty a code editor and 1M tokens of context...
An AI coding agent is the most confident version of Humpty Dumpty you'll ever encounter. It will interpret your vocabulary however it sees fit, and it will never tell you it's confused. It won't raise its hand and ask "wait, do you mean a purchase order or a delivery order?" It will pick one interpretation, generate plausible code, and move on. As confidently as ever.
How AI agents amplify vocabulary ambiguity
The problem isn't new. Teams have always talked past each other. But in traditional development, ambiguity encounters friction: code reviews, pair programming, whiteboard sessions, the "wait, what exactly do you mean by 'order'?" conversation over coffee. Misunderstandings cascade, but they mostly get caught eventually.
With AI agents, that friction disappears. The code compiles, the tests pass, and the semantic mismatch only surfaces when a downstream system interprets the same word differently. Or when the wrong action leads to a production incident.
In How Creating a Ubiquitous Language Ensures AI Builds What You Actually Want, Daniel Schleicher wrote: "LLMs are amplifiers. When we give an AI agent ambiguous instructions where 'order' could mean a dozen different things, it amplifies the chaos by generating code that reflects our confusion."
The flip side is equally true: precise vocabulary gets amplified into correct class names, correct lifecycle states, and correct boundaries. The agent works with whatever you give it - if you give it ambiguity, then that's what it amplifies.
Russell Miles tells a story about a finance agent that confused booking (revenue recognition in one bounded context) and reservation (risk allocation in another):
"The agent mashed them like a bad DJ, and began taking action that would've landed the CFO in handcuffs."
— Russell Miles, Domain Driven Agent Design
Ambiguous words, different contexts, no clear definitions, and code that compiled just fine all the way to production.
Ubiquitous Language: DDD's pattern for shared vocabulary
The good news is that Domain-Driven Design (DDD), a widely-adopted methodology, introduced by Eric Evans in 2003, provides both the vocabulary and the pattern for a solution. It's called Ubiquitous Language:
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code.
— Eric Evans, Domain-Driven Design (2003)
Martin Fowler describes it as "the practice of building up a common, rigorous language between developers and users."
And Vaughn Vernon sharpens it even more:
"[...] a shared language developed by the team - a team comprised of both domain experts and software developers"
— Vaughn Vernon, Implementing Domain-Driven Design (2013)
The important distinction here: It's not a glossary imposed from above, not industry jargon adopted wholesale. It is a language the team builds together through use.
But note that - despite the name - the Ubiquitous Language is all but ubiquitous. In Vernon's words: "There is one Ubiquitous Language per Bounded Context."
What does "Customer" really mean?
The term "Customer" seems universal - it shows up in the codebase of virtually every single business application.
But look at how each subdomain actually refers to the same person: marketing calls them a lead, sales calls them a prospect, the warehouse calls them a consignee, finance calls them a debtor, and support calls them a claimant.
All these subdomains may refer to the same person, but the words they use aren't synonyms. They carry different attributes, different lifecycle states, different invariants, and different behavior.
And nobody really "creates" or "deletes" anything: a lead is captured, a prospect is qualified, a purchase intent is confirmed, a shipment is dispatched. Each subdomain has its own language, refined over decades - or centuries - of practice.
Flattening all of this into a Customer class with a type field and CRUD operations may feel like it's simplifying things. But it actually erases the precision and clarity each domain has built, and replaces it with generic ambiguity, which the code, the database schema, the team, and - more often than not - the users of the software have to work around.
When writing the original book, Evans described the Ubiquitous Language for teams of humans - developers, product managers, and domain experts - modelling a shared domain.
But now, we have a new participant: the coding agent. And when the agent reads your prompt, your system instructions, your project rules, it's doing something analogous to a new developer onboarding onto the team.
Except it onboards every session, with no memory of last time's disambiguation, and no instinct to ask when a term's exact meaning is unclear. Tell it "delete the order" and it will. Generically, ambiguously, and very confidently.
Practitioners applying DDD's Ubiquitous Language to AI agents
I'm not the only one seeing this. Across the industry, people are arriving at the same pattern from different directions.
Martin Fowler described at the Pragmatic Summit 2026 how a colleague is "developing a precise language to communicate about the domain with the agent... that's basically the kind of model building, language building, domain-driven design stuff that we're used to doing, but it makes him more efficient to talk to the agent."
Matt Pocock built a glossary skill that scans the codebase, extracts terminology into markdown, and feeds it to the agent. Reading the agent's thinking traces, he found it improved implementation alignment while even reducing verbosity - an unexpected benefit in terms of token use and cost.
Daniel Schleicher formalized it with the "Spec Ambiguity Resolver" pattern: a living glossary where AI flags ambiguous terms, proposes definitions, and waits for human approval. Once approved, consistency is enforced project-wide:
"The greatest leverage in modern software development with AI lies not in accelerating typing, but in establishing semantic agreement before implementation begins."
— Daniel Schleicher, How Creating a Ubiquitous Language ...
Tim Oleson named "Language Consistency - usage of ubiquitous language in agent communications" as a first-class domain alignment metric for agent systems.
Whether they came to it through practicing Domain-Driven Design or arrived at it independently, the pattern is the same. And it shows up in places you might not expect: every MCP tool name is a vocabulary decision the LLM reasons over. confirm_purchase_intent() and submit_order() produce different agent behavior even when the underlying operation is identical. Chris Hughes writes that the tools layer "protects your domain from the LLM's interface requirements - translating between 'strings the LLM can reason about' and 'rich domain objects your code works with.'"
Marc Brooker's Specification Loop explains how this compounds over time: each resolved ambiguity becomes a stable term that enriches the shared vocabulary. The next conversation starts from a higher baseline and the loop gets cheaper over time as the vocabulary grows. "I believe that the trips around the loop are fundamental to the success of the whole enterprise. They're what we've been doing all along."
How to define domain vocabulary for your coding agent
The Ubiquitous Language isn't a document you have to write upfront and rigidly apply. It's a living artifact that evolves through use.
A common practice in teams: whenever someone realizes there's an ambiguity - two people using the same word differently, or one word meaning two things - the team pauses, discusses, and agrees on a term. And this doesn't have to be the academically "correct" term. What matters is that everyone on the team knows exactly what it means. Then you write it down, and use it consistently. In conversations, in code, and in the documentation.
This practice naturally extends to conversations with a coding agent. Whenever there's a misunderstanding, missing clarity, or ambiguity in what the agent produces, spend a moment to establish a specific term for the concept. Define it. Add it to whatever artifact represents the current shared state of the vocabulary: your CLAUDE.md or AGENT.md, your cursor rules, or just a simple domain-terms.md, referenced as the canonical glossary of terms. The agent will start using it from that point forward, each disambiguation compounds, and every new conversation starts from a higher baseline.
But remember: each bounded context has its own vocabulary. If your application has a fulfillment module and a billing module, each gets its own language section in that module's CLAUDE.md (or whatever file your agent reads when entering a directory). The terms in one context don't need to match the terms in another - that's the whole point.
Here's what a modules/fulfillment/CLAUDE.md might contain:
## Fulfillment Domain Language
**Consignee**:
The person or entity receiving a shipment. Identified by delivery
address, contact phone, and access instructions. A consignee may
differ from the purchaser.
*Avoid*: Customer, Buyer, User
**Consignment**:
The full set of items to be delivered to a consignee. May be
fulfilled as one or more Shipments depending on stock location
and logistics.
*Avoid*: Order, Delivery (a delivery is one shipment arriving,
not the full set)
**Shipment**:
A physical package dispatched to a consignee via a carrier. Has
tracking number, weight, dimensions, and a declared value.
*Avoid*: Order, Package (ambiguous with code packages)
**Dispatch**:
The act of handing a shipment to a carrier. Irreversible - once
dispatched, the shipment is the carrier's responsibility.
*Avoid*: Send, Ship (verb), Process
And modules/billing/CLAUDE.md in the same application, even though it might refer to the same physical person or purchase event, is using terms native to its own domain:
## Billing Domain Language
**Debtor**:
The legal entity liable for payment. Identified by tax ID, billing
address, and agreed payment terms (net-30, net-60, etc.).
*Avoid*: Customer, Account, User
**Invoice**:
A legal demand for payment tied to one or more line items. Carries
a due date, VAT status, and regulatory classification. An invoice
is never deleted - it is reversed with a **Credit Note**.
*Avoid*: Order, Bill (ambiguous with infrastructure billing)
**Settlement**:
The act of a debtor satisfying an invoice in full or in part.
Records payment method, date, and reconciliation reference.
*Avoid*: Payment (ambiguous - is it the act or the money?),
Transaction
Both examples describe the same person making the same purchase. But the vocabularies are completely different, because the contexts model different responsibilities, different invariants, different behaviors, and different lifecycles.
Tell an agent "handle the customer's order" without this, and you get a generic Customer class with a type field. Tell it within a defined context, and you get a Consignee with a delivery address or a Debtor with payment terms.
The vocabulary manifests in an architecture that captures the richness of the business domains it models. And - whichever context you're in - the agent knows exactly what you mean.
And remember: You don't need a formal glossary to start.
All you need is one line the next time something goes wrong: *"In this project, 'order' means a confirmed purchase intent, not a request or a reservation."
Add it. Use it. Let it accumulate.
If you want to learn more about how Domain-Driven Design maps to the age of coding agents, I recently wrote about how engineers building MCP servers are reaching for DDD's Bounded Contexts and Anti-Corruption Layers.
