Why Your AI Coding Assistant Keeps Breaking Working Code

Why does an AI coding assistant break code that already worked?

An AI coding assistant breaks working code because it changes more than the task needs, and nothing checks the result before you accept it. It reads part of your project, guesses the rest and stops when the code looks done. Looking done and being done are not the same thing.

Here is the loop most of us know:

• One fix, two new bugs. You ask for a small change. The diff touches six files. Something unrelated stops working.
• "Fixed" without proof. The assistant says the bug is gone. It never ran the code.
• Corrections pile up. You correct it, it gets worse, you correct again. The chat fills up with failed attempts.
• Context switching hurts. A hotfix lands, you stash your branch and lose your place.

It is not only the main assistant. On July 9, 2026, I gave a review agent one clear rule: read only, do not edit. It ran git stash on its own while my main session was still editing. When the stash came back, my whole working folder jumped back in time, and for a while I had no idea who had reset it. The rule was only in the prompt; nothing enforced it.

The problem is not the model. It is a workflow with no brakes.

How to stop an AI assistant from breaking code, step by step

You stop an AI assistant from breaking code by adding brakes: a saved checkpoint, a plan, small steps, tests first and a review at the end. Each step below works today with free tools and any AI coding assistant.

1. Save a clean checkpoint first. Commit your work before you ask for any change. If the change goes wrong, one command takes you back.
2. Ask for a plan, not code. Make the assistant read the relevant files and write a plan before it edits anything. In Claude Code, plan mode does exactly this: it reads and proposes without changing files. Edit the plan until it matches what you want.
3. Have someone attack the plan. A second agent, or a friend, reads the plan and looks for wrong guesses. This is the cheapest place to catch a mistake, because no code exists yet.
4. Cut the plan into small steps. One step should change one behavior. If you cannot describe the step in one sentence, it is too big.
5. Write a failing test first. This is called test-driven development, or TDD. You write a test for the next small piece, watch it fail (red), write just enough code to pass it (green), then tidy up (refactor). Martin Fowler's short guide to test-driven development explains the cycle well.
6. Run the whole test suite after every step. A test suite is the full set of tests for your project. Running all of it, not only the new test, is what catches the bug in the file the assistant should not have touched.
7. Use a worktree for parallel work. A worktree is a second folder linked to the same repository, on its own branch. Run git worktree add ../hotfix -b hotfix and fix the urgent bug there while your feature branch stays open. The git worktree docs cover add, list and remove.
8. Review the diff yourself before "done". Ask the assistant for evidence: the test output and the commands it ran. Then read the diff. Anything outside the task's scope goes back.
9. Start fresh after two failed corrections. The Claude Code docs give this advice too. Clear the chat and write a better first prompt that includes what you learned.

I compared the skills that help most with this in the best Claude Code skills for indie developers. If a skill you installed never seems to run, why Claude Code skills do not trigger covers the usual causes.

Tell the assistant what "broken" means

"It is still broken" gives the model almost nothing to work with. Anthropic's Claude Code best practices say to describe the symptom, the likely place and what fixed looks like. Paste the exact error. Name the file. Ask for a failing test that shows the bug before the fix.

Also say what must keep working, such as "the login tests must still pass". Put rules that apply to every task, like your test command, in a CLAUDE.md file, which Claude Code reads at the start of each session. The same guide warns that a long chat fills the context window, and the model then starts to forget earlier instructions.

The faster way: install CodeForge and let the workflow run itself

The faster way is to install the workflow once as skills, so the assistant follows it every time without you asking. A skill is a saved set of instructions that Claude Code loads when a task matches it. CodeForge is 14 of those, covering brainstorming, plans, TDD, code review, debugging, verification and git worktrees.

I run this same loop on my own sites every day. To be clear, I run it with my own agents, not with CodeForge itself, so read these numbers as proof that the loop works, not as a test of the package. Between September 21 and October 20, 2026, a review agent ran 165 times across 16 of my projects. The median run took 2 minutes 38 seconds. Of the 46 runs that reviewed a plan before any code existed, 41 found at least one blocking problem. A final check step ran 19 times in the same month, with a median of 2 minutes 54 seconds.

Those 41 plan reviews are why I trust the loop. Each one flagged a problem while fixing it still meant editing a text file, not undoing a merged change.

How to use it, step by step

1. Buy and download. Polar or Gumroad sends the files right after payment. Unzip them anywhere.
2. Install the plugin. In Claude Code, run /plugin marketplace add with the path to the unzipped folder, then /plugin install codeforge@codeforge-dev. This is the route in Anthropic's plugin install guide, and it installs the skills and hooks together. The README in the package still shows a cp command into the plugins folder; skip it. I once installed a plugin by hand, its folder shortcuts were never filled in, and I fixed each one myself. Now I always use the installer.
3. Other tools. Cursor, Codex, OpenCode and Gemini CLI each have their own adapter file and install note in the package. For Gemini CLI that is gemini extensions install with the folder path.
4. Start a feature with brainstorming. Describe the goal. The skill asks questions, then the plan skill writes a plan for you to approve.
5. Build with the TDD skill. Each step goes red, then green, then refactor, and the suite runs after each one.
6. Use a worktree for parallel branches. The worktree skill picks a folder, checks it and creates a second checkout for a hotfix or a second feature.
7. Finish with review and verification. The review skill checks the diff against the plan, and the verification skill asks for fresh test output before the change counts as done.

What the output looks like

Each feature leaves the same trail. The plan skill saves a dated plan file under docs/codeforge/plans/, so you can open it a month later and see what was agreed. Then comes a list of small steps, a test for each step, passing test output and a review note. When something breaks later, you can see which step brought it in.

The review note is where the value shows. This one came from my own review agent on one of my sites on October 9, 2026, not from a CodeForge run, but CodeForge's review step writes the same kind of verdict:

All 27 profession ids and 7 blog slugs named in the link matrix also exist in data/professions.ts and data/blog.ts. Verdict: fix first. The design is sound, but three of the plan's assumptions are wrong.

That review took 1 minute 51 seconds. It found three wrong guesses in a plan before a single file changed.

How much time it saves

I never timed a feature with and without this loop, so I cannot give you an honest "hours before, hours after" number. What I can measure is the cost of the brakes themselves: a median of under three minutes per review and under three minutes per final check, across a month of real work.

The first features are slower, and that is expected. The saving shows up in the evenings you no longer spend reverting.