Vibe-Coded Software Audit: What to Check Before Launch

You prompted your way to working software. It signs people up, shows the right screens, and demos well. But if nobody has reviewed the implementation, important assumptions remain untested. Before real money, personal data, or many users touch it, the code and its operating environment deserve a risk-based review.

This is not an argument against building with AI. AI-assisted tools can shorten the path to a prototype. Production readiness still requires the same secure-development disciplines as other software. The NIST Secure Software Development Framework organizes those disciplines around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.

What is a vibe-coded audit?

A vibe-coded audit is a structured, risk-based review of an AI-assisted system beyond its visible features. A feature review asks whether the product does what a user expects. An audit also asks who may read or change each record, what happens when a dependency fails, where credentials live, how duplicate requests behave, and what evidence supports a safe release.

Some failures do not appear on the happy path. Examples include a network interruption, a retried payment request, or an object identifier changed to access another account. Code review, configuration review, and targeted tests help expose those conditions before launch. The OWASP Application Security Verification Standard 5.0 provides a current basis for testing web application technical security controls.

What should the review cover?

The exact scope depends on the architecture and risk profile. These are common review areas, not a claim that every AI-assisted codebase contains the same defects.

• Authentication and authorization. Verify that server-side controls prevent one user from reading or changing another user's resources. Broken Access Control remains the first category in the OWASP Top 10:2025, which makes it a sensible priority, not proof that it is the most frequent finding in a particular audit.
• Data integrity. Check transaction boundaries, constraints, idempotency, and recovery so partial writes or duplicate requests do not leave inconsistent state.
• Credentials and configuration. Look for secrets in client bundles, repositories, logs, build output, and overly broad runtime permissions.
• Error and recovery paths. Exercise timeouts, unavailable dependencies, empty results, retries, and user-visible recovery rather than testing only successful calls.
• Performance and capacity. Inspect query patterns and measure representative workloads. A pattern that works with demo data may become slow or costly at a larger scale, but the threshold must be tested rather than guessed.
• Dependencies and licences. Inventory components, review known vulnerabilities and maintenance status, and check whether licence obligations fit the intended distribution and use. NIST SP 800-204D specifically includes dependency review and controls intended to keep secrets out of commits.
• Test evidence. Assess existing unit, integration, security, and acceptance tests. Coverage varies by project, so the goal is evidence for the highest-risk behavior, not an assumed percentage.

"A polished demo is useful evidence that the happy path works. A launch decision also needs evidence about access control, failure handling, data integrity, and recovery."

Which findings block the launch and which can wait?

Severity should reflect impact, likelihood, exposure, and the available safeguards. We use three practical planning buckets, then document the reasoning for each finding.

• Blocker. A credible path to exposed customer data, unauthorized money movement, unrecoverable corruption, or a similarly severe outcome may justify delaying launch until it is fixed or otherwise contained.
• High. A consequential weakness with meaningful exposure often needs remediation before broader rollout, even when it has not yet caused an incident.
• Cleanup. Lower-risk maintainability or consistency work can usually be scheduled, provided it does not combine with other weaknesses into a larger risk.

This classification is context-dependent. The same defect can receive a different priority in an internal read-only tool and in an internet-facing payment product.

What do you actually get from the audit?

The agreed statement of work should define the deliverables. Wavect typically proposes a findings report that explains each issue, its severity, evidence, and recommended action. When remediation is included, the scope can also cover a fixed branch and focused regression tests. It should not be assumed that every finding or every refactor is included unless the proposal says so. For the deeper mechanics of a hardening pass, see QA for AI-generated code.

Audit, full QA, or rebuild: which one do you need?

These are different engagements, and the appropriate choice follows from the system's condition and business risk.

If the audited product moves money, the next problem is sequencing fixes without losing control of live payment paths. Our anonymized fintech architecture remediation case shows one project-specific sequence for typed foundations, authorization, idempotency, webhooks, and release gates without defaulting to a full rewrite.

• Audit. Appropriate when the product broadly works and the immediate need is a bounded risk assessment before launch, growth, or payment processing.
• Full QA. Appropriate when the product needs an ongoing process of tests, reviews, release checks, and hardening across successive changes.
• Rebuild. Worth evaluating when evidence shows that core constraints, architecture, or repeated patterns make targeted remediation disproportionately risky or costly. A comparison should include migration risk and the cost of preserving working behavior. Rebuilding is not automatically cheaper.

How much does a vibe-coded audit cost and how long does it take?

As of 2 September 2026, Wavect uses a planning range of a few working days to about two weeks for this service. This is a first-party planning range, not an industry benchmark or a fixed promise. Codebase size, architecture, documentation, deployment access, and the sensitivity of data and money flows can change the scope. We confirm the deliverables, price, and schedule after an initial look in the proposal. This audit is one entry point to our software QA service.