97% AI Coding Tool Adoption: What It Means for Your Merge Gate

Black Duck released their June 2026 AI coding adoption study, and one number stands out: 97% of developers now use at least one AI coding tool. GitHub Copilot leads at 83% adoption, followed by Claude Code at 63%. That's not early adoption anymore. That's saturation.

If you're running a team of 50 engineers, statistically 48 or 49 of them are using an AI coding tool right now. Some of those engineers are generating entire pull requests with Copilot or Claude Code. Others are using AI for autocomplete, test generation, or boilerplate. Either way, the code hitting your merge gate has fundamentally changed, and most merge gate configurations haven't kept up.

The adoption numbers in context

Black Duck's study confirms what most engineering leaders already suspected: AI coding tools aren't optional anymore. But the breakdown matters. Copilot's 83% market share reflects Microsoft's distribution power through VS Code and enterprise licensing, not necessarily best-in-class capability. Claude Code's 63% adoption tells a different story. It's a terminal agent used for longer autonomous coding sessions, which means the code it produces tends to be larger, more complex, and harder for a human reviewer to fully inspect.

The practical implication is straightforward: virtually every PR your team opens has some AI involvement. The question isn't whether AI-generated code is entering your main branch. It already is. The question is whether your review process is calibrated for it.

AI-generated code carries more vulnerabilities

The same Black Duck study found that AI-generated code introduces 1.57x more security vulnerabilities than human-written code. That's not a rounding error. It's a 57% increase in vulnerability density per line of code.

Why does this happen? AI coding models are trained on public repositories that include vulnerable code. They pattern-match effectively for functionality, but they don't reason about security the way a seasoned engineer does. Common patterns include:

• Missing input validation on user-facing endpoints
• Hardcoded secrets or credentials in configuration code
• SQL injection via string concatenation instead of parameterized queries
• Insecure deserialization patterns copied from outdated examples
• Overly permissive CORS or authentication middleware

These aren't exotic attack vectors. They're the kind of issues a careful human reviewer catches in their first pass. But at 97% adoption, the volume of AI-generated code has outpaced the capacity of human review.

AI review tools don't fully close the gap

The obvious response to "AI writes more vulnerable code" is "use AI to review it." The Black Duck study tested that assumption and found that AI-powered review tools still miss approximately 29% of vulnerabilities when applied to AI-generated output. That's better than no automated review, but it's far from the safety net many teams assume they have.

This gap exists because most AI review tools were designed for human-authored code. They look for patterns that humans typically get wrong. AI-generated code gets wrong in different ways, producing code that's syntactically clean and conventionally structured but subtly insecure. A function might pass every linter rule while silently skipping authentication checks that a human would have included by habit.

The review tool performance gap matters because teams are stacking two compounding risks: more AI-generated code in every PR, plus review tooling that underperforms specifically on that type of code.

What changes about your merge gate at 97% adoption

Most pre-merge gates were designed around a set of assumptions that no longer hold.

PR volume goes up. AI coding agents like Copilot Workspace and Claude Code can generate PRs faster than any human. Teams that adopted these tools report 2-3x increases in PR throughput. Your human reviewers were already a bottleneck. Now they're drowning.

Authorship trust erodes. When a senior engineer opens a PR, reviewers bring implicit trust to the review. They skim the obvious parts and focus on the tricky bits. When that same engineer's PR is 80% Copilot-generated, that trust isn't earned by the code itself. The reviewer doesn't know which lines the human wrote and which the model wrote.

Merge gate configuration needs updating. A merge gate that requires one approved review and passing CI tests was designed for a world where humans wrote the code and reviewed each other's work. That gate provides no defense against the specific vulnerability patterns AI models introduce. You need a review layer that evaluates the code itself without relying on assumptions about who or what wrote it.

What a merge gate should look like now

The effective pre-merge gate in a 97%-AI-adoption world needs three properties:

1. Author-agnostic review depth. The gate should apply the same scrutiny regardless of whether the commit came from a human, Copilot, Claude Code, or Devin. No fast-tracking based on authorship signals.
2. Blocking enforcement. Advisory comments and annotations aren't enough. If the review finds a critical or high-severity issue, the merge button should be disabled until the issue is resolved. That means a required status check, not an optional PR comment.
3. Codebase context. Static analysis catches generic patterns. But the most dangerous AI-generated vulnerabilities are context-dependent: an endpoint that skips auth because the model didn't understand the project's middleware chain, or a database query that uses the wrong access pattern for the project's permission model. The review tool needs to understand your codebase, not just the diff.

Tenki's Code Reviewer was built for exactly this scenario. It runs as a required status check in your CI pipeline, applies the same depth of review to every PR regardless of authorship, and understands your full codebase when evaluating diffs. In Tenki's own benchmark against 122 seeded bugs, it achieved 68.9% recall (catching 84 of 122 bugs) compared to GitHub Copilot's 24.6% recall (30 of 122). That recall gap is the difference between catching a vulnerability before merge and discovering it in production.

Per-seat pricing breaks down when agents write most PRs

There's a billing dimension to the 97% adoption number that most teams haven't thought through yet. Traditional code review tools charge per seat: $19/user/month for Copilot, $39/user/month for Copilot Enterprise, similar ranges for CodeRabbit and others. That pricing assumes a roughly stable ratio of PRs to developers.

AI agents break that ratio. A single developer using Claude Code or Devin might generate 5-10x the PR volume they'd produce manually. Per-seat pricing means you're paying the same flat rate whether a developer opens 5 PRs a month or 50. For light users, you overpay. But the real problem is that per-seat models don't scale with the actual review workload your pipeline absorbs.

Tenki charges $1 per review instead of per seat. You pay for the work done, not the headcount assigned. If an agent generates 40 PRs in a week for one developer, you pay for 40 reviews. If another developer opens 2 PRs that week, you pay for 2. The cost tracks the actual review load. For teams where AI agents are generating the majority of PRs, this model can be significantly cheaper than per-seat alternatives while delivering higher recall.

Configuring your gate for AI-authored code

If you're an engineering leader or platform engineer reading this, here's what to do this week:

1. Audit your current PR authorship. Check your last 100 merged PRs. How many were opened by bots, Copilot Workspace, or agent-generated branches? Most teams are surprised by the percentage.
2. Make automated review a required status check. If your AI review tool is running as an optional annotation, it's doing nothing when a developer clicks "Merge" anyway. Move it to a blocking gate in your branch protection rules.
3. Evaluate your review tool's recall on AI-generated code specifically. Ask your vendor for benchmarks on AI-generated vulnerabilities, not just human-written ones. If they can't provide those numbers, that's an answer in itself.
4. Recalculate your review tooling cost. If agents are doubling your PR volume quarter over quarter, your per-seat bill stays flat but your coverage per dollar drops. Model out what per-review pricing looks like for your actual volume.
5. Set severity thresholds. Not every finding should block a merge. Configure your gate to block on critical and high-severity issues while surfacing medium and low findings as comments. This keeps developer velocity high without letting the dangerous stuff through.

The 3% holdout won't last

The 3% of developers not yet using AI coding tools are likely in air-gapped environments, regulated industries with explicit bans, or simply haven't been asked recently. That number is headed to zero. Planning your merge gate around the assumption that human-only code is the norm is planning for a world that's already gone.

The teams that adapt their review gates now will ship with confidence. The ones that don't will discover their gaps in production, one vulnerability at a time.