The most expensive word an AI coding agent says is “fixed.”
It says it with total confidence. Sometimes it’s right. But often enough to matter, it isn’t: the bug is still there, or it moved somewhere else, or the fix quietly broke something nobody touched. If you’re not an engineer, you can’t always tell the difference. So you ask again, it says “fixed” again, and an afternoon disappears.
People who build with AI talk about this loop more than almost anything else. Ask around and you’ll hear the same story: a fast start, then a wall where every fix breaks something else and the errors stop making sense.
I’ve been building real software with AI agents for a year: a walking game on the App Store, and a community app a small group tests with me every week. I’ve been stuck in that loop plenty. Here’s what I’ve learned about why it happens, and the habits that get me out.
Four times “fixed” wasn’t
None of these were dramatic. That’s the point. Each one looked like success.
The check that checked nothing. A step that was supposed to confirm the code was sound reported all clear. It had looked at zero files. Broken code went straight through, because “no errors found” and “nothing was examined” look exactly the same.
The save that saved nothing. A change to someone’s permissions came back as a success. The database had quietly refused it, because the rules didn’t allow that edit, and reported success anyway. Nothing changed, and the screen said it had.
The deploy that hadn’t landed. I had an agent check whether a new version was live. The server answers any missing page by sending the home page with a “success” code. So a check that only looked for “success” reported the update was live minutes before it actually was.
The upgrade that didn’t upgrade. My app was slow, and upgrading the plan seemed like the obvious fix. It didn’t help. The plan and the size of the machine underneath were two separate settings, and I’d only changed one.
In every case the agent wasn’t lying. It reported what it saw. It just saw the wrong thing, or checked the easy thing instead of the real one.
Why the loop happens
Three reasons, as far as I can tell:
- The agent checks what’s easy to check. Did the command run? Did the page load? Those are cheap questions, and they’re not the same as “does it work for a real person?”
- It fixes symptoms, one at a time. Each fix makes sense on its own. Without a picture of the whole system, five sensible fixes can add up to a mess.
- It can’t see your users. It doesn’t know about the phone that behaves differently from the browser, or the person who taps the button twice. You do, or you can find out.
So the fix isn’t a better prompt. It’s a better habit around the prompt.
Seven habits that get me out
1. Save a restore point before every fix
Commit, or use your tool’s version history, before you ask for a change. Then a bad fix costs you one click, not a day of untangling.
2. Make it explain before it touches anything
Most bad fixes start with a guess. Make the agent find the cause first, out loud, before it changes a single line.
Don’t change any code yet. Explain what you think is causing this bug, what evidence supports that, and what else it could be. Then tell me how we could confirm the cause before fixing it.
If the explanation doesn’t make sense to you, that’s your signal. Ask it to explain again, simpler, until it does.
3. Decide how you’ll know it worked, before the fix
This is the habit that changed the most for me. Agree on the test first, and the agent can’t grade its own homework afterward.
Before you fix this, tell me exactly how I can check that it’s fixed myself: what to click, what I should see, and what I’d see if it’s still broken.
4. One change at a time
If you ask for three fixes at once and something breaks, you won’t know which one did it. Fix one thing, confirm it, save, then move on.
5. Confirm it yourself, the way a user would
Not “the command ran.” Open the app, on the device people actually use, as the kind of person who uses it, and do the thing. If you can, do it as a different user too, to make sure you can’t see what you shouldn’t.
You said this is fixed. Give me a step-by-step way to confirm it from the outside, as a real user would, without trusting the code or your summary. Include one check that would fail if the fix only looks like it worked.
And the rule underneath all of it: if the AI says done and your check fails, believe the check.
6. Turn every correction into a rule
When you catch the agent getting something wrong, don’t just fix it. Write the correction down somewhere it reads at the start of every session, like a project instructions file. My rulebook started as a list of mistakes. It’s now the most useful thing in the project. (More on that here.)
We just fixed this. Write a one-line rule for the project instructions that would have prevented it, in plain language, so you follow it next time.
7. Three strikes, then stop
If the same problem survives three fixes, more prompting won’t solve it. Something about the picture is wrong. Stop, go back to your restore point, and reset.
Stop. Summarize everything we’ve tried for this problem, what happened each time, and what we now know is NOT the cause. Don’t suggest another fix yet.
Then take that summary into a fresh session, or to a person who knows the system. A clean start with a good summary beats a long chat full of failed guesses. And knowing when to ask a human isn’t failure. It’s judgment.
What this means for design teams
Designers are shipping more code than ever, and design leaders are doing it too. That’s good news. But “it works on my screen” was never enough, and with AI it’s easier than ever to mistake looking finished for being finished.
The habits above aren’t really technical. They’re the same things good design critique has always done: define what success looks like, test with real people, and don’t take anyone’s word for it, including your own. Teams that make “how will we know it worked?” a normal question will ship faster, not slower, because they’ll stop paying for fixes twice.
Want the full set? The Vibe Coding Checklist covers the ten systems AI-built apps need before real users. Its free Fix Kit has a check, a fix and a confirm prompt for each one.
Stuck on a fix? I do a few 1:1 sessions where you share your screen and I teach you how to check and fix it yourself.