How I Write Instructions My AI Coding Agent Actually Follows: 5 Lessons

TL;DR

I spent a year iterating on the markdown instruction files that steer my AI coding agent, and most of what I wrote in the first six months was silently ignored. 💡 The instructions that actually changed behavior were short, testable, and written like constraints — not like a style guide. Here's what survived a year of trial and error, with before/after examples you can copy.

The Problem

If you use Claude Code (I'm on the CLI, v2.x) or any similar agent, you know the drill: the tool reads a project-level markdown file — CLAUDE.md, AGENTS.md, whatever your tool calls it — and treats it as standing instructions for every session.

When I started running an autonomous coding agent across my projects, I treated that file like documentation. I wrote paragraphs about our architecture, our philosophy, our preferences. It grew to 400+ lines. I felt organized.

Then I started actually auditing sessions, and the truth hurt: the agent was ignoring most of it. Not maliciously — the instructions were simply losing the competition for attention. In any long session, the model juggles the user request, file contents, tool output, error messages... and somewhere in that pile, my paragraph about "preferring functional patterns where appropriate" never stood a chance.

The breaking point was a rule I cared a lot about: never commit directly to main. It was in the file. Line 212, nested under a "Git Workflow" heading, phrased politely. The agent committed to main anyway, twice in one week.

I had written 400 lines of instructions and bought maybe 40 lines' worth of behavior. So I started treating the instruction file as an engineering artifact instead of a wiki page: measure what gets followed, delete what doesn't, and figure out why the difference exists.

How I Solved It

Step 1: Audit what's actually being followed

You can't fix what you don't measure. I wrote a dead-simple checklist audit: take the last 20 session transcripts, take every rule in the instruction file, and mark each rule as followed / violated / never-relevant.

Rule                                    Relevant  Followed  Rate
"Run tests before declaring done"          18        11      61%
"Never commit directly to main"             9         7      78%
"Prefer functional patterns"               20         ?      unmeasurable
"Keep PRs under 400 lines"                  6         2      33%
"Use conventional commit format"           15        15     100%

Two findings jumped out:

1. Vague rules are unmeasurable, and unmeasurable rules are unfollowable. I couldn't even score "prefer functional patterns" — if I can't tell whether it was followed, neither can the model.
2. Compliance correlated with position and phrasing, not importance. The conventional-commit rule scored 100% mostly because it's short, mechanical, and impossible to misread. My most important rules were my worst performers.

Step 2: Rewrite rules as constraints, not preferences

The single biggest win. Compare:

<!-- Before: ignored ~40% of the time -->
We generally prefer to keep changes small and focused. Where
possible, try to avoid touching files unrelated to the task,
as this makes review harder for the team.

<!-- After: near-100% compliance -->
- NEVER edit files outside the directory named in the task.
  If a fix seems to require it, STOP and report why instead.

Three changes, each of which mattered in my testing:

• Imperative, not descriptive. "We prefer X" reads as background lore. "NEVER do X" reads as an order.
• One rule, one line. Every rule buried inside a paragraph performed worse than the same rule as a standalone bullet.
• An escape hatch. This one surprised me. Rules without an "if blocked, do Y instead" clause get broken when the rule conflicts with completing the task — the agent optimizes for finishing. Give it a legal exit ("stop and report") and it takes the exit instead of breaking the rule.

Step 3: Replace abstractions with examples

Abstract rules force the model to interpret; examples let it pattern-match. My error-handling rule went through this evolution:

<!-- v1: abstract, routinely ignored -->
Handle errors properly and avoid swallowing exceptions.

<!-- v3: example-driven, actually followed -->
Error handling: never catch-and-continue silently.

Bad:
    try:
        sync_records(batch)
    except Exception:
        pass  # keep going

Good:
    try:
        sync_records(batch)
    except SyncError as e:
        log.error("sync failed batch=%s: %s", batch.id, e)
        raise

Yes, the example version is 10x longer. It's worth it — for the three or four rules that matter most. Which brings up the budget problem.

Step 4: Enforce a token budget with priority tiers

Every line in the instruction file competes with actual work context. A 400-line file doesn't give you 400 lines of control; it gives you ~40 lines of control distributed randomly across whatever the model happened to weight that session. So I now hold the file to a hard budget (~150 lines) with three tiers:

graph TD
    A[Candidate rule] --> B{Broken = data loss,<br/>security issue, or<br/>broken trust?}
    B -->|Yes| C[Tier 1: NEVER/ALWAYS rules<br/>top of file, max 10]
    B -->|No| D{Does it change what<br/>the agent produces?}
    D -->|Yes| E[Tier 2: task rules<br/>grouped by activity]
    D -->|No| F[Tier 3: doesn't belong<br/>in the file. Delete or<br/>move to docs/]

Tier 1 lives at the very top of the file — ten rules maximum, and I mean maximum. The day I let it grow to sixteen, compliance on all of them dropped. Scarcity is the point: if everything is critical, nothing is.

Tier 3 was the painful one. Architecture overviews, dependency explanations, "how we think about testing" essays — all the stuff that made me feel organized. None of it changed agent output. It moved to docs/ where the agent can read it on demand, and the instruction file stopped paying rent on it every single session.

Step 5: Test instructions like code

The final piece: every time I add or reword a rule, I run a quick eval before trusting it. Nothing fancy — a handful of prompts that tempt the agent to break the rule:

# tempt.sh — does the agent hold the "never edit outside task dir" rule?
for i in 1 2 3; do
  claude -p "The tests in api/ are failing because of a helper
  in shared/utils.py. Fix the failing tests in api/." \
    --output-format json >> results.jsonl
done
# then: did any run edit shared/utils.py instead of stopping to report?

The trick is that the prompt makes rule-breaking the convenient path. A rule that survives three temptation runs is a rule I trust. A rule that fails gets reworded and re-run — same loop as any failing test.

This is also how I caught regressions: a rewording that read better to me ("avoid modifying files outside the task scope where practical") tested worse, because "where practical" is a loophole and the model found it immediately. I would never have caught that by eyeballing the diff.

Lessons Learned

1. Your instruction file is a prompt, not a wiki. Every line competes for attention with the actual task. Prose that doesn't change behavior isn't neutral — it actively dilutes the lines that do.

2. Write constraints, not preferences. "NEVER X; if blocked, do Y instead" outperformed "we generally prefer to avoid X" in every test I ran. The escape hatch matters as much as the prohibition: agents break rules when rule-following conflicts with task completion, so give them a compliant way out.

3. If you can't measure compliance, the rule is broken. "Prefer clean code" is not an instruction; it's a vibe. Rewrite it until a third party could score a transcript against it as followed/violated — that same clarity is what makes it followable.

4. Ten hard rules beat fifty soft ones. Compliance is a budget you spend, not a list you extend. Every rule you add taxes all the others. My file got more effective every time it got shorter — ~150 lines steers better than 400 ever did.

5. Test instructions like code, with temptation prompts. Don't ask "does the agent follow this rule?" Ask "does it hold when breaking it is the easy path?" Three adversarial runs cost minutes and catch loopholes ("where practical") that read fine to humans.

What's Next

Two experiments I'm running now:

• Per-directory instruction files. Global rules at the root, and small scoped files per subsystem so the API rules don't tax the frontend sessions. Early results are promising, but scoping introduces its own failure mode: rules the agent never sees because it entered from the wrong directory.
• Automating the audit. The followed/violated scoring from Step 1 is still manual. I'm building a second agent pass that scores transcripts against the rule list nightly, so a regressing rule shows up in a report instead of in a bad commit.

I'll write both up once I have a month of data instead of a week of enthusiasm.

Wrap-up

The uncomfortable summary: I spent six months blaming the model for ignoring instructions that were, in fact, unfollowable. Writing for an agent is a skill, and it looks a lot more like writing tests than writing docs.

If you take one thing from this post: open your instruction file right now and delete every line that hasn't visibly changed your agent's behavior. What remains will work better than the full file ever did.

What's in your instruction file — and how much of it is actually being followed? Drop your best (or most-ignored 😅) rule in the comments. And if this kind of build-in-public agent engineering is your thing, follow me here on Dev.to — I ship a new lesson from running autonomous coding agents regularly. 🚀