How to fix an AI-built website before you rebuild it
When an AI-built website is broken, the question that gets asked is almost always "do I fix it or do I rebuild it." That framing is the trap. The trap is that there are three real paths, not two, and most people who escalate to a full rebuild did it because nobody ran the diagnostic that would have made one of the other paths work.
Repair is one path. Rebuild is another. The path in the middle, which gets skipped because nobody named it, is stabilization. A stabilization sprint takes the existing draft, runs it through the production-readiness gates that should have been run before launch, and either gets it shippable or proves that it isn't. Either outcome saves money compared to a blind rebuild.
I want to walk through the diagnostic that picks between those three, because once you have it, the decision is usually quick.
What "broken" actually means
Before you can choose a path, you have to know what shape of broken you are looking at. The diagnostic question is the same question I ask on every build that comes apart: where exactly does the user path dead-end. Not "the site feels broken." Not "it doesn't work right." Where, in concrete steps, does the visitor stop being able to do the thing the site is for.
The diagnostic should produce one of three answers:
The dead-end is a single feature. Form doesn't submit. A button doesn't navigate. A page returns the wrong content. The rest of the site is fine.
The dead-end happens across multiple features but in a specific environment. Works in some browsers, breaks in others. Works on desktop, breaks on mobile. Works in preview, breaks in production. Multiple things fail in a correlated way.
The dead-end is everywhere. Pages don't render correctly. Layout collapses. Multiple flows are broken. Nothing feels stable.
These three answers map to the three paths.
When repair is the answer
If the dead-end is a single feature, repair is the answer. One isolated bug means the underlying architecture is mostly fine. The fix is to identify the specific failure, write the change, verify it end to end, and ship.
This is the cheapest path. It's also the path AI tools were designed for. A well-scoped repair task, with a clear definition of "done" and a way to verify, is exactly the shape of work where AI agents can do most of the work without supervision drift.
The trick is the definition of "done." Most failed repairs failed because "done" meant "the AI said it changed the file" instead of "I loaded the page and watched the user path complete." The methodology that covers this gap is in the-gate-that-caught-us, and the short version is: the functional leg comes before the performance leg, and "complete" means a human watched the thing work after the change.
If your diagnostic returns shape one (single isolated failure), repair is the path. Budget a day or two of focused work.
When rebuild is the answer
Rebuild is the right answer in two specific cases. The first is when the AI-generated codebase has accumulated enough load-bearing junk that adding another fix on top would create more damage than it removes. This usually shows up as a file structure nobody can navigate, three different state-management approaches running in parallel, components that share no styling pattern, or a build pipeline that takes an unreasonable amount of time to do basic checks.
The second case is when the site, as it exists, doesn't actually match what the business needs. Sometimes the AI built a beautiful working brochure site for a business that needed an e-commerce site. The features that aren't there are the ones the business actually depends on. No amount of repair fixes a category mismatch.
In both rebuild cases, the right move is to use the existing site as a reference for what the business wants the visitor experience to be, then build the new version with a real architecture from the start. The old site is documentation, not a foundation.
Rebuild is the most expensive path. It's also the most strategically valuable when it's actually the right call, because the second build (with the lessons of the first) is usually substantially better than what the first build could have become with more patching.
When stabilization is the answer
This is the path that gets skipped because nobody names it, and it's the most common right answer. Stabilization assumes the AI-built site is approximately correct in structure but was launched without the production-readiness work that should have come before launch.
What gets done in a stabilization pass: the site gets run through the gates that should have run before deploy. Forms get tested with real submissions. Performance gets measured. Mobile rendering gets verified on real devices. Privacy-browser behavior gets checked. SEO surface gets audited. The full visitor path gets walked, every entry point, every form, every link, every button, end to end.
The output of a stabilization pass is one of two things. Either the site is now genuinely launch-ready and the visitor experience holds up, or the audit surfaces blocking issues that prove the site needs a rebuild. Either way you stop the repair-rebuild loop with a clear answer.
Stabilization is faster than rebuild and more honest than repair. If your diagnostic returned shape two (correlated failures in specific environments) or shape three (broad instability), stabilization is usually the path that should run first. The decision about rebuild can wait until the audit is done, and frequently the audit makes the decision obvious.
The structural pattern behind stabilization is the three-leg gate: structure, function, performance. Run all three. The methodology comes from the catch documented in two-bugs-one-symptom. The principle is that surface signals (greps, file checks, build output) need to be paired with semantic signals (does the rendered page actually behave the way a user expects). A site that passes structure but fails function isn't fixed. A site that passes function but fails performance isn't fixed either.
The decision tree
Single feature broken: repair.
Multiple features broken in a correlated way: stabilization first, decide on rebuild after.
Broad instability across the site: stabilization first, rebuild likely.
Beautiful site but doesn't match the business: rebuild.
If you can't tell which one you're in, the diagnostic itself is the work. Pay for the diagnostic. It costs less than a wrong path and it gives you a defensible answer to "what should I do next."
Why this matters more than it sounds
The reason this matters is that most "AI built my website, it doesn't work, I had to pay twice" stories are stories about a wrong path. Somebody picked rebuild when repair would have worked. Or somebody picked repair when stabilization was the answer. Or somebody bounced between repair attempts for three rounds before admitting the codebase needed a rebuild.
Each of those wrong-path stories costs money and trust. The diagnostic costs a fraction of either path. Running the diagnostic first is the cheap move.
Got an AI-built site that's failing in real use and you can't tell which path it needs? Send the site URL, the failure description, what you've tried, and your timeline. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded