The expertise you need. The attitude you want.
The expertise you need. The attitude you want.
Your AI coding tool keeps "fixing" the same bug? How to break the loop and find the root cause
You paste the error. The AI says "Fixed!" The bug comes back. You paste it again, and now something else is broken too. If you build with Cursor, Claude Code, GitHub Copilot, Replit, Lovable, Bolt or v0, you've probably lived this loop.
The loop happens because each attempt guesses at the symptom without evidence of the cause. This guide walks through the method built into Vibewright's Vibe-Coding Tech Lead · Bug Hunter builds, which are live now. Every step separates the symptom, the cause and the fix, and ends with a check that proves the bug stays fixed.
Step 1: stop generating after two or three tries
The Bug Hunter's loop-breaker rule is simple. If an AI tool has attempted the same fix two or three times, stop asking it. More attempts usually pile changes on top of changes, and each one can quietly weaken something else. Auth code is the classic case, where a "fix" skips a session check just to make the error go away.
- Revert to the last commit that worked, or the last one before the AI "fixes" began, so you're debugging the original code and not five layers of guesses.
- Look at the full diff of everything those attempts changed. Anything you don't understand doesn't ship.
Step 2: write the bug down properly
Most bad fixes come from a vague bug report. Before touching code, capture:
- Expected vs. actual: what should happen, and what happens instead.
- The exact error text and stack trace, copied, not paraphrased.
- Steps to reproduce, as few as possible.
- Where it fails: locally, in a preview deploy, in production, or all three.
- What changed right before: code, a dependency update, an environment variable, a dashboard setting.
Then restate the bug in one sentence. If you can't, you don't understand it yet, and neither will your AI tool.
Step 3: read the stack trace from your own code
Skip the library frames at the top. Find the first frame in a file you or your AI wrote, and note the error type, message, file and line. That's where to start looking, even if the real cause turns out to be upstream.
Step 4: reproduce it, then shrink it
Get the bug to happen every time. Then make the failing case as small as you can: the smallest input, the fewest steps, one file if possible. Commenting out half of the suspect code and checking whether the bug survives is crude, and it works.
If it used to work, let Git find the commit that broke it. git bisect does a binary search through your history:
git bisect start
git bisect bad # the current commit has the bug
git bisect good <commit> # a commit you know worked
# Git checks out a commit in the middle. Test it, then mark it:
git bisect good # or: git bisect bad
# Repeat until Git names the first bad commit, then clean up:
git bisect reset
If you have a test or script that exits 0 when things work and 1 when they don't, git bisect run <your-test-command> does the marking for you. AI tools commit fast, so this often lands on the exact change in a handful of steps.
Step 5: one hypothesis at a time
List up to three likely causes, ranked by how probable they are, with a quick test for each. Run the cheapest test first, and update the list after every result. Never change two things at once, or you won't know which one mattered.
These are the usual suspects the Bug Hunter checks in AI-generated code:
- Functions, options or packages the AI invented. Check the docs and the version you actually have installed.
- Outdated API usage after a major version change.
- A missing
await or an unhandled promise rejection.
- Environment variables that are missing, misnamed, or exposed to the wrong side (server vs. browser).
- Server and client boundary errors, like hydration mismatches or browser-only APIs running on the server.
- CORS settings or auth redirect URLs that match localhost but not your production domain.
- A silent
try/catch that swallows the real error.
- Duplicate logic, where the AI fixed one copy and the bug lives in the other.
- Race conditions in state updates and webhooks.
- Time zones and date parsing.
- Off-by-one errors and missing null or undefined checks.
A tip for production-only bugs: if it works locally and fails in production, suspect configuration before code. A login loop that only happens on your real domain is usually the auth provider's site URL or redirect settings, or cookie settings, not your login function. No amount of rewriting code fixes a dashboard setting.
Step 6: fix the cause, then prove it stays fixed
- Write a failing test that reproduces the bug, when you can.
- Fix the root cause, not the symptom.
- Run that test and the related tests.
- Write two sentences for your bug log: what broke and why.
That last check is what the Bug Hunter calls the stays-fixed check: the test, log line or alert that will tell you if this bug ever comes back. If you can't name one, the bug isn't done.
Step 7: give your AI tool one precise instruction
Once you have evidence, the AI becomes useful again. Instead of "fix the login bug," give it one tightly scoped prompt:
- The file to change.
- The cause you found, and the evidence (error, log, failing test).
- The constraint: "Don't modify other files."
- The acceptance check: "The failing test in
auth.test.ts passes and nothing else changes."
Or fix it by hand. Sometimes it's one line.
If it's already broken in production
Order matters. First, assess the impact: who's affected and whether data is at risk. Second, mitigate: roll back, or switch the feature off. Only then debug, from logs and your error monitor (Sentry or similar). Finish with a short postmortem covering what happened, why, the fix and how you'll prevent it. Structured logs with request IDs make every future bug faster, as long as they never contain secrets or personal data.
Where the Bug Hunter build fits
Each Bug Hunter build is a ready-to-paste system prompt for Claude Projects, ChatGPT Projects, Gemini, Grok, Cursor and other agent frameworks. About 80% of its attention goes to reproducing, isolating and fixing bugs at the root. Say "run onboarding" and it asks for your stack, what's broken, where it fails and what changed, then runs workflows for bug intake, reproduction and isolation, the hypothesis loop, fix plus regression test, the AI loop breaker, and production incident triage. It also refuses to help you commit secrets or run destructive commands without your explicit approval.
It's guidance, not a certified security audit, and it never claims code works unless it was run. You review and test everything before production.
Setup guides: Claude Projects, ChatGPT Projects and Gemini Gems and skills. They use a CFO build as the example, but the steps are the same for any Vibewright build. Planning a new app? Start with the one-page architecture plan and the pre-launch security checklist.
Then pick the debugging partner you'll actually listen to at 1 a.m. The Bug Hunter comes in seven tones: Aggressive (hard deadlines, no excuses), Affirming (earned praise, then the next step), Dry (answer first, numbered steps), Funny (one joke, then the real plan), Sarcastic (wry, fully useful under the snark), Boardroom Professional and Calm Zen. Same method, different voice. See how tones change an agent.
Get the Bug Hunter
- Free sample: claim the CFO · Tax Planner · Funny build with your email to see how a Vibewright build is put together before you buy. The download link lands in your inbox right away. License: Personal and commercial use allowed. No redistribution.
- Pick your tone: single build $9, role pack $49 (every Vibe-Coding Tech Lead build), launch bundle $79, All-Access $19/mo or $149/yr, or Founding Member $199 lifetime for the first 100. 7-day refund on subscriptions. No refunds on downloads.
Choose your Bug Hunter tone on /pricing · Or grab the free sample