42% of Committed Code Is AI-Written and Only 48% of Developers Always Verify It

Adoption stopped being the story

72% of developers who have tried AI coding tools now use them every day, which ends the era of weekend experiments. More telling is where the code goes: 88% use AI for prototypes and proofs of concept, 83% for internal non-critical production software, 73% for customer-facing applications, and 58% for business-critical or mission-critical services. That last number is the one to sit with. Fifty-eight percent of teams are putting AI-generated code into systems where failure is expensive.

The volume claim is 42% of committed code being AI-generated or assisted today. Sonar frames the projection as an increase of over half by 2027, which lands near 65%. I would treat the trajectory as directionally reliable and the exact figure as survey-dependent, because self-reported shares are notoriously sensitive to how you ask the question.

# Measure the AI share of your own commits instead of trusting a survey average.
import re, subprocess

AI_TRAILER = re.compile(r"Co-authored-by:\s*(Claude|Copilot|Cursor|Codex|Gemini|Devin)", re.I)
AI_MARKER = re.compile(r"(?im)^\s*(generated|assisted)[- ]by:\s*(ai|llm|agent)")

def ai_share(repo, since="6.months"):
    log = subprocess.run(
        ["git", "-C", repo, "log", f"--since={since}",
         "--pretty=format:%H%x1f%B%x1e"],
        capture_output=True, text=True, check=True,
    ).stdout
    total = ai = 0
    for record in [r for r in log.split("\x1e") if r.strip()]:
        _, _, body = record.partition("\x1f")
        total += 1
        if AI_TRAILER.search(body) or AI_MARKER.search(body):
            ai += 1
    return {"commits": total, "ai_commits": ai, "share": round(ai / max(1, total), 3)}

print(ai_share("."))
# Survey baseline for comparison: 42% of committed code today, 65% expected by 2027.
# Commit counts are not line counts -- report both, and say which one you are quoting.

The trust gap is structural, not transitional

96% of developers do not fully trust AI-generated code. That number is easy to misread as scepticism, and it is not. It is the correct posture for a system that is right most of the time without ever telling you when it is not. The interesting figure is next to it: only 48% always verify before committing. So roughly half of the developers who do not trust the output are shipping it without checking.

This is the mechanics of a verification debt. Nothing explodes immediately, because most AI code is fine, which is precisely why the unverified half keeps growing unnoticed until it does not.

# The verification bottleneck in one number: minutes of review per PR, split by AI share.
from statistics import mean

def review_budget(prs):
    '''prs: [{"ai_lines": int, "total_lines": int, "review_minutes": float}]'''
    buckets = {"0-25%": [], "25-50%": [], "50-75%": [], "75-100%": []}
    for pr in prs:
        share = pr["ai_lines"] / max(1, pr["total_lines"])
        key = "0-25%" if share < .25 else "25-50%" if share < .5 else "50-75%" if share < .75 else "75-100%"
        buckets[key].append(pr["review_minutes"])
    return {k: round(mean(v), 1) for k, v in buckets.items() if v}

SAMPLE = [
    {"ai_lines": 40,  "total_lines": 200, "review_minutes": 18},
    {"ai_lines": 160, "total_lines": 200, "review_minutes": 41},
    {"ai_lines": 95,  "total_lines": 120, "review_minutes": 33},
    {"ai_lines": 12,  "total_lines": 130, "review_minutes": 15},
]
print(review_budget(SAMPLE))
# Sonar reports 38% of developers say AI code takes more review effort than human code.
# This table tells you whether that is true in your repo, and by how much.

Verification is the new bottleneck

38% of developers say reviewing AI-generated code requires more effort than reviewing code written by a human colleague. That single line explains why teams can report higher personal productivity and unchanged delivery speed in the same quarter. If generation gets cheaper and review gets more expensive, you have moved the queue, not shortened it.

AI code is harder to review for reasons that do not show up in a diff: it looks confident, it is stylistically consistent, it rarely leaves the small messes that signal struggle, and it can be plausible in exactly the places it is wrong. A human reviewer's tells are gone. That is an argument for reading structure, tests and runtime behaviour, not just the patch.

# Defect density by AI-share cohort beats a single trust percentage.
DEFECTS = [
    # cohort, merged_prs, prs_with_post_merge_defect
    ("0-25%",  420, 21),
    ("25-50%", 260, 19),
    ("50-75%", 180, 22),
    ("75-100%", 90, 17),
]

def density(rows):
    print(f"{'cohort':9}{'PRs':>6}{'defect PRs':>12}{'rate':>8}")
    for cohort, prs, bad in rows:
        print(f"{cohort:9}{prs:6}{bad:12}{bad / prs:8.1%}")

density(DEFECTS)
# Watch the sample sizes. The 75-100% cohort usually has the fewest PRs and the widest
# confidence interval, which is exactly where people over-read the number.

Usage and effectiveness diverge by task. Documentation gets 74%; refactoring gets 43%.

Usage and effectiveness diverge by task

AI is used for new code development by 90% of developers, but only 55% of those users rate it extremely or very effective there. Refactoring: 72% usage, 43% effectiveness. The top effectiveness scores go to writing documentation at 74%, explaining or understanding existing code at 66%, and generating tests at 59%.

The pattern is consistent: AI is strongest where the context already exists and the output can be checked cheaply, and weakest where the task requires judgement about what the code should become. That is not a temporary limitation of model quality, it is a description of where the verification loop is cheap and where it is not. Plan your adoption around the loop, not around the benchmark.

# Usage is not effectiveness. Score each task twice, then subtract.
TASKS = {
    # task: (share of developers using AI for it, share rating it very/extremely effective)
    "new code":      (0.90, 0.55),
    "refactoring":   (0.72, 0.43),
    "documentation": (None, 0.74),
    "explain code":  (None, 0.66),
    "generate tests":(None, 0.59),
}

for task, (usage, effective) in TASKS.items():
    gap = "n/a" if usage is None else f"{(usage - effective) * 100:+.0f} pts"
    print(f"{task:15} usage={'n/a' if usage is None else f'{usage:.0%}':>5}  effective={effective:.0%}  gap={gap}")

# The pattern from the survey: AI is strongest where context already exists
# (documentation, explanation, tests) and weakest where judgement matters most (refactoring).

What the tooling evidence suggests

Sonar reports that SonarQube users show substantially stronger outcomes on code quality, rework cost and defect rates than non-users, and are 44% less likely to experience outages caused by AI-generated code. Treat that as a vendor reporting on its own users, which is a real caveat: teams that adopt static analysis are also the teams that care about quality. The selection effect is doing some of the work.

Still, the mechanism is plausible and cheap to test in your own repo. If unverified AI code is the risk, then automated checks running before merge are the direct mitigation, and the question is not whether to add them but which ones catch what your reviewers currently miss.

# Five metrics worth putting on one dashboard, all from data you already have.
def scorecard(team):
    return {
        "ai_share_of_commits": team["ai_commits"] / max(1, team["commits"]),
        "always_verify_rate": team["verified_prs"] / max(1, team["merged_prs"]),
        "review_minutes_per_100_lines": 100 * team["review_minutes"] / max(1, team["lines_reviewed"]),
        "post_merge_defect_rate": team["defect_prs"] / max(1, team["merged_prs"]),
        "change_failure_rate": team["failed_changes"] / max(1, team["deploys"]),
    }

TEAM = {
    "commits": 1200, "ai_commits": 540,
    "merged_prs": 380, "verified_prs": 190,
    "review_minutes": 7600, "lines_reviewed": 41000,
    "defect_prs": 31, "deploys": 210, "failed_changes": 17,
}
for k, v in scorecard(TEAM).items():
    print(f"{k:30}{v:8.2%}" if v < 1 else f"{k:30}{v:8.2f}")

# Track the five together. Any one of them alone can be gamed, and a move in one
# without a move in the others is usually a measurement change, not an improvement.

58% of teams put AI-assisted code into business-critical services.

Five numbers I would put on one dashboard

AI share of commits, always-verify rate, review minutes per 100 lines, post-merge defect rate, change failure rate. Every one of those can be computed from git history, your issue tracker and your deploy log. None requires a survey.

Track them together, because any single metric can be gamed in a week. AI share up with review minutes flat means you are not reviewing the new volume. Verify rate up with defect rate flat means the checks are ceremonial. Change failure rate up with defect rate flat means your definition of a defect is the problem, not the code.

The survey is useful as a baseline to argue with. It says 42% and 48%. Your numbers will differ, and the difference is the only part you can act on.