Built fast with AI. Now it almost works.

What vibe coding is, and where it stops

AI tools let almost anyone build working software in days. That is a real gain for testing ideas. It becomes a risk when the result quietly turns into the product.

Simon Willison, co-creator of the Django web framework, gives the clearest definition of vibe coding: (Willison, 2025)

building software with an LLM without reviewing the code it writes. (Willison, 2025)

He considers it fine for low-stakes projects and prototypes, and recommends checking with someone more experienced before sharing anything that other people will use. The Thoughtworks Technology Radar goes further: it “strongly caution[s] against using it for production code.” (Willison, 2025) (Thoughtworks Radar, 2025)

The same applies whoever built it: an AI app builder, a freelancer or agency delivering mostly AI-written code, or your own team working with AI agents. What matters is not that AI wrote the code, but that nobody reviewed it.

What goes wrong underneath

AI-built software can look finished and work in a demo, while the problems sit where nobody looks.

Security is the most serious. At the IEEE Symposium on Security and Privacy, researchers found security weaknesses in about 40% of 1,689 programs written by an AI coding assistant. A 2025 benchmark presented at ICML tested AI models on 392 realistic back-end tasks: even the best model produced correct code only 62% of the time, and attacks succeeded on around half of the correct programs. (Pearce et al., 2022) (Vero et al., 2025)

The most common flaw in web applications generally is broken access control: users reaching data or functions that aren't theirs. OWASP reports that “100% of the applications tested were found to have some form of broken access control.” AI-generated apps are no exception. (OWASP Top 10:2025)

Quality problems follow. Erik Doernenburg of Thoughtworks recorded what a coding agent did in his own project: it duplicated logic instead of reusing existing functions, weakened type checks so the code would compile, and proposed “a completely unnecessary cache.” (Doernenburg, 2026)

Over time this becomes what Thoughtworks calls codebase cognitive debt: “the growing gap between a system's implementation and a team's shared understanding of how and why it works.” Then fixing one thing breaks two others. (Thoughtworks Radar, 2026)

Secure what's exposed

If the software is live and holds personal data or payments, security comes before anything else.

Check these first:

• Database access rules: can a user read or change only their own data? Try it with a second test account.
• Keys and passwords in the code or in the app sent to the browser. Move them out and replace them.
• Admin pages and internal functions reachable without logging in.
• Outdated or unknown software packages, with an automated dependency scan.
• Backups that exist and can actually be restored.

Then have the security reviewed by someone other than the builder, against a recognised standard. The OWASP Application Security Verification Standard (ASVS) “provides a basis for testing web application technical security controls” and is widely used for exactly this. (OWASP ASVS)

Take ownership

You can't repair what you can't reach. Make sure the company, not one person, controls the software.

• Access to the code repository, with its full history.
• Access to hosting, the database, domain names and every external service the app uses.
• The account of the AI app builder, if one was used, and a way to export the code.
• The contract: who owns the code, and what happens when the builder stops working on it.
• The builder's notes, and the instructions or prompts they gave the AI. They explain why things are the way they are.

Store the access details in the company's password manager, not in someone's personal account.

Pin down what works today

Before changing anything, record what the software does now, so you notice when a change breaks it.

Write automated tests for the flows the business depends on: sign-up and login, payment, the core feature customers come for. They describe today's behaviour, including its quirks; the point is to notice change, not to judge it yet.

These tests also let AI tools help with the repair safely. Anthropic's documentation for its coding agent calls a check the AI can run “the difference between a session you watch and one you walk away from.” (Claude Code docs)

Map the system

Write down how the software works, so the knowledge stops living in one head, or in none.

A useful map is short: the main parts and what each does, where data is stored, which external services are called, how it is deployed, and the known weak spots. Store it with the code, where both people and AI tools will read it.

This is the first step against cognitive debt. Thoughtworks also recommends tracking the team's cognitive load and adding automated checks on the architecture, so the design stays visible as the code changes. (Thoughtworks Radar, 2026)

Decide per part: keep, repair or rewrite

Not every part deserves the same care. Decide part by part, not for the whole system at once.

Birgitta Böckeler of Thoughtworks suggests three questions for any AI-generated code: (Böckeler, 2025)

• How likely is it to be wrong?
• If it is wrong and nobody notices, what are the consequences?
• Will anyone notice when it is wrong?

A full rebuild is sometimes the right answer, but it should be a conclusion from this review, not a reflex. What already works is worth keeping.

Repair in small, tested steps, and check it can grow

Change one thing at a time, run the tests, and keep each change small enough to undo.

Typical repairs: remove duplicated logic, simplify what is overly complicated, give each part a clear job, and add tests as you go. Small steps keep the software working while it improves.

If you expect much more use, test it at that scale before your customers do: how it behaves with ten times the users, and what hosting and any AI services will cost at that level. Software that works for ten users can fail at a thousand.

Keep using AI, with guardrails

The aim is not to stop using AI. It is to make sure the next feature doesn't repeat the problem.

Böckeler calls the set of guides and automatic checks around a coding agent its harness: instructions it reads, tests it runs, rules checked on every change. With that in place, AI can keep building on the software safely. (Böckeler, 2026)

Rescue checklist

For the owner, with whoever does the technical work.

• Database access rules, keys, admin pages and dependencies are checked.
• Security is reviewed against OWASP ASVS by someone other than the builder.
• The company controls the code, hosting, database and accounts.
• Who owns the code is clear in the contract.
• Tests cover sign-up, payment and the core feature.
• A short map of the system is stored with the code.
• Each part has a decision: keep, repair, rewrite or remove.
• Repairs happen in small, tested steps.
• The software is tested at the expected scale.
• AI keeps being used, with tests, checks and review.

What this would look like for you