Vibe-Coded Software Audit: What Breaks Before Launch

You prompted your way to working software. It signs people up, it shows the right screens, it demos well. And you have never read the code that runs it. That is the situation a vibe-coded audit is built for. The plain truth underneath it is uncomfortable but simple: you cannot trust code you have never read. Before real money or real users touch it, someone who reads code for a living has to look at what the model actually wrote, not at what it looks like it does.

This is not an argument against building with AI. It got you a product faster than any other route would have. It is an argument for checking that product the same way you would check anything that is about to hold customer data and take payments.

What is a vibe-coded audit?

A vibe-coded audit is a structured read of AI-generated code for the risks the model skipped. It is not a feature review. A feature review asks "does it do what the user wants." An audit asks the questions the prompt never did: who can read this data, what happens when this call fails, where did this secret end up, what breaks at a thousand users instead of ten.

The distinction matters because the failures here are invisible from the outside. The product looks finished. The gaps sit in the parts no demo exercises: the path where the network drops, the request that arrives twice, the user who edits the URL to read someone else's record. We read the code to find those before a user does.

The seven things we check first

Every audit starts in the same places, because vibe-coded software fails in the same places. These are the findings we surface most often.

• Security and authorization. The login works. The check that stops user A from reading user B's data is missing, or it lives in the frontend where anyone can step around it. This is the most common serious finding, and the most expensive to miss.
• Data integrity. Writes that can half-complete. A record saved with no matching record it depends on. State the database cannot actually guarantee, so the numbers drift over time and nobody knows why.
• Leaked secrets. API keys, database URLs, and tokens hardcoded in client-side code or committed to the repo. The model pastes them inline because that makes the example run. Anyone who opens the bundle can read them.
• Error handling. The happy path is covered. A failed call, a timeout, or an empty result throws an unhandled exception and the screen goes blank, with no message and no recovery.
• Scalability and queries. A database call looped inside a render, or a whole table pulled to count its rows. Fine with ten records in the demo, fatal with a hundred thousand in production.
• Dependencies and licences. Packages that are outdated, abandoned, or carry known vulnerabilities, plus licences that quietly forbid the commercial use you are planning.
• Test coverage. Usually none. There is nothing stopping the next change, AI-written or not, from silently breaking what already works.

"The danger of vibe-coded software is not that the code is bad. It is that nobody has read it. Trust is the one thing a model cannot hand you, and it is the only thing that decides whether you can launch."

Severity: what blocks launch versus what can wait

Not every finding stops a launch, and treating them as if they do just freezes you. We sort everything we find into three buckets so you know what to fix tonight and what to schedule.

• Blocker. Anything that exposes customer data, loses money, or corrupts state. A broken authorization check or a leaked payment key does not wait. The launch waits for it.
• High. Real risk that has not bitten yet. The query that dies at scale, the missing error handling on a payment path, the abandoned dependency with a known CVE. Fix before you grow into it.
• Cleanup. Debt that is real but survivable. Inconsistent patterns, thin validation on low-stakes inputs, missing tests on stable code. Worth doing, safe to schedule.

The point of the split is honesty about urgency. We will not dress a cleanup item up as a blocker to pad the work, and we will not let a real blocker hide in a long list.

What you actually get

The deliverable is not a PDF of complaints you cannot act on. It is two things. First, a findings report: every issue, its severity, and what it puts at risk, written so a non-technical founder can decide what matters. Second, a fixed branch with tests: the blockers closed, the highs addressed where scope allows, and a regression suite that holds the fixes in place. You get working code back, not a list of reasons it is broken. If you want the deeper mechanics of how that hardening pass runs, we cover it in QA for AI-generated code.

Audit versus full QA versus rebuild

These are three different calls, and the honest answer depends on what the read turns up.

• Audit. The right call when the product mostly works and you need to know what is hiding before you scale or take payments. Fast, focused, ends in a findings report and a fixed branch.
• Full QA. The right call once the product is real and ongoing. A standing process of tests, reviews, and hardening that keeps the next change from undoing the last one. The audit is often the first step into it.
• Rebuild. Sometimes the read shows the core itself is wrong, a data model that cannot hold what you need, or the same broken pattern copied across the whole codebase. When that happens, rebuilding the core is cheaper than patching it forever, and we will say so on the first call rather than bill you to patch a foundation that needs pouring again.

Cost and timeline

An audit runs from a few days to about two weeks. The range is honest, not evasive, and two things move it: how big the codebase is, and how much real money or sensitive data it touches. A read-only internal tool sits at the short end. A product that takes payments and holds personal data sits at the long end, because those are exactly the parts that need the closest read. We scope it after a first look, not before, and we tell you the band up front rather than discover it on your invoice. This is the front end of our software QA service.