Back to Blog

When AI Writes Half Your Code, Shift-Left Becomes a Volume Problem

When AI Writes Half Your Code, Shift-Left Becomes a Volume Problem

TL;DR

AI-assisted development now produces 22% of merged code across 135,000+ developers (DX, 2025), with top-quartile teams running 40-60% AI-assisted lines. The old shift-left logic still holds, but the bottleneck has moved from detection to triage. Scanners scale. Human triage queues don't. The teams that are actually clearing backlogs aren't running faster scanners. They're routing findings directly to the service owner with a drafted fix attached. Cantina (AppSec plus OpSec plus everything in between) does this on a single platform: finding generation, ownership routing, auto-fix PR, runtime correlation, and compliance evidence in one flow.

Key definitions

Shift-left: Moving security checks earlier in the software development lifecycle so bugs are caught before code ships, where fixes are cheaper.

Routing layer: The system that takes a security finding and attaches it to the right service owner, the right repository, and a drafted remediation, instead of dropping it into a shared queue.

AI-assisted code volume problem: The mismatch between how fast AI coding tools generate code (scales linearly with seats) and how fast human triage absorbs findings (scales with headcount).

Something I hear very little talk about in the AI coding debate: the security teams downstream are not okay.

The shift-left logic still works on paper. Catch a bug before it ships and the cost of the fix drops by an order of magnitude. That math hasn't changed. The volume has.

How much code is AI actually shipping?

DX analyzed 135,000+ developers and found 22% of merged code is now AI-authored. GitHub Copilot reached 20 million cumulative users in July 2025, up 5 million in three months. Top-quartile engineering teams are running 40-60% AI-assisted lines, and 91% of developers report their teams are merging PRs that contain Copilot-generated changes.

Aka the pipeline is moving more code per engineer than it has at any point in the history of software, and the trend line is still climbing.

What does the new volume look like inside an AppSec team?

Teams that used to merge ten pull requests a day are merging thirty. The scanner that ran in two minutes runs in six. The triage queue one engineer used to clear in an afternoon now needs three engineers and a backlog ticket nobody owns.

Industry analysis of AppSec workflows puts the actual fix-work at about 20% of an AppSec engineer's time. The other 80% goes to jumping between dashboards, eliminating duplicates, and chasing false positives. That math was already ugly before AI assistants started doubling code throughput.

And the work isn't just bigger. It's also riskier: AI-generated code carries vulnerabilities at 2.74x the rate of human-written code, and CVEs attributed to AI-generated code went from 6 in January 2026 to 35 in March.

Why isn't a faster scanner enough?

Because the scanner was never the bottleneck. Triage was.

Static analysis has been "fast enough" for a decade. The thing that used to break wasn't the scan, it was the human queue downstream of it. So when AI shoves another 22% of code through the door, the scanner shrugs and adds it to the list. Heck, the scanner is the only part of the stack that scales linearly with code volume.

Everything after the scanner (the part where a human reads the finding, figures out who owns the service, decides if the data is customer-facing, opens a Jira, follows up on the PR) does not scale linearly. It scales with headcount, and headcount is the one input no AppSec leader gets to double this year.

So the bottleneck moves: the scanner still runs in six minutes, but the 200 new findings it produced this week sit in the queue for six weeks.

What changes when routing becomes the scaling primitive?

The teams actually reducing alert backlogs are the ones whose tools route findings based on which service they hit, who owns it, and whether the data is customer-facing.

Scanners that just produce findings keep adding to the queue. Scanners that produce a finding tied to a service owner, a remediation path, and a draft PR remove items from it.

That is the inversion most platforms haven't made yet. Shift-left was framed as "move detection earlier in the SDLC." The actual lever now is "compress the gap between detection and the right human." Detection earlier is meaningless if the finding still sits in a queue with 12,000 friends.

The tail should not wag the dog: AppSec exists to ship fixed code, not to ship more findings.

How does Cantina handle this?

Cantina is AppSec plus OpSec plus everything in between, on one platform. For the volume problem, the part that matters is what happens after a finding fires:

  • The AppSec lens generates the finding with code-level context (the function, the call site, the data flow)
  • The routing engine matches it to the right service owner based on CODEOWNERS, recent commit authorship, and runtime ownership signals
  • The auto-fix workflow opens the PR with the fix already drafted against the actual repo
  • The OpSec lens correlates whether the same path is exposed at runtime
  • The compliance lens captures the evidence trail without anyone copying screenshots into a spreadsheet

The finding doesn't enter a queue. It enters a pull request, on the right repo, with the right reviewer, with the runtime exposure attached.

What does this look like on a real triage queue?

Three patterns hold across the teams running this setup:

  1. Findings-per-engineer drops, fixed-findings-per-engineer rises. Same scanner, same code volume, different routing. The total number of findings stops being the metric anyone tracks because it stops being load-bearing.
  2. Time-to-fix collapses from weeks to days for owned services. The pre-drafted PR is the thing that does this. A reviewer who gets a PR with a one-paragraph context note merges faster than a reviewer who gets a Jira ticket pointing at a file.
  3. The "who owns this?" question stops appearing in standups. Ownership routing is invisible when it works. You notice it only the week it breaks.

None of this requires changing the scanner. It requires changing what happens between the scanner and the human.

What should I actually do this quarter?

If you're an AppSec lead watching your queue grow with your engineering org's AI adoption, the move is not to buy a faster scanner. The move is to audit the routing layer:

  • Do findings carry a service owner by the time they reach a human?
  • Do they carry a runtime correlation, or does the engineer have to switch consoles to check?
  • Do they carry a draft fix, or just a description of the problem?

If the answer to any of those is no, that's where the next quarter's effort goes. Not on more detection. On the routing layer.

See it on your stack

Book a 30-minute platform tour at cantina.security. Bring a real PR workflow from one of your repos and we'll wire up routing live.

FAQ

Is shift-left still a valid AppSec strategy in 2026?

Yes, but the bottleneck has moved. The cost-of-fix math behind shift-left still holds: bugs caught before merge are cheaper to fix by an order of magnitude. What's changed is that the binding constraint is no longer "developers seeing the issue." It's the routing layer between the issue and the engineer who can fix it.

How much code is AI generating in production codebases right now?

22% of merged code is AI-authored across a DX study of 135,000+ developers. Top-quartile teams report 40-60% AI-assisted lines, and 91% of developers say their teams are merging PRs that contain Copilot-generated changes.

Does AI-generated code introduce more vulnerabilities than human code?

The data so far says yes. AI-generated code carries vulnerabilities at roughly 2.74x the rate of human-written code, and CVEs attributed to AI-generated code went from 6 in January 2026 to 35 in March 2026.

What's the actual bottleneck in AppSec when code volume scales?

Triage, not detection. Static analysis has been fast enough for years. Industry analysis of AppSec workflows puts the actual fix work at about 20% of an engineer's time, with the other 80% going to dashboard-hopping, deduplication, and false-positive investigation. AI-driven code volume amplifies the triage load directly.

What does a "routing layer" do that a scanner doesn't?

A scanner produces findings. A routing layer attaches each finding to a service owner, a repository, a runtime correlation, and ideally a drafted fix in a pull request. The finding never enters a shared queue. It enters a specific PR with a specific reviewer.

How does Cantina handle AI-accelerated code volume?

Cantina runs AppSec, OpSec, and the routing between them on one platform. A finding fires with code-level context, the routing engine matches it to a service owner via CODEOWNERS and commit signals, the auto-fix workflow drafts the PR, the OpSec lens correlates runtime exposure, and the compliance lens captures the evidence trail in the same flow.