--- title: "Vibe-Coded Software Audit" canonical: https://wavect.io/blog/vibe-coded-software-audit/ language: en description: "You cannot trust code you never read. The audit Wavect runs on vibe-coded software, seven things we check first, and what blocks launch vs what can wait." image: "https://wavect.io/img/blog/headers/header_vibe-coded-software-audit.png" --- [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 7 min read · 08 Jun 2026 [**Next**](/blog/qa-for-ai-generated-code/) # Vibe-Coded Software Audit: What Breaks Before Launch TL;DR You cannot trust code you have never read: a vibe-coded audit is a structured read of AI-generated code for the risks the model skipped, before real money or real users touch it. The most common serious finding is a missing or frontend-only check stopping user A from reading user B's data. An audit runs from a few days to about two weeks depending on codebase size and how much money or sensitive data it touches, scoped after a first look. Related service: [Vibe Coding Rescue](/services/vibe-coding-rescue/) 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. ## What breaks first in vibe-coded software? 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. ![Christof Jori](/img/team/christof.webp) "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." ## Which findings block the launch and which 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 do you actually get from the audit? 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](/blog/qa-for-ai-generated-code/). ## Audit, full QA, or rebuild: which one do you need? 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 as a [custom software development](/services/software-development/) project 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. ## How much does a vibe-coded audit cost and how long does it take? 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](/services/software-quality-assurance/). ## Final thoughts Vibe-coded software is not worse software. It is unread software. The model wrote a confident first draft and skipped the parts nobody prompted for, which happen to be the parts that decide whether the thing survives real users. That work did not disappear. It is waiting for you at launch, where it is most expensive to discover. If you shipped something you have never read and money or users are about to touch it, get someone to read it first. An audit is a few days against the cost of finding the same gaps the hard way, after the incident instead of before it. ## You may also like.. [**From Lovable and Cursor Prototype to Production** How a weekend AI prototype becomes software you can actually launch, and the work that sits between the two.](/blog/lovable-cursor-prototype-to-production/) [**Wavect vs Dotbite** A fair comparison of two Austrian software shops, and which one fits a founder-led AI build versus a custom-software project.](/compare/wavect-vs-dotbite/) QA and production readiness ## Continue through this cluster [Start with the cornerstone**QA for AI-Generated Code**](/blog/qa-for-ai-generated-code/) - [External QA Benchmark: What We Find in the First 30 Days](/blog/external-qa-benchmark-first-30-days/) - [What Software Maintenance Costs After Launch: A DACH SaaS Benchmark](/blog/software-maintenance-cost-benchmark-dach-saas/) - [Agile De-engineering](/blog/agile-de-engineering/) - [Lovable, Bolt, and Replit App Due Diligence](/blog/lovable-bolt-replit-app-due-diligence/) - [The Vibe-Code Production-Readiness Checklist](/blog/vibe-code-production-readiness-checklist/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 7 min read · 08 Jun 2026 [**Next**](/blog/qa-for-ai-generated-code/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/vibe-coded-software-audit/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/vibe-coded-software-audit/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "You cannot trust code you have never read: a vibe-coded audit is a structured read of AI-generated code for the risks the model skipped, before real money or real users touch it. The most common serious finding is a missing or frontend-only check stopping user A from reading user B's data. An audit runs from a few days to about two weeks depending on codebase size and how much money or sensitive data it touches, scoped after a first look.", "articleBody": " Blog overview/Delivery and QA/QA and production readiness Vibe-Coded Software Audit: What Breaks Before Launch TL;DR You cannot trust code you have never read: a vibe-coded audit is a structured read of AI-generated code for the risks the model skipped, before real money or real users touch it. The most common serious finding is a missing or frontend-only check stopping user A from reading user B's data. An audit runs from a few days to about two weeks depending on codebase size and how much money or sensitive data it touches, scoped after a first look. Related service: Vibe Coding Rescue 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. What breaks first in vibe-coded software? 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.\" Which findings block the launch and which 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 do you actually get from the audit? 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-08", "description": "You cannot trust code you have never read: a vibe-coded audit is a structured read of AI-generated code for the risks the model skipped, before real money or real users touch it. The most common serious finding is a missing or frontend-only check stopping user A from reading user B's data. An audit runs from a few days to about two weeks depending on codebase size and how much money or sensitive data it touches, scoped after a first look.", "headline": "Vibe-Coded Software Audit: What Breaks Before Launch", "image": "https://wavect.io/img/blog/headers/header_vibe-coded-software-audit.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/vibe-coded-software-audit/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/vibe-coded-software-audit/", "wordCount": 1567 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/delivery-qa/", "name": "Delivery and QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/qa-production/", "name": "QA and production readiness", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/vibe-coded-software-audit/", "name": "Vibe-Coded Software Audit | ", "position": 5 } ] } ```