AI coding tools have changed the arithmetic of software delivery. They now generate 42% of committed code, heading toward a projected 65% by 2027. Yet the security pass rate has stalled at 55% since 2023. Follow the data and the divergence widens: Faros AI’s telemetry of 22,000 developers shows pull-request review time up 441%, incidents per PR up 243%, and 31% of PRs merging with zero human review. That is the speed-security divergence. Faster code generation is slowing delivery and compounding security debt.
The tools are writing more code than your team can safely review, test, or govern, and the attack surface has moved with them, toward the agentic supply chain where dependencies and pipeline credentials are the new targets. This series maps the problem into four decisions. Start with the numbers behind the speed-security divergence, then understand slopsquatting and the new supply chain, measure tools by delivery outcomes rather than vendor benchmarks, and finally decide where the fix belongs. Each section below gives the overview; the linked articles carry the detail.
In This Series
- Why AI Coding Tools Ship Faster but Fail More Security Tests — The data behind the divergence: the 55% pass-rate stall, the AI code paradox, error profiles, and security debt.
- Slopsquatting and the New AI Supply Chain Attack Surface — The TeamPCP/LiteLLM compromise and the agentic governance vocabulary.
- How to Measure and Compare AI Coding Tools by Delivery Outcomes — DORA metrics and outcomes-based comparison over vendor benchmarks.
- How to Govern AI Coding Tools and Decide Where the Fix Belongs — The policy spectrum and the model-tool-platform decision.
Where to start: “Why is my AI-generated code failing security tests?” takes you to article 1. “How do I protect my supply chain from AI-specific attacks?” takes you to article 2. “How do I compare tools on real delivery outcomes?” takes you to article 3. “How do I govern this and decide where the fix belongs?” takes you to article 4.
Why has the AI code security pass rate stalled at 55% since 2023?
Veracode‘s July 2026 report, covering 150+ models across four testing snapshots, found the security pass rate has stayed at 55% since 2023 even as syntax correctness has climbed. The metric measures how often AI-generated code finishes a security task without introducing a vulnerability. Gains are uneven: SQL injection passes 82% of the time because training examples are abundant, while context-dependent flaws such as XSS (15%) and log injection (13%) stay under-represented. Better models are not automatically more secure models. That gap is what matters.
This is the number the rest of the series hangs on. Veracode’s 2026 GenAI Code Security Report found models have become excellent at writing code that compiles while security has barely moved. Veracode describes it plainly: syntax correctness has climbed past 95%, but the security pass rate sits at “approximately 55%”, virtually where it stood two years ago. Compiling code and safe code have been different things for a while.
What you should weigh is whether your own security gates are calibrated for context-dependent flaws, as well as the formulaic ones models already handle well. A flat pass rate is the part that should concern you. At 42% of committed code and climbing toward 65%, the same 55% means the absolute volume of vulnerabilities keeps rising even while the rate holds.
Read the data behind the speed-security divergence for the language-by-language numbers and why even the best model still fails roughly one security task in three.
What is the “AI code paradox,” and why does faster code generation slow delivery?
The paradox is that accelerating the writing stage slows the overall pipeline. Coding is only about 15% of shipping work, per DORA research. When tools accelerate that slice and flood the other 85% (review, testing, integration, incident response) with more code, throughput stalls downstream. Faros AI telemetry from 22,000 developers shows PR review time up 441%, incidents per PR up 243%, and 31% of PRs merging with zero human review. Speed at the keyboard becomes rework and review backlog everywhere else.
The paradox is easy to name and easy to ignore. Coding is one stage in a much longer pipeline. When a tool accelerates that stage and floods the rest with more output, the end-to-end result slows down. Faros AI’s “Acceleration Whiplash” telemetry, drawn from 22,000 developers, shows what that flood looks like: median PR review time up 441%, incidents per PR up 243%, and 31% of PRs now merging with zero human review.
The trade-off for your team is straightforward. Velocity gains concentrated in 15% of the pipeline can inflate the other 85%. Treat “PRs merged” as a throughput signal only. Review has become the new constraint, and review is now concentrated in senior engineers, the people the tooling was supposed to free up.
That downstream flood connects back to the pass-rate problem above and forward to security debt below. The full paradox analysis is in the wider speed-security divergence cluster, where the 441% review-time figure gets its full context.
How do AI-generated and human-written error and vulnerability profiles differ?
The difference lies in the pattern of defects as much as in their number. New Relic’s 2026 State of AI Coding found AI-generated code carries 75% more logic bugs. AI code is often syntactically correct (it compiles) yet security-incorrect in characteristic ways, skewing toward logic flaws and context-dependent injection issues. Human code skews toward other defect classes. Treating AI output as a distinct code source with its own error profile lets you target review and testing where each source actually fails.
The more useful question is how they fail differently. New Relic’s 2026 State of AI Coding found AI-generated code carries 75% more logic bugs, and the pattern matters more than the headline. AI code tends to be syntactically correct but wrong in characteristic ways: logic flaws, flawed control flow, and context-dependent injection issues. Human code skews toward its own defect classes.
That distinction changes how you triage and test. If AI and human defects concentrate in different places, one generic review standard misses both. You want review and scanning tuned to each error profile, so you catch the logic bug the model buried in plausible-looking code as well as the classic mistake a senior developer would have spotted.
The side-by-side profile comparison, and what it means for security debt, is in the AI error-profile comparison.
What is security debt, and why is it affecting 82% of organisations?
Security debt is the accumulating backlog of unremediated AI-generated vulnerabilities, produced faster than teams can triage. 82% of organisations now report it. The “Vulnpocalypse” label, from coverage of the March 2026 wave of compromised packages, describes accumulation rather than a single flaw: every merge adds vulnerabilities that outpace review capacity. When prioritising, reachability, exploitability, and production exposure matter more than raw CVE count. The decision is what to triage first and what to accept as residual risk.
Security debt is what happens when the vulnerability stream outruns your capacity to triage it. Veracode reports it now affects 82% of organisations, up from 74% a year earlier. The “Vulnpocalypse” label sounds dramatic, but it describes accumulation: every merge ships flaws faster than anyone can review them, and the backlog compounds.
Prioritisation is the job. Reachability, exploitability, and production exposure matter more than raw CVE count. You are deciding what to fix first and what to accept as residual risk.
The security-debt deep dive is in the divergence data breakdown. Debt is also the bridge to the next section, because unremediated AI-generated flaws are exactly what later turns into the supply-chain attack surface.
Read more: These four sections are the data block, covered in full by Why AI Coding Tools Ship Faster but Fail More Security Tests. Want to skip ahead? The supply-chain threat starts next, and the governance decision comes at the end.
What is slopsquatting, and how did the TeamPCP campaign compromise LiteLLM?
Slopsquatting is squatting on the plausible-but-nonexistent package names that AI assistants hallucinate or suggest. Attackers pre-register those names so a later install delivers malware. In the TeamPCP campaign, attackers used stolen CI/CD tokens to compromise LiteLLM, a package with 95 million monthly downloads, in under ten days, turning a trusted dependency malicious at the source. The compromise point was the pipeline. That shift, from code to the agentic supply chain, is the lesson of the TeamPCP case.
Slopsquatting takes the typosquatting playbook and points it at the AI’s own output. Where typosquatting pre-registers near-miss spellings of real packages, slopsquatting pre-registers the plausible package names an assistant invents. The TeamPCP campaign showed how fast this can go wrong: stolen CI/CD tokens were used to publish backdoored versions of LiteLLM, a package with 95 million monthly downloads, in under ten days. A trusted dependency was turned malicious at the source.
You are protecting the agentic supply chain and the pipeline itself, as well as source code. The questions to ask now are where AI-suggested dependencies enter your build, and whether your CI/CD credentials are scoped and rotatable, because those credentials are the target.
The full TeamPCP narrative is in slopsquatting and the AI supply chain. It connects back to the security debt above and forward to governance at the end.
What is the OWASP Agentic Top 10 for 2026, and which risks apply to AI-assisted coding?
It is the first risk taxonomy built specifically for agentic applications, where tools act autonomously rather than only respond. For AI-assisted coding, the salient entries are Human-Agent Trust Exploitation and agentic supply-chain entry points, alongside classic injection. The first covers agents manipulating the human approval you grant them; the second covers the new ways dependencies enter your pipeline. It reframes the threat model. You are now securing an autonomous actor with credentials and reach.
The OWASP Agentic Top 10 for 2026 is the first taxonomy written for tools that plan and act on their own. For AI-assisted coding, the entries that matter include Human-Agent Trust Exploitation: attackers exploit the fluent, confident behaviour of agents to get humans to skip validation. Agentic supply-chain entry points matter just as much, because dependencies now arrive through a new channel.
This changes how you assess risk. You are evaluating an actor’s behaviour and permissions, as well as its code output. The trust-exploitation entry connects directly to the 97% rubber-stamp behaviour covered later in the governance section.
The full taxonomy walk-through, and which entries apply to AI-assisted development, is in the AI supply-chain attack surface breakdown.
What is agentic governance in the software supply chain, and how does MLSecOps extend DevSecOps?
Agentic governance is the control layer for autonomous agents across the supply chain: identity, least privilege, human-approval gates, and provenance for agent actions. MLSecOps extends DevSecOps from code and binaries to model weights, datasets, and model provenance. The gap they close is the “binary gap”: traditional tooling protects source and compiled binaries while missing the AI-generated code and agent actions between them. A living, operationalised SBOM tied to build and runtime reduces risk where a static snapshot cannot.
Agentic governance treats AI agents as primary actors in your supply chain, which is exactly what they have become. It means controlling identity, least privilege, human-approval gates, and provenance for every agent action. MLSecOps extends the same discipline into the machine-learning lifecycle: model weights, datasets, and model provenance, as well as code and binaries.
The “binary gap” is what both close. Traditional tooling protects source code and compiled binaries, while missing the AI-generated code and agent actions in between. The static-versus-living SBOM question follows naturally: a snapshot is a compliance artefact; an operationalised SBOM tied to build and runtime reduces risk. This is the bridge from the insecurity data to the governance decision.
The governance vocabulary and the SBOM comparison are in the agentic governance and supply-chain deep dive. Once the supply-chain threat is understood, the next question is whether the tooling is delivering at all.
Read more: The supply-chain block is covered in full by Slopsquatting and the New AI Supply Chain Attack Surface. Next up: how to measure tools by delivery outcomes, or jump straight to the governance decision.
How do you measure the real impact of AI coding tools on delivery velocity and stability?
Measure what changed in your own pipeline. DORA metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) are the neutral lens. Watch the throughput-stability trade-off: velocity can rise while change failure rate and review load spike. Treat “PRs merged” as a throughput signal only, since 31% now merge with zero human review. The comparison that matters is your before-and-after, anchored to incidents and rework.
DORA’s four metrics are the neutral lens vendor dashboards lack. The right comparison is your pipeline before and after adoption. Watch the throughput-stability trade-off: velocity can climb while change failure rate and review load spike behind it.
What you watch is incident rate, review burden, rework, and security pass rate alongside velocity. When 31% of PRs merge with zero human review, a rising merge count can hide a coverage problem.
This is the evaluation that follows from the paradox earlier in the series. The measurement framework in detail is in measuring and comparing AI coding tools.
How do you compare AI coding tools by delivery outcomes instead of vendor benchmarks?
Vendor benchmarks (completion scores, HumanEval-style results) do not predict production delivery or security. Compare tools on your own pipeline: PR cycle time, review burden, incident rate, security pass rate, and cost. Run a candidate model against an internal benchmark repo and a pilot team before full rollout. Among the top tier (GitHub Copilot, Claude Code, Cursor), security is largely undifferentiated, so the deciding factors are governance defaults, integration with your review gates, and observed incident impact.
Completion scores and HumanEval-style results measure a narrow thing that does not predict production delivery or security. The comparison that matters is your own pipeline: PR cycle time, review burden, incident rate, security pass rate, and cost. Run a candidate against an internal benchmark repo and a pilot team before you roll it out company-wide.
Across the top tier, the security picture is flat. Veracode found code-specialist models average a 51% security pass rate versus 52% for general-purpose models, so no vendor wins on safety. The decision should hinge on governance defaults, integration with your review gates, and observed incident impact. A tool’s auto-mode default is one example of a reliability default worth weighing.
The full comparison, including GitHub Copilot, Claude Code, and Cursor, is in the delivery-outcomes comparison. The policy decision that follows is the final section.
How do you evaluate an AI-assisted development policy between banning tools and unrestricted use?
The realistic policy sits between the two extremes, risk-tiered rather than binary. Use allow-lists, mandate human review for security-sensitive paths, govern data, IP and secrets, and explicitly treat auto-mode or agentic features. Neither a blanket ban (which drives shadow adoption) nor unrestricted use (which removes the control you still need) survives contact with real teams. The decision is where you place the review gate and which changes require a human.
A ban drives developers to unapproved tools with no security oversight. Unrestricted use removes the control you still need. Both endpoints fail in practice. The realistic policy is risk-tiered: you decide where the review gate sits and which changes require a human.
The levers are allow-lists, mandatory human review for security-sensitive paths, data, IP and secrets governance, and explicit treatment of auto-mode and agentic features. Claude Code’s auto-mode default is the live test, because Anthropic’s own telemetry showed humans approving 97% of prompts on reflex. A policy that treats that prompt as a real control is already out of date.
Policy follows from what you measure, which is why this connects back to the measurement section. The full policy spectrum is in governing AI coding tools and the model-tool-platform fix. The next question is where that policy gets enforced: in the model, the tool, or the platform.
How do you decide whether the security fix belongs in the model, the tool, or the platform?
The fix is distributed, and enforcement happens at the platform. The model can improve security training and classifiers. The tool can add guardrails and scanners. The platform owns the pipeline gates, CI/CD policy, and provenance, which is where policy gets enforced. Your decision is architectural: which layer you trust to hold the guarantee. For most teams the durable control is blast radius and observability at the platform.
The Model-Tool-Platform Security Question is the capstone. The model can improve security training and classifiers (the OpenAI GPT-5 series is the current benchmark), the tool can add guardrails and scanners (Claude Code’s auto-mode is the live test), and the platform owns pipeline gates, CI/CD policy, and provenance. Each layer can contribute. They do not contribute equally.
The model layer alone leaves a gap: Anthropic’s classifier missed 11% of dangerous actions even while outperforming human review. Reusable security skills like Red Hat’s prodsec-skills and open-source tools such as Anti Slop and RapiDAST help at the tool layer, and durable control lives in blast radius and observability at the platform.
That decision takes its inputs from the supply-chain and measurement sections, and the full argument is in the model-tool-platform decision.
Resource Hub: AI Coding Tools Deep Dives
Understanding the Divergence and the New Attack Surface
- Why AI Coding Tools Ship Faster but Fail More Security Tests: the 55% pass-rate stall, the AI code paradox, the AI error profile, and security debt at 82% of organisations. About 10 minutes.
- Slopsquatting and the New AI Supply Chain Attack Surface: the TeamPCP/LiteLLM compromise, the OWASP Agentic Top 10, MLSecOps, and agentic governance. About 10 minutes.
From Data to Decision: Measuring and Governing
- How to Measure and Compare AI Coding Tools by Delivery Outcomes: DORA-metrics measurement and outcomes-based comparison of GitHub Copilot, Claude Code, and Cursor. About 9 minutes.
- How to Govern AI Coding Tools and Decide Where the Fix Belongs: the policy spectrum between banning and unrestricted use, and the model-tool-platform architectural decision. About 10 minutes.
Suggested reading order: Start with the data (article 1), then the supply-chain threat (article 2), then measurement (article 3), and finish with governance (article 4). Security-focused readers can jump to article 2; governance-focused readers can jump to article 4 after the data.
Frequently Asked Questions
What is “agent debt,” and how does it differ from security debt?
“Agent debt” is New Relic’s term for the accumulating deficit of unvetted architectural logic in AI-generated code. It reads as high quality at review but triggers incidents once deployed. Security debt is its security-specific cousin: the backlog of unremediated vulnerabilities. Both grow faster than review can absorb. New Relic found 94% of leaders rate AI code higher at review, yet 78% report more incidents. See the speed-security data in article one.
Why did code review become the bottleneck once AI coding tools scaled?
AI removed the writing constraint and exposed the reviewing one. With more PRs flowing, senior reviewers became the scarce resource AI was meant to free. Faros AI telemetry shows review time up 441% and 31% of PRs merging with zero human review. The paradox and governance articles treat this as the central pipeline failure.
Why was Claude Code’s per-call approval prompt an “approval placebo”?
Because humans approved nearly every prompt, the approval gate offered ritual instead of control. When Anthropic made Auto Mode the default in August 2026, its classifier caught 89% of dangerous actions versus 13.6% for humans — still missing 11%. Durable control now lives in blast radius, observability, and recovery. See the governance and architecture discussion.
Claude Code vs GitHub Copilot vs Cursor — which is more secure?
Among the top tier, security is largely undifferentiated. The pass-rate data shows no clear winner, so the decision should hinge on governance defaults, integration with your review gates, and observed incident impact. See the outcomes-based tool comparison.
What should you look for before letting an AI coding agent run with reduced human review in CI/CD?
Look at blast radius, observability, and recovery before you remove a control: what the agent can touch, how you detect a bad action, and how fast you can roll back. Verify sandboxing and least-privilege credentials so untrusted input never coexists with secrets and state-changing power. See the governance framework.
How do you know whether your code review is actually catching AI-generated vulnerabilities?
Attribute vulnerabilities by source (human versus AI commits) and track security pass rate by tool and model rather than relying on review volume. If 31% of PRs merge with zero human review, coverage is an illusion. Scan for hallucinated or squatted dependencies and watch security-sensitive paths. See the measurement and comparison article.
Is slopsquatting just a new name for typosquatting?
It extends typosquatting. Typosquatting pre-registers near-miss spellings of real packages; slopsquatting pre-registers the plausible-but-nonexistent names an AI assistant hallucinates or suggests. Both exploit install trust, but slopsquatting turns the AI’s own output into the lure. See the slopsquatting case study.
Where can you find the Veracode 2026 report and Anthropic’s Auto Mode documentation?
The Veracode 2026 GenAI Code Security Report is the source for the 55% pass-rate figure across 150+ models, and Anthropic’s telemetry documents the Auto Mode default, the 97% rubber-stamp rate, and the classifier miss rate. Both are referenced and contextualised in the data and governance articles.
Start with the data
The speed-security divergence is a delivery problem you now own: the tools write more code than your business can review, the attack surface has moved into the pipeline, and the security fix is only enforceable where you control the gates.
- Start with the data behind the speed-security divergence (article 1)
- Security-focused? Jump to the slopsquatting and supply-chain article (article 2)
- Governance-focused? Jump to the governance and fix decision (article 4)
