Every product has a language.
Not a programming language. A domain language. The specific words that mean specific things in the context of this particular product, this particular business, this particular problem space.
In an e-commerce platform a Customer is not the same as a User. An Order is not the same as a Cart. A Listing is not the same as a Product. These distinctions matter. They reflect real differences in the business domain. The right word in the right place makes code readable. The wrong word, or five different words for the same concept, makes code that requires translation every time someone reads it.
Your team knows this language. You have been building it for months or years. It lives in conversations, in pull request comments, in the names your product managers use when they describe features. It is the shared vocabulary that makes your team efficient.
Your AI does not know any of it. And every session it invents its own.
What domain language drift actually looks like
It starts subtly and accumulates over time.
In the first few months the AI generates components and hooks that use reasonable naming. Nothing obviously wrong. The words it chooses are generic React vocabulary and they work well enough for what they describe.
But beneath the surface the domain language is fragmenting. The concept your team calls a Customer appears as User in some components, Client in others, Buyer in the ones the AI generated when it was looking at a different part of the codebase. The concept your team calls an Order appears as Purchase in one hook, Transaction in another, Checkout in a third.
None of these are wrong in isolation. User is a reasonable word. So is Client. So is Buyer. But they are not the same word and in your domain they do not mean the same thing. The AI does not know the difference because nobody told it.
Over six months of sessions, the codebase stops speaking one language. It speaks five. The AI's language for this week's feature, the AI's language from three months ago, what the senior developer wrote before the AI was in the workflow, what the new developer added last sprint, and the actual domain language that exists in business conversations but has never been written down in a form the AI could follow.
A new developer joins and tries to understand the codebase by reading it. They find Customer in some places and User in others and cannot tell if they are the same thing or different things. They have to ask. The answer is that they are the same thing. The AI just did not know.
Why domain language matters more than naming conventions
Naming conventions are about form. PascalCase for components. camelCase for functions. handleX for event handlers. These are rules about how words are written.
Domain language is about meaning. Customer versus User. Order versus Purchase. Listing versus Product. These are decisions about which words carry which concepts.
Both matter. But they solve different problems. Naming conventions solve consistency of form. Domain language solves consistency of meaning. And consistency of meaning is what makes a codebase readable to someone who understands the business.
A codebase with perfect naming conventions but fragmented domain language is technically consistent but semantically confusing. You know how the words are capitalized. You do not know which word to use when you are describing a person who has completed a purchase.
Domain language fragmentation is harder to notice than naming convention violations because it does not trigger any automated checks. No linter catches the fact that Customer and User are being used interchangeably. No TypeScript error appears when a component receives a User object and calls it a Customer internally. The code compiles. The tests pass. The language is fragmented and nobody knows.
Where the AI's invented language comes from
The AI is not making random choices when it names domain concepts.
It is making locally reasonable choices based on whatever context is visible in the current session. If the file it is working in uses User, it uses User. If the adjacent hook uses Customer, it might switch. If the prompt mentions a buyer, it might use Buyer. If it cannot infer anything from context, it falls back to the most generic available term.
Each individual choice is defensible. The aggregate is chaos.
This is the core of the problem. The AI is not bad at naming. It is excellent at locally consistent naming within a session. The problem is that locally consistent naming across different sessions, with different context, making different locally reasonable choices, produces a codebase that is globally inconsistent in meaning.
Domain language is by definition not something the AI can derive from context alone. Context tells it what React patterns are visible nearby. It does not tell it that in this product, in this business domain, Customer means someone who has completed at least one purchase while User means anyone with an account. That distinction exists in the business. It has never been written down in a form the AI can use before it generates something.
Building the domain language document
The fix is not complicated. It is just work that almost no team does because it does not feel like a development task.
A domain language document is a list of the concepts in your product and the specific words your codebase uses to represent them. Not a business glossary. Not user-facing terminology. The specific technical terms that should appear in component names, hook names, type definitions, and variable names throughout the codebase.
Here is what a domain language document looks like for a simplified e-commerce context:
Domain language rules for this project:
Person concepts:
- User: anyone with an account, authenticated or not
- Customer: a User who has completed at least one purchase
- Guest: an unauthenticated visitor
- Never use: Client, Buyer, Shopper, Member
Transaction concepts:
- Cart: items selected but not yet purchased
- Order: a completed purchase transaction
- LineItem: a single product within a Cart or Order
- Never use: Basket, Purchase, Transaction, Item (alone)
Product concepts:
- Product: the base catalog entry
- Listing: a Product with pricing and availability for a specific context
- Variant: a specific configuration of a Product
- Never use: Item, Good, Merchandise, SKU (in component names)
This document does not take long to create for a project that has been running for any meaningful time. The domain language already exists. It lives in conversations and pull request comments and the names product managers use. Writing it down is mostly a matter of making explicit what is already implicit.
Once it exists it becomes part of the rules the AI receives before every session. The AI stops inventing its own vocabulary because the vocabulary has been defined. Customer appears where Customer should appear. User appears where User should appear. The distinction is maintained because the rule exists.
What changes in the codebase over time
Domain language consistency compounds in the same way that domain language fragmentation does. But in the right direction.
When the AI uses the correct domain terms consistently, new components look like existing components not just structurally but semantically. A developer reading a new feature written last week can immediately understand what it is talking about because the words are the same words used everywhere else.
The cognitive overhead of reading the codebase drops. Not because the code became simpler. Because the language became consistent. A developer does not have to translate between User and Customer and Client when reading different parts of the system. They encounter one word for each concept and they know immediately what it means.
Onboarding accelerates. A new developer learns the domain language once from the documentation and then sees it applied consistently everywhere in the codebase, including in every component and hook the AI generates from that point forward.
Search becomes reliable. A developer looking for everything related to Orders can search for Order and find it. They do not have to also search for Purchase and Transaction and Checkout and Fulfillment and hope they have covered all the variations.
The codebase starts reading like it was written by a team that shared a language. Because the rules ensure that it was. Even when the AI was involved in building large portions of it.
The language your product already has
Your product already has a domain language. Your team already knows it.
The gap is not that the language does not exist. The gap is that it has never been written down in a form the AI can follow before it generates something.
Every time the AI uses the wrong word for a concept in your domain, it is not making a mistake. It is filling a gap you left open. The word you wanted was not in the rules. So it used the word that seemed most reasonable given the context it had.
Write the domain language down. Give it to the AI before every session. And stop finding five words for the same concept in a codebase that should only ever have one.
The prompt does not matter. The rules do.
Your React project has a language. It developed over time through the work your team did and the conversations you had about what things should be called.
Your AI speaks a different language every session. Not because it cannot speak yours. Because you never told it what yours was.
Write it down. Apply it consistently. And let the codebase finally speak one language instead of five.
Want to find where your React project's domain language has fragmented?
I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your AI has been inventing vocabulary instead of following the language your product already has.
Top comments (0)