DEV Community

Cover image for 57% of AI Code Works. Only 11.8% Is Safe. Here's What the Benchmark Found.
xxxn3m3s1sxxx
xxxn3m3s1sxxx

Posted on

57% of AI Code Works. Only 11.8% Is Safe. Here's What the Benchmark Found.

You write a prompt. The agent writes the code. Tests pass. You ship it.

But what if 4 out of 5 "working" solutions carry an exploitable vulnerability?

That's not hypothetical. It's the result of SUSVIBES — a peer-reviewed benchmark published at ICML 2026 (arXiv:2512.03262v3) that tested 12 coding agent configurations on 186 real-world tasks from GitHub repositories where human developers had previously committed vulnerable code.

The Gap Between "Works" and "Is Safe"

The headline numbers:

  • 57% of solutions from SWE-Agent + Claude 4 Sonnet were functionally correct
  • 11.8% were actually secure
  • 82.8% of functionally correct solutions still had exploitable flaws

That means the code passed unit tests, satisfied the feature request, and looked production-ready — while still shipping the same kind of vulnerabilities human developers have historically introduced in the same codebase.

The benchmark covers 79 CWE categories from the Common Weakness Enumeration. These aren't theoretical edge cases. They're the vulnerability classes that show up in real CVEs.

Why Security Hints Don't Work

The researchers tried the obvious fix: prepend a security reminder to the prompt. Add a line like "make sure this code is secure" or include hints about known vulnerability patterns.

It didn't work.

Functional correctness stayed roughly the same. Security outcomes barely moved. The agents lack an internal mechanism to check for security risk — they optimize for "does this code do what was asked?" not "does this code introduce attack surface?"

This finding is significant because it means the problem isn't about prompt engineering. It's architectural. The agents are trained to satisfy functional specifications. Security is an orthogonal objective that current training doesn't encode.

The Real-World Implications

Consider what this means for teams deploying vibe-coded features:

  1. Tests passing is not a security gate. Your test suite validates functionality. It doesn't validate that you didn't introduce a path traversal, SQL injection, or authentication bypass.

  2. Review speed goes up, security signal goes down. When a reviewer sees "tests pass, code looks right," the tendency is to approve. The vulnerability hides in the parts the reviewer doesn't check.

  3. The best agent still fails 88.2% of the time on security. Even the highest-performing configuration (SWE-Agent + Claude 4 Sonnet) only secured 11.8% of tasks. Other configurations scored worse.

  4. Adding agents doesn't help. The gap between functionality and security persists across all tested frameworks (SWE-Agent, Claude Code, OpenHands). The issue isn't the harness — it's the model's training objective.

What Should Teams Actually Do?

The researchers don't argue for banning vibe coding. They argue for layered controls:

  • Static analysis as a mandatory gate. Every AI-generated commit passes through a SAST tool (Semgrep, CodeQL, Bandit) before review. Non-negotiable.

  • Security-focused test cases. Don't just test "does it work?" Test "does it fail safely?" Add adversarial inputs, boundary conditions, and privilege escalation scenarios.

  • Human review on the security axis. Separate the functional review from the security review. Different reviewers, different checklists.

  • Monitor the leaderboard. The SUSVIBES leaderboard (leililab.github.io/susvibes-leaderboard) tracks agent configurations over time. As models improve, re-evaluate.

The benchmark is open source: github.com/LeiLiLab/susvibes. You can run it against your own agent setup.

The Uncomfortable Truth

Vibe coding makes developers faster. The SUSVIBES data confirms that.

But "faster" and "safer" are independent variables. Current agents optimize for the first. The second requires tooling, process, and discipline that the agents themselves don't provide.

If you're shipping AI-generated code to production without a security layer between the agent and your users, you're deploying code that — by benchmark evidence — is almost certainly vulnerable.

The fix isn't to stop using AI agents. It's to stop treating "it works" as the finish line.


Sources: Zhao et al., "Is Vibe Coding Safe?", ICML 2026 / arXiv:2512.03262v3. SUSVIBES benchmark: github.com/LeiLiLab/susvibes. Leaderboard: leililab.github.io/susvibes-leaderboard.


Tactical Debrief

  • 82.8% of functionally correct AI code is insecure — passing tests ≠ safe to deploy
  • Security hints don't work — the problem is architectural, not a prompt engineering issue
  • 79 CWE categories tested across 186 real-world tasks — not synthetic benchmarks
  • Static analysis is mandatory — don't ship AI code without SAST as a gate

Do not subscribe. If this was useful, you'll find the next one.

Top comments (0)