Stop, and get back to the last version that worked, if there is one. AI tools write a lot of code quickly, and when something breaks, asking them to "fix it" over and over tends to stack change on change until nothing works and nobody knows why. Find the first real error message, fix one problem at a time, and check the app after every change. If there's no working version to go back to, the project needs someone who can read the code.
What's the problem
It worked yesterday. You asked for one more feature, or one small fix, and now it won't start, or half of it is broken. Each attempt to fix it changes more files, and the app gets further from working. You can't read the code well enough to see what went wrong.
Why it happens
- Fixes pile up. Each "fix" changes code the AI can't fully see, breaks something else, and the next fix chases that. After a few rounds, the original problem is buried.
- Big apps outgrow what the AI keeps in mind. Once the project is bigger than what the tool considers at once, it starts contradicting decisions it made earlier.
- It invents things. Code-generating AI sometimes uses packages or functions that don't exist. Research found it recommends non-existent packages at least 5.2% of the time for commercial models.
- There's no safety net. Without version history and tests, there's no "last working version" and no quick way to know what a change broke.
How to fix it
- Stop making changes. Every new change makes this harder.
- Go back to the last version that worked. Use your builder's history, or Git if the project is synced to a repository. If it isn't, set that up now so it never happens again.
- Find the first real error. The browser console, the server log or the terminal. Copy the exact message.
- Fix one thing, then check. Give the AI the exact error and ask for the smallest change that fixes only that. Test before asking for anything else.
- Check every package it added actually exists and is the one you meant, on the package registry, before installing it.
- Save a working version after each fix (a commit, or the builder's checkpoint).
- Add a few tests for the flows that matter, so the next change can't silently break them.
When to call Preventionlabs
If going back a version and fixing one error at a time gets you moving, keep going. Call us when there's no working version left, the AI keeps going in circles, or the app works in the builder and nowhere else. A resurrection makes what's already there work: it builds and starts on maintained dependencies, deployed in your own hosting account, with the user flows you list working end to end. It doesn't add features the app doesn't already have. It gets the ones you have working, and live.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- Spracklen, Wijewickrama, Sakib, Maiti, Viswanath and Jadliwala: We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMsresearch paper (arXiv)
the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models
- Perry, Srivastava, Kumar and Boneh (ACM CCS 2023): Do Users Write More Insecure Code with AI Assistants?peer-reviewed research
Furthermore, we find that participants who trusted the AI less and engaged more with the language and format of their prompts (e.g. re-phrasing, adjusting temperature) provided code with fewer security vulnerabilities.
- Bolt: GitHub for version controlplatform docs
Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.