When the AI gets stuck, what gets you out is usually a smaller request, not a longer prompt.
When the AI gets stuck, a better prompt is almost never the answer. Three things work: make the request smaller, describe the goal afresh instead of describing another fix, and know the point where you stop prompting and read the code yourself. AI coding agents really do loop. They will apply the same patch three times in different words, report it as fixed, and leave the bug where it was. That is a known failure mode, not a sign you phrased something badly. If the agent is going the wrong way rather than going nowhere, iterating with the agent is the gentler route back.
Below: why the loop happens, the three moves that break it, how to hand the agent a fact instead of a theory, and the threshold where prompting stops being your cheapest tool.
Work out which kind of stuck this isThe short version
A loop means the agent is fixing your description, not the defect.
An agent reads your message, your project files and whatever error text it can reach. It does not see your screen. So when you describe a fix, it builds your description. If the description contains a guess about the cause, you get a well made version of the guess. Three rounds of that is what an AI coding agent loop actually is.
Breaking it means changing what the agent has to work with, not how carefully you ask. Smaller scope, a different starting point, or a fact it can read for itself. If none of those land within a few turns, this has stopped being a prompting problem.
Why an agent loops instead of stopping
There are two kinds of stuck and only one of them is noisy. The loud kind is a build that fails. Newly's documentation, read on 3 October 2026, says the agent starts fixing a failed build, an error or a crash in the preview without you clicking anything. There is a published ceiling on that. After the same build failure happens three times in a row, the agent stops and explains the problem instead. That is for a Remote chat, which is every chat in the web app. The same page says those repair turns use credits like any other agent work. So the loud loop does end by itself, and it costs you something to get there.
The quiet kind is the one that eats an afternoon. The app builds, it runs, and the behaviour is still wrong. Nothing in that path reports a failure, so nothing stops. The agent says it is fixed because the only thing it could check passed. You are the failure detector now, and the agent will keep going as long as you keep answering.
The repetition itself has a dull explanation. Your sentence is most of the input. If the AI keeps making the same mistake, look at what you gave it. A phrase like the save button is broken narrows nothing. So the agent edits the nearest plausible file and reports back. Your next message reacts to its reaction. Two turns later you are both steering by each other rather than by the app.
One more thing worth knowing before you fight it. Newly chooses the model behind its agent in a Remote chat and publishes no model or effort picker, so switching to a stronger model is not a lever you have there. That removes a step most people try first.
The three moves that actually get past it
Move one: make the request smaller, not more detailed. One change, one screen, one behaviour. Newly's own docs point the same way. They say a turn that hits the one hour limit is usually trying to do too much at once. The fix they give is to break the work into smaller requests. Smaller also makes the result checkable, which is the real gain: you can tell in ten seconds whether it worked.
Move two: describe the goal afresh, and stop describing the fix. Say what you did, what you saw, and what you expected. Newly's prompting page gives the shape as a worked example: tapping Save does nothing, and you expected it to go back to the list with the new item added. That is a fact. The state is not updating is a theory, and a theory sends the agent to whichever file matches the theory. Our ai app prompting tips go further on phrasing a request that lands.
Move three: change the starting point. Three stacked fixes leave the code in a state neither of you can reason about, and the fourth message is arguing with the first three. Newly saves a version after every turn that changes files, and Restore to here under an earlier message puts the code back. Restoring does not run the agent, so it uses no credits. Going back and asking once is cheaper than talking the agent out of a direction it has already committed to.
There is also a step before all three: ask for the cause and forbid the fix. Newly publishes the wording for this. Tell the agent to look at the relevant files and logs first and explain what is causing the problem. Add that it should change nothing yet. Ask mode in a Remote chat cannot edit files at all, which is exactly why it is useful here.
Try it
Which kind of stuck is this?
Pick the line that matches what you are looking at. Five shapes, five different moves, and only one of them is about wording.
Nothing selected yet.
Give it the error, not your reading of the error
The fastest way out of a loop is a line of text the agent did not have to guess. React Native, which is what Newly writes, puts that text in two places. LogBox is the in app overlay that appears when your app logs a warning or an error, and it will not dismiss on a fatal error because your code cannot run. React Native DevTools is the built in debugger, and React Native's documentation recommends its Console panel as the source of truth, because LogBox hides or re-levels some logs. Both read on 3 October 2026.
Two things to correct if you arrived from an older tutorial. Remote JavaScript Debugging is gone: React Native's Other Debugging Methods page says it was removed as of React Native 0.79, and React Native DevTools is what replaced it. And none of this exists in the app you ship, because the docs state that the Dev Menu, LogBox and React Native DevTools are all disabled in release builds. A bug that only shows up in a release build gets no overlay and no console, and that is a different hunt from the one on this page.
When you cannot reach a console, the next best fact is a precise sentence plus a screenshot. Use the app's own screen titles and button labels in your message, because those are strings in the code and they give the agent somewhere to land. Answer the questions it asks you, rather than skipping them. The ones about accounts and shared data decide the shape of the whole app. Our guide to building an app with ai questions covers which ones matter.
One class of stuck no wording can fix. Newly's cloud simulators are fixed devices, an iPhone 17 Pro on iOS 26 and a Pixel 8 on Android, and the docs say you cannot pick another model or OS version. A symptom that only appears on a different model or an older OS cannot be reproduced there at all. That needs the app on the real phone, through TestFlight on iOS or an APK or Google Play internal testing on Android. Until you do it, you are both debugging a report rather than a bug.
React Native, Debugging Basics (LogBox, DevTools, release builds)
When to stop prompting and open the code
Here is the threshold, stated plainly because most pages on this subject will not state one. If three focused, well described turns have not moved the bug, prompting has stopped being your cheapest tool. When the AI cannot fix the bug after that, more messages mostly buy you more variations of the same patch. This option exists only because the project is a real React Native and TypeScript codebase, not a format that only the builder can read.
One command does most of the work. TypeScript's own CLI documentation, read on 3 October 2026, lists noEmit as a boolean flag that disables emitting files from a compilation. Run the compiler with that flag and you get the full type check and no output files. A fair share of the bugs that survive three agent turns are a type the agent satisfied without understanding, and this prints them with a file and a line number. Paste that output into the chat and the loop usually ends on the next turn.
Getting the code out takes a minute. Download source in the project's Settings gives you a ZIP of the project, packed from main. The newly command line tool pulls a branch into an empty folder instead. It defaults to dev, the branch your chats work on, and needs Node.js 20 or later. Know the limit before you plan around it: the documentation says you cannot send app code from your computer back into a hosted project, so that export is one way. If you want your editor and the agent working on the same files, the Mac app can open a folder you control instead. It saves each turn as a git commit inside that folder.
And some of these are not stuck, they are out of reach. A request that needs a signed account, a paid membership or a real device is waiting on you, not on a better sentence. Reading the honest boundary of where vibe coding stops before the fourth attempt is cheaper than finding it after the tenth.
Five shapes of stuck, and what each one needs
| What the loop looks like | What the agent cannot see | The move that breaks it | Smaller request helps | Time to open an editor |
|---|---|---|---|---|
| The same build error, three turns running | the cause behind the message | Ask for the cause, forbid the code change | Yes | not yet |
| It builds, and the behaviour is still wrong | what you saw and what you expected | Describe the outcome, not the patch | Yes | not yet |
| Each fix breaks the previous fix | a starting point that is not three patches deep | Restore an earlier version, then ask once | Yes | not yet |
| It asks you the same question back | a decision only you can make | Answer it inside the request | No | no |
| Only one real phone shows it | a device the cloud simulators do not have | Install the build on that phone and report it | No | sometimes |
Why the editor is an exit and not a last resort
A loop is only cheap to leave if you can leave. Plenty of builders keep your project in a shape you cannot open, so when the agent stalls, the only tool left in your hand is another message. That is worth checking about any of them before you commit a month of evenings, because it decides what happens on the bad afternoon rather than the good one.
Newly writes a real React Native and TypeScript project you own. It previews on cloud simulators while it builds, uploads to App Store Connect and TestFlight for iOS, and publishes to Google Play internal testing and builds a standalone APK for Android. The code comes out as a ZIP from the project Settings or through the newly command line tool. It is $25 a month, there is no free plan, and credits are effort based, so a long investigation costs more than a short answer. Automatic repair turns after a failed build are charged the same way, which is the real argument for stopping a loop early rather than letting it run.
That is the honest ending. Not that the agent never gets stuck, because it does, and not that the next prompt will be the one. The point is that getting stuck has an exit that is not another prompt. Read the code, find the line, paste the error back, or fix it yourself and carry on.
Questions people ask when the agent will not budge
Because it is fixing your description of the problem rather than the problem. The agent cannot see your screen. It reads your message, your project files and whatever error text it can reach. If the message carries a theory about the cause, it implements the theory, then reports success. Replace the theory with what you did, what you saw and what you expected, and the next attempt has something real to work from.
Describe the next change, not the last fix
Write one sentence for the behaviour you want, name the screen and the button the way your app does, and send that instead of a fourth attempt at the patch. If it still will not move, pull the code and run the type check.
Start building