How to stop AI coding tools breaking your code

Guide · checked against the docs on Oct 15, 2026

AI coding tools can read your project, edit files and run commands. That's useful right up until a small request turns into changes you didn't ask for. No habit stops every breakage. The ones below make problems easier to catch and easier to undo. Each one comes from the tool makers' own docs or the git manual, read on October 15, 2026. The prompts at the end are a starting point: we haven't scored them or tested them against each tool.

Not affiliated with or endorsed by Anthropic, OpenAI, Cursor, GitHub, Aider or the Git project. Features and shortcuts change, so check each tool's docs.

Why AI tools break working code

There are three common reasons. The tool may change more than you asked. It may say it's done without running any checks. And it doesn't remember your project from one session to the next. Cursor's rules docs put that last one plainly: "Large language models don't retain memory between completions." Every habit below targets one of those three problems.

Commit before every AI change

Before you let a tool edit anything, save a snapshot with git:

git add -A
git commit -m "Before AI change"

Now whatever the tool does, you can see exactly what changed and get back to this point. Some tools do this for you. Aider's git docs say: "Whenever aider edits a file, it commits those changes with a descriptive commit message. This makes it easy to undo or review aider's changes." If files already have unsaved changes, "Aider will first commit any preexisting changes with a descriptive commit message."

Scope the change small, and say what not to touch

One function in one file is easier to check than "improve the cart". Name the file and the function. Then list what's off limits: tests, config, secrets and new packages. OpenAI's Codex guide calls it "a good default" to include four things in a prompt: "Goal … Context … Constraints … Done when". The do-not list is your constraints.

Ask for a plan before any edits

Anthropic's Claude Code tips page warns: "Letting Claude jump straight to coding can produce code that solves the wrong problem. Use plan mode to separate exploration from execution." OpenAI says the same for Codex: "If the task is complex, ambiguous, or hard to describe well, ask Codex to plan before it starts coding." Its list of common mistakes includes "Skipping planning on multi-step and complex tasks".

How to get there:

Claude Code, plan mode: "Enter plan mode by pressing Shift+Tab until the status bar shows ⏸ plan mode on, or start the session with claude --permission-mode plan. Claude reads files and answers questions without making changes." (Shift+Tab per the docs, checked Oct 2026.)
Codex, Plan mode: "Toggle with /plan or Shift+ Tab." (Shift+Tab per the docs, checked Oct 2026.)
Any tool: just ask for a plan and tell it to wait for your OK. See prompt 1 below.

While you're at it, keep permissions tight. OpenAI's advice: "If you're new to coding agents, start with the default permissions. Keep approval and sandboxing tight by default…" Another mistake on its list is "Giving Codex full permission to your computer before you understand the workflow".

Give it a project instructions file

Because the tool forgets between sessions, put the basics in a file it reads every time. Cursor's docs explain why that works: "Rules provide persistent, reusable context at the prompt level." The file name depends on the tool:

Tool	File	From the docs
Claude Code	`CLAUDE.md` or `.claude/CLAUDE.md`	"Run /init to generate a starting CLAUDE.md automatically." It can also load AGENTS.md "instead of or alongside" CLAUDE.md. (memory docs)
Codex	`AGENTS.md`	"Codex reads AGENTS.md files before doing any work." (AGENTS.md guide)
Cursor	`.cursor/rules` (Project Rules) or `AGENTS.md`	AGENTS.md is a "Simple alternative to .cursor/rules." (rules docs)
GitHub Copilot	`.github/copilot-instructions.md`, plus `.github/instructions/NAME.instructions.md` for specific paths	Repository custom instructions (GitHub docs)
Aider	`CONVENTIONS.md` (any name works)	Load it "with /read CONVENTIONS.md or aider --read CONVENTIONS.md." (conventions docs)

What goes in it? Anthropic lists "build and test commands, coding standards, architectural decisions, naming conventions, and common workflows." OpenAI adds "Constraints and do-not rules" and "What done means and how to verify work".

Keep it short. OpenAI: "A short, accurate AGENTS.md is more useful than a long file full of vague rules. Start with the basics, then add new rules only after you notice repeated mistakes." Cursor: "Good rules are focused, actionable, and scoped," and "Keep rules under 500 lines."

Tell it how to check its work

Anthropic's advice: "Give Claude a check it can run: tests, a build, a screenshot to compare." Its docs show a prompt that builds the check in: "write a validateEmail function. example test cases: user@example.com is true, invalid is false, [email protected] is false. run the tests after implementing".

OpenAI says the same: "Don't stop at asking Codex to make a change. Ask it to create tests when needed, run the relevant checks, confirm the result, and review the work before you accept it." Aider can run your tests itself with --test-cmd <test-command> and the --auto-test switch (lint and test docs).

When something fails, ask for the real fix. Anthropic's example: "fix it and verify the build succeeds. address the root cause, don't suppress the error".

Read the diff before you accept

The diff is the list of every line the tool changed. The git manual describes git diff as: "Show changes between commits, commit and working tree, etc". Run it after every AI change:

git diff --stat   # which files changed
git diff          # every changed line

If a file shows up that you didn't ask about, that's your cue to ask why. Codex also has a built-in /review that can "Review uncommitted changes".

When it breaks: undo in the tool, then in git

Many tools have their own undo:

Claude Code: "/rewind, or press Esc twice when the prompt input is empty, to open the rewind menu." (Esc twice per the docs, checked Oct 2026.) But note: "Checkpointing does not track files modified by Bash commands." And "Checkpoints are designed for quick, session-level recovery. For permanent version history and collaboration, continue using version control, such as Git…" (checkpointing docs)
Aider: "Use the /undo command to instantly undo any AI changes that you don't like."

Git is the undo that works no matter which tool made the change.

Not committed yet? Use git restore. The manual says it will "Restore specified paths in the working tree with some contents from a restore source." By default it restores from the index, which holds your last commit plus anything you staged with git add:

git restore src/cart.js

This throws away the uncommitted changes in that file, so look at the diff first.

Already committed? Use git revert. The manual: "Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit)."

git revert HEAD

That adds a new commit that undoes the bad one, and keeps the history. Commit or restore any loose changes first, since revert needs a clean working tree.

We ran these exact steps on a small test project: a break, git diff, git restore, then a committed break and git revert, with tests after each.

Copy-paste prompts

Swap in your own file names. You can check whether the tool followed each one by looking at git diff and the test output.

Plan only: "Don't edit any files yet. Read src/cart.js and list the files you'd change to add a discount code, and why. Wait for my OK."
Small scope: "Change only the function applyDiscount in src/cart.js. Don't rename anything, don't touch other files, and don't add packages."
Do-not list: "Don't change anything in tests/, package.json, or .env. If you think one of them needs to change, stop and tell me."
Done when: "Add a check that the quantity is at least 1. Done means: npm test passes and a new test covers quantity 0."
Run the checks: "After the change, run npm test and npm run build, paste the output, and fix the root cause of any failure. Don't skip or delete tests."
Explain the diff: "Show me the diff of what you changed, file by file, and explain each change in one sentence."
Cleanup: "Did you change anything I didn't ask for? List it, then undo those parts."
Write the instructions file: "Write a short AGENTS.md for this repo with the test command, the build command, and these rules: don't edit .env, don't add dependencies without asking, and run tests before saying you're done." (Use the file name from the table above for your tool.)
After a failed fix: "Your last two fixes didn't work. Stop editing. Explain what you think the bug is and what you'd check first."

Prompt 4 follows OpenAI's "Done when" pattern, and prompt 5 is adapted from Anthropic's root-cause example.

Next step

New to building with AI? Start with our vibe coding guide for beginners. Still picking a tool? The guide to choosing an AI tool for FiveM has a checklist you can reuse for any project. A prompt pack built on these habits is coming soon.

We haven't published hands-on test results for these tools. This guide collects what the tool makers and the git manual say, not how the tools performed for us.

Not affiliated with or endorsed by Anthropic, OpenAI, Cursor, GitHub, Aider or the Git project. Features and shortcuts change, so check each tool's docs.