Every fix breaks something else in your AI-built app.

Building with an AI tool has a recognisable early phase. Each prompt adds something, and the product visibly grows. The loop is the phase after that, and it is easy to miss the moment it starts, because each individual session still ends with something fixed.

Look at the last two weeks of work instead of the last session. If most of the signs below apply, further prompting in the same way is unlikely to end differently, and the routine in the sections that follow is worth the pause.

An AI coding tool works from what it has been shown: your message, the error text and the files it opened for this request. It rewrites code until the error you reported stops appearing. It does not always know what else relied on the code it rewrote. A function that formats a date for the invoice screen may also feed the reminder emails, and a change that satisfies the invoice can quietly alter the emails.

The second half of the cause is that nothing checks yesterday's working behaviour. Software teams guard against this with automatic tests, small programs that click through the important journeys after every change and raise a flag when one stops working. Most AI-built products have none, because nobody asked for them and the product worked without them. So a broken reminder email goes unnoticed until a customer mentions it, by which time several more changes sit on top.

The pile itself then becomes a problem. Each repair adds a special case, the same job ends up written in two or three places, and the tool has more conflicting code to read on the next request. The tool is being asked to keep a whole product consistent with no list of what the product is supposed to do, and that is a hard job for a person as well.

The second habit replaces the missing tests with a page of paper. List the handful of things the product must do for you to take a customer's money in good conscience. Write each as steps with a visible result: 'A new person signs up with an email address, lands on the dashboard and sees an empty project list.' 'A customer pays with a card and the plan on the account page changes.' Keep the list short enough to click through over a coffee.

After every change, however small, go through the whole list. This is the step people skip, and it is the one that breaks the loop, because it tells you within minutes that the fix for the invoice damaged the sign-up. You then know which change did it, since there has only been one. Mark each line as passing or failing with the date.

The list also answers the question you could not answer before. How far you are from done is the number of lines that fail, plus any lines you have not yet written because the feature does not exist. That is a count you can show a co-founder, an investor or an engineer, and it moves in one direction when the work is going well.

Ask for one change per request. 'Fix the checkout total and also tidy the settings page and add dark mode' gives you three sets of edits and no way to tell which one broke the sign-up. A single request with a single expected result can be accepted or thrown away as a unit. Say what must stay the same as well as what should change, naming the screens the tool should leave alone.

Set yourself a limit on repeats. If you have asked for the same fix three times and the fault is still there or keeps returning, do not ask a fourth time in the same words. The tool has shown that it cannot find the cause from the information it has. Go back to the last save where that journey passed, and compare: what was added between then and now? The cause is somewhere in that difference.

A change of question often helps at that point. Ask the tool to explain, without editing anything, how the failing feature works and which files take part in it. Read the answer for surprises, such as two places that both calculate the total. Then ask for the smallest change that addresses the cause you found. If the explanation makes no sense to you or contradicts itself, that is useful information about the state of the code, and the next section covers what to do with it.

Once you have the list and a few days of one-change-at-a-time work, a pattern shows. Either the failing lines go down and stay down, or the same one or two lines keep failing whatever you do. The first product needs finishing. In the second, the trouble usually sits in one area that everything else leans on, most often how the data is organised or how sign-in and permissions were set up.

A part that needs rebuilding is a smaller thing than a product that needs rebuilding. The screens, the wording, the flow you tested with real people and most of the features can usually stay while one foundation underneath is replaced. The table sets out what points each way. Deciding for certain takes someone reading the code, and our guide to rebuild cost covers what a full replacement involves if it comes to that.

Carry on alone while the count of failing lines is falling. The routine on this page is how working engineers avoid the same loop, and plenty of founders finish with it. Keep the saves, keep the list, and add a line to the list whenever a customer finds a fault it did not cover.

Ask someone when the count has stopped moving, when the failing lines involve money or private data, or when you have gone back to an old save more than once for the same fault. Bring the list and the names of your saves. An engineer who can see what must work, what fails and which version last passed starts well ahead of one who is handed a chat history. Our Diagnostic is a fixed-price written plan: we read the code, tell you which parts are sound and which one is causing the repeats, and quote the next phase, with the fee credited to the build if you continue with us. Whoever does the work, your repo and accounts stay yours.