It’s AI coding era but naming is still hard

“There are only two hard things in computer science: cache invalidation and naming things.”
~ Phil Karlton

It’s been about a year since I started using AI daily.

In my core role as an SRE/DevOps engineer, AI behaves like a very fast and very obedient assistant. It helps me collect data across services via MCP, generate Terraform modules, work with Helm charts, and automate routine tasks.

There is no “wow” factor here. Just speed.

I don’t expect creativity.
I don’t want initiative.
I want predictable output.

In these scenarios, I already know what the result should look like. I have examples, constraints, and a clear definition of done. AI just accelerates execution. Control stays on my side.

---

Then I switch context.

I start using AI for software development. And everything changes.

As an AWS Community Builder, I have access to tools like Kiro and Kiro CLI - agentic AI development environments backed by Anthropic (and other) models. These tools are powerful.

But they expose a different problem.

Not in AI. In us.

The real bottleneck

When working with AI on anything non-trivial, the bottleneck is not code.

It’s how you describe what you want.

Not syntax.
Not frameworks.
Not even architecture.

Language.

If your instructions are vague, inconsistent, or overloaded with assumptions - the output will reflect that.

And unlike humans, AI won’t ask clarifying questions by default. It will generate something that looks correct but is fundamentally wrong.

This is where things start breaking.

Naming breaks everything

One example from practice.

I had to modify an old project that wasn’t maintained for ~8 years. The goal was simple: update dependencies, remove legacy functionality, and add new features.

The problem was not the code.

The problem was naming.

The same concept - a media file - was called:

• track
• item
• product

Depending on the part of the codebase (mobile apps, backend, frontend), they were developed by different freelancers at different times.

From a human perspective, this is annoying.

From an AI perspective, this is chaos.

The model tries to infer relationships. It guesses. Those guesses propagate into generated code, queries, and logic.

Before doing any actual work, I had to:

1. Recall the real domain model
2. Standardise terminology
3. Refactor naming across the codebase

Only after that AI became useful again.

Non-native constraint (and advantage)

As a non-native English speaker, I hit another limitation.

My vocabulary is narrower. I often use simpler words. Sometimes these words are technically correct, but semantically ambiguous.

For humans, this is manageable. For AI, it creates drift.

At the same time, this constraint forces something useful:

More precision. Less noise.

And with AI, precision matters more than expressiveness.

Don’t start with code

Most people approach AI like this:

“Here’s the idea — build it.”

This is the fastest way to get something wrong.

The approach that actually works is different:

1. Define terminology
2. Lock naming conventions
3. Describe entities and relationships
4. Let AI ask questions
5. Refine understanding
6. Only then generate code
7. This feels slower. It isn’t. AI can write code in seconds. Refactoring unclear code takes hours.

The key shift is simple:

Don’t ask AI to build. Ask it to interrogate you.

“Ask me everything you need to fully define this system.”

This forces you to externalise assumptions — things that are obvious to you but invisible to AI.

This is not new. This is what business analysts have always done. What changes now is the leverage. AI handles a large part of implementation. The bottleneck moves to understanding and definition.

Which means:

People who can clearly describe problems gain more influence than people who can just implement solutions. Not because they write code. Because they define it. AI doesn’t remove complexity. It shifts it.

From code → to thinking

From implementation → to communication

The developers who benefit the most are not the fastest coders. They are the ones who can clearly describe what needs to be built.

Naming things is still hard. Now it’s also critical.

---

Looking for your comments, no matter if you agree or don’t!
Let’s connect on LinkedIn !