The Age of AI: Why Your Coding Agent Ignores Your Style Rules

Everyone's writing code with AI agents now. Claude, Copilot, Cursor, whatever your stack — the productivity is real. But if you've been at this for more than a few weeks, you've hit the same wall: the coding style, structure, and patterns your agent produces are inconsistent, even when you've spelled everything out in a CLAUDE.md or equivalent instruction file.

You wrote the rules. The agent still breaks them. Here's why, and here's what actually fixes it.

Why instruction files fail

The rules in your CLAUDE.md are advisory. They sit in context as background guidance, competing with everything else the model is juggling. And they lose that competition constantly, for one simple reason: the immediate prompt outweighs standing instructions.

When you type "add a login endpoint," that's loud, specific, and right in front of the model. "No semicolons" or "no vertical alignment" is quiet, generic, and buried twenty rules deep in a file the model read once at the start of the session. Given a choice between the loud, specific thing and the quiet, buried thing, the model follows the loud thing. Every time.

This isn't a bug you can prompt your way out of. It's just how attention and prioritization work when instructions compete.

Skills have the same problem

Once people notice instruction files aren't holding, a common next move is to reach for "skills" — structured, reusable instruction sets the agent can invoke. It feels like an upgrade. It isn't.

A skill is still advisory. It's a second document that can be ignored the exact same way the first one was. You haven't changed the failure mode, you've just added another artifact that competes for the same limited attention as the loud, immediate prompt. If a CLAUDE.md rule can get overridden, a skill built on the same trust model can too.

The "follow the nearest file" trap

Another common workaround: instruct the agent to "follow the style of the nearest existing file" when starting new work. This is reasonable in general — codebases should be internally consistent, and this is a natural pointer toward that.

The problem shows up the second time you generate code. If the agent got it wrong the first time and produced inconsistent code, that inconsistent file is now sitting in your codebase. Point the agent at "the nearest file" again, and you're using the wrong example as the teacher. Each generation compounds the drift instead of correcting it. The problem doesn't stay the same size — it grows.

The real fix: deterministic tooling

Here's the underlying insight: most of what people put in style rules — semicolons, spacing around =, no vertical alignment, brace placement — isn't a judgment call. It's exactly the kind of thing a formatter or linter already exists to enforce.

Set up ESLint + Prettier, or Biome if you want one faster tool instead of two, with a config that encodes your actual rules:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "printWidth": 80
}

{
  "extends": ["eslint:recommended"],
  "rules": {
    "no-multi-spaces": "error",
    "brace-style": ["error", "1tbs"],
    "semi": ["error", "always"]
  }
}

Once this is in place, it doesn't matter what the model "remembers" from your instruction file. The code either gets mechanically rewritten to conform, or the lint step fails. You've converted a hope into a hard constraint — physics instead of a polite request.

Automate it so you never have to review for it

A config sitting in your repo still only enforces conformance if someone runs it. The next step is to remove that dependency on human follow-through entirely. If your agent tooling supports hooks, wire up a PostToolUse hook that runs on every Edit/Write operation and fires the formatter and lint --fix automatically:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $CLAUDE_FILE_PATH && npx eslint --fix $CLAUDE_FILE_PATH"
          }
        ]
      }
    ]
  }
}

Now conformance happens on every single change, without you reviewing anything, and the model can't skip it. This is the part that directly solves the "I don't have time to review every diff" problem — you're not reviewing for style anymore, because style is no longer negotiable.

What's left for skills and instruction files

None of this means instruction files or skills are useless — it means you've been asking them to do a job they were never suited for. Mechanical rules belong in a linter. What's left over is judgment: is this the right architectural pattern for this part of the codebase, or is it spaghetti that happens to run? Is this consistent with how the rest of the system is built, not just the nearest file?

A linter can't answer that. This is where a skill, or better, an automated review subagent that diffs new code against your actual conventions after a task completes, earns its place. It's a smaller job than people usually assign to instruction files — maybe 20% of what they were being asked to cover — but it's the part that genuinely requires judgment instead of enforcement.

Conclusion

Stop asking advisory text to do deterministic work. Split the problem: mechanical style rules go into a formatter/linter, wired up to run automatically on every edit. Judgment calls — architecture, pattern consistency, "does this fit" — are what you keep a skill or review step around for. Once you draw that line, the inconsistency problem mostly disappears, not because the model got better at remembering, but because it no longer has the option to forget.

Daily Chronicle