Why your AI agent ignores the rules you wrote for it

A while back I wrote one line into the instructions file my agents read at the start of every task: never put a model or vendor name in the blog's titles, descriptions, or metadata. One sentence. Unambiguous. The agent read that file every single session. And then one morning I caught a finished draft with a vendor name sitting right there in the description field, already staged, heading for the commit.

That taught me something I now say to every vibe coder hitting the same wall. When an agent ignores a rule you wrote, the fix is almost never another rule. It is moving that rule out of prose and into something that runs whether or not the model was paying attention. A rules file proposes. A gate disposes.

why does my agent ignore the rules i wrote?

Start with why it happens, because the mechanism points straight at the fix. A rules file is prose, and prose is advisory. The model does not execute your instructions the way a compiler executes code. It reads them as one more input, weighed against the actual task, the file it is editing, the last thing you typed, and the ten thousand tokens of context it is already holding. Your rule is in there competing with all of it, and sometimes it loses.

It loses more as the file grows, and this is the part people get backwards. Adding a rule feels like tightening control. Past a certain length, in my experience somewhere around eighty lines, another rule does not raise compliance. It lowers it, evenly, across everything. The instruction you cannot afford to have ignored is now sitting on line one hundred forty between two preferences that barely register, and the model gives all three roughly equal weight. Call it the attention ceiling. A longer rules file is not a stricter one, it is a more diluted one. That is the quiet tax of vibe coding at any real scale: the tools do what you say right up until the saying stops scaling.

the fix is fewer rules plus a gate

So I stopped trying to win the attention contest for the handful of rules that truly cannot ship. I moved them out of the file entirely and into a check that does not depend on attention at all.

For me that check is a pre-commit hook. It is a small script that runs automatically every time I try to commit, before anything lands. It greps the staged files for the specific things that must never reach production, a vendor name in a title, an em dash in the prose, a personal name anywhere, and if it finds one it exits with an error and the commit fails. No negotiation, no attention budget, no I will remember next time. The bad change physically cannot land until the violation is gone.

The morning I caught that vendor name in the description, I did not write a sterner paragraph in the rules file. I wrote six lines of grep. The next time an agent drifted toward the same mistake, the commit just failed, with the offending file and line number printed right there in the terminal. The rule went from something I hoped the model would honor to something the system refused to let through.

the same rule lives in four places now

The prose rule did not get deleted. It got demoted from doing the whole job alone to being the first of four layers, and that layering is the actual pattern worth stealing.

Layer one is still the instruction in the agent's file. It proposes, it sets intent, it catches the easy ninety percent at generation time. Layer two is a drafting skill that loads on every writing task and reinforces the same constraint while the text is being produced, closer to the moment of the mistake. Layer three is the pre-commit hook, the mechanical gate that runs at the boundary and refuses the commit. Layer four is an audit that walks the whole published corpus after the fact and flags anything that slipped past the first three. A voice spec I wrote earlier is one of those upstream layers, and the hook is the one that actually stops the commit when everything above it misses.

None of those layers trusts the one before it to be perfect. That is the entire idea. A rule that only lives in prose is a suggestion. A rule that also lives in a gate is a constraint. When you catch yourself writing the same instruction a third time in bigger font, that is the signal to stop writing rules and start enforcing one.

what breaks with this approach

The failure mode is real and worth naming, because it kills the whole system quietly. It is over-gating. The pre-commit hook is satisfying the first time it catches something, so the temptation is to push every preference into it, every style nit, every maybe-someday. Do that and the commit step turns into a wall of false positives. You start reaching for the bypass flag just to get work done, and once bypassing is a habit the gate is decorative. A gate that cries wolf gets ignored in exactly the way a prose rule does.

So the discipline is restraint about what earns a gate. The hook is reserved for true non-negotiables, the short list of things that must never ship under any circumstance and that you can express as a mechanical check. Genuine judgment calls stay in the advisory layer, where a human or a model is supposed to weigh them. The test I use is simple: if I can write a grep for it and I never want to see it reach production, it belongs in the gate. If it needs judgment, it stays prose. This is the spec-first instinct aimed sideways at rules, the same move that puts the contract in a file that leads the build, pointed instead at the three things that must never leak.

questions that keep coming up

A few that come up whenever I describe this.

Does this just move the problem, since the hook is code and code can have bugs? A little, but not in a way that matters. The difference is that the hook runs deterministically on every commit and does not compete for attention. It runs or it does not, and you can test it once and then trust it. Prose gets re-weighed against everything else every single time. Moving a rule from prose to code trades a probabilistic failure you cannot debug for a deterministic one you can.

How do I decide what goes in prose versus the gate? Non-negotiables in the gate, judgment in prose. If you can write a mechanical check for it and you never want it in production, gate it. Everything that needs a person or a model to weigh context stays advisory, and that is most things.

What if I do not write code and cannot add a git hook? The principle still transfers, because the enforceable checkpoint beats the written request at every level. It might be a linter, a template that will not save without a required field filled in, a review step someone has to sign off, or a small script a non-coder runs on a folder. The move is the same one every time: take the thing that must not slip, and put it somewhere that checks instead of somewhere that merely asks.

If you are formalizing your own AI orchestration after the messy phase and want to compare notes on which rules can stay prose and which ones need a gate, /work-with-us.