The debate around vibe coding has settled into a predictable shape: people who write code with AI assistance are reckless, people who don't are careful, and the fix is to get more humans back in the loop. It's a comfortable narrative because it has a villain. It's also wrong, or at least pointed at the wrong target.
A senior engineer using Copilot or Cursor ships the same category of vulnerable code as someone vibe coding their first SaaS product. Not because skill doesn't matter, it does, for design decisions, architecture, knowing what to build. But for a specific class of security bug, skill level is almost irrelevant. The model suggesting the code was trained on a snapshot of the world that's already out of date the moment it ships, and it's generating that code at a volume no human review process was built to handle.
That's the actual problem, Not who's typing, How much code is being produced, and how fast the threat landscape underneath it moves.
The training data is always behind the threat
Every LLM used for code generation has a training cutoff. Everything it knows about secure patterns, vulnerable dependencies, and best practices is frozen at that point. New CVEs get published daily, the OSV database adds entries continuously, a package that was safe at training time can have a critical vulnerability disclosed the next week and the model has no way to know that.
This isn't a hypothetical edge case, It's the default state of every AI-assisted codebase. The model will confidently suggest:
import requests
response = requests.get(url, verify=False) # commonly suggested, rarely flagged
verify=False disables TLS certificate verification. It shows up constantly in tutorials and Stack Overflow answers from years ago, exactly the kind of pattern that gets absorbed into training data and reproduced without context. The model isn't being careless, it's reproducing what it learned, and what it learned has a shelf life.
The same applies to dependency versions. A model trained six months ago might recommend a package version with a known CVE disclosed in the meantime, with no signal to the developer that anything's wrong. The code runs, the tests pass and the vulnerability ships.
The real shift is volume, not intent
Here's what actually changed in the last two years: the amount of code a single developer can produce went up by an order of magnitude. That's true whether they're using AI deliberately and carefully, or vibe coding an entire app over a weekend.
Code review processes, the ones most teams still use, were designed for a world where a senior engineer could reasonably read every line of every PR. That assumption breaks down when PRs are 5x larger and arrive 3x more often. Nobody decided to skip security review. The math of human attention just stopped working.
This is the part the vibe coding debate misses entirely. The conversation about "is it okay to ship code you don't fully understand" is a separate, legitimate question. But even code written by someone who understands every line is vulnerable to the same training-data lag, and produced at the same volume that overwhelms manual review. Blaming vibe coding treats the symptom and ignores the mechanism.
What manual review can't keep up with
Consider what's actually required to catch a vulnerability introduced by AI-suggested code:
- Know the current CVE landscape, not what was true at training time, but what's true today
- Trace data flow across files, not just read the diff in isolation
- Check every new or updated dependency against live vulnerability databases (OSV, NVD, GitHub Advisories)
- Do this at the speed code is being merged, not in a quarterly audit
A human reviewer can do all four. They cannot do all four, accurately, for every PR, every day, across a growing codebase, without it becoming their entire job. That's not a knock on engineers, it's a description of what the volume of AI-generated code actually demands.
This is where the conversation needs to shift from "should we trust AI to write code" to "how do we close the gap between code velocity and security review velocity." Those are different problems with different solutions.
Closing the gap requires matching the speed, not adding more humans
The instinct to fix this with more manual review doesn't scale, you'd need to grow your security headcount proportionally to your AI-assisted output, which defeats the purpose of using AI assistance in the first place.
What actually works is tooling that operates at the same speed code is generated, cross-referencing against vulnerability data that updates daily instead of training data that's frozen. This means scanning for vulnerable dependency versions against live databases, not static rule sets. It means analyzing the full project graph instead of isolated diffs, since vulnerabilities frequently emerge from how files interact rather than from any single file in isolation. And it means flagging deprecated or insecure patterns the moment they're introduced, not in a retrospective audit weeks later.
This is the gap Ixtli is built to close, normalizing OSV, NVD, and GitHub Advisories into a single engine that checks every PR against what's known today, not what was known when the model generating the code was trained. The point isn't to slow down AI-assisted development. It's to make the review process move at the same speed the code does.
What this means for your workflow
If you're shipping AI-assisted code, and at this point, almost everyone is, whether deliberately or as a byproduct of using modern editors, the relevant question isn't whether to trust the AI. It's whether your review process can keep pace with what it's producing.
A few things worth checking regardless of how your team writes code:
| Risk | Why training-data lag makes it worse | What to do |
|---|---|---|
| Outdated dependency versions | Model recommends packages safe at training time, vulnerable now | Scan against live CVE databases on every PR |
| Deprecated security patterns | Old patterns (e.g. verify=False) persist in training data |
Flag at commit time, not in quarterly audits |
| Cross-file vulnerabilities | Diff-based review misses interaction effects | Analyze full dependency graph, not isolated changes |
| Volume exceeding reviewer bandwidth | More code, same number of reviewers | Automate the first pass; humans review what's flagged |
The skill of the person writing the code matters less here than most people assume. What matters is whether the system around that code can verify it against reality as it exists today, not as it existed when the model was trained.
If your team is shipping faster than your review process can verify, that gap doesn't close itself, it just gets wider as the codebase grows. Worth checking before it becomes the kind of thing you find out about from a security researcher instead of a teammate.
Top comments (0)