吞吐涨 75%，首评等待涨 105%：读懂 2026 年 Q3 的 AI 工程数据

2026 年有三份彼此独立的数据，描述了同一个形状，所以很难再把它当成某家厂商的 PPT。DX 测得人均周吞吐在四个季度里从 1.43 升到 2.51 个「复杂度加权 PR」，而 AI 生成代码占比最高的组织，等第一次评审的时间要久 105%。Faros 发现「工作重启」增加 66.7%、QA 停留时长增加 300.6%、完全没有经过任何评审就合并的 PR 增加 76.3%。哈佛的研究者发现人均 PR 增加 23%，但完成 issue 的提升在统计学上并不显著。作者产能上去了，验证产能没有。

作者产能上去了，评审产能没有

三份数据，同一个形状

这三份数据用不同方法测不同对象，正因如此，它们指向同一结论才值得注意。DX 调研了 500 多家工程组织，把源码管理、CI/CD 与 AI 工具的遥测数据和开发者主观感受结合起来，覆盖 2026 年 7 至 9 月。Faros 的《AI 工程报告 Q3 2026》以「速度陷阱」（The Speed Trap）为题发布，测量的是其客户群里的工作流状态流转。哈佛的论文看的是企业层面的生产瓶颈。三者的落点都是同一个不对称：变更量急剧上升，而理解、评审、验证这些变更的产能没有同比上升。它们都没有说 AI 编码工具不值得用，而是指出了新的约束在哪里——而那个位置，通常不是团队习惯去看的地方。

# PR size, straight out of git. No vendor dashboard required.
import statistics, subprocess

def pr_sizes(since="6 months ago"):
    log = subprocess.run(
        ["git", "log", "--since=" + since, "--numstat", "--pretty=format:%H|%ad", "--date=short"],
        capture_output=True, text=True, check=True).stdout
    commits, current = [], None
    for line in log.splitlines():
        if "|" in line and line.count("|") == 1:
            if current:
                commits.append(current)
            current = {"sha": line.split("|")[0][:8], "added": 0, "files": set(), "date": line.split("|")[1]}
        elif current and line.strip():
            parts = line.split("\t")
            if len(parts) == 3 and parts[0].isdigit():
                current["added"] += int(parts[0])
                current["files"].add(parts[2])
    if current:
        commits.append(current)
    return commits

rows = pr_sizes()
added = [r["added"] for r in rows]
files = [len(r["files"]) for r in rows]
print("commits:", len(rows))
print("lines added p50/p90:", statistics.median(added), sorted(added)[int(len(added) * 0.9)])
print("files touched p50/p90:", statistics.median(files), sorted(files)[int(len(files) * 0.9)])

# Faros measured average PR size up 71.8% and files edited per PR up 52.0%.
# If your p90 is climbing and your reviewer count is not, the queue is already full.

Faros：吞吐上去了，验证被推后了

Faros 的数字在前三分之一很好看，之后就一路变差。人均任务吞吐增加 69.0%，人均完成的 epic 增加 53.7%；在约 10% 有部署数据的团队中，部署频率提升 13.8%。然后是：人均「工作重启」增加 66.7%，QA 平均停留时长增加 300.6%，平均 PR 规模增加 71.8%，每个 PR 涉及的文件数增加 52.0%，首次评审的中位等待时间增加 114.5%，而「没有任何人工或 agent 评审就合并」的 PR 增加 76.3%。人均每日任务上下文增加 44.6%，每日 PR 上下文增加 24.8%。这幅图景就是「协调化」：开发者监督更多工作单元，而亲手写的比例在下降。

# Review coverage and first-review latency from a saved API export.
# Save the JSON once, then this is a pure calculation, not a live query.
import json, statistics
from datetime import datetime, timezone

def parse(ts):
    return datetime.fromisoformat(ts.replace("Z", "+00:00"))

with open("pulls_export.json") as fh:
    pulls = json.load(fh)

merged = [p for p in pulls if p.get("merged_at")]
no_review = [p for p in merged if not p.get("reviews")]
latencies = []
for p in merged:
    reviews = p.get("reviews") or []
    if reviews:
        first = min(parse(r["submitted_at"]) for r in reviews)
        latencies.append((first - parse(p["created_at"])).total_seconds() / 60)

print("merged PRs:", len(merged))
print("merged with no review: %.1f%%" % (100 * len(no_review) / len(merged)))
if latencies:
    print("first review p50 minutes: %.0f" % statistics.median(latencies))
    print("first review p90 minutes: %.0f" % sorted(latencies)[int(len(latencies) * 0.9)])

# Faros found median time to first review up 114.5% and PRs merged with no
# human or agentic review up 76.3%. Both are visible in this export.

PR 变大是这一整套数字的源头

DX：真正的约束是评审队列

DX 的周中位 TrueThroughput（一种复杂度加权指标）从 2025 年 Q4 的 1.43 个 PR/开发者，升到 1.74、2.11，再到 2026 年 Q3 的 2.51，环比增速分别为 21.7%、21.3% 与 19.0%。配套的那张图才是重点：首次评审的中位等待时间按组织内 AI 代码占比分层，占比 20-40% 时为 40 分钟，40-60% 时 56 分钟，60-80% 时 71 分钟，超过 80% 时 82 分钟——相差 105%。DX 很谨慎地把原因归于「评审容量」而不是「评审者更不情愿看 AI 代码」。Waydev 对同一数据集的解读还补充了一点：PR 中位规模大约翻了一倍，从 46 行代码升到 102 行。

# Work restarts: a task that moves forward, then comes back. Faros measured +66.7%.
import csv
from collections import Counter, defaultdict

RESTART_STATES = {"in progress", "in development", "reopened"}

rows = list(csv.DictReader(open("issue_transitions.csv")))
history = defaultdict(list)
for row in rows:
    history[row["issue_key"]].append(row)

events, restarts = 0, 0
for key, moves in history.items():
    moves.sort(key=lambda r: r["changed_at"])
    seen_forward = False
    for move in moves:
        events += 1
        state = move["to_state"].strip().lower()
        if state in {"review", "qa", "done"}:
            seen_forward = True
        elif seen_forward and state in RESTART_STATES:
            restarts += 1
            seen_forward = False

print("transitions:", events, "restarts:", restarts)
print("restart rate: %.1f%%" % (100 * restarts / max(1, events)))

# The cost is not the second attempt. It is the context rebuild, plus the
# reviewer or QA pass that has to happen again on work already examined.

哈佛：编码从来就不是瓶颈

哈佛那篇论文是对任何「生产力提升」说法最有用的一剂矫正。编码 agent 的采用让每位员工创建的 PR 增加 23%，但完成的 Jira issue 与 epic 的提升很小，且统计上不显著。作者估计写代码大约占工程师 42% 的时间，而另一项调查显示是 30%。如果写代码不到工作量的一半，把它变快对交付的影响就是有上限的。同一篇论文还发现：PR 从提交到合并的时间增加 49%；收到正式变更请求的 PR 占比从约 13% 升到 25%；参与评审的员工占比增加 14%。评审的人变多了，但需要返工的工作也变多了。

# QA dwell time: how long work sits between "ready for QA" and QA finishing.
import csv, statistics
from datetime import datetime

def ts(value):
    return datetime.fromisoformat(value)

dwell, open_since = [], {}
for row in csv.DictReader(open("stage_events.csv")):
    key, stage = row["issue_key"], row["stage"].strip().lower()
    if stage == "qa":
        open_since[key] = ts(row["entered_at"])
    elif key in open_since:
        dwell.append((ts(row["entered_at"]) - open_since.pop(key)).total_seconds() / 3600)

if dwell:
    print("QA samples:", len(dwell))
    print("median hours in QA: %.1f" % statistics.median(dwell))
    print("p90 hours in QA: %.1f" % sorted(dwell)[int(len(dwell) * 0.9)])

# Faros measured average time in QA up 300.6% as AI adoption deepened.
# Growth here usually means verification moved downstream, not that QA slowed down.

真正的约束在写完之后

在汇报任何数字之前，先算这四个

四个指标就能覆盖这些报告描述的大部分内容，而且都能从你已经在存的数据里算出来。第一，首次评审等待时长，以分钟计，同时给中位数和 p90。第二，评审覆盖率：合并的 PR 中至少经过一次评审的比例。第三，「工作重启率」：进入评审或 QA 后又回退的任务比例。第四，变更规模分布：以行数和文件数计的 p50 与 p90。它们合起来回答一个问题：更多的产出是更快交付了，还是只是在队列里待得更久。还可以再留第五个数字：每位开发者每天接触多少个不同任务与 PR。

# Comprehension debt, proxied: AI-authored lines versus reviewed lines per file.
import subprocess
from collections import defaultdict

AI_TRAILERS = ("Co-authored-by: copilot", "Generated-by:", "Assisted-by:")

def ai_share_by_file(since="3 months ago"):
    log = subprocess.run(
        ["git", "log", "--since=" + since, "--pretty=format:%x00%H%n%B%x00", "--numstat"],
        capture_output=True, text=True, check=True).stdout
    stats = defaultdict(lambda: {"ai": 0, "human": 0})
    blocks = log.split("\x00")
    for i in range(1, len(blocks) - 1, 2):
        body = blocks[i].lower()
        is_ai = any(t.lower() in body for t in AI_TRAILERS)
        for line in blocks[i + 1].splitlines():
            parts = line.split("\t")
            if len(parts) == 3 and parts[0].isdigit():
                stats[parts[2]]["ai" if is_ai else "human"] += int(parts[0])
    return stats

rows = ai_share_by_file()
for path, s in sorted(rows.items(), key=lambda kv: -(kv[1]["ai"] + kv[1]["human"]))[:10]:
    total = s["ai"] + s["human"]
    print("%-48s ai=%5.1f%% lines=%d" % (path[:48], 100 * s["ai"] / max(1, total), total))

# Faros calls the deferred understanding "comprehension debt". The files at the
# top of this list are where the next incident will be explained the slowest.

根据这些数据该改什么

三份报告指向同一个方向：限制变更规模，因为本文里几乎每一笔下游成本都随它放大；把评审容量当成一等资源，如果评审吞吐原地不动而写作产能翻倍，队列本身就变成了交付系统；让「重启」变得可见，因为回退的任务正是那个让吞吐数字比实际情况好看的隐性成本；在架构与接口上继续保留人在环内，哈佛的数据显示瓶颈恰好在这里；最后，向管理层汇报时别再报原始的提交数或 PR 数——AI 恰好把那个数字吹大，而它背后的交付并没有同步变化。