Quick Answer
AI-generated code is not secure by default. Veracode's 2026 report finds an average security pass rate of 56% across the models it tracks, so about 44% of tasks produced code with a known vulnerability, and the rate has barely moved in a year. Someone has to review that code before it ships, and who does it is a hiring decision.
AI coding assistants now write a large share of the code that reaches production, and shipping faster rarely comes with a plan for checking what was generated. This post separates what the data shows (AI-written code often fails basic security tests, and verification lags generation) from what it does not (that most websites are vulnerable, or that hiring alone causes breaches). The staffing angle is OpenWorks's own assessment and is labeled as such.
Is AI-generated code secure by default?
No. In Veracode's 2026 GenAI Code Security Report, the average security pass rate across the models it has tracked is 56%, which means roughly 44% of code-generation tasks produced code with a known vulnerability. The first report put the pass rate at 55%.
Data Point
Average security pass rate for AI-generated code: 56% across more than 100 models tracked in four testing snapshots, versus 55% in the first report. Tests used standardized coding tasks with no security-specific guidance. More: veracode.com/resources/analyst-reports/2026-genai-code-security-report
Veracode, 2026 GenAI Code Security Report (2026)
Two limits matter. The tests ran on raw models, without the tooling, guardrails or human review a production team would add, so the figure describes what the model writes, not what a company ships. The study also does not measure how many live websites are vulnerable.
Does anyone actually review the code AI writes?
Not consistently. In Sonar's 2026 State of Code Developer Survey of more than 1,100 developers, 48% said they always check AI-assisted code before committing it, while 96% said they do not fully trust that it is functionally correct. Developers also reported that AI accounts for 42% of the code they commit. These are self-reported figures from a vendor of code-review software, and the 96% refers to functional correctness, not security.
Data Point
48% of surveyed developers say they always check AI-assisted code before committing it; 42% of their committed code is AI-assisted (developer-reported). Self-reported survey. More: sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
Sonar, State of Code Developer Survey (2026)
Are flaws from AI-written code showing up in real software?
Yes, in a small, growing and undercounted number of cases. Georgia Tech's Vibe Security Radar traces public vulnerability advisories back to AI coding tools. It confirmed 74 cases: about 18 across seven months of 2025 and 56 in the first three months of 2026, including 35 in March alone. The researchers describe the count as a floor, because tracing depends on markers that can be removed.
Data Point
74 public vulnerability cases confirmed and traced to AI coding tools between May 2025 and March 2026, with 35 in March 2026 alone. The count is a floor: tracing relies on markers such as co-author tags, which can be removed. More: cc.gatech.edu/news/bad-vibes-ai-generated-code-vulnerable-researchers-warn
Georgia Tech SSLab, Vibe Security Radar (2026)
Why is reviewing AI-generated code a staffing decision?
OpenWorks's assessment, not a study finding: generated code adds review work that someone with security judgment has to own. The Georgia Tech researchers advise reviewing AI output as carefully as a junior developer's pull request, especially input handling and authentication. A team that adopts AI assistants and keeps the same hiring plan has more code to check and nobody new to check it.
- Senior engineers with time reserved for review. Input handling and authentication are the areas the Georgia Tech researchers flag.
- Automated scanning built into the delivery pipeline, with a named person who owns the results. Veracode's 2026 analysis calls for verifying code inside the workflow.
- A security-minded engineer or analyst who triages findings and decides what blocks a release.
- A clear owner for fixes, so flagged issues do not pile up as security debt.
Which roles cover the review layer on a team that uses AI to write code?
Four roles share the work: senior engineering reads the code, DevOps runs the scanning, a security analyst triages findings and a delivery lead owns fixes and sign-off. The table summarizes what each covers and where the gap tends to appear, in OpenWorks's judgment.
| Role | What it covers | Typical gap (OpenWorks view) |
|---|---|---|
| Senior engineer | Reads generated code before merge | Review slips when time is not reserved |
| DevOps engineer | Runs scanning inside the pipeline | Scans run, but nobody owns the results |
| Security analyst | Triages findings, sets release gates | Findings pile up without a decision |
| Delivery lead | Owns fixes and release sign-off | Fixes wait behind feature work |
Key Takeaway
AI-generated code needs a review layer, and the layer has names attached: who reads the code, who owns the scanner, who decides what blocks a release. Putting those roles in the hiring plan before the next AI-assisted release is the staffing step that closes the verification gap.
Frequently Asked Questions
Is AI-generated code less secure than human-written code?
The sources reviewed here do not compare the two directly. Veracode measures how often AI-generated code fails security tests (about 44% of tasks in 2026), and Georgia Tech counts real advisories traced to AI tools. Neither sets a human-written baseline, so a ranking is not supported.
Does the data show that most websites built with AI are vulnerable?
No. Veracode tested models on standardized tasks, not live sites, and Georgia Tech confirmed 74 public cases through March 2026, a count its researchers call a floor. The data supports a review requirement, not a claim about the share of vulnerable sites.
Who should be accountable for reviewing AI-generated code?
OpenWorks recommends naming one accountable owner per release, usually a senior engineer or delivery lead, with a DevOps engineer or security analyst running scanning and triage. This is OpenWorks's own guidance, not a finding from the studies cited.
Can a nearshore team cover the review layer?
Yes, if the roles are defined before the search starts and the engineers work in US and Canadian time zones, since review blocks releases and needs same-day answers. OpenWorks reports an average of about 3 weeks from first consultation to integration.
OpenWorks, based in Langford, BC, places nearshore engineers in specialized roles, including cloud, DevOps and security, in US and Canadian time zones. The average is about 3 weeks from first consultation to integration, the 90-day replacement guarantee applies across engagement models, and OpenWorks reports 98% retention and 0% churn after 12 months. For a team shipping AI-assisted code, those figures describe how quickly review roles are filled, how mismatch risk is covered and how long people stay on the codebase.