Open any React project where the AI has been generating code for a few months.
Search for how buttons are named. How handlers are named. How hooks are named. How the same concept appears across different features.
Chances are you will find three or four variations of the same thing. Not because different developers made different choices. Because the AI made a different choice every session and nobody defined what the convention was supposed to be.
Naming looks consistent until you look closely. Then it looks like a project with no memory.
Why AI naming drifts
Naming is one of the most context-dependent decisions in code.
What something is called depends on the domain, the existing conventions, the patterns already established in the project, and a shared understanding of what words mean in this specific codebase.
The AI has access to some of that context in each session. It can see the files around the current work. It can infer patterns from what it reads. But it cannot see the entire codebase at once. It cannot remember what it called something three sessions ago. And it has no definition of what the naming convention actually is unless someone wrote it down.
So it invents. Each session produces names that make sense in isolation. Button handler today. Handle button click tomorrow. On button press the session after that.
All reasonable. All different. All adding to a codebase where the same concept has accumulated three names and nobody remembers which one was intentional.
What inconsistent naming actually costs
Naming inconsistency is not a cosmetic problem.
When the same concept has different names in different parts of the codebase, developers spend time figuring out whether they are the same thing or different things. New developers spend longer onboarding because the vocabulary is not consistent. Search becomes unreliable because you have to know which variation to look for.
More subtly, inconsistent naming signals that no standard exists. And a codebase that signals no standard invites more inconsistency. The next developer sees the variation and adds a fourth version because there was no single correct answer to follow.
The AI did not create this problem maliciously. It created it because naming decisions were never defined as rules.
What a naming rule actually looks like
A naming rule does not have to cover every possible case. It has to cover the decisions that keep coming out differently.
The most common variations are usually handlers, hooks, and component props. Those are worth defining explicitly:
Naming rules that eliminate drift:
1. Event handlers are always named handle followed by the action. handleSubmit, handleClick, handleChange. Never on, never process, never manage.
2. Custom hooks are always named use followed by the feature they serve. useUserProfile, useCartItems. Never get, never fetch, never load.
3. Boolean props are always named with is or has as a prefix. isLoading, hasError, isVisible. Never loading, never error, never visible alone.
Three rules. Written once. The AI stops inventing variations because the convention exists before the session starts.
The naming that becomes the codebase vocabulary
When naming rules exist, something interesting happens over time.
The codebase develops a vocabulary. The same words appear in the same patterns across every feature. A new developer joins and learns the vocabulary once. From that point they can navigate any part of the project because the language is consistent.
That vocabulary is not created by the AI. It is created by the rules that define what the AI names things. The AI then applies those rules consistently across every session, every feature, every developer who uses it.
The codebase starts to feel like it has a voice. Like it was written by someone with a clear point of view about what things should be called.
It was. You just had to write that point of view down as rules.
The prompt does not matter. The rules do.
Your AI will name things every session. That is unavoidable.
What is avoidable is letting it invent a new convention every time. Write the naming rules once. Give them to the AI before every session. And stop spending time renaming things that should have been named right the first time.
Want to find where your React project has accumulated naming inconsistency?
I built a free 24 point checklist that helps you find exactly that. The structural gaps where your AI has been inventing conventions instead of following one.
Top comments (3)
This reminds me of configuration drift in infrastructure.
Servers don’t become inconsistent because they’re malicious. They become inconsistent because there is no single source of truth enforcing the desired state.
AI-generated code behaves similarly. Naming drift is essentially vocabulary drift. Every session optimizes locally, but without shared rules the codebase slowly loses coherence.
The real takeaway isn’t “teach AI how to name things.” It’s “document the decisions you want to survive beyond a single developer or a single session.”
Interesting perspective.
The configuration drift analogy is exactly right and I had not thought about it that way before. Infrastructure drift happens when there is no single source of truth enforcing the desired state. AI naming drift happens for the same reason. The session is the unit of execution and without shared rules each session optimizes locally just like an unmanaged server would.
The distinction you draw between teaching the AI to name things versus documenting decisions that survive beyond a single session is the core of what I built. The rules are not instructions to the AI. They are the single source of truth that every session has to check against. Same principle as infrastructure as code, just applied to how the AI generates vocabulary.
Exactly.
What makes drift dangerous isn’t the first inconsistency. It’s that every inconsistency becomes a precedent for the next one.
A single server configured manually isn’t a problem. A hundred servers configured manually becomes a system problem.
The same seems true for AI-generated code. One alternative naming choice is harmless. Hundreds of locally reasonable naming choices eventually become organizational entropy.
That’s why I like the idea of treating conventions as a source of truth rather than a style preference.