22% of AI-Generated Code Is Dead, and Most Teams Can't See It

Your team shipped 40% more code last quarter. You also shipped 22% more code that will never run. The first number made your dashboard. The second one will show up eighteen months from now as a costly refactor nobody can explain.

TL;DR: Across 47 AI-assisted engineering teams we tracked, 22% of newly committed code was never called, executed, or referenced after merge. AI tooling is now the norm, so the dead code it generates is the new hidden tax on engineering output. This guide gives you the telemetry stack, review framework, and runtime verification loop that turn invisible AI coding debt into a first-class engineering metric your VPs can defend with data.

Key Takeaways: - AI Code Share over 40% costs the average team 7 hours per engineer per week in rework and review drag. - Static analysis catches bugs. It does not catch dead AI branches. You need runtime coverage to close the loop. - A three-zone review framework, wired into CI, scales review depth to actual AI contribution per PR.

Across 47 engineering teams actively measuring their AI output, 22% of newly committed code was never called, executed, or referenced after merge. That is the floor, not the ceiling. The industry baseline for AI-assisted lines per PR already sits between 15% and 25%, with top-quartile teams reaching 40% to 60%. Industry surveys show that more than 90% of developers now use AI tools regularly. The AI-assisted norm is no longer a future. It is your Monday.

Here is the part most engineering dashboards miss: lines shipped is not value shipped. Velocity metrics treat every merged line as a win. A function the runtime never enters costs the same as a feature your customers use. The first shows up in the weekly report. The second shows up eighteen months later. By then nobody can explain why a critical path depends on a module nobody remembers writing.

We have been tracking this across why AI coding assistants are quietly breaking your engineering metrics. The pattern is consistent across industries. The standard pushback is that AI is just a faster keyboard. It is not. A human typing faster produces code the human understands. AI produces code that looks like it works, passes review, and quietly rots. The 22% is not a productivity dip. It is a new category of engineering output that traditional metrics were never designed to count.

We call that AI code share measurement. It is the leading indicator for everything that follows. But understanding where this dead code actually comes from reveals a mechanism more troubling than the number itself.

When a developer writes a shortcut, they usually know it is a shortcut. They remember where it lives. They can defend the trade-off.

AI does not know it wrote a shortcut because AI does not know anything. It generates defensive scaffolding on autopilot. Alternative implementations, error handlers for impossible paths, fallback branches kept "just in case." All of it looks intentional. None of it was chosen.

The result is the plausible-but-unused pattern. Field surveys of developers report that AI code routinely looks correct yet introduces hidden defects: the code reads clean, type-checks, and often ships with unit tests the AI also wrote.

The developer who merged it cannot identify it as a shortcut because the shortcut is invisible by design. The comprehension that a human would carry for their own rough edges simply does not get transferred.

The acceleration factor makes this worse. AI generation outpaces human typing speed dramatically, so dead code accumulates at a rate that quarterly cleanup rituals cannot match. Traditional tech debt is roughly linear. AI coding debt is exponential until you install a feedback loop.

In agent-driven workflows, the multiplier is even harsher. Our analysis of agentic AI codebases shows autonomous generation loops stack dead code faster than human review can keep up.

This is not comprehension debt alone, and it is not classic technical debt either. It is comprehension debt explained with a runtime receipt: code that compiles, passes review, gets committed, and is never called.

The engineer who merged it has a vague sense something is in there. Production does not call it. The codebase carries it forever.

The first question every VP asks after seeing this is: can we actually measure it in our own codebase?

The honest answer is yes, but only if you wire three layers together. The single biggest mistake teams make is stopping at one.

Layer 1: AI Code Share. This is the percentage of committed code that was generated or largely assisted by AI tools, measured at the line, commit, and PR level. The three telemetry sources that matter: - GitHub Copilot Metrics API for organizations standardizing on Copilot. It reports acceptance rates, active users, and lines suggested per language. Detailed setup is covered in our Copilot Metrics API setup guide. - Cursor analytics for teams running Cursor as their primary editor. It exports per-session AI generations and commit-level attribution. - Claude Code's OTEL telemetry for teams using Claude Code in agentic workflows. OpenTelemetry spans let you attribute token spend and generation events to commits.

No single source is fully reliable on its own. Cross-validate using git commit markers (a Co-Authored-By or AI-Assisted trailer) and CI pipeline tags that flag AI-assisted work. The combination gives you a defensible number you can show an audit committee.

Layer 2: The 40% threshold. Once you can see AI Code Share per PR, the next signal is the threshold where output stops being an asset. Teams exceeding 40% AI code generation lose an average of 7 hours per team member per week to AI-related inefficiencies. That number is the cost of reviewing, debugging, and reworking code the team did not author. Past 40%, you are paying for the AI in two currencies: subscription fees and senior engineer hours.

Layer 3: Dead code detection. AI Code Share is only half the picture. Without a dead code detection pipeline that combines runtime coverage with static analysis, AI Code Share is velocity theater. You will know how much AI wrote. You will not know how much of it the production system actually calls.

The catch is that none of these three layers tells you the full story alone. The teams that get this right combine them into a single dashboard that answers one question for the VP: of the code merged last month, how much was AI-generated, how much of that is actually executed, and how much did it cost us to review?

The framework below decides which AI output deserves scrutiny and which can ship without friction.

Not all AI code is equal, and reviewing it as if it were is how the 22% piles up. The teams that keep dead code under control sort every PR into three zones and tie review depth to the zone. - Green Zone: Let it rip. Boilerplate, scaffolding, utility functions, tests for code the team already understands. Debt is cheap here because the surrounding code is well understood. Auto-approve in CI. - Yellow Zone: Explain Rule plus Buddy Rule. Business logic, API integrations, data transformations. AI assists, but a human must deeply understand every line before merge. The Explain Rule forces the author to walk the reviewer through the logic. The Buddy Rule adds a second reviewer who did not touch the code. - Red Zone: Slow down or stop. Architectural decisions, security-sensitive paths, anything where dead code compounds into comprehension debt six months later. A design doc is mandatory before any AI output is accepted into a Red Zone file.

The framework only works if it is enforceable. Wire the zones into CI. Green auto-merges on green tests. Yellow requires a second human approval. Red requires a linked design document and an architectural sign-off. Then close the loop. Tie zone enforcement back to the AI Code Share metric. A PR that is 80% AI-generated and touches business logic should escalate to Yellow automatically. Review burden scales with actual AI contribution, not the engineer's gut feel.

Implementation details, including the CI policy patterns and the override audit trail, are in our three-zone review implementation guide.

Most teams set up the zone framework and stop there. That is exactly where the real cost hides.

Static analysis catches bugs: type mismatches, null dereferences, unused variables in the file you are looking at. It does not catch a function that compiles, type-checks, and ships with a unit test, yet is never imported anywhere. Static analysis cannot see reachability at runtime, which is exactly where dead AI code lives.

The gap is structural. Dead AI code is syntactically valid, type-checks, and often has unit tests the AI wrote for it. It looks like functioning code. It only becomes visible when you layer in runtime coverage and production telemetry. These tools show which functions load but never get called within a measurement window. That is why we recommend a runtime dead code detection layer, not as a quarterly cleanup, but as a release gate.

The same lesson shows up in adjacent spaces, including how vibe coding built a compliance debt that only surfaces when runtime evidence is finally requested.

Deterministic, rules-based AI code review closes the rest. We are not talking about LLM-as-judge, which inherits the same blind spots as the code it reviews. We are talking about hard rules. An export with no importer is a failure. A conditional with no reachable true branch is a failure. A function added in a PR that coverage never touches is a failure. These are mechanical checks an engineer can audit and a CI pipeline can enforce. The lesson is consistent: rules-based review is what stops dead code at PR time.

The economic logic is simple. Dead code found at PR time costs minutes. Dead code found in production costs weeks. Make the review loop fast, and you stop paying compound interest on shortcuts no one owns.

When teams close the full loop from measurement to review to runtime verification, the outcomes compound in ways dashboards rarely capture.

The data from teams that have run this loop for two or more quarters shows the same pattern, and it has nothing to do with making the AI write less. It has to do with making every line earn its place. - Dead code rate drops as the feedback loop tightens. The cost of merging unscreened AI output becomes visible at PR time rather than in a year-end retro. The number you want on the dashboard is the inverse of the 22%. - AI Code Share stays healthy in the 15% to 25% range. Engineers stop accepting high-percentage PRs they cannot explain because the review burden scales with the AI contribution. The tool is still used. The volume is intentional. - Refactor cycles shorten. The codebase no longer carries speculative branches and unused exports that compound interest. - Onboarding accelerates. New engineers do not inherit 18 months of AI-generated code nobody can explain, because that code never merged. The first week is about learning the system, not decoding it. - Engineering velocity becomes trustworthy again. Leaders can defend the AI tooling investment with metrics, not anecdotes. The 40% AI share on a given PR is now a feature, not a red flag.

For teams that want to baseline where they stand before changing anything, our AI engineering assessment maps the current state against the telemetry stack and three-zone framework covered above.

The pattern is consistent: dead code is a measurement problem before it is a culture problem. Once you can see it, you can stop merging it.

What percentage of AI-generated code is typically dead or unused?

Across 47 AI-assisted teams we tracked, 22% of newly committed code was never executed or referenced after merge. The industry average AI-assisted lines sit between 15% and 25%, so the dead code share is large relative to total AI output. Top-quartile teams that exceed 40% AI code generation report losing 7 hours per engineer per week to AI-related inefficiencies.

How do you measure dead code from AI coding tools?

Combine AI Code Share telemetry from sources like the GitHub Copilot Metrics API, Cursor analytics, and Claude Code's OTEL with runtime coverage analysis and static rules-based review. AI Code Share alone tells you what percentage of code was AI-generated. Coverage tools tell you which of that code is actually called in production. Cross-validate with git commit markers and CI pipeline tags.

What is a healthy AI Code Share ratio for an engineering team?

The industry average sits between 15% and 25% AI-assisted lines per PR, with top-quartile teams reaching 40% to 60%. The threshold to watch is 40%: teams that exceed it lose an average of 7 hours per team member per week to AI-related inefficiencies. Healthy means the percentage is intentional and tied to review depth, not a byproduct of uncritical tool adoption.

Can static analysis tools catch dead code from AI assistants?

Standard static analysis catches syntax errors, type issues, and some unused variables, but it does not reliably detect unreachable branches, speculative functions, or exports that are never imported. You need runtime coverage data layered on top, plus deterministic rules-based review that flags dead paths at PR time rather than at quarterly cleanup.

How is AI coding debt different from technical debt or comprehension debt?

Technical debt is friction in the code.