A vibe code audit is a structured review of an app built mostly through AI prompts, done before real users and real data touch it. A person who can read the code checks who can see what, where the secrets
live, how the app handles input, and whether anyone can maintain it. If you built the app with Cursor, Lovable, Bolt, Replit or Claude Code and you can’t say with confidence what is inside it, this is the step between a working demo and a product you can stand behind. We offer it as a fixed-price Vibe Check at $449 one-off, with a $59 ShipDoctor scan as a lighter first look.
TL;DR
- A vibe code audit is a human-led review of AI-generated code for security, reliability and maintainability before launch.
- In a study of 200 public vibe-coded apps, 91.0% had at least one vulnerability, and nearly two thirds of all findings were Critical or High severity.
- The most common problem is broken access control: users reaching data or actions they should not.
- Every AI-generated change needs a human owner. That is the rule behind a good audit and the rule that keeps the app safe afterward.
- Fix in order of damage: exposed secrets and open data first, then authentication, input handling, dependencies, and finally structure.
Table of Contents
- What a vibe code audit is
- Why AI-built apps need one
- What an audit checks
- Automated scans versus human review
- What you get back
- How to fix findings in the right order
- Keeping the app safe after launch
- What this costs
- Where Bowtie fits
- Our perspective
- FAQ
- Sources
What a vibe code audit is
Vibe coding means describing what you want in plain language and letting an AI tool write the software. It is fast, and it is how many founders get a prototype in front of customers in a weekend. The catch is that the person who ships the app often never read the code that runs it.
An audit closes that gap. Someone with engineering experience reads the codebase, tests how it behaves, and reports what is risky, what is broken, and what to repair first. It is not a rewrite and it is not a verdict on whether AI was a bad idea. It is the “last mile” review that turns a prototype into something you can put customers on.
It differs from a normal code review in one way. In a team that wrote its own code, reviewers can lean on the author’s understanding. In a vibe-coded app, nobody holds that understanding, so the audit has to rebuild it from the code itself.
Why AI-built apps need one
The evidence is now fairly plain. An academic study, Understanding the (In)Security of Vibe-Coded Applications, audited 200 publicly deployed vibe-coded applications and found 1,186 vulnerabilities. Ninety-one percent of the apps had at least one, and 65.77% of the vulnerabilities were rated Critical or High.

Those numbers matter for a nontechnical founder because the failures are not exotic. They are the ordinary mistakes that let a stranger read your customers’ records.
Industry research points the same way. Wiz Research reported in September 2025 that one in five organizations building on vibe-coding platforms was exposing itself to risk without realizing it. Its examples included passwords sitting in client-side JavaScript, database row-level security that was too permissive or switched off, and internal apps deployed to the public internet with no login.
None of this means the app is bad. It means the AI optimized for “it runs” and nobody checked for “it is safe to run in public.”
What an audit checks
A useful audit has a clear list. Here is what we look at and why each item matters to a business owner.
Access control: who can see and change what
This is the big one. In the study above, broken access control was the largest category: 339 vulnerabilities, 28.58% of all findings, present in 64.00% of the audited apps. In plain terms, a logged-in user can open another user’s invoice by changing a number in the address bar, or an admin page works for anyone who guesses its URL.
If your app uses a hosted database with row-level security (rules that decide which rows each user may read), an audit confirms those rules exist, are switched on for every table, and actually restrict users to their own data.
Authentication and sessions
Authentication failures, meaning weak login, password reset, or session handling, rank among the top three categories. The auditor checks how people sign in, how sessions expire, whether sign-in is enforced on the server rather than only in the browser, and whether admin accounts are protected.
Injection and input handling
Injection happens when the app treats user-typed text as a command. It is the third of the top three categories, which together make up 60.20% of all findings. The auditor looks for database queries built by gluing strings together, unsafe handling of uploads, and forms that trust whatever they receive.
Secrets and configuration
API keys, database passwords and payment keys should live in server-side environment settings, never in code that ships to the browser or sits in your repository history. An AI tool will sometimes paste a key straight into a file to make something work. This is quick to check and expensive to miss.
Dependencies
AI tools pull in packages freely, and sometimes suggest ones that are outdated or do not exist. OWASP’s guidance says to audit AI-generated dependency lists before merging and to set up your build pipeline to fail when a known-vulnerable dependency appears.
Deployment and operations
Can you deploy the same way twice? Is there logging, so you would know if something broke at 2 a.m.? Are backups tested? These questions decide whether a launch is a launch or a gamble.
Maintainability
The last check is whether another engineer could pick the code up. Duplicated logic, giant files and no tests make every future change risky. This is where the audit overlaps with refactoring, and we cover that in how to refactor AI-generated code without breaking it.
Automated scans versus human review
Both have a job, and a sound audit uses both.
Automated scanners are good at breadth. They flag known-vulnerable packages, secrets in files, and missing security headers in minutes. That is the idea behind a low-cost scan such as our ShipDoctor scan at $59 one-off: a quick, inexpensive first pass.
Scanners cannot judge intent. They do not know that your “customer” role should never see another customer’s order, or that a discount code endpoint can be abused. Those are logic flaws, and finding them takes a person reading the code against how your business works.
The rule that holds the whole process together comes from OWASP. Its Secure Coding with AI guidance says every AI-generated change should have a human owner responsible for its correctness, security and maintenance. It also recommends explicit developer approval before merging AI-generated code, with an audit trail of who approved it and which AI tool and model version produced it.
That is exactly what an audit supplies for code nobody owned. It names an accountable human, and it creates the record.

What you get back
A good audit report is something a nontechnical founder can act on. Expect:
- A ranked list of findings, with severity and a plain-language explanation of the business impact.
- The location of each problem in the code, so a developer can fix it without guessing.
- A recommended fix order.
- A view of what is sound, so you know what not to touch.
If a report is only a scanner printout with no priorities, you have paid for noise. Ask what you can do on Monday morning after reading it.
How to fix findings in the right order
Not everything is urgent. Work in this order.
- Close open data and rotate exposed secrets. If a key was ever in a public repo or browser bundle, treat it as compromised and replace it. Turn on and test access rules for every table.
- Fix authentication and authorization. Enforce sign-in and permission checks on the server for every sensitive action.
- Repair input handling. Use parameterized queries and validate what users send.
- Update dependencies and add automated gates. Have your pipeline fail on known vulnerabilities, as OWASP recommends. Our piece on QA for AI applications shows how to turn checks into release gates.
- Add monitoring and logging. You cannot respond to what you cannot see.
- Refactor for the long term. Break up the largest files, add tests around the critical paths, and document how the thing deploys.
Be careful with step six. Tidying AI code without tests around it can break what works. That is why the order matters and why the tests come first.
Also expect to repeat the work. The same study found that better prompting and agent setups reduce vulnerabilities but do not eliminate the underlying risk. Every new feature the AI writes can reintroduce the same class of flaw.
Keeping the app safe after launch
An audit is a snapshot. The app changes every time someone prompts a new feature, so the routine matters more than the single review.
- Give every AI-generated change a named human approver.
- Review every file in an agent-generated change, not just the one you asked about. OWASP specifically advises this.
- Keep a build pipeline that blocks merges when tests or dependency checks fail.
- Watch logs and alerts so problems reach you before customers do.
- Re-audit after major features, new integrations, or a change in the kind of data you hold.
For U.S. businesses, a common reference point is NIST’s Secure Software Development Framework, SP 800-218, which describes practices for secure development environments, release provenance, tracking security requirements and responding to vulnerabilities. It is a useful yardstick if enterprise or government customers ask how you build software. If you handle regulated data such as health or payment information, talk to your compliance counsel or qualified assessor about the specific rules that apply to you; an audit report supports that conversation but does not replace it.
What this costs
Our published prices for this work, all in U.S. dollars:
| Option | Price | Best for |
|---|---|---|
| ShipDoctor scan | $59 one-off | A fast first look at an app |
| Vibe Check | $449 one-off | A review of a vibe-coded app before launch |
| Ship Shape Service | from $1,850 per month | Ongoing help getting and keeping the app production-ready |
| Crew Service | from $2,950 per month | Continuing engineering support beyond a single review |
For larger systems we also offer a Senior Developer Review from $449 one-off and deeper assessments, such as a CI assessment at $4,500 or an infrastructure assessment at $2,750.
Compare any of these with the cost of a breach, a leaked customer list, or a launch you have to pull back. The audit is the cheap part of that equation.
Where Bowtie fits
We combine AI expertise with experienced human engineers, and our focus is clean, secure, production-ready code. If your app is vibe-coded and you are not sure what is inside, the Vibe Check is the place to start: a $449 one-off review of what you have built. If you want us to carry on after the findings, the Ship Shape and Crew services keep support going beyond launch, so the fixes do not get undone by the next round of prompts.

You can see everything we do for AI-built software on our services page, including AI code reviews and optimization and team augmentation. For background, read why every AI application needs a professional code audit and what production-ready AI code takes.
Our perspective
We see the same story from founders again and again. The prototype works, the demo goes well, and then comes the question nobody planned for: is this safe to put customers on?
Our answer is that AI is a superb way to start and a poor place to stop. The model writes quickly, but it does not own the result. A person has to. That is why we pair AI tooling with experienced engineers who read the code, test the risky paths and tell you plainly what to fix.
We also think an audit should never be a one-time shock. The best outcome is a codebase you understand, a short list of fixes in a sensible order, and support that continues after launch, so the next feature does not reopen the last problem.
If you are a nontechnical founder holding an app you did not write line by line, you are not behind. You are one review away from knowing where you stand.
Chad
FAQ
How long does a vibe code audit take?
It depends on the size of the app and how many integrations it has. A scan returns results in minutes, while a human review of a small to mid-size app is a matter of days rather than months. The scope and timing for your app are agreed up front on our Vibe Check page.
Do I need an audit if my AI tool already has built-in security checks?
Built-in checks help catch known patterns, but they do not know your business rules. Whether one customer can reach another’s data is a question about your app’s logic, and it takes a human reading the code. An audit covers that gap.
Is a vibe code audit the same as a penetration test?
No. A penetration test attacks a running system from outside to see what breaks. An audit reads the code and configuration from inside, which also reveals maintainability and deployment problems. Many teams use the audit first, fix what it finds, and then decide whether an outside test is warranted for their customers or industry.
Will the audit tell me to rebuild everything?
Usually not. Most apps need targeted fixes in a sensible order, not a rewrite. Where parts are too tangled to repair, the report says so and shows which parts to replace and which to keep.
What should I have ready before an audit?
Access to the code repository, a list of the services the app connects to, such as the database, payments and email, and a short description of who the users are and what data they hold. That context lets the reviewer judge risk against how your business actually works.
Sources
- Understanding the (In)Security of Vibe-Coded Applications
- Wiz Research: Risks in 20% of Vibe-Coded Apps
- Secure Coding with AI, OWASP Cheat Sheet Series
- NIST Secure Software Development Framework (SP 800-218)