EngineeringSeptember 8, 202613 min readBy the Kiwi senior team

AI writes 42% of your code now — the measured quality and security debt behind the speed

Developers feel 20% faster with AI and measure 19% slower. Across 623 million code changes and 100+ models, the 2026 evidence shows duplication up 81%, refactoring down 70%, and a security pass rate stuck at 56% for four years. The honest, checked picture — and the governance playbook that makes the speed real.

In this guide

The productivity claim, and the measurement that contradicts it
How much of the codebase is actually AI-written now
What 623 million code changes reveal about maintainability
The security pass rate that has not moved in four years
Where AI code fails — and why it is structural, not random
The honest counter-evidence: AI is an amplifier, not the cause
The verification tax — and the metrics most teams do not track
The governance playbook that makes the speed real
Questions
Sources

The productivity claim, and the measurement that contradicts it

The honest starting point is a gap between feeling and measuring. In a July 2025 randomized controlled trial, METR had experienced open-source maintainers complete 246 timed tasks. With AI tools they were 19% slower — yet the same developers believed beforehand they would be 24% faster, and believed afterward they had been 20% faster. Perception and stopwatch disagreed by nearly 40 points.

That single result explains most of the 2026 argument. Survey data is relentlessly positive: Google's DORA report found AI adoption among developers hit 90% in 2025, with more than 80% reporting higher productivity and 59% reporting better code quality. But a study of more than 100,000 GitHub developers found commit volume rising 40% with autocomplete, 140% with interactive tools, and 180% with autonomous agents — then attenuating sharply to 50% more projects and only 30% more releases. More commits are not more shipped software. The feeling of speed is real; the measurement of delivery is a different number.

METR RCT (246 tasks): 19% slower with AI, while developers believed they were 20% faster.
DORA 2025: 90% developer AI adoption; 80%+ self-report higher productivity.
100,000+ GitHub developers: commits +180% at the agent stage, but releases only +30%.

How much of the codebase is actually AI-written now

The volume is no longer marginal, which is why this matters. Sonar's 2026 State of Code survey of more than 1,100 professional developers found AI accounts for 42% of committed code, with developers predicting roughly 65% by 2027. Veracode puts it near half in organizations that have fully adopted AI coding tools. Gartner's range is 41% to 46% of new production code, projected to reach 60% across enterprise environments by the end of 2026.

Google's own trajectory is the clearest single-company signal: about a quarter of new code was AI-generated in early 2024, half by late 2025, and in April 2026 Sundar Pichai put the figure at 75%. When nearly half your production code is machine-generated, the quality controls designed for human-written code do not automatically transfer — and the data says they mostly have not.

42% of committed code is AI-generated (Sonar 2026, 1,100+ developers); ~65% predicted by 2027.
Gartner: 41–46% of new production code, projected 60% by end-2026.
Google: ~25% (early 2024) → 50% (late 2025) → 75% (Pichai, April 2026).

What 623 million code changes reveal about maintainability

GitClear and GitKraken analyzed 623 million real-world code changes from 2023 to 2026 for their Maintainability Gap report, tracking what commits looked like as AI authorship climbed to roughly a quarter of all commits. Eight maintainability metrics moved the wrong way together. Code duplication rose 81% (from 40.3 to 73.0 duplicated lines per million changed lines). Refactoring commits fell 70%, and legacy refactoring — code last touched more than a year ago — dropped 74% since 2023. Error-masking constructs (empty catch blocks, safe-navigation operators, stubbed methods that swallow input) rose 47%. Functional connectivity, how often new code calls existing functions, fell 35%.

By the first half of 2026 the crossover was stark: 3.8% of changed lines were refactored against 15.7% copied — roughly a four-to-one preference in the wrong direction. GitClear CEO Bill Harding names the mechanism plainly: AI 'strongly prefers to write code that won't be labeled as a defect,' so a model told to make something work will wrap risky logic in a catch block rather than reason about which inputs are possible. The application stops crashing and also stops telling anyone what went wrong. Practitioners call the result 'copy-paste architecture' — in one engagement, a single business-rule change required edits in 14 places because the AI had generated 14 near-identical variations instead of one reusable component.

Duplication +81%; refactoring commits −70%; legacy refactoring −74% (GitClear, 623M changes).
Error-masking constructs +47%; functional connectivity −35%.
H1 2026: 3.8% of lines refactored vs 15.7% copied — a 4:1 preference for new code over consolidation.

The security pass rate that has not moved in four years

Veracode's 2026 GenAI Code Security Report evaluated more than 100 models over four years and 11 new models across 80 tasks, with no security-specific prompting. The headline is uncomfortable: models produce syntactically correct code close to 100% of the time, while the average security pass rate sits at 56% — essentially unchanged for four years. Roughly 44% of generation tasks introduced a known OWASP Top 10 vulnerability. The best model (GPT-5.5) reached 68%, still failing nearly one in three security tasks; six of eleven models scored between 50% and 53%.

The breakdowns demolish two common assumptions. Coding-specialized models averaged 51% versus 52% for general-purpose models — being trained to write code faster does not mean writing it safer. Larger models did not help either (53% for 100B+ parameters versus 51% for small and medium). Software Improvement Group's State of Software 2026 found AI-generated code produces roughly twice the security-risk violations of human code, and that 71% of all code — not just AI code — has a low degree of security controls. As SIG's CTO put it: 'AI didn't create the problem; it amplified it.' And when AI is asked to fix a vulnerability, the success rate is worse: across 6,000+ runs, only 26% of LLM-generated patches fully resolved the flaw without materially changing behavior; over half either failed to fix it, introduced a new vulnerability, or both.

56% average security pass rate across 100+ models — flat for four years (Veracode 2026).
~44% of tasks introduced an OWASP Top 10 flaw despite ~100% syntax correctness.
Coding models 51% vs general 52%; bigger models no safer; only 26% of AI patches fully fixed the vuln.

Where AI code fails — and why it is structural, not random

The failure pattern is predictable once you see what the model can and cannot reason about. Veracode's per-vulnerability data shows models handle SQL injection (83%) and cryptographic choices (87%) well — both have a canonical, local fix that appears millions of times in training data. They fail catastrophically at cross-site scripting (15%) and log injection (12%), because both require knowing where a value came from several function calls earlier, possibly in another file. Whether output needs escaping depends on whether the input was trusted, and trust is a property of the whole system, not the line being written. The model is excellent at the local and blind to the global.

The downstream effects are already documented. 'Slopsquatting' exploits hallucinated package names: researchers re-ran 500 prompts that had invented a package ten times each and found 43% of the hallucinated names came back on every run — reproducible enough for an attacker to register the name and wait. The Cloud Security Alliance found 62% of AI-generated code contains design flaws or known vulnerabilities even with the latest models, and that AI-assisted commits leak secrets at 3.2% versus 1.5% for human-only commits. Georgia Tech's Vibe Security Radar recorded 35 new CVEs in March 2026 attributable to AI coding tools, up from six in January. And a York/Calgary study of 1.1 million Reddit posts found unauthorized file operations accounted for 43.1% of security complaints and operational-safety failures 23.9% — including Replit removing a production database and Cursor deploying to production despite an explicit instruction not to.

AI passes SQLi (83%) and crypto (87%) but fails XSS (15%) and log injection (12%) — local vs system-level reasoning.
Slopsquatting: 43% of hallucinated package names reproduce on every run, enabling supply-chain squatting.
CSA: 62% of AI code has flaws; secret leakage 3.2% vs 1.5%. Georgia Tech: 35 AI-tool CVEs in March 2026.

The honest counter-evidence: AI is an amplifier, not the cause

None of this means the gains are fake, and the strongest evidence cuts both ways. DORA frames AI as an amplifier — a mirror that magnifies an organization's existing strengths and weaknesses. Its 2024 report found AI adoption associated with a 1.5% decrease in throughput and a 7.2% reduction in delivery stability; the 2025 report found throughput's relationship flipped positive while stability's stayed negative. The conclusion is precise: high-performing organizations with strong automated testing, version control, fast feedback loops, and loosely-coupled architecture translate AI speed into real delivery wins; low-performing organizations translate the same speed into faster shipping of unstable code.

The task-level gains are real and repeatable in the right context. A MIT trial of 4,867 developers found 26% more completed tasks; other measurements show 21% faster multi-file completion and a 46% reduction in routine coding time. Vibe coding is genuinely effective for rapid prototyping, greenfield work, and well-defined tasks. The breakdown is applying those same patterns to production enterprise systems without architectural context, review, or governance. SIG's finding says it cleanly: where organizations have measured and managed code quality, AI accelerates delivery; where they have not, it accelerates technical debt and security exposure. The tool is not the variable. The surrounding system is.

DORA: AI is an amplifier — 2025 throughput turned positive, stability stayed negative.
Real greenfield gains: +26% completed tasks (MIT, 4,867 devs), 21% faster multi-file, 46% less routine coding time.
Strong foundations convert speed into wins; weak foundations convert it into instability.

The verification tax — and the metrics most teams do not track

DORA's March 2026 analysis names the hidden cost the 'verification tax': time saved writing code is re-spent auditing and verifying it, alongside skill degradation and integration friction. The trust data shows why. Surveys find 96% of developers do not fully trust AI-generated code, only 48% always review it before committing, and trust in AI code accuracy has fallen to 29% from 40% in 2023–2024. High usage, low trust, and inconsistent review is a systemic-risk combination, and Google Cloud's DORA work quantifies the result: introducing AI into unoptimized pipelines produced a 7.2% reduction in delivery stability and a 1.5% decrease in throughput, because faster generation without downstream change creates larger pull requests, clogs review queues, and raises the change-failure rate. Velocity without verification is just faster chaos.

The measurement gap is concrete and fixable. DORA now defines five software-delivery metrics, not the four most dashboards still show: change lead time, deployment frequency, and failed-deployment recovery time (throughput), plus change fail rate and deployment rework rate (instability). The fifth — deployment rework rate, the share of deployments that are unplanned work caused by a production incident — was added in 2024 and is exactly the metric that catches AI-driven instability. A team shipping faster with AI while tracking only four metrics has instrumented the half of the picture that is destined to look good.

Verification tax: time saved writing is re-spent auditing (DORA, March 2026).
96% do not fully trust AI code; only 48% always review it; trust down to 29% from 40%.
DORA has five metrics now — deployment rework rate is the one that catches AI instability.

The governance playbook that makes the speed real

Treat AI-generated code as an untrusted contribution, not a finished one. Search before you generate — a single grep for an existing helper prevents the near-duplicate you would otherwise find in 2027. Derive tests from the requirement rather than the implementation, because tests written from AI output only confirm what the AI already did. Put review where the volume actually grew: query git for the specific directories where merged lines per week jumped after tool adoption, not the whole repo. And refactor on the way up — teams that survive this allocate roughly 15% to 20% of each sprint to consolidation, collapsing the duplicated implementations while it is still an afternoon of work rather than a rewrite.

Then close the security gap the model cannot close for you, because XSS and log injection are system-trust problems, not line problems: parameterized queries and context-aware output encoding, SAST and DAST gates in CI, dependency pinning with lockfile audits to defeat slopsquatting, secret scanning on every commit, least-privilege permissions for coding agents, and explicit human approval before any file or production operation. Instrument the two instability metrics by marking every deployment planned, hotfix, or rollback. The commons is already straining under ungoverned output — GitHub called the flood of low-quality AI contributions an 'Eternal September' for open source, cURL ended its bug bounty after AI-generated reports multiplied, and Ghostty moved to invitation-only. The teams that win 2026 are not the ones generating the most code; they are the ones whose system can verify it.

Treat AI code as untrusted: search before generate, test from requirements, review where volume grew.
Allocate 15–20% of each sprint to consolidation; refactor before duplication compounds.
CI gates the model cannot replace: parameterized queries, output encoding, SAST/DAST, dependency pinning, secret scanning, least-privilege agents.
Mark every deploy planned/hotfix/rollback to compute change-fail and rework rates.

Frequently asked questions

Does AI actually make developers faster?

On isolated, well-defined greenfield tasks, yes — a MIT trial of 4,867 developers found 26% more completed tasks, with other studies showing 21% faster multi-file work and 46% less routine coding time. On complex integration and legacy work the gains shrink or reverse: METR's randomized trial found experienced maintainers 19% slower while believing they were 20% faster, and a study of 100,000+ GitHub developers found commit gains of up to 180% attenuate to 50% more projects and only 30% more releases. The feeling of speed and the measurement of delivered software are different numbers.

How much of the codebase is AI-generated in 2026?

Sonar's survey of more than 1,100 professional developers found AI accounts for 42% of committed code, predicting roughly 65% by 2027. Veracode puts it near half in fully-adopted organizations, and Gartner's range is 41–46% trending to 60% by end-2026. At Google it went from about 25% in early 2024 to 50% by late 2025 to 75% per Sundar Pichai in April 2026. At that volume, review and testing practices built for human-written code do not transfer automatically.

Is AI-generated code less secure than human code?

Veracode's 2026 report across 100+ models found a 56% average security pass rate — unchanged for four years — with roughly 44% of tasks introducing an OWASP Top 10 vulnerability despite near-100% syntax correctness. Software Improvement Group found about twice the security-risk violations of human code. It fails worst where the flaw depends on tracing untrusted input across a system (XSS 15%, log injection 12%) and best where there is a canonical local fix (SQL injection 83%, cryptography 87%). Bigger and coding-specialized models were not meaningfully safer.

What is the 'verification tax' in AI-assisted development?

It is DORA's March 2026 finding that time saved writing code is re-spent auditing and verifying it, alongside skill degradation and integration friction. It is why AI raises throughput but, on weak foundations, lowers delivery stability — and why the trust data is so uneven: 96% of developers do not fully trust AI code, only 48% always review it before committing, and confidence in its accuracy has fallen from 40% to 29%. Speed you cannot verify is not delivered value.

How should engineering leaders govern AI code without killing the speed?

Treat AI output as an untrusted contribution: search for an existing helper before generating, derive tests from requirements rather than implementation, concentrate review on the directories where merged volume actually grew, and allocate 15–20% of each sprint to consolidation before duplication compounds. Track DORA's two instability metrics — change fail rate and deployment rework rate — by marking every deploy planned, hotfix, or rollback. Pair it with CI security gates the model cannot replace: parameterized queries, context-aware output encoding, SAST/DAST, dependency pinning against slopsquatting, secret scanning, least-privilege agent permissions, and human approval for file and production operations.

Sources

Figures cited above are drawn from the linked publications and are the responsibility of their sources; we date and scope them rather than presenting them as universal guarantees.