Over the years we’ve been told a lot of things about naming. Use Hungarian notation. Keep names short and abbreviated. And if in doubt, just call it a Manager, a Controller or a Helper. Or we’ve gone off-piste entirely and picked fun codenames, something the team can rally around like it’s a pet they’ve adopted. Maybe I’m just boring, but when it comes to systems, I think we all need to be descriptive and boring.
It’s been over 20 years since Eric Evans wrote Domain-Driven Design. A lot of it has faded from my memory, the patterns, the building blocks, the tactical design. But one thing stuck, ubiquitous language. One shared vocabulary between the business and the code, no translation.
When the code doesn’t speak the same language as the business, we all end up carrying a mental translation layer and over time that overhead compounds. New starters spend half their onboarding just learning what things are called, documentation drifts, and bugs hide not because the logic is wrong but because the same concept has three names and someone assumed they were interchangeable. And it works both ways, different concepts with similar names are even more dangerous, one mishap away from deleting the wrong thing.
None of this is new. But AI makes it worth talking about again. LLMs consume vast amounts of training material, distilled down into a model where words carry weight and meaning shaped by every context they’ve ever appeared in. A word might mean something specific to your domain, and that’s important.
And before anyone says this doesn’t matter in a world where developers stop writing code entirely, I’d argue the opposite. If specs become the source of truth, the language in those specs drives everything. Vague specs produce vague systems. The problem doesn’t go away, it just moves left.
If your business has custom names for products or processes, you can help the LLM along, prompt-stuffing a glossary, adding context files, nudging the model into your private vocabulary. And it works. But it would be nice if the codebase itself did that work, if the names were so clear, so grounded in the domain, that no translation was needed. I can hear the groans. Self-documenting code. As we move into a more agentic world, where humans are out of the loop, a misread concept isn’t just a problem for a developer anymore, it’s an agent taking the wrong action. And agents move fast. The translation tax doesn’t go away. It just gets paid by something that won’t ask a clarifying question, and will sprint confidently in the wrong direction before anyone notices.
So what’s the answer? Be boring. Be descriptive. Use the same language as the business. And when names change, because they will, stay disciplined and change the code or spec to match. Let it slip and you’re back to the translation tax. The Pragmatic Programmer called this the Broken Window Theory. Small things left unchallenged signal that nobody cares, and the rot spreads. A stale name is a broken window. And whatever you do, don’t name it after your cat.
And if you do name it after your cat, at least write a glossary. And stick to it.
Opinions are my own.