Why Your AI Coding Agent Keeps Ignoring Instructions

Your AI coding agent skipped the instruction again. You told it to use snake_case for database columns, or never touch the migrations folder directly, or write a test before committing, and a few turns later it's doing whatever it wants. The instinct is to repeat yourself louder, add exclamation points, or write "IMPORTANT" in all caps. None of that fixes anything, because "ignoring" is almost never the real problem. The agent has no memory or will of its own between turns. It's either lost the instruction from its active context, is still following an earlier instruction you never withdrew, was given something it couldn't actually check itself against, or is defaulting to whatever pattern shows up most often in its training data. Each of those needs a different fix, and none of them is fixed by volume.

It's not defiance, it's one of four failure modes

An AI coding agent doesn't hold a running mental model of your preferences the way a human collaborator does. Every response it generates is built fresh from whatever text is currently in its context window: your system prompt, the conversation so far, the files it has read, and any project instructions file it's been given. If our explainer on what an AI coding agent actually is didn't already make this clear: there's no persistent self that remembers you told it something three days ago, or even thirty turns ago, unless that instruction is still physically present in what it's reading right now.

That single fact explains almost every case of an agent ignoring you. The four causes below cover the vast majority of them, and each one has a distinct, testable fix rather than a vague plea to pay attention.

Cause 1: The instruction scrolled out of the context window

Long sessions fill up. As a conversation runs for dozens of turns, older messages get pushed toward the edge of the context window, and many tools summarize or truncate early context to make room for new work. An instruction you gave once, early on, and never repeated is a prime candidate for getting dropped or compressed away, especially if it was a side comment rather than part of the main task.

Before: on turn 4 of a session that runs to turn 70, you say: "From now on every new API route needs a zod schema validating the request body." By turn 50 the agent is writing routes with no validation, not because it disagrees, but because that sentence is no longer anywhere in what it's reading.

After: move standing rules out of the conversation and into whatever persistent project file your tool re-reads every session, a CLAUDE.md, an agent config, a rules file. Instead of a one-time chat message, write this into that file:

API routes: every new API route must validate its request body with a zod schema before touching the database. Before writing a handler, check whether a schema for this shape already exists in schemas/.

A rule that lives in a file the agent reloads each session survives the scroll. A rule that lives only in message history doesn't.

Cause 2: An earlier instruction was never withdrawn, so it's still in effect

Instructions in a chat session accumulate, they don't expire. If you told the agent something early on and later gave a conflicting instruction without explicitly canceling the first one, the agent may try to honor both, or fall back to whichever one feels more load-bearing in context, which is often the older, more general one.

Before: turn 6, working on a rough prototype, you say: "Don't worry about error handling for now, just get the demo working." Turn 45, now building the real payment flow, you say: "Add proper error handling to the payment flow." The agent wraps the one function you pointed at, but the rest of the code stays unguarded, because your earlier instruction to skip error handling was never revoked and still technically applies to everything else.

After: "Ignore what I said earlier about skipping error handling, that was only for the throwaway demo scaffolding. Starting now, every function that touches the database or an external API needs proper error handling, not just the payment flow." Naming the old instruction and explicitly killing it does more work than any number of new instructions layered on top.

Cause 3: The instruction wasn't something the agent could verify

Agents optimize toward instructions they can check themselves against. "Make it secure" or "follow best practices" or "clean this up" gives the model nothing to test, so it does something plausible and calls it done, which reads as ignoring you when the result doesn't match what you had in mind.

Before: "Make sure the API is secure."

After: "Add rate limiting of 100 requests per minute per IP to every public route. Validate all request bodies with zod before any database call. Reject requests to protected routes that don't include a valid Authorization header. Run npm run test:security and paste me the output before telling me you're done."

The second version gives the agent something to check its own work against, which is the difference between an instruction and a wish.

Cause 4: Your ask was unusual, and the agent defaulted to the common pattern

Coding agents are pulled toward whatever pattern appears most often in training data, and that pull is strong enough to override an instruction that only says what not to do. A bare negative instruction competes against thousands of examples of the default approach, and it usually loses unless you also show the agent what to do instead.

Before: "Don't use an ORM, write raw SQL queries." Two features later, the agent adds an ORM to a new file anyway, not out of spite, but because raw SQL without an ORM is the unusual choice and the model reverts to the statistically common one under pressure. This shows up constantly in schema and migration work too, which is worth reading if you're fighting an agent's default instincts there.

After: "Do not introduce an ORM anywhere in this repo, no Prisma, Drizzle, or TypeORM. Write parameterized SQL using the pg client directly. Use db/queries/users.ts as the template for every new query file, same structure, same error handling." Giving the agent a concrete file to pattern-match against beats a rule stated only in the negative, because now there's a positive example competing with the training-data default instead of just a prohibition.

A fast way to diagnose it while it's happening

When an agent seems to ignore you mid-session, it's faster to diagnose than to repeat yourself:

• Ask it to restate the constraints it thinks currently apply. If your instruction isn't in the list, it scrolled out of context, cause 1.

• Scan back through the session for anything you said earlier that conflicts and was never explicitly canceled, cause 2.

• Ask how it would verify the instruction was followed. If it can't answer concretely, the instruction was too vague to begin with, cause 3.

• Check whether what you asked for is a common pattern or an unusual one, and whether you gave it something concrete to copy rather than just something to avoid, cause 4.

If the same wrong fix keeps coming back turn after turn rather than a one-off slip, that's a related but distinct problem, more like an agent stuck in a loop than one that's forgotten a rule, and worth troubleshooting differently. Choosing among the growing set of AI coding tools matters here too. Some handle long-context persistence and project rule files much better than others, and that difference shows up exactly in how often you hit these four failure modes.

Frequently asked questions

Why does my AI coding agent keep forgetting instructions in long sessions?

Because most tools have a finite context window, and as a session grows, older messages get pushed out or summarized to make room for new ones. An instruction given once early on and never repeated is likely to be dropped first. Moving standing rules into a persistent project file instead of a chat message fixes this.

Should I repeat instructions to an AI coding agent?

For anything you want enforced across an entire session, yes, but repeating it in chat is a workaround, not a fix. Better to put durable rules in a project instructions file the agent reloads every turn, so you're not relying on it staying in the conversation history.

What's the best place to put persistent rules for an AI coding agent?

Whatever file your specific tool treats as always-loaded context, commonly a CLAUDE.md, an agent rules file, or project-level config. Rules stated there survive context trimming in a way that a message from turn 4 of an 80-turn session does not.

Why does my AI coding agent revert to old patterns after I explicitly said not to?

A negative instruction alone competes against a much larger number of training examples showing the common approach, and often loses. Pairing the prohibition with a concrete positive example, an existing file to pattern-match against, gives the agent something to copy instead of just something to avoid.

How do I know if my instruction to an AI coding agent was too vague?

Ask it how it would verify the instruction was satisfied. If the answer is fuzzy or it can't point to a specific check, test, or condition, rewrite the instruction as something with a concrete, checkable outcome.