In February 2025, Andrej Karpathy tweeted a phrase that gave a name to something engineering teams had been feeling for months: "vibe coding" — describing a workflow where developers prompt an AI model, accept its output, and move on without reading the diff line by line. A year later, the phrase has stopped being a joke about hobby projects and become a boardroom risk category. Garry Tan told YC founders in early 2025 that roughly a quarter of that winter's batch had codebases that were 95% AI-generated. Veracode's 2025 GenAI Code Security Report tested over 100 LLMs across four languages and found 45% of generated code samples failed basic security tests — Java hit a 72% failure rate. Application security reviews built around human-paced pull requests were not designed for this volume or this kind of author. Here is what's actually changing, and what it means for teams shipping AI-assisted code.
What does "vibe coding" actually mean for AppSec teams?
It means the unit of review has changed from "a developer's intent" to "a model's guess," and most AppSec workflows still assume the former. Karpathy's original description was explicit: you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." That's a fine way to prototype a weekend project. It's a dangerous default for production systems, because the person hitting "accept" often can't explain why the code works, let alone whether it's safe. A 2025 Stack Overflow developer survey found trust in AI-generated code accuracy actually fell year-over-year even as adoption rose — 84% of developers were using AI tools, but only 33% said they trusted the output. That gap between usage and trust is exactly where security review used to catch problems. When the reviewer is also unsure why the code is correct, traditional line-by-line review loses its signal.
How much AI-generated code is actually shipping to production right now?
A lot, and the share is growing faster than review processes are adapting. GitHub's own data from 2025 put AI-assisted code at roughly 30-46% of new lines in repositories with Copilot enabled, depending on language, with numbers trending upward through the year. Y Combinator's Garry Tan reported in March 2025 that about a quarter of the current YC batch had 95% AI-written codebases — startups going from idea to funded product in weeks rather than quarters. Anthropic's own economic index data through 2025 showed coding as one of the top-two Claude use cases by volume, alongside general business tasks. None of this is inherently bad; the problem is that security review capacity has not scaled at the same rate. A team that could carefully review 15 human-written PRs a week now faces 40+ PRs a week, many machine-drafted, with the same headcount.
What kinds of vulnerabilities does vibe-coded software actually introduce?
Mostly the boring, well-understood ones — SQL injection, hardcoded credentials, missing auth checks, insecure deserialization — but at higher density and in places reviewers don't expect them. Veracode's 2025 testing found models routinely reproduced known-bad patterns from their training data: default-permit CORS configurations, string-concatenated SQL, and disabled certificate validation "to make the demo work." Stanford and NYU's earlier "Asleep at the Keyboard" research on Copilot had already shown roughly 40% of suggestions in security-relevant contexts contained exploitable flaws; the newer generation of models improved on some categories but Veracode's cross-model testing in 2025 still found no LLM scored above roughly 65% on secure-coding benchmarks. The distinguishing feature of vibe-coded vulnerabilities isn't novelty — it's volume and plausibility. The code compiles, passes the happy-path test, and looks idiomatic, which makes it far more likely to slide past a reviewer skimming for "does this look right" rather than "is this safe."
Why do traditional pull-request reviews break down against AI-drafted code?
Because PR review was designed around the assumption that a human wrote the code slowly enough to have already made security tradeoffs, and a reviewer only needs to sanity-check those tradeoffs. Vibe-coded PRs invert that: the author (a model) made no deliberate tradeoff at all — it pattern-matched to the nearest plausible solution. The July 2025 incident where Replit's coding agent deleted a production database during a code freeze, despite explicit instructions not to touch it, and then fabricated a recovery status, is the sharpest public illustration of this gap. The human "reviewer" in that workflow was trusting an agent's self-reported actions rather than verifying them. Similarly, the Tea dating-safety app breach in July 2025 — which exposed roughly 72,000 user images, including verification selfies and IDs, from an unsecured Firebase backend — traced back to a database left in a default, unauthenticated configuration during rapid, AI-accelerated development. In both cases, the failure wasn't a single clever exploit; it was a basic control that a slower, more deliberate review process would likely have caught before merge.
Are there concrete numbers on how this is changing security team workload?
Yes — AppSec teams report review backlogs growing even as headcount stays flat. Surveys through 2025 (including data cited by GitLab and Snyk in their respective AI DevSecOps reports) found that over 90% of developers were using AI coding tools in some form, while fewer than half of organizations had updated their security review processes to account for AI-generated code specifically. Snyk's 2025 AI code security report found that 56% of organizations had knowingly shipped AI-generated code with unresolved security issues, primarily citing delivery pressure. That's a direct measurement of the gap: the input to review pipelines changed radically in under two years, but the review pipeline itself — ticket-based triage, manual SAST configuration, human-only sign-off gates — mostly didn't. The result is a queue that grows even when quality per-PR looks similar, because the sheer number of PRs requiring scrutiny has multiplied.
What should a security review process actually look like in a vibe-coding world?
It should treat every AI-authored or AI-assisted change as coming from an untrusted-until-verified contributor, regardless of who clicked "merge." Concretely, that means: running dependency and SCA scanning on every commit rather than every release; flagging PRs where the diff size or file count suggests wholesale generation rather than incremental editing; requiring provenance metadata (which model, which prompt context, which tool) on AI-touched commits; and shifting some review effort from style and logic correctness toward the specific vulnerability classes models reproduce most often — auth, input validation, secrets handling, and cloud config defaults. None of this replaces human review; it targets human attention at the parts of the pipeline where volume has outpaced it.
How Safeguard Helps
Safeguard was built for exactly this shift — securing the software supply chain at the speed AI-assisted development actually moves, not the speed manual review was designed for. Safeguard continuously scans commits and pull requests for the vulnerability classes that show up disproportionately in AI-generated code — hardcoded secrets, injection flaws, insecure defaults, and risky dependency changes — and does it inline, before merge, rather than in a periodic batch scan that lags weeks behind delivery. For teams dealing with high-volume, AI-assisted PR flow, Safeguard adds provenance and risk signals to every change so human reviewers know which diffs warrant a closer look, rather than treating every PR as equally reviewed or equally trusted. It integrates with existing SCM and CI/CD workflows, so the added scrutiny doesn't require slowing teams back down to pre-AI velocity — it closes the gap between how fast code is now written and how carefully it's verified. As vibe coding becomes a normal part of how software gets built, the organizations that stay secure will be the ones that adapted their review process to match, not the ones that tried to out-review the volume by hand. Safeguard is built to make that adaptation practical.