Configuring rules to prevent AI from breaking your project
Set priorities, safety red lines, and modification scopes for AI coding assistants by configuring rule files like AGENTS.md or .cursor/rules/*.mdc, preventing unauthorized changes, hardcoded secrets, broken tests, and endless error loops.
DEV.to #cursor
CursorClaude CodeCopilotWindsurfCodexZedAmp
Added 2026-11-01 · originally published Sat, 31 Oct 2026 18:49:50 +0000
Key points
- Set clear rule priorities for the AI: when rules conflict, safety red lines take highest precedence, followed by the current task, tech stack standards, and working style.
- Establish concrete security rules: strictly forbid placing keys behind public prefixes (such as NEXT_PUBLIC_, VITE_, etc.), and private data interfaces must verify caller permissions to prevent unauthorized access.
- Limit high-risk autonomous operations by the AI: executing rm -rf, git force push, database resets, skipping or disabling tests, and installing new dependencies without permission are all prohibited.
- Restrict the scope of modifications to prevent things from getting out of hand: stay within the task scope, do not rename or beautify unrelated code, make only minimal changes, and never rewrite working files wholesale.
- Introduce a debugging circuit breaker: after two failed fix attempts, the AI must stop trying and summarize the next two options to prevent getting trapped in an endless error loop.
Pitfalls
- The AI is asked for a small fix and ends up "tidying up" four other unrelated files.
- API keys are hardcoded in components or placed in NEXT_PUBLIC_ prefix variables that anyone can read.
- A new API route works, but fails to check record ownership, leading to unauthorized access to other people's data (changing an ID lets you read anyone's data).
- The AI tries five times to fix the same broken fix, making the situation worse every time.
- "Fixing" tests by simply skipping them.
.cursorrules
- Rule conflict priority: 1. Safety red lines 2. Current task 3. Tech stack standards 4. Working style. - Any private data operations must verify caller identity and record ownership permissions on the server side (return 403 if unauthorized, 404 if record does not exist). - Strictly prohibited from executing destructive commands without authorization (such as rm -rf, git reset --hard, git push --force, dropping tables, etc.). - Strictly prohibited from disabling, skipping, or relaxing tests, lint rules, or type checks without authorization. - Do not install new dependencies without permission; verify the exact package name before installing. - Debugging restriction: Must stop and report options after 2 consecutive failed repair attempts.
Copy-ready prompt
Please follow these rules: 1. Strictly control the scope of modifications. Only modify code directly related to [current feature or fix], and do not refactor, rename, or "beautify" unrelated files. 2. Keep changes minimal. Completely rewriting working files is strictly prohibited. 3. Do not hardcode any API keys or sensitive information, and never place secrets in public prefixes such as NEXT_PUBLIC_ or VITE_. 4. If you encounter an error, you must stop immediately after two consecutive failed fix attempts and summarize two optional next steps for me. Do not blindly keep trying. 5. When performing database queries or private data access, you must verify the current user's identity and their access permissions to the record on the server side.
#AI Frontend Dev#Pitfalls and Tips#Cursor Config#Security Guidelines
Related techniques
Summarized by AI from the original source - refer to the original post for details. Copyright belongs to the original author.