Skip to content
BSWEN
Blog

How to stop AI from changing your environment variable naming conventions

Cowrie
Cowrie
Dev @ Bswen

Problem

When I ask AI assistants like Claude or Codex to add a _TEST_ prefix to my environment variables, they keep “correcting” it to TEST_ (without the leading underscore).

My prompt:

Add _TEST_ prefix to these environment variables:
DATABASE_URL
API_KEY
REDIS_HOST

What I get:

Terminal window
TEST_DATABASE_URL=...
TEST_API_KEY=...
TEST_REDIS_HOST=...

The AI removes the leading underscore. I explicitly said _TEST_, but it gives me TEST_ instead.

What happened?

I need the _TEST_ prefix format. The leading underscore is required by my system. But the AI assumes I made a mistake and “helpfully” removes it.

This happens because:

  1. Training bias: AI models see millions of codebases using TEST_, DEV_, PROD_ prefixes. Almost never see _TEST_ with a leading underscore.

  2. Helpfulness override: AI assistants are tuned to be helpful. They “fix” apparent errors to prevent mistakes.

  3. Convention priority: Models prioritize common patterns over exact instructions. When your request violates conventions, they assume it’s wrong.

The problem isn’t that the AI can’t understand you. It’s that the AI is too smart—it recognizes an unusual pattern and decides you must have made a mistake.

How to solve it?

I tried several approaches. Here’s what worked.

Approach 1: Explicit intent declaration

You must use the EXACT pattern I specify, even if it violates common conventions.
Do NOT "correct" or "improve" the naming pattern.


Add _TEST_ prefix to these environment variables:
DATABASE_URL
API_KEY
REDIS_HOST

This helps, but the AI might still “correct” the pattern if it’s confident enough that you’re wrong.

Approach 2: Provide multiple examples (works better)

Add _TEST_ prefix to all environment variables:


DATABASE_URL → _TEST_DATABASE_URL
API_KEY → _TEST_API_KEY
REDIS_HOST → _TEST_REDIS_HOST


Follow this EXACT pattern for all variables.

Multiple examples establish that the pattern is intentional, not a typo.

Approach 3: Negative constraints (most reliable)

Transform these environment variables by adding _TEST_ prefix:


DO NOT:
- Remove the leading underscore
- Change _TEST_ to TEST_
- "Correct" the naming pattern


DO:
- Keep _TEST_ exactly as specified
- Apply _TEST_DATABASE_URL format


Variables:
DATABASE_URL
API_KEY
REDIS_HOST

Telling the AI what NOT to do is often more effective than telling it what to do.

Approach 4: Technical context (when applicable)

Add _TEST_ prefix to these environment variables:
DATABASE_URL
API_KEY
REDIS_HOST


IMPORTANT: Our deployment system parses environment variables and requires
the leading underscore (_TEST_) to identify test environment configs.
The system will NOT recognize TEST_ (without underscore). Keep the exact
_TEST_ prefix pattern or deployments will fail.

Explaining WHY the unusual pattern is needed prevents the AI from assuming it’s a mistake.

The reason

AI models prioritize being helpful over being literal. When they see:

  • Your instruction: “Use _TEST_ prefix”
  • Common convention: “Use TEST_ prefix”

They decide the convention is correct and your instruction is wrong. This is called “helpful overcorrection.”

The model thinks:

  • 99.9% of codebases use TEST_
  • User asked for _TEST_
  • User probably made a typo
  • I’ll “fix” it for them

To override this behavior, you need to signal that the non-standard pattern is:

  1. Intentional (not a mistake)
  2. Required (not optional)
  3. Backed by a specific reason (not a random choice)

Summary

In this post, I showed how to prevent AI assistants from changing your naming conventions when they violate common patterns. The key point is that AI prioritizes being helpful over following exact instructions—you need to explicitly override the “helpfulness” impulse with clear context, examples, and negative constraints.

The most reliable approach is to combine multiple strategies: state that the pattern is intentional, provide multiple examples, use negative constraints, and explain the technical rationale when applicable.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: