Smarter Foundry · Updated
Signs you're in a loop
- The same error comes back after being “fixed”.
- The agent rewrites files that were working.
- Each fix adds a special case instead of removing the cause.
- The agent says it fixed the problem and nothing has changed.
- You can no longer say what the last five changes did.
When you notice two of these, stop prompting. More attempts in the same conversation usually add code without adding understanding.
1. Save the last good state
If the project is in Git, commit before every attempt, and find the last commit where things worked. If they've piled up, going back to that commit and reapplying only the change you needed is often faster than untangling the rest. Lovable, Replit and Bolt all keep a version history you can restore from.
2. Write down exactly how to reproduce it
Steps, input, what you expected, what happened. “Checkout is broken” gives the agent nothing to work with. “Signed in as a new user, clicked Upgrade, paid with the Stripe test card, got sent back to /pricing instead of /dashboard, and the account is still on the free plan” gives it a lot.
3. Get the real error
Describing an error loses the details the agent needs. Copy the actual text from:
- the browser console (right-click, Inspect, Console);
- the Network tab, for the failing request and its response;
- your server or function logs in the hosting dashboard;
- the third-party dashboard, such as Stripe's webhook log.
4. Find which layer is failing
Most bugs live in one place: the browser, your API, the database, or a third-party service. The Network tab usually tells you which. If the request never leaves the browser, it's a front-end problem. If the server returns an error, look at the server logs. If the server returns success and the data is still wrong, look at the database and its access rules.
5. Start a fresh session
A long conversation carries every failed attempt with it, and the agent keeps building on them. Open a new chat and give it only the reproduction steps, the exact error, and the files involved.
6. Ask for a diagnosis before a fix
Try something like:
Don't change any code yet. Explain what is causing this, which file and line, and how we could confirm it.
If the explanation doesn't match what you see, say so. Once you agree on the cause, ask for the smallest change that fixes it.
7. Prove the fix
Ask for a test, or at least a log line, that fails before the fix and passes after it. Then run through the reproduction steps yourself, so you know the bug is gone and not just hidden.
8. Give it current documentation
AI models learn from code written before their training cut-off. Payment, auth and email providers change their APIs, and an agent may confidently use a version that no longer exists. Paste the relevant page of the current docs into the conversation.
When the problem isn't in the code
Plenty of “bugs” are configuration, and the agent can't see your dashboards. Check these before changing code:
- Environment variables set locally but missing in production.
- Auth redirect URLs that still point at localhost or the preview domain.
- A webhook endpoint registered against the wrong URL, or in test mode.
- Test keys used in production, or live keys used locally.
- DNS or email records that haven't been added yet.
When to get help
Consider handing it off when two focused sessions haven't moved a single bug, when the fix needs a change in how the data is structured, or when you've stopped trusting large parts of the codebase. A second person who reads the code with fresh eyes often finds the cause quickly, because they aren't carrying the history of attempts. The production checklist is a good next read once the app is working again.