Bain 测出来了：AI 多写了 21% 的代码，审查吃掉了 91% 的时间

先把数字的出处和边界说清楚

来源是 Bain 的技术与工程调查，2026 年 4 月，样本 293 人。四个数字：任务 +21%、审查时间 +91%、并发工作流 +47%、预期发布周期 +148% 与生产力 +95%，实际捕获 20-27%。

必须说清它不说什么。这些是资深负责人的自述，不是埋点数据；「任务数」这个单位把任务大小藏起来了；21% 和 91% 不是同一个单位，不能相加。

所以那句最容易写出来的结论——「AI 让你变慢了」——报告并没有这么说。它说的是约束转移了，而给约束的预算没转移。

# The four numbers, and where they come from. Quote the sample size,
# because "Bain says" without n=293 is how a survey becomes folklore.
#
#   source: Bain Tech and Engineering Survey, April 2026, n=293
#     +21%  tasks completed per developer
#     +91%  time spent reviewing output
#     +47%  concurrent workstreams each developer manages
#           expected +148% release-cycle speed, +95% productivity (1-2 yrs)
#           captured today: +20% to +27%
#
# What the numbers do NOT say, and this matters:
#   - they are self-reported by senior leaders, not instrumented
#   - "tasks completed" is a unit that hides task size
#   - 21% and 91% are not in the same unit, so they cannot be added
#
# The temptation is to write "AI makes you slower". The report does not say
# that. It says the constraint moved, and the budget for the constraint did not.

python3 - <<'PY'
tasks, review = 1.21, 1.91
print(f"throughput multiplier : {tasks:.2f}x")
print(f"review load multiplier: {review:.2f}x")
print(f"review load per unit of output: {review/tasks:.2f}x")

# 1.91 / 1.21 = 1.58. For every unit of shipped output you now do 58% more
# review work than before. If review capacity did not grow, review is the queue.
PY

审查是一个队列，队列有行为

把 91% 除以 21%，得到 1.58。意思是：每产出一单位，你要多做 58% 的审查工作。如果审查能力没涨，那审查就是队列。

用 Little 定律算一下就很清楚。原来每周 40 个变更、每个 2 小时、5 个审查者：利用率 0.80，积压持平。现在到达量乘 1.21、单件时间乘 1.58、审查者还是 5 个：利用率 1.91，每周积压增长约 123 个工时。

1.91 不是「有点忙」，是数学上不可持续。工作不会消失，它排队。而队列就是速度死掉的地方。注意这里唯一没变的变量：审查人数。整个标题说的就是这个。

两个真杠杆一个假杠杆。真的：降低单件审查时间（更小的 diff、更好的测试、带类型的契约）；真的：提高审查容量（更多人，或者把审查提前）。假的：降低标准——那只是把队列挪到生产环境。

# Little's law, applied honestly. Review is a queue, and queues have behaviour.
#   L = lambda * W      queue length = arrival rate * time in system
#
# Before: 40 items/week arriving, 2.0 hours of review each, 5 reviewers at 40h.
# After:  arrival rate rises with throughput, and per-item review time goes up
#         because generated diffs are longer and less familiar to the reviewer.

python3 - <<'PY'
def queue(arrivals_per_week, hours_per_item, reviewers, hours_per_reviewer=40.0):
    capacity = reviewers * hours_per_reviewer          # item-hours available
    demand   = arrivals_per_week * hours_per_item      # item-hours requested
    return {
        "capacity_h": capacity,
        "demand_h": demand,
        "utilisation": round(demand / capacity, 2),
        "backlog_growth_h_per_week": round(demand - capacity, 1),
    }

before = queue(40, 2.0, 5)
after  = queue(40 * 1.21, 2.0 * 1.58, 5)

for label, q in (("before", before), ("after", after)):
    print(label, q)

# before: utilisation 0.80, backlog flat
# after : utilisation 1.91, backlog grows ~123 item-hours per week
#
# 1.91 utilisation is not "busy". It is mathematically impossible to sustain.
# The work does not disappear; it queues, and the queue is where velocity dies.
# Note what did not change: reviewer count. That is the whole headline.
PY

# Two legitimate levers, and one fake one:
#   real: reduce hours_per_item  (smaller diffs, better tests, typed contracts)
#   real: raise capacity         (more reviewers, or move review earlier)
#   fake: lower the bar          (this just moves the queue to production)

第一件事：让工程知识变成机器可读

报告里的第一个要素听起来很朴素：把工程知识写成机器可读的形式。为什么有用？因为智能体的成本主要由「它必须猜多少上下文」决定。每一条你没写下来的约定，都是一条它可能猜错的约定，而每一个猜错都是一条审查意见。

最便宜的版本是在仓库里放一个契约文件——不是没人看的 wiki，是进版本库、人和智能体都会加载的文件。写清三件事：怎么构建和验证、哪些不变量不许破、东西都在哪。

再补一条审查规则：超过 400 行变更的 diff 必须拆。这条本身就砍掉很大一块审查时间，因为大 diff 的审查质量是断崖式下降的。

为什么这能降 91%？因为那 91% 里大部分不是「代码很烂」，而是「代码很陌生」。文档比审查者的注意力便宜，而审查者的注意力恰好就是已经用完的那个东西。

# Lever one from the report: make engineering knowledge machine-readable.
# The insight is unglamorous. An agent's cost is dominated by how much context
# it must infer. Every convention you leave undocumented is a convention the
# agent guesses wrong, and every wrong guess is a review comment.

# A repository-level contract file is the cheapest version of this. Not a wiki
# nobody reads: a file in the repo, versioned, that both humans and agents load.

mkdir -p .agents
cat > .agents/CONTRACT.md <<'MD'
# Repository contract

## Build and verify
- build:  npm ci && npm run build
- test:   npm test -- --runInBand
- lint:   npm run lint
- A change is not done until all three pass locally. CI is not a linter.

## Invariants an agent must not break
- no new runtime dependency without an explicit approval step
- public API types live in `src/types/public.ts` only
- migrations are append-only; never edit an applied migration
- feature flags default to off and are removed within 30 days

## Where things live
- handlers:  `src/api/handlers/`      one file per route
- domain:    `src/domain/`            no imports from `src/api/`
- fixtures:  `test/fixtures/`         generated, do not hand-edit

## Review expectations
- diffs over 400 changed lines must be split
- every new branch needs a test that fails without the change
MD

# Why this reduces review time: it converts "why did you do it that way"
# into a rule the agent can read before writing. The 91% is mostly not
# "code is bad", it is "code is unfamiliar". Documentation is cheaper than
# reviewer attention, and reviewer attention is the thing that ran out.

利用率 0.80 变成 1.91：审查不是变忙了，是数学上不可持续了。

第二件事：把机械验证自动化，人只看判断

三道门，从便宜到贵。第 0 道是纯机械的：lint、类型检查、测试，不需要任何人花时间。第 1 道看 diff 形状：改了超过 400 行就拒绝，让它拆。第 2 道要行为证据：涉及源码的变更，必须有一个「没有这个改动就失败」的测试。

这套东西的目的不是把审查自动化掉，而是把人的注意力只花在机器查不了的部分：这是不是正确的改动。第 0 和第 1 道大概能去掉一半的审查时间，但一点判断力都替代不了。

我特别想强调第 2 道。一个「加了改动之后通过」的测试证明力很弱，一个「没有改动就失败」的测试才是证据。这个区别看起来很小，实际决定了审查者是读代码还是在猜。

# Lever two: automate quality verification, so a human reviews judgement
# instead of mechanics. Three gates, cheapest first.

cat > .agents/gates.sh <<'SH'
#!/usr/bin/env bash
# Gate 0 - mechanical, no human time, fails fast
set -euo pipefail
npm run lint
npx tsc --noEmit
npm test -- --runInBand --silent

# Gate 1 - diff shape, catches the review-time killer
CHANGED=$(git diff --numstat origin/main...HEAD | awk '{s+=$1+$2} END {print s+0}')
echo "changed lines: $CHANGED"
if [ "$CHANGED" -gt 400 ]; then
  echo "REJECT: diff too large to review well. Split it." >&2
  exit 1
fi

# Gate 2 - behavioural evidence, the only gate a human should read
if git diff --name-only origin/main...HEAD | grep -qE '^src/'; then
  # A test that fails without the change is worth more than a passing suite.
  git stash list >/dev/null
  npm test -- --runInBand --coverage --silent > .agents/coverage.txt 2>&1 || {
    echo "REJECT: tests fail with the change applied" >&2; exit 1; }
  echo "coverage written to .agents/coverage.txt"
fi
SH
chmod +x .agents/gates.sh

# The point is not to automate review away. It is to spend human attention
# only on the part a machine cannot check: is this the right change?
# Gate 0 and 1 remove maybe half the review time and none of the judgement.

第三件事：把交付流程本身当成产品来度量

这是最容易被跳过的一条，也是唯一能告诉你「刚才那两个杠杆到底有没有用」的一条。

我只跟四个数：每周审查工时（约束本身）、变更行数中位数（你能控制的杠杆）、返工率（速度是真的还是假的）、前置时间（领导会问的那个）。

判断方法很直接：如果合并数上升而每周审查工时走平，说明架构变了；如果审查工时跟着合并数一起涨，说明你只是加了量。

一年之后有意思的问题不会是你用了哪个模型，而是你的交付流程有没有变快而没有变坏。报告在这点上很直白：瓶颈已经从写代码转移到了代码周围的一切，而大部分组织还没为「周围的一切」建起架构。由此有两件事。第一，148% 那个预期不是模型问题，所以没有任何一次模型发布能把它补上。第二，真正补上的团队从外面看会很无聊：更小的 diff、写下来的不变量、自动化的验证、每周的四个数。

# Lever three, and the one most teams skip: treat the delivery process as a
# product with its own metrics. Without this you are guessing which of the
# two levers worked.

python3 - <<'PY'
import json, statistics

def weekly_metrics(rows):
    lead   = [r["lead_time_h"] for r in rows]
    review = [r["review_h"] for r in rows]
    size   = [r["changed_lines"] for r in rows]
    rework = sum(1 for r in rows if r["rework"]) / len(rows)
    # Review load per merged change is the number that predicts the wall.
    return {
        "merged": len(rows),
        "median_lead_time_h": statistics.median(lead),
        "median_review_h": statistics.median(review),
        "median_changed_lines": statistics.median(size),
        "review_hours_per_week": round(sum(review), 1),
        "rework_rate": round(rework, 2),
    }

sample = [
    {"lead_time_h": 31, "review_h": 3.2, "changed_lines": 210, "rework": False},
    {"lead_time_h": 58, "review_h": 6.4, "changed_lines": 690, "rework": True},
    {"lead_time_h": 22, "review_h": 1.8, "changed_lines": 120, "rework": False},
    {"lead_time_h": 74, "review_h": 9.1, "changed_lines": 980, "rework": True},
]
print(json.dumps(weekly_metrics(sample), indent=2))

# Track four numbers weekly and nothing else:
#   review hours per week          <- the constraint
#   median changed lines           <- the lever you control
#   rework rate                    <- whether speed is real
#   lead time                      <- the outcome leadership asks about
#
# If review hours per week flattens while merged count rises, the architecture
# changed. If review hours rise in step with merged count, you only added volume.
PY

# A year from now the interesting question will not be which model you used.
# It will be whether your delivery process got faster without getting worse.
# The report's framing is blunt about this: the bottleneck moved from writing
# code to everything around it, and most organisations have not built the
# architecture for the "everything around it" part yet. Two things follow.
# First, the 148% expectation is not a model problem, so no model release
# closes it. Second, the teams that close it will look boring from outside:
# smaller diffs, documented invariants, automated verification, weekly numbers.

真正的杠杆是更小的 diff、写下来的不变量、自动化的验证。