Setting Coding Rules for AI Assistants in Your Dev Workflow

Last quarter I let an AI coding assistant loose on a legacy PHP codebase without any guardrails. Within twenty minutes it had "helpfully" refactored a working payment module, invented three functions that didn't exist, and silently swapped a battle-tested date library for one that hadn't been updated since 2019. The code compiled. The tests I didn't have never caught it. That mess took a full afternoon to untangle.

Here's the uncomfortable stat: a 2024 GitHub study found that developers accept roughly 30% of AI-suggested code without meaningful review, and separate research from Stanford showed that engineers using AI assistants often write less secure code while feeling more confident about it. The tool isn't the problem. The absence of rules is. An AI assistant with no boundaries is a very fast intern who never sleeps, never asks permission, and never remembers your team's conventions.

This article is about fixing that. You'll learn how to write concrete ai coding assistant rules that actually change model behavior, where to put them so tools like Cursor, Copilot, and Claude Code respect them, and how to build a review workflow that catches the 30% before it ships. We'll walk through a real before/after, compare the major rule formats, and end with the questions people actually type into Google.

Key Takeaways

• Write rules as constraints, not vibes. "Prefer clean code" does nothing. "Never add a dependency without listing it in the PR description" works.
• Put rules where the tool reads them — .cursorrules, CLAUDE.md, or a shared AGENTS.md — not buried in a wiki no model can see.
• Scope permissions tightly. An assistant should never touch secrets, CI config, or production credentials without explicit approval.
• Require the assistant to explain diffs before you merge, especially dependency changes and deletions.
• Version your rules like code. They drift, they need review, and they belong in the repo.
• Trust nothing you can't verify. Every AI change needs the same scrutiny you'd give a stranger's pull request.

Why AI Coding Assistants Need Explicit Rules

Modern assistants are probabilistic. They predict plausible code, not correct code. Left unguided, they optimize for "looks like something a developer would write," which is exactly how you end up with hallucinated APIs and subtly wrong logic.

Rules do three things. They constrain the solution space so the model stops inventing things. They encode your team's context so suggestions match your actual stack. And they create an audit trail, so when something breaks you know what the assistant was told to do.

There's also a security dimension people underrate. An assistant that can read your entire repo can read your .env file, your deploy scripts, and any hardcoded keys you forgot about. If it then pastes a snippet into a public chat or a logging service, you've leaked credentials. This is the same class of problem I covered in our guide on how to safely give AI agents access without sharing passwords, and it applies double when the agent can write files.

The three failure modes rules prevent

• Hallucination: made-up functions, non-existent config options, imaginary CLI flags.
• Scope creep: you ask for a bug fix, it rewrites four files and reformats everything.
• Silent risk: new dependencies, weakened validation, or removed security checks that no one flagged.

What Good AI Coding Assistant Rules Actually Look Like

The single biggest mistake I see is writing rules like a corporate values poster. Vague aspirations don't survive contact with a language model. Specific, testable constraints do.

Compare these two rule sets aimed at the exact same goal:

Weak rules (ignored in practice)

• Write clean, maintainable code.
• Follow best practices.
• Be careful with dependencies.
• Keep security in mind.

Strong rules (change behavior)

• Use TypeScript strict mode. Never use any; use unknown and narrow it.
• Do not add npm packages. If a package is genuinely needed, stop and ask, and explain why the standard library can't do it.
• Every function that touches user input must validate it with the existing zod schemas in /src/schemas.
• Never edit files in /config, /.github, or anything named *.env*.
• When you delete code, list every deleted block in your summary and say why.

The difference is that a model can actually follow the second set. Each rule maps to an observable behavior. That's the standard to hold yourself to: if you can't tell whether the assistant obeyed a rule by reading the diff, the rule is too vague.

Where to Put Your Rules So the Assistant Reads Them

Rules only work if the tool ingests them. Each assistant has its own convention, and getting this wrong is why teams say "I wrote rules but it ignores them." It never saw them.

Tool	Rule file	Scope	Auto-loaded?
Cursor	.cursorrules or .cursor/rules/*.mdc	Per project	Yes
Claude Code	CLAUDE.md	Repo + subdirectories	Yes
GitHub Copilot	.github/copilot-instructions.md	Repo	Yes (in supported IDEs)
Cross-tool standard	AGENTS.md	Repo	Growing support
Windsurf	.windsurfrules	Per project	Yes

My advice: keep a single source of truth. I write the canonical rules in AGENTS.md at the repo root, then symlink or reference it from the tool-specific files. On Windows that symlink step is genuinely annoying to do by hand, which is one reason I keep a tool like Windows Symlink Creator Pro around instead of fighting mklink syntax every time. On Unix it's a one-line ln -s.

For teams that share snippets and rule templates across projects, having a fast, private way to store and paste them matters more than you'd think. I keep my standard rule blocks in LionPaste so I can drop a vetted AGENTS.md into a new repo in seconds rather than copy-pasting from an old project and forgetting half of it.

A Worked Example: Before and After Rules

Let me make this concrete. I ran the same task twice on a small Node.js API: "Add rate limiting to the login endpoint."

Run 1: No rules

The assistant:

• Added express-rate-limit (a new dependency, fine) plus redis and ioredis (unnecessary for our scale).
• Refactored the auth middleware, changing 3 unrelated files.
• Hardcoded a Redis connection string with a placeholder password directly in the source.
• Removed an existing input length check "for simplicity."

Net result: 4 files changed, 2 useless dependencies, 1 security regression, and a hardcoded credential pattern that would've been copied forward. Cleanup: ~45 minutes.

Run 2: With rules in place

I added an AGENTS.md with the strong rules from earlier, plus: "Rate limiting must be in-memory unless the task explicitly mentions Redis. Do not modify unrelated files. Never remove existing validation."

This time the assistant:

• Added only express-rate-limit.
• Touched exactly 1 file: the login route.
• Kept every existing check intact.
• Listed the new dependency in its summary and asked whether I wanted a distributed store "for multi-instance deployments."

Net result: 1 file changed, 0 regressions, 0 cleanup. Same model, same prompt. The only variable was the rules file. That is the entire argument for this article in one experiment.

Building a Review Workflow Around AI Changes

Rules reduce bad output. They don't eliminate it. You still need a review layer, and the good news is you can automate most of it.

1. Force a diff summary. Add a rule requiring the assistant to output a plain-English summary of every change, grouped by file. If the summary and the diff disagree, that's your first red flag.
2. Flag every new dependency. New packages are the highest-risk change an assistant makes. Vet each one the way you'd vet any third-party code. Our walkthrough on how to verify open-source software before adding it to your stack is the checklist I actually use.
3. Never let it touch secrets. Add *.env*, credential stores, and CI files to a hard "do not edit" list, and back it with .gitignore and pre-commit hooks so a mistake can't reach the remote.
4. Run the same tests you'd run for a human PR. Lint, type-check, unit tests, and a security scan. AI code is not a special category that skips CI.
5. Review deletions harder than additions. Assistants love to "simplify" by removing edge-case handling. Deleted validation is where bugs hide.
6. Keep a human in the merge. Auto-generated, human-approved. No auto-merge on assistant branches, ever.

If your project is a WordPress site or plugin, add a plugin-specific gate too. An assistant editing plugin code should never bypass update verification. The process in how to verify a WordPress plugin update before installing it applies whether a human or an AI made the change, and hardened setups pair well with something like eDarpan WordPress ProtectionCover image: Where the Magic Happens by George P. Macklin, licensed under BY-SA 2.0 via Openverse.