Vibe-Code to Production

An app now comes together from a few sentences of instructions in hours: a feature gets requested in Cursor, an interface gets designed in Lovable, a backend spins up in Replit, Codex or Claude Code wires up an integration. Screens render, forms save data, login works. But the model that wrote it was optimizing for finishing the request, not for holding up in production. Veracode's 2025 report, testing over a hundred models, found that 45 percent of generated code carried an OWASP Top 10 flaw, and model size did not change that rate. In an independent audit of vibe-coded applications, only 10.5 percent came back secure. The problem isn't limited to security either: integrations like payments or authentication get left half-built, the app has never been tested under real user load, and AI calls go out with no spend cap or rate limit. This service exists for that exact point: teams who got their product to a certain place with these tools and now don't know what's missing before it goes live.

Three situations, three different entry points

People come to us in one of three states. The first is a live leak: user data, an API key, or another customer's record is visible by mistake, and either you or a security researcher noticed. The second is a pre-launch check: the product is considered done, but nobody looked at security and resilience systematically, and someone wants a professional pass before it goes live. The third is a growth stall: the code has become a pile nobody wants to touch, every feature shipped quickly risks breaking something else, and nobody knows where to start. The first step is the same in all three: read the existing code and separate what works from what happens to work.

Three stages: find, fix, install the gate

Most vibe-code audits deliver one thing: a report ranking findings. A finding list does not change your codebase, it only tells you where you stand. Our work runs in three stages: audit first, covering not just security flaws but half-built integrations, endpoints never tested under load, and the cost risk of unbounded AI calls; fix second; and third a permanent security gate wired into your CI/CD pipeline, the automated system that builds and ships your code with every update. Without the third stage the other two are temporary, because the next AI-assisted commit reproduces the same failure class. Once the gate is in place, every new change you or your AI tool pushes is scanned automatically and blocked before it merges.

Where we look during the audit

Four areas get scanned every time, because nearly every real leak comes from one of them: who can see what, where secrets are sitting, whether dependencies actually exist, and where user input ends up. Alongside these we flag half-built integrations such as payments or authentication, and endpoints that will break under real traffic; these aren't a separate line item, they're part of the same pass.

Access control and visibility permissions

The most expensive failure class is access control, because it stays quiet. In the Tea app, flawed authorization logic the model generated exposed private messages to other users. Every project created on Lovable before November 2025 was exposed for 48 days; a free account could reach another user's source code, database credentials and customer data. In both cases the code ran fine and the screens looked right; the problem sat where tests never look: whether a user can swap their own ID and reach someone else's record. During the audit we test every endpoint by hand for who can see which record, because an automated scanner alone does not catch this.

Secret and credential leaks

AI-assisted commits expose secrets at twice the rate of human-written code: an API key, a database password, a third-party token ends up hardcoded or dropped into Replit's environment file. The model is not doing this maliciously, it is taking the shortest path to a working example, and the shortest path usually means writing the secret as plain text. The audit scans the entire codebase, including past commits, because once a secret has entered history, deleting it from the environment file is not enough; the key itself has to be rotated.

Dependencies and hallucinated packages

When models are prompted for code, on average a fifth of the packages they suggest do not actually exist, and these names are not random: rerun the same prompt and a high share of the same hallucinated names come back. That predictability created a new attack class called slopsquatting. An attacker registers a real package under the hallucinated name and drops malicious code inside it, and because the model recommended that exact name, a developer installs it without noticing. During the audit we check whether every package in your dependency list actually exists and whether its download count and maintenance history look reasonable.

Input validation and injection-class bugs

In the same Veracode report, 86 percent of tested code was vulnerable to XSS, meaning a user's input gets written straight into the page and runs in the browser, and 88 percent was open to log injection, where unchecked data gets written into server logs. Both come from the same root: data coming from a user is never cleaned before it is written to the screen or dropped into a query. Model-generated code usually works fine for the intended use case, not for a malicious one. During the audit we trace every user input to see where it ends up, whether that's the screen, a query, or a file path, and whether validation exists at that point.

Fixing and locking it in

Finding issues is never sold apart from fixing them; they come together, because a finding list on its own protects no one. The fix isn't limited to security either: finishing a half-built payment integration, completing an authentication flow, or adding spend and rate limits to AI calls all move through the same package.

The fix: mergeable code, not a report

We do not stop at the finding list. Every finding gets its own pull request, a self-contained proposed change you can review and approve: the files that changed, the reasoning, and a test that proves the hole existed before the fix. Priority follows severity and proximity to user data; an access bug leaking personal data in production is closed before a configuration issue that has no measurable impact. We work like a new engineer reading your codebase, not imposing our own preferences; we make the smallest change that fits the architecture you already have.

A security gate built into CI/CD

A fix is not permanent, because your AI tool can reproduce the same mistake tomorrow. That's why the last step is embedding static analysis, dependency scanning and secret scanning into your release pipeline: every pull request is scanned automatically, and a critical finding blocks the merge. The gate works the same regardless of who pushes the change; whether you wrote it by hand or an AI agent committed it makes no difference. This gate gets added to a CI/CD pipeline you already have, or built together with our DevOps and CI/CD service if you don't have one yet. Once the gate is running, the same failure class stops reaching production at all, and your own team can maintain it without needing us again.

How scope gets defined

Scope gets written down during the scoping call: which repository, which environment, which integrations are included. Which AI tool produced the code doesn't change the audit's scope; everything goes through the same process. The audit scans known failure classes that can be found with current knowledge, and every class we scan closes with either a fix or a knowingly accepted risk note. An architectural decision, redesigning the entire data model for instance, falls naturally outside this audit's boundary; if that need comes up, the work moves to Backend Scaling or CTO as a Service. Because this clarity is built in from the start, what each side is getting is clear from the first day of the conversation.

Initial scan findings

A first scan of a vibe-coded application turns up almost the same three things nearly every time, regardless of which tool produced the code: an admin screen reachable without authentication, at least one API key hardcoded into the source, and at least one user input with no real validation. An independent scan of more than five thousand publicly deployed vibe-coded apps in May 2026 found that around 40 percent exposed sensitive data such as medical or financial records, and more than two thousand corporate apps had no access control at all. We hold ourselves to the same discipline: every piece of code we ship, this site included, passes through a sanitization layer that lets nothing past its allowed tag list and an automated pre-commit review. We don't recommend a method we don't apply to our own work.

Process: from first contact to delivered code

The process runs in four steps. It starts with a short scoping call covering which repository, which environments and which integrations are involved. From there the audit follows, usually taking three to five business days and ending in a written finding list ranked by severity, one that can also be taken on its own. The fix comes next, with its length depending on how many findings are in scope, and each one arrives as its own pull request. The last step installs the CI/CD gate and runs a trial with your team. Everything closes with a handover document covering what each check looks for, what to do when it fires, and how your team updates the gate going forward.