42% 的提交代码来自 AI，却只有 48% 的开发者每次都验证

采用率已经不再是有价值的信息

试过 AI 编码工具的开发者里，72% 现在每天都在用，周末尝鲜的时代结束了。更能说明问题的是代码流向：88% 用在原型和概念验证，83% 用在内部非关键生产软件，73% 用在面向客户的应用，58% 用在业务关键或任务关键的服务上。最后这个数字值得多停一会儿：58% 的团队把 AI 生成的代码放进了「出事很贵」的系统。

体量方面的说法是：目前提交的代码里 42% 由 AI 生成或辅助生成。Sonar 把 2027 年的预测表述为「再增长一半以上」，落到 65% 附近。我建议把趋势当作方向性可靠、把精确数字当作依赖样本的说法——自报的比例对「问题怎么问」极其敏感。

# 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.

信任缺口是结构性的，不是过渡期的

96% 的开发者不完全信任 AI 生成的代码。这个数字容易被误读成「怀疑论」，其实不是。它是对一个「大多数时候正确、但从不告诉你什么时候不正确」的系统唯一正确的姿态。真正的信息在旁边那个数字：只有 48% 的人提交前每次都验证。也就是说，那些不信任输出的人里，大约有一半在没有检查的情况下就把它发出去了。

这就是验证债的运作方式。它不会立刻爆，因为大部分 AI 代码确实是好的——恰恰因为这个，「没被验证的那一半」才能在不被注意的情况下持续变厚，直到某天不再如此。

# 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.

验证成了新的瓶颈

38% 的开发者表示，评审 AI 生成的代码比评审人类同事写的代码更费劲。这一行就解释了为什么同一个季度里，团队既能报告「个人效率提升」，又能报告「交付速度没变」。如果生成变便宜了、评审变贵了，你只是把队列挪了个位置，没有把它变短。

AI 代码更难评审的原因不在 diff 里：它看起来很自信，风格前后一致，几乎不留那种「卡住过」的小凌乱，而且它能恰好在你不知道的地方说得头头是道。人类评审者赖以判断的那些「破绽」消失了。这本身就是一条论据：要读结构、读测试、读运行时行为，而不只是读那个补丁。

# 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.

使用率与有效性按任务分化：写文档 74%，重构 43%。

使用率与有效性按任务分化

90% 的开发者用 AI 写新代码，但其中只有 55% 认为它在这一点上「非常有效或比较有效」。重构：72% 使用率，43% 有效性。有效性最高的是写文档 74%、解释或理解既有代码 66%、生成测试 59%。

规律相当一致：AI 在「上下文已存在、输出可以低成本校验」的地方最强，在「需要判断代码应该变成什么样」的地方最弱。这不是模型质量的临时限制，而是对「验证回路在哪里便宜、在哪里昂贵」的一次描述。做采用规划时，按验证回路来规划，而不是按基准分数来规划。

# 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).

工具层面的证据说明了什么

Sonar 报告称，SonarQube 用户在代码质量、返工成本与缺陷率上的表现明显好于非用户，并且因 AI 生成代码导致故障的概率低 44%。这条要当成「厂商在讲自己用户的事」来读，这个提醒是实打实的：采用静态分析工具的团队，本来也是在乎质量的那批团队，选择效应承担了一部分解释力。

但机制本身合理，而且在自己仓库里验证很便宜。如果风险来自「没被验证的 AI 代码」，那么合并前自动跑的检查就是最直接的缓解手段；问题不是「要不要加」，而是「哪几项能抓住你的评审者现在漏掉的東西」。

# 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% 的团队把 AI 辅助代码放进了业务关键服务。

我会放进同一张看板的五个数字

提交里的 AI 占比、每次都验证的比例、每百行代码的评审分钟数、合并后缺陷率、变更失败率。这五个全都能从 git 历史、issue 跟踪器和部署日志里算出来，一个都不需要问卷。

要放在一起看，因为任何单一指标都能在一周内被「优化」。AI 占比上升、评审分钟数持平，说明你没有在评审新增的量；验证率上升、缺陷率持平，说明这些检查是仪式；变更失败率上升、缺陷率持平，说明问题在你的「缺陷」定义，而不是代码。

问卷的价值在于给你一个可以对线的基线。它说 42% 和 48%。你的数字一定不同，而那个差异，才是你能动手的部分。