The Numbers Are In

Ninety-five percent of developers now use AI coding tools at least weekly. Not occasionally. Not experimentally. Weekly.

That stat comes from Anthropic’s Agentic Coding Trends Report, published in January. And it’s just the starting point. Seventy-five percent of developers use AI for half or more of their work. Fifty-six percent report doing 70% or more of their engineering with AI assistance. Over half regularly use AI agents — not just autocomplete, but autonomous tools that read, plan, and execute across codebases. Among staff-plus engineers, agent adoption hits 63.5%.

The labor market confirms it. Job postings requiring AI coding tool experience increased 340% between January 2025 and January 2026. Postings for pure implementation roles — “take this spec and write the code” positions — declined 17% over the same period.

This is not an emerging trend. This is the new baseline. AI-assisted development won. The debate is over.

Now comes the harder question: what did we break on the way here?

More Code, More Problems

In December 2025, CodeRabbit published an analysis of 470 open-source GitHub pull requests, comparing AI-co-authored code against human-written code across a range of quality metrics. The findings were not subtle.

AI-co-authored code had 1.7x more “major” issues than human-written code. Not minor style nits — major problems. The kind that break things in production.

Security vulnerabilities appeared at 2.74x the rate of human-written code. Misconfigurations were 75% higher. The analysis flagged elevated rates of logic errors, incorrect dependency usage, and flawed control flow — the kinds of bugs that don’t show up in a unit test because the test was also generated by the same tool that introduced the bug.

Let that ratio sink in. Nearly three times the security vulnerability rate. In a world where 95% of developers are using these tools weekly and the majority are using them for most of their work.

This isn’t a hypothetical risk model. This is what’s shipping right now.

The Velocity Trap

Here’s how it plays out in practice.

A developer using an AI agent gets a task. The agent reads the relevant files, plans an approach, writes the implementation, generates tests, and presents the result. The developer reviews it, sees that it looks reasonable, confirms the tests pass, and merges. Elapsed time: maybe 20 minutes for what used to take half a day.

That’s the productivity story everyone celebrates. And it’s real — the velocity gain is not imaginary.

But something shifted in that workflow. The developer reviewed code they didn’t write and may not fully understand. The tests were generated by the same system that wrote the implementation, so they validate what the AI intended to do, not necessarily what the code should do. The review was faster because the code looked clean — AI-generated code is almost always syntactically tidy, well-commented, and superficially reasonable.

The surface quality masks the structural risk.

When a human writes code, the act of writing creates understanding. You know where the edge cases are because you thought through them while implementing. You know which parts are fragile because you struggled with them. That tacit knowledge informs your review, your testing, and your debugging when things go wrong at 2 AM.

When an AI writes code and a human approves it, that tacit knowledge doesn’t transfer. The developer is reviewing output, not reconstructing intent. And the gap between those two activities is exactly where security vulnerabilities, logic errors, and misconfigurations live.

The Economics Make It Worse

Cost is the other half of this equation, and it cuts in a dangerous direction.

Pricing models for AI coding tools are debated as intensely as capabilities. MIT Technology Review’s January 2026 breakdown of generative coding identified cost consciousness as a primary driver of adoption patterns. Teams choose tools based on per-seat costs, token limits, and pricing tiers — not based on which tool produces the most secure output.

This creates a predictable dynamic: organizations adopt the most cost-effective AI coding tool that clears a capability threshold, deploy it across their entire engineering org, and then rely on existing code review and CI/CD processes to catch problems. But those processes were designed for a world where humans wrote code at human speed.

When your developers are producing 2x, 3x, or 5x more code with AI assistance, your review processes don’t automatically scale to match. The same senior engineers who used to review a manageable volume of pull requests are now facing a firehose. Review quality drops. Shortcuts get taken. The rubber stamp becomes the default.

Meanwhile, the security team is still staffed for the old velocity. The SAST tools are still tuned for human-written code patterns. The threat modeling happens at the same cadence it always did, even though the attack surface is growing at a rate nobody planned for.

What Actually Needs to Change

The answer is not to stop using AI coding tools. That ship sailed. It sailed, docked, unloaded, and the port was renamed after it. You’re not putting this back in the box.

The answer is that your security posture needs to match your development velocity. And for most organizations, it doesn’t. Not even close.

Code review has to evolve

Human code review of AI-generated code requires a different mindset than reviewing human-written code. Reviewers need to be more adversarial, not less. The code will look clean. The comments will be helpful. The structure will be plausible. Your job is to ask: “what did this tool not consider?” Check for hardcoded secrets, missing input validation, overly permissive defaults, and dependency choices that introduce supply chain risk. Don’t trust the tests the AI wrote to validate the code the AI wrote.

CI/CD pipelines need security gates that match the throughput

If your team is merging 3x more PRs per week, your static analysis, dependency scanning, and security checks need to handle that volume without becoming a bottleneck that people bypass. Automated security tooling isn’t optional anymore — it’s the only way to maintain coverage at AI-assisted development speed.

Governance needs to catch up

Who approved the AI tool your team is using? What data does it send externally? What models is it running? Is there a policy on which tasks are appropriate for AI agents versus human implementation? For most organizations, the answers range from “unclear” to “we haven’t thought about it.” That was acceptable in 2024. It’s not acceptable when AI writes the majority of your production code.

Security teams need AI-specific threat models

The vulnerability patterns in AI-generated code are different from human-written code. The CodeRabbit data shows this clearly — the failure modes cluster around misconfigurations, incorrect dependency usage, and control flow errors, not the classic buffer overflows and injection attacks that traditional SAST tools are tuned to catch. Security teams need to understand these patterns and adjust their tooling and review processes accordingly.

Developers need to maintain understanding

This is the cultural piece, and it might be the hardest. Engineers need to resist the temptation to approve code they don’t understand just because the tests pass and it looks reasonable. If you can’t explain what the code does and why it does it that way, you haven’t reviewed it — you’ve rubber-stamped it. AI agents are force multipliers for engineers who understand their systems. They’re liability generators for engineers who don’t.

The Uncomfortable Middle Ground

The industry is in an awkward spot. The productivity gains from AI coding tools are real and significant. The quality and security risks are also real and significant. Both things are true simultaneously.

The organizations that will navigate this well are the ones that treat AI-assisted development as a capability that requires new governance, not just a tool that slots into existing workflows. They’ll invest in security tooling that matches their new velocity. They’ll update their review practices. They’ll make deliberate choices about what their AI tools can access and what runs on infrastructure they control.

This is what platforms like Calliope are built for — giving teams the AI-powered development capabilities they need while keeping the infrastructure, the data, and the governance under their own roof. Because when 95% of developers are using AI tools and most of the resulting code has measurably higher vulnerability rates, “we’ll figure out security later” is not a strategy.

The tools are here. The adoption is done. The security posture is what’s lagging.

Close the gap before someone else finds it for you.

Sources

• Anthropic, 2026 Agentic Coding Trends Report (January 20, 2026). https://resources.anthropic.com/2026-agentic-coding-trends-report
• MIT Technology Review, Generative Coding: AI Software 2026 Breakthrough Technology (January 12, 2026). https://www.technologyreview.com/2026/01/12/1130027/generative-coding-ai-software-2026-breakthrough-technology/
• CodeRabbit, Analysis of AI-Co-Authored Code Quality in Open-Source Projects (December 2025). Referenced in multiple industry analyses of 470 open-source GitHub pull requests.