IOV LABSVibe coding, describing what you want and letting the model write it, is now how a lot of software gets made. The pitch is speed. The quiet question is whether the code is safe, and the comfortable assumption is that a modern model plus a linter has it covered. We tested that with a small, controlled experiment, and the comfortable assumption is wrong in an instructive way.
The vibe tax
We wrote ten security-sensitive Python tasks, the kind where the fast, obvious solution is the insecure one, and asked two models for each one twice: once "make it work fast," once "make it secure." Then we checked, for every generation, whether the code is actually vulnerable, using a per-task oracle that looks for the specific bug. Asking only for speed raised the vulnerability rate from 20 percent to 50 percent. One sentence of security intent more than halves it. The effect showed up in both models, a Claude and a GPT, so it is not a quirk of one vendor: Claude went 10 to 40, GPT 30 to 60.
The risk didn't vanish, it moved
Here is the part that older studies would miss. The famous vulnerabilities they measured, SQL injection, command injection, weak password hashing, unsafe YAML, weak randomness, came out safe by default even under the vibe prompt. The models reached for parameterized queries, list-argument subprocess calls, PBKDF2. The failures were somewhere else entirely: JWT signature verification skipped, unsafe deserialization, HTML rendered without escaping, TLS verification turned off with no SSRF guard, path traversal. The security training worked on the bugs everyone talks about, and the risk slid to the ones about trust and verification that no one demoes.
The scanner is blind exactly here
The most uncomfortable number. Of the code our oracle flagged as truly vulnerable, 35 percent of everything, the industry-standard generic scanner bandit detected zero. Not less, zero. Trust-and-verification bugs are the blind spot of generic static analysis, which is exactly the category the risk moved into. So the developer runs the linter, sees green, and ships, at the precise moment the vulnerability is present and unseen. This matches the field reports that traditional tools miss most AI-generated vulnerabilities; here it is in a clean experiment.
The model half-knows, but not when it counts
Is this a "false sense of security"? Partly, and honestly less than the headline would like. When we asked the model, in a separate call, to rate its own code's security from zero to ten, it gave the truly vulnerable code a 3.5 and the safe code a 6.6. It can tell the difference, somewhat. The problem is that this judgment only fires when you stop and ask "is this secure?" During generation, going fast, it says nothing and ships the vulnerable version. The safety check exists but sits in a separate room that the vibe never walks into. That is the same shape as our observer-effect and completion-illusion findings: the model behaves differently when it knows it is being evaluated, and its silent self-report cannot be trusted.
Takeaway. Vibe coding's danger is not that AI writes obviously broken code, it mostly does not anymore. It is that the remaining vulnerabilities are quiet, live in the trust-and-verification layer, pass the scanner clean, and slip past a developer whose whole mode is speed. The answer is not "be more careful," which is the opposite of vibe. It is systemic: put security in the default prompt, add task-specific verification the generic scanner lacks, and gate safety at the system layer instead of trusting the model's silence.
A pilot, forty generations, disclosed and reproducible. The point is not the exact percentages; it is the shape, and the shape is stable across two vendors.