AI coding agents are getting absurdly good. Whether it's GPT-4, Claude Sonnet, or something else, having an AI pair-programmer can feel like magic.
But here’s the thing nobody talks about:
The code they write often feels… alien.
Not wrong — just off.
🎯 The Problem
You ask the agent to write a component, a helper function, or even a config file — and what you get is:
- Functional, yes.
- Accurate, mostly.
- But completely misaligned with your style.
Variable names don’t follow your naming conventions. Braces are in weird places. It destructures things you wouldn’t. The imports are ordered strangely. Sometimes it even uses APIs you’d never touch.
At first, I thought the fix was simple:
📝 Write a coding conventions document.
I created a clear markdown file with all my stylistic preferences:
- Naming rules
- Folder structure
- Syntax conventions
- Patterns to avoid
Then I pasted it into the chat and told the agent:
“Follow these rules.”
It worked for a few prompts.
Then it forgot.
🤖 Agents Follow Context, Not Suggestions
Here’s the catch:
AI agents don’t remember your suggestions — they react to context.
Unless you keep repeating your style guide every few prompts, it fades. You’re left copy-pasting reminders over and over, and even then, the agent might prioritize code patterns it’s seen more often on GitHub over your personal taste.
âś… The Real Fix: Let ESLint Speak For You
What actually worked was this:
I created a strict, opinionated ESLint config that embodied my coding style.
Not just “use semi-colons” — I went all-in:
- Custom rules
- Plugin overrides
- Import ordering
- JSX formatting
- Naming conventions
Once this config was active in my codebase, something amazing happened:
- The agent started writing code that fit.
- When it didn’t, the lint errors showed up — and the agent fixed them instantly.
- I stopped explaining. The config did the talking.
Because most AI agents inside editors like VSCode see the same lint errors you do. They adjust their output in real-time based on what they see in your codebase.
đź§ Linting = Real-Time Reinforcement Learning
Every lint error becomes a feedback signal. It’s like reinforcement learning — but inside your editor.
Instead of telling the agent “please don’t use any
,” your linter throws a red squiggle. The agent fixes it. Done.
The more you enforce style with tooling, the faster the agent adapts. No more alien code. No more babysitting.
🛠️ Pro Tips
1. Don’t be shy — be strict
Go beyond Prettier defaults. Add ESLint rules that actually reflect how you think.
pnpm i -D eslint eslint-config-98kb
Then build your eslint.config.js:
// eslint.config.js
import {defineConfig} from 'eslint/config';
import {recommended, strict, typescript} from 'eslint-config-98kb';
export default defineConfig(
recommended,
strict,
typescript,
);
2. Enable auto-fix on save
Your agent will see the output clean up as it works — another feedback loop.
3. Use prompts for logic, not style
Don’t waste tokens on stylistic instructions. Let the config guide the tone.
✨ Conclusion
Coding agents don’t care what you say.
They care what your codebase enforces.
So stop asking them nicely to follow your style.
Tell them with tooling.
Linting isn’t just for humans anymore — it’s how you speak to your AI pair.
đź’¬ Your Turn
Have you tried teaching your coding agent to match your style?
Did you go the linter route — or something else?
Would love to hear your take 👇
Top comments (0)