{"slug": "your-agent-keeps-using-that-word", "title": "Your agent keeps using that word ...", "summary": "AI coding agents amplify ambiguity in human language, confidently generating code based on their own interpretation of vague terms without asking for clarification. It argues that this lack of friction, unlike traditional development where misunderstandings are caught through team interaction, can lead to serious production errors. The solution proposed is Domain-Driven Design’s \"Ubiquitous Language,\" a shared, precise vocabulary co-created by developers and domain experts for each specific bounded context.", "body_md": "\"You keep using that word. I do not think it means what you think it means.\"\n\n— Inigo Montoya,The Princess Bride(1987)\n\nTwo people using the same word while meaning completely different things has been a staple of comedy for centuries.\n\nLewis Carroll built an entire scene around it in 1871:\n\n\"When I use a word,\"Humpty Dumpty tells Alice,\"it means just what I choose it to mean - neither more nor less.\"\n\nNow imagine what happens if you give Humpty Dumpty a code editor and 1M tokens of context...\n\nAn 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.\n\n## How AI agents amplify vocabulary ambiguity\n\nThe 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.\n\nWith 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.\n\nIn [How Creating a Ubiquitous Language Ensures AI Builds What You Actually Want](https://www.danielschleicher.com/software/engineering,/ai,/spec-driven/development/2026/01/04/removing-ambiguity-with-spec-driven-development.html), 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.\"*\n\nThe 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.\n\nRussell Miles tells a story about a finance agent that confused *booking* (revenue recognition in one bounded context) and *reservation* (risk allocation in another):\n\n\"The agent mashed them like a bad DJ, and began taking action that would've landed the CFO in handcuffs.\"\n\n— Russell Miles,[Domain Driven Agent Design]\n\nAmbiguous words, different contexts, no clear definitions, and code that compiled just fine all the way to production.\n\n## Ubiquitous Language: DDD's pattern for shared vocabulary\n\nThe 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\n\n**Ubiquitous Language**:\n\nUse 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.\n\n— Eric Evans,Domain-Driven Design(2003)\n\nMartin Fowler [describes it](https://martinfowler.com/bliki/UbiquitousLanguage.html) as *\"the practice of building up a common, rigorous language between developers and users.\"*\n\nAnd Vaughn Vernon sharpens it even more:\n\n\"[...] a shared language developed by the team - a team comprised of both domain experts and software developers\"\n\n— Vaughn Vernon,Implementing Domain-Driven Design(2013)\n\nThe 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.\n\nBut note that - despite the name - the Ubiquitous Language is all *but* ubiquitous. In Vernon's words: *\"There is one Ubiquitous Language per Bounded Context.\"*\n\n## What does \"Customer\" really mean?\n\nThe term \"Customer\" seems universal - it shows up in the codebase of virtually every single business application.\n\nBut 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*.\n\nAll 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.\n\nAnd 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.\n\nFlattening all of this into a `Customer`\n\nclass with a `type`\n\nfield 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.\n\nWhen writing the original book, Evans described the Ubiquitous Language for teams of humans - developers, product managers, and domain experts - modelling a shared domain.\n\nBut 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.\n\nExcept 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.\n\n## Practitioners applying DDD's Ubiquitous Language to AI agents\n\nI'm not the only one seeing this. Across the industry, people are arriving at the same pattern from different directions.\n\nMartin Fowler described at the [Pragmatic Summit 2026](https://www.youtube.com/watch?v=CZs8J1ZD0CE) 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.\"*\n\n[Matt Pocock](https://www.aihero.dev) 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.\n\nDaniel 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:\n\n\"The greatest leverage in modern software development with AI lies not in accelerating typing, but in establishing semantic agreement before implementation begins.\"\n\n— Daniel Schleicher,[How Creating a Ubiquitous Language ...]\n\nTim Oleson named *\"Language Consistency - usage of ubiquitous language in agent communications\"* as a first-class [domain alignment metric](https://www.linkedin.com/pulse/domain-driven-designs-role-agentic-services-mcp-tools-tim-oleson-rwipe) for agent systems.\n\nWhether 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()`\n\nand `submit_order()`\n\nproduce different agent behavior even when the underlying operation is identical. Chris Hughes [writes](https://medium.com/@chris.p.hughes10/building-scalable-mcp-servers-with-domain-driven-design-fb9454d4c726) 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.'\"*\n\nMarc Brooker's [Specification Loop](https://brooker.co.za/blog/2025/12/16/natural-language.html) 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.\"*\n\n## How to define domain vocabulary for your coding agent\n\nThe Ubiquitous Language isn't a document you have to write upfront and rigidly apply. It's a living artifact that evolves through use.\n\nA 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.\n\nThis 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`\n\nor `AGENT.md`\n\n, your cursor rules, or just a simple `domain-terms.md`\n\n, 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.\n\nBut 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.\n\nHere's what a `modules/fulfillment/CLAUDE.md`\n\nmight contain:\n\n```\n## Fulfillment Domain Language\n\n**Consignee**:\nThe person or entity receiving a shipment. Identified by delivery\naddress, contact phone, and access instructions. A consignee may\ndiffer from the purchaser.\n*Avoid*: Customer, Buyer, User\n\n**Consignment**:\nThe full set of items to be delivered to a consignee. May be\nfulfilled as one or more Shipments depending on stock location\nand logistics.\n*Avoid*: Order, Delivery (a delivery is one shipment arriving,\nnot the full set)\n\n**Shipment**:\nA physical package dispatched to a consignee via a carrier. Has\ntracking number, weight, dimensions, and a declared value.\n*Avoid*: Order, Package (ambiguous with code packages)\n\n**Dispatch**:\nThe act of handing a shipment to a carrier. Irreversible - once\ndispatched, the shipment is the carrier's responsibility.\n*Avoid*: Send, Ship (verb), Process\n```\n\nAnd `modules/billing/CLAUDE.md`\n\nin the same application, even though it might refer to the same physical person or purchase event, is using terms native to its own domain:\n\n```\n## Billing Domain Language\n\n**Debtor**:\nThe legal entity liable for payment. Identified by tax ID, billing\naddress, and agreed payment terms (net-30, net-60, etc.).\n*Avoid*: Customer, Account, User\n\n**Invoice**:\nA legal demand for payment tied to one or more line items. Carries\na due date, VAT status, and regulatory classification. An invoice\nis never deleted - it is reversed with a **Credit Note**.\n*Avoid*: Order, Bill (ambiguous with infrastructure billing)\n\n**Settlement**:\nThe act of a debtor satisfying an invoice in full or in part.\nRecords payment method, date, and reconciliation reference.\n*Avoid*: Payment (ambiguous - is it the act or the money?),\nTransaction\n```\n\nBoth 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.\n\nTell an agent *\"handle the customer's order\"* without this, and you get a generic `Customer`\n\nclass with a `type`\n\nfield. Tell it within a defined context, and you get a `Consignee`\n\nwith a delivery address or a `Debtor`\n\nwith payment terms.\n\nThe 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.\n\nAnd remember: You don't need a formal glossary to start.\n\n**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.\"**\n\nAdd it. Use it. Let it accumulate.\n\n*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.*", "url": "https://wpnews.pro/news/your-agent-keeps-using-that-word", "canonical_source": "https://dev.to/aws/your-agent-keeps-using-that-word--4g36", "published_at": "2026-05-21 20:52:57+00:00", "updated_at": "2026-05-21 21:01:59.546341+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "developer-tools"], "entities": ["Inigo Montoya", "The Princess Bride", "Lewis Carroll", "Humpty Dumpty", "Alice"], "alternates": {"html": "https://wpnews.pro/news/your-agent-keeps-using-that-word", "markdown": "https://wpnews.pro/news/your-agent-keeps-using-that-word.md", "text": "https://wpnews.pro/news/your-agent-keeps-using-that-word.txt", "jsonld": "https://wpnews.pro/news/your-agent-keeps-using-that-word.jsonld"}}