When your AI agent keeps breaking your code
You ask the agent for one small change. It touches six files, the build goes red, and the next three attempts to fix it make things worse. This is the most common way AI-assisted projects get stuck, and it happens in Cursor, Claude Code, Copilot and Codex alike. The cause is rarely the model being "bad". It is usually a missing safety net and a request that left too much open. This guide covers what to do in the middle of a mess, and how to set things up so it happens less.
Why the agent keeps breaking things
- Big, vague requests. "Add user profiles" gives the agent hundreds of decisions to make on its own. Each wrong guess compounds.
- No way to check its own work. If the agent cannot run your tests, typecheck or build, it cannot tell that it broke something. It will say it is done anyway.
- Repeating the same fix. After a failed attempt the agent often tries a slight variation of it. Three variations later you have three layers of broken code.
- Stale or ignored instructions. A rules file that is too long, in the wrong place or in the wrong format may not be loaded at all.
- No restore point. If your last working version is not committed, every experiment risks it.
Step 1: make sure you can go back
Before any rescue attempt, commit what you have, even if it is broken:
git add -A && git commit -m "before rescue"If you do not use git, copy the whole folder first. Everything below assumes you can undo it. For future work, commit before each task and keep tasks small enough that a failed one costs you a single git restore.
Step 2: stop the loop
When an agent has failed at the same fix twice, asking for "the fix" a third time rarely works. Change the shape of the request instead. Ask for a report and forbid code changes until a hypothesis is confirmed. This prompt is the first rescue prompt in the Vibemast kit and is free to use:
Stop. Do not change any code.
You have tried to fix [PROBLEM] several times and it is still failing. Write a short report:
1. The exact error or wrong behavior, copied word for word.
2. Every fix you have tried so far and why each failed.
3. What you now know FOR CERTAIN (verified by running something) versus what you are ASSUMING.
4. Three different hypotheses, including at least one that contradicts your earlier assumptions.
5. For each hypothesis, a read-only check or tiny experiment that would confirm or kill it.
Then run the cheapest experiment and tell me the result. Make no fix until one hypothesis is confirmed.It works because it separates what the agent knows from what it assumes, and it makes the next step a cheap experiment rather than another edit.
Step 3: if it worked yesterday, find the change
"It was fine, now nothing works" is a search problem. Git already has the list of changes. Ask the agent to use git log and git diff between the last good point and now, to revert one change at a time on a throwaway branch, and to report the exact change that broke it before it applies any fix. You approve the fix; it does not apply it on its own.
Step 4: if the build is red, group the errors
After a long session you may have dozens of type errors. They usually come from one or two root causes: a renamed export, a wrong type, a version mismatch. Ask the agent to run the typecheck, group the errors by cause, and fix one group at a time while re-running the check. Set boundaries in the same prompt. The kit's version includes: no any, no @ts-ignore, no deleting code or tests to silence errors, and no new packages without telling you why.
Make it less likely next time
Give the agent a way to check its work
Put your exact test, lint and typecheck commands in your instruction file and tell the agent not to say a task is done until they have run. See our AGENTS.md example for a template.
Ask for a plan before code
For anything that touches more than one or two files, ask for a plan first and approve it. Claude Code and Cursor both have planning modes for this.
Keep rules short and loaded
If Cursor seems to ignore your rules, check the basics. Project rules must be .mdc files in .cursor/rules; a plain .md file there is ignored. Check that the rule type matches how you want it to load, and keep each file under 500 lines. Our guide to Cursor rules for Next.js and Supabase shows a working layout.
Remember that instructions are not enforcement
Claude Code's docs describe CLAUDE.md as context, not enforced configuration. The agent reads it and usually follows it, but nothing guarantees that. If something must never happen, such as reading .env or running a destructive command, use the tool's permission settings or hooks. Claude Code documents permissions.deny and hooks for this. Cursor has its own command approvals. Use rules for guidance and permissions for hard limits.
A short stop rule to add to your file
- If two attempts at the same fix fail, stop. Summarise what you tried
and ask me. Do not keep looping.
- Keep diffs small. Do not refactor or reformat code you were not asked to touch.
- Do not delete tests or loosen types to make errors go away.What the kit adds
The Vibemast Ship-It Kit has eight rescue prompts, each matched to a symptom: looping, "it worked yesterday", red build, an app nobody understands, a pile of copy-pasted fixes, a giant file, "works locally but not in production", and a clean restart that keeps what is good. The rules files in the kit carry the stop rule above for four stacks. You can try the free version first: the mini pack includes the "Break the loop" prompt and four build prompts. The kit does not make an agent infallible. It gives you a faster way out when things go wrong.
Who the paid kit is for, and who it is not for
- Worth it if you build on one of its four stacks (Next.js with Supabase, Vite with React, FastAPI, Phaser) and want tested files and prompts today instead of writing and testing your own.
- Not worth it if you only need one rules file for one project. The free guides and the free mini pack are enough, and you can adapt them yourself.
Related guides
FAQ
Why does Claude Code keep failing at the same task?
Usually it is retrying a variation of the same idea. Stop it, ask for a report of what is verified and what is assumed, and ask for hypotheses that contradict its earlier ones.
Why does Cursor not follow my rules?
Check the extension (.mdc), the folder (.cursor/rules), the rule type, and the length. If a rule must never be broken, enforce it with permissions rather than relying on instructions.
Should I start a fresh chat?
Often yes. After many failed attempts the conversation is full of wrong assumptions. Start fresh, paste in the error and your report from step 2, and keep the task small.
Is it safe to let the agent run git commands?
Read-only commands such as git log and git diff are low risk. For anything destructive, ask it to use a throwaway branch or stash and tell it never to run destructive commands on your work without approval.