Why does everything break when you change one small thing?

The short answer

Your app breaks because pieces of it you never touched are quietly wired to the piece you did. A discount function feeds three pages, a shared card component renders on five screens, one prop gets renamed and a layout two folders away goes blank. That connection was always there; you just couldn’t see it until it snapped. Add an agent that edits fast and doesn’t always stop at the exact edge of what you asked for, with no tests running in the background to catch what moved, and a one-line fix turns into three broken screens. This kind of fragility says nothing about your skill or the quality of what you’ve built. The three things that usually catch this before a user does (a named scope, a fast check, a habit of reading what changed) haven’t been built into your workflow yet. All three are learnable in an afternoon.

Why one small change breaks three other things

This happens in two different ways, and it helps to tell them apart because each needs its own fix.

The first is real coupling: two features share one piece of logic, on purpose or by accident, and a change made for feature A quietly changes feature B’s behavior too. This is the classic version, the one every engineer has a war story about, and it’s not new to AI-assisted coding. What is somewhat new is how often it happens invisibly, because you never wrote the shared function yourself and don’t know it’s shared until something downstream breaks.

The second is almost the opposite problem: duplicated logic instead of shared logic. GitClear’s 2025 analysis of 211 million changed lines across major codebases found that copy-pasted code rose from 8.3% to 12.3% of all changed lines between 2021 and 2024, while genuine refactoring (cleaning up and consolidating logic) dropped from about a quarter of changes to under 10% over the same period. When an agent solves a problem by writing a new version of something that already exists elsewhere rather than reusing it, you get five almost-identical copies of the same rule. Fix a bug in one, and the other four still have it. You didn’t imagine the fix. It just didn’t reach the other copies, because there wasn’t really “one” place the logic lived.

Either way, the pattern you’re feeling is the same: a change with a blast radius bigger than the part of the screen you were looking at.

Ask for the scope before the agent starts, not after

The single highest-leverage habit here is agreeing on the boundary of a change before any code gets written, not diagnosing the damage after. Anthropic’s own guidance for Claude Code recommends exactly this: explore what the code currently does, have the agent write a plan, and only then let it implement, because letting an agent “jump straight to coding can produce code that solves the wrong problem.” You don’t need Plan Mode turned on by default to get this benefit. You can just ask, in plain language, before a change that touches more than one file: “what files does this need to change, and is there anything outside those files this could affect?” A vague answer is your cue to narrow the ask before you say go, not after you’re staring at a broken page.

For anything you catch yourself repeating twice, put it in CLAUDE.md once instead: “never touch checkout/, billing/, or database migrations without asking me first,” for example. A rule written down once outlives a rule you have to retype every session.

Commit before you touch anything, so undo is one command

Official Git documentation puts this more plainly than most tutorials bother to: “anything that is committed in Git can almost always be recovered… [but] anything you lose that was never committed is likely never to be seen again.” That single sentence is the entire argument for committing constantly. A commit is the save point that makes “just try it and see” a safe thing to say to an agent. If the last two hours of edits went badly, you want the last commit to be from ten minutes ago, not this morning.

The habit in practice: after every change that works, ask for a commit with a real message before the next request goes out. If you’re new to what a commit even is, git basics covers the save-and-rewind model underneath this; if something already broke and you need to get back, rollback and revert covers exactly how to undo it without losing the parts that were fine. Frequent, small commits also mean that if you ever do end up combining two branches of work, the merge conflicts you hit are small and localized instead of one enormous tangle to untangle by hand.

Give it something it has to check, not just claim

“Looks done” isn’t the same thing as “works,” and left alone, an agent will treat the first as good enough because it has no other signal to go on. Anthropic’s own best-practices guidance for Claude Code is direct about this: give the agent a check it can run (a test, a build, a screenshot compared against the original), so that “the difference between a session you watch and one you walk away from” is a real pass or fail instead of a guess. You don’t need a real test suite for this to work. A smoke test can be three steps you run by hand in under two minutes: load the homepage, log in, complete the one flow that makes you money or matters to your users. If those three things still work after a change, most of what would have embarrassed you in front of a user is already caught. If you can script even one of those three, do it, since a script never skips a step when you’re in a hurry.

Read the diff before you say “looks good”

The last habit is the simplest and the most skipped: look at what changed, not just whether the page you were watching still renders. Ask for the diff and read it the way you’d reread a message before sending it, checking whether anything outside the file you asked about got touched. This is the same instinct behind Anthropic’s own recommendation to add an adversarial review step on longer or unattended changes, having a fresh subagent look only at the diff against the stated plan and flag anything that wandered outside scope, since a reviewer that didn’t write the code has no attachment to defending it. You don’t need a second agent for a five-line fix. You do need to open the diff for anything that touched more than the one file you had in mind, because “it looks fine” and “it only changed what I asked for” are two different claims, and only reading the diff answers the second one.

What Glim would tell you

This is the moment Glimfly built Glim for. Glim is a small companion that sits next to your agent and narrates what it’s doing while it’s doing it, including the part that usually stays invisible until something breaks: which files it just opened, whether it’s about to edit something outside the scope you agreed on, whether a change has been checked or just looks finished. Instead of finding out the blast radius after the fact, you see it forming in real time. If you want the rest of the vocabulary this guide leans on, Plan Mode is a good place to keep reading.