Your AI tool is going in circles. I'll find the bug and make it stay fixed.

You’re not doing it wrong

You built something real, or you’ve kept something real running, with an AI tool as your engineering team. That took judgment and stubbornness. For months it worked: you described a problem, the tool wrote a fix, you shipped it.

Then it stopped working. Now you paste in the error, the tool apologises, explains the problem with total confidence, and changes something. The error moves. You paste the new one. It changes the first thing back. By the end of the day you have twenty versions of the same file and the bug is still there, or it’s gone and something else broke that you won’t notice until a customer does.

This is a very common place to land, and it isn’t a sign that you made bad decisions. It’s a sign that the app has grown past the point where an assistant with no memory of the whole system can reason about it. That’s when an engineer helps most.

Why the loop happens

AI coding tools are very good at the next ten lines. They are much weaker at the questions that sit behind a stubborn bug:

• The cause isn’t where the error is. The page crashes in the invoice view, but the real problem is a record that was saved wrong three steps earlier. The tool fixes the symptom where it shows up, so the problem comes back.
• It can’t see what’s running. It reads the code you show it, not the database, the logs, the server settings or the background job that runs at midnight. Many stubborn bugs live in exactly those places.
• It doesn’t say no. Ask it to add a workaround on top of a workaround and it will. It rarely tells you that the approach is wrong and the fix is two steps back.
• Nothing checks its work. Without tests, there’s no way to know a change didn’t break something else. Every fix is a guess, and guesses compound.

An experienced engineer works differently. I reproduce the bug, read the logs and the data, trace it to where it actually starts, and fix it there. Then I write a test that fails if it ever comes back.

What I do

1. Reproduce it. On a copy of your app and data, not on the live site. If I can’t make it happen on demand, I add the logging that will catch it next time.
2. Find the real cause. Usually a short list of suspects: data saved in an unexpected shape, two parts of the code that disagree about a rule, a timing problem between a request and a background job, a setting that differs between your laptop and the server.
3. Fix it at the source. Often that means undoing some of the workarounds stacked on top. The fix is small, explained, and reviewed against the rest of the app.
4. Add tests. For the bug itself, and for the things closest to it that you care about most, like payments, logins and anything a customer sees.
5. Clean up the data the bug left behind, if any, carefully and with a backup first.
6. Write it down. What went wrong, why, how it was fixed and how to spot it early.

Your AI tools get better afterwards

I don’t want you to stop using AI tools. They are a fair way to build, and you clearly know your product well enough to direct them. I want them to stop going in circles.

So part of every job is leaving the codebase in a state an AI assistant can work in safely:

• Tests it can run. When the tool proposes a change, the tests tell you right away whether it broke something.
• A written instructions file in the project, which most AI coding tools read automatically: how the app is organised, the rules that must never be broken, which files to leave alone, how to run the tests, and the mistakes it made before.
• Clear structure in the places that confused it, so the next change has an obvious home.

The instructions file alone often changes how well the tool behaves. It stops guessing about things it can now read.

Documentation, so the next person isn’t starting cold

Whoever works on the app next, you, an AI tool, a freelancer or a new hire, gets a written handoff: a plain-language overview of how the app fits together, runbooks for deploying and restoring a backup, decision notes on why things were fixed the way they were, the performance numbers I measured, and those AI-assistant instructions. You own all of it, along with the code, the accounts and the hosting. Nothing depends on me staying involved.

Take a business like this one

The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.

Picture a small online shop selling handmade furniture, with a custom ordering app the owner built with an AI tool over a long winter. Customers configure a piece, pay a deposit, and get updates as it’s built. It runs most of the business.

For three weeks, some customers have been charged their deposit twice. Not all of them, and not in any pattern the owner can see. The AI tool has “fixed” it four times. Once it added a check that blocked some real orders. Once it changed the checkout page, which broke the confirmation email. The owner is now refunding by hand every morning.

What I’d do for a shop shaped like this:

1. Read the payment logs against the orders. Find which orders were charged twice and what they have in common. In a case like this it’s often a slow confirmation page and a customer clicking twice, combined with code that creates a new charge each time instead of checking for an existing one.
2. Fix it at the source. Each order gets one payment, enforced so a second click, a retry or a page refresh can’t create another.
3. Undo the workarounds that were blocking real orders and breaking emails.
4. Tests for the full checkout: one click, two clicks, a dropped connection, a declined card.
5. List every double charge from the past weeks so the owner can check each refund was made.
6. Leave the notes and the AI instructions file, so the next feature the owner builds with their tool doesn’t walk back into the same trap.

The owner goes back to building furniture and talking to customers, which is the work only they can do.

What it costs

It starts with a small fixed-price diagnosis: I find the cause and tell you in writing what it is, how big the fix is and what else I noticed that’s worth worrying about. Often the diagnosis and the fix are the same afternoon of work. Anything larger is scoped and quoted before I start, so there are no surprises. No retainer and no lock-in.

What I need from you

Access to the code (a copy is fine to start), read access to the hosting and logs, and a description of the bug in your own words: what you see, when it started, what the AI tool already tried. If you kept the chat history with the tool, that helps too. It’s a record of what’s been ruled out.