To Vibe or Not to Vibe: An Empirical Security Analysis of AI-Generated Code Patches

Why This Matters

When a developer merges an AI-generated patch after checking that it fixes the reported bug, they're implicitly trusting that the model hasn't introduced a new security flaw in the surrounding code. That assumption is largely untested. Prior work has shown AI tools produce insecure code in controlled generation tasks, and that AI-generated code in public repositories contains widespread vulnerabilities — but no prior study had measured security impact specifically in the bug-fix scenario, where a model patches a real, reported defect in a production codebase and that patch is measured against what a human engineer actually shipped for the same bug.

Approach

SNRA builds three isolated variants of each buggy repository using git worktrees: control (the unpatched code at the bug's base commit), golden (the control with the human-written fix applied), and AI (the control with a given model's patch applied). Each variant is run through CodeQL's security-extended and security-and-quality query suites, and findings are compared as sets keyed by (rule ID, file path, line hash) so a patch's Fixed and Introduced findings can be computed independently of line-number drift between variants. A CVSS-weighted variant of this metric distinguishes patches that fix or introduce many low-severity style findings from patches that touch fewer but genuinely exploitable ones.

The pipeline (pipeline_ai.py) reads a SWE-bench Pro parquet file and a Docent CSV of AI agent trajectories, joins them on instance ID, builds the three worktrees per instance, runs codeql database create and codeql database analyze per worktree using Python's ThreadPoolExecutor, and appends parsed SARIF results to a Parquet output — with existing CodeQL databases reused across runs to make re-execution incremental.

Key Results

• Across the current pipeline run (139 commits, 4 repositories, 1,112 CodeQL runs, ~426 CPU hours), the human-written golden patch nets +15 (142 findings fixed, 127 introduced) — a net security improvement.
• Both AI models evaluated net-worsen security: Claude 4.5 nets -53 (47 fixed, 100 introduced), and GPT-5 nets -114 (128 fixed, 242 introduced).
• Regression rates (share of instances introducing at least one new finding): 89.1% for the human patch, 95.1% for Claude 4.5, 96.7% for GPT-5.
• CVSS-weighted severity flips the ranking: GPT-5's larger volume of introduced findings is mostly low-severity (-0.13 avg/change), while Claude 4.5 introduces far fewer findings but of much higher severity (-0.47 avg/change) — including 4 new instances of a shell-command-injection rule (CWE-78) absent from both the original code and the human patch.
• AI isn't purely additive risk, though: GPT-5 independently fixed 83 vulnerabilities that the human patch had missed, suggesting a complementary rather than purely adversarial relationship between AI and human review.

Implications

The central finding is that functional correctness and security correctness are orthogonal — a patch that closes the reported bug can simultaneously open a new one, and reviewing for the former tells you nothing about the latter. The paper argues automated security scanning (e.g. CodeQL in CI/CD) should be a mandatory gate on AI-generated patches, not an optional post-hoc audit, and that severity-weighted metrics matter: a raw-count dashboard would have ranked Claude 4.5 as the safer model here, when CVSS-weighting shows the opposite.

Status

This is ongoing graduate research with a UT Dallas professor, targeting publication. The current results cover 2 of 13 available AI models and 4 of 11 SWE-bench Pro repositories; expanding to the full model and repository set, adding statistical significance testing, and normalizing by patch size are the next steps.