How to Tell an AI Coding Agent What Not to Touch

The working pattern for AI coding agent non-goals is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running AI coding agent non-goals as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

All three, in that order, and you stop as soon as the boundary holds. A prompt non-goal covers this one task. A rule covers the convention. A hook covers the thing that must not happen even when the model has talked itself into a good reason.

The rule layer is an .mdc file under .cursor/rules/ with a glob in the frontmatter. A rule scoped to **/*.tsx with alwaysApply: false costs nothing until you open a matching file, which is what makes file-scoped boundaries cheap enough to keep several of.

What separates those two layers from the third is enforcement. Rules are instructions the model attempts to follow, so they move the odds without setting a floor. A hook is a script you write and check into the repo, it runs at fixed points in the agent loop including before a file read and before a shell command, and it returns allow or deny. Same input, same answer, every run. That is the difference between a boundary and a strong hint, and it is why anything load-bearing ends up in the third layer.

I used to think the trigger for escalating was how dangerous the file was. It is closer to how often you repeat yourself. The second time you type the same non-goal into a prompt it wants to be a rule, and a rule you have watched the agent walk straight past is telling you it needed to be a hook.

Not reliably. .cursorignore keeps files out of semantic search, out of agent file reading and out of context selection, which is genuinely useful. It is a convenience feature rather than a boundary, though: someone can still open an ignored file by hand, and terminal and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. tools cannot honor it.

So the failure here is a belief rather than a bug. You add a path, you watch it disappear from context, and you file the tree as fenced. Then an agent with shell access reads it through a command, because the shell has no idea the editor was told to look away.

For anything that genuinely must not be read, the documented answer is file system permissions or encryption, with a hook to scan or block access on top. Keep .cursorignore for what it is good at, which is holding secrets and noise out of the context you are paying for.

Every other answer gets slightly worse. A rule carrying one instruction plus three hundred others spreads the model's attention across all of it, and that attention is finite in roughly the way a person's is.

Output quality comes down to the model you pick and the context you supply, weighted something like 60/40 to 70/30 toward the model. Context is the minority share and it is the share you control, so filling it with prohibitions that have nothing to do with today's task is a poor trade. The rules Cursor itself ships are often eight lines long.

Which is why the habit that works is reactive. Add the boundary when you catch the agent crossing it, not in anticipation of everything it could conceivably do. And leave the linter alone: deterministic tooling already covers deterministic rules better than a paragraph of English will.

Team size changes who owns the list. On a small team it is two or three scoped rules plus a line in the prompt, and that is proportionate to the risk. In an org the boundaries that matter get deployed through MDM, where an enterprise hook takes precedence over whatever a developer has configured locally, and configs get scoped per group so the design team and the security team are not reading each other's prohibitions. That last part is underrated, I think, because a prohibition aimed at somebody else is just noise in your context window.