Cover Image Photo by Scott Graham on Unsplash
A habit that turned repetitive frustration into one-time fixes
"Rename this to processUserData because we use process[Entity]Data pattern for all transformation functions."
That single word, "because," reduced how often I correct AI in a session.
Not across sessions. AI doesn't remember those (I will discuss this in next article). But within a single session, adding "because" to my corrections changed how AI applied them.
Here's why that matters.
Why AI Guesses
AI tools are designed to act on available information rather than ask clarifying questions. That's what makes them fast and fluid. You don't get peppered with "Did you mean X or Y?" every time you ask for something.
The tradeoff: AI guesses. Sometimes the guess is wrong, and you correct it.
But here's what I missed at first: when you correct AI, it guesses again. It has to infer what you meant by the correction.
"Rename this to processUserData" could mean:
- You want this specific function renamed
- You follow a naming convention for all transformers
- You're matching an existing pattern in the codebase
- You just prefer it that way for no particular reason
Without knowing which, AI picks whichever seems most likely based on its training.
The Default: Match to General Patterns
LLM is fundamentally a pattern-matching system, but it matches against patterns from its training data, not your specific codebase. Without more context, AI defaults to what it's seen most often across millions of codebases.
If you say "rename to processUserData," AI applies the change where you pointed. When you ask it to create the next transformation function, it might name it handleOrderInfo or convertProductData, matching common patterns from its training, not your local convention.
The problem: when your correction reflects a local pattern (your naming conventions, your architectural constraints, your domain rules), AI has no way to distinguish it from a one-off preference. You may end up correcting the same underlying issue in different places, wondering why AI "didn't learn."
It did learn. It learned you wanted that one function renamed. It didn't learn that you follow a convention, because you didn't tell it.
The Fix: Add "Because"
"Because" changes AI's interpretation.
"Rename this to processUserData" is a one-off request. Apply here, with no signal about where else it applies.
"Rename this to processUserData because we use process[Entity]Data pattern for all transformation functions" is a convention with scope. Apply to all transformation functions in this module.
The difference in the same session:
| Correction | AI's Interpretation | What Happens Next |
|---|---|---|
"Rename this to processUserData" |
One-off rename | Applies to that function. Next transformer gets named handleOrderInfo or whatever feels natural. |
"Rename to processUserData because we use process[Entity]Data for all transformers" |
Naming convention | Applies to that function AND next transformer gets named processOrderData consistently. |
"Because" tells AI: this isn't arbitrary. Here's when it applies.
Same-Session Examples
Without "because":
You: "Add retry logic here."
AI applies: Retry on this specific call.
Later in the session, when AI writes another call to the same service, it might not include retry—especially if you've moved on to other code.
With "because":
You: "Add retry with exponential backoff because the auth service has 2-3 second cold-start latency after being idle."
AI now has context: This service is unreliable after idle periods. When it writes the next auth service call, it's much more likely to add retry logic because it understands the problem you're solving.
Without "because":
You: "Validate this phone number."
AI applies: Basic format validation on this input.
Later, AI handles another phone input with minimal validation.
With "because":
You: "Validate with libphonenumber because we support international formats and need carrier lookups for SMS routing."
AI now has context: Phone handling in this system needs international support and carrier data. It's more likely to use libphonenumber consistently because it understands the domain requirements.
The pattern: "because" gives AI local information it can't infer from its training. Your naming conventions, internal service constraints, and domain-specific requirements are unique to your system. Without "because," AI matches against general patterns from its training data, plus limited context in current session, not your codebase's patterns.
What This Applies To
This habit works with chat-based AI tools: ChatGPT, Claude, Copilot Chat, Cursor, and similar. You're having a conversation, and your corrections shape the rest of that conversation.
For pure autocomplete tools (basic Copilot suggestions), you can't "correct with because" directly. There, code comments and instruction files matter more, that's a different workflow.
Results also vary by model. AI tools with stronger reasoning may generalize better even without explicit "because." The habit helps across tools, but don't expect identical results everywhere.
The Habit
When you correct AI, add "because."
That's the whole habit. No setup required. No files to create. No tools to configure.
Next time AI does something you need to fix:
- Don't just say what to change
- Add why
If you don't know why, that's useful information too. Maybe it IS just a preference. But if there's a reason (architecture, security, external constraints, past incidents), say it.
The test: does AI apply the principle appropriately elsewhere in the same session? If yes, the "because" worked. If not, maybe the reasoning needs to be clearer, or maybe AI's context window has moved on.
Try It
Your next AI coding session:
- Work normally until you need to correct something
- Add "because" with your reasoning
- Notice if AI applies the principle to other code in the session
No commitment. No system to adopt. Just one word.
If it helps, keep doing it. If it doesn't, you've lost nothing.
This habit helps within a session. If you want patterns to persist across sessions, that requires something more: an instruction file that loads at session start. I'll cover that in a follow-up article.
Top comments (0)