AI 编码更快，交付为何未必更快？把审查、返工与学习计入收益

1. Separate output volume, task speed and delivery quality

Lines of code, suggestion acceptance and commit counts describe usage or output activity. They can help diagnosis without establishing that more customer problems were solved. Equivalent functionality can require different code lengths, and one change can become several commits. Changing acceptance criteria and work-item size remove the common denominator from a before-and-after count.

Task time also has two meanings: human effort and calendar time from request to usable release. Parallel agents can reduce waiting while consuming review effort; faster generation can lengthen review queues. This article models expected human effort and tool cost for an equivalent change, not a full team queueing system.

2. A real-task experiment is not a permanent verdict

In METR’s early-2025 randomised trial, 16 developers familiar with their mature open-source repositories completed 246 tasks. Allowing the tools of that period increased completion time by 19%, with a reported interval of +2% to +39%. Participants expected a 24% reduction beforehand and estimated a 20% reduction afterwards.[1] The outcome concerns sampled task time, not annual output for all developers.

The practical lesson is that a smoother experience can differ from measured acceleration. The finding does not establish that AI is unhelpful in other repositories, tasks or later versions. Translate a fast-generation experience into complete timing: define the task first, then record understanding, interaction, verification and revisions through equivalent acceptance.

3. In 2026, wider adoption makes comparison harder

In February 2026, METR reported recruitment and task-selection effects when developers resisted working without AI, plus timing difficulties with parallel agents. Raw task-time estimates were −18% for returning developers (interval −38% to +9%) and −4% for new recruits (−15% to +9%). METR explicitly judged the signal unreliable for the current productivity effect.[2]

Do not connect these zero-crossing raw estimates to the earlier result as a proven reversal. Unreliable evidence also does not establish zero benefit. A company pilot should record unsubmitted tasks, people declining the no-AI condition and incomplete assigned work. Looking only at successful users hides the selection process behind adoption.

4. Workplace evidence shows opportunity and delivery friction

Anthropic’s December 2025 account combined a survey of 132 engineers and researchers, 53 interviews and usage analysis. Respondents reported roughly 50% productivity gains, while most described only 0–20% of their work as fully delegable.[4] This is experience from early adopters inside a frontier-tool supplier, not a controlled estimate transferable to every company’s costs.

GitLab’s June 2026 Harris Poll surveyed 1,528 developers and technology buyers in six countries. Some 79% agreed that individual gains had not translated proportionately into faster delivery; 85% agreed that review and validation had become the bottleneck.[5] These are agreement rates, not measured shares of projects that slowed down, and the publishing company sells a development platform.

Together, these sources motivate a testable operating hypothesis: stronger generation needs complementary acceptance capacity. If reviewers lack requirements and test evidence, output growth can merely move work downstream. A useful pilot must allow local data to disprove that hypothesis.

5. Skill formation is an outcome on another timescale

Shen and Tamkin’s 2026 preprint studied 52 Python-experienced participants unfamiliar with Trio, with 26 in each group. The AI group performed worse on the subsequent unassisted quiz, while main-study completion time did not differ significantly.[3] This concerns immediate understanding after learning unfamiliar material, not long-term professional competence or every AI workflow.

Exploratory usage-pattern analysis suggests that explanations and cognitive engagement may support learning, but the patterns were not separately randomised and do not establish a causal effect for a particular prompt. Product teams can test designs that ask users to predict behaviour, identify failure conditions and independently modify a variant. Their effectiveness needs a separate evaluation.

A June 2026 observational analysis of about 400,000 Claude Code sessions also linked domain expertise with session success.[7] This supports investigating designs that retain domain judgement. Session-end success is not long-term maintainability, and the association is not a causal estimate of training returns. An answer appearing on screen is an incomplete test of understanding.

6. An original model: 50% less coding can mean 11% higher cost

Let baseline coding time be B, verification V₀, probability of one additional rework episode p₀ and mean repair time conditional on rework R₀. Expected baseline human minutes are H₀=B+V₀+p₀R₀. With AI, H₁=B(1−s)+A+V₁+p₁R₁+L, where s is coding-time reduction, A active prompting/coordination and L additional comprehension or training. Do not count a stage twice.

The default scenario sets B=60, V₀=25, p₀=0.15 and R₀=100, giving H₀=100 minutes. AI inputs s=50%, A=10, V₁=40, p₁=0.25, R₁=80 and L=10 give H₁=110. At a common labour rate w=60 currency units/hour and task-level tool fee F=1, C₀=100 and C₁=111. Coding time halves while complete-task cost rises 11%. All inputs are illustrations, not estimates from the cited samples.

Reducing AI verification from 40 to 20 minutes while holding other inputs fixed gives C₁=91, a 9% saving. Cost parity occurs at V₁*=29 minutes: H₀−B(1−s)−A−p₁R₁−L−60F/w. The boundary makes verification effort visible; it does not justify cutting necessary tests to create a nominal saving. If less review raises rework probability, change both inputs.

The model assumes eventual acceptance under equivalent requirements and at most one separately counted rework episode. It excludes unlimited repair, abandonment, production incidents, scope changes, different role rates and calendar waiting. Record actual failures and multiple repair rounds directly or extend the model. Freed minutes also do not automatically become cash payroll savings.

7. Make the pilot a falsifiable product experiment

Select a task family before combining new features, migrations and urgent fixes into an average. Record acceptance criteria, expected difficulty, repository familiarity and dependencies before tool assignment. Randomise at an appropriate task or team level where feasible; otherwise document selection rules, concurrent changes and task mix, and keep association distinct from causation.

Track human effort, calendar lead time, first-pass acceptance, rework and later defects together. Fix the defect-observation window in advance, retain incomplete assigned tasks in the denominator, and add an unassisted transfer check for learning tasks. Report valued time, delivery capacity and realised financial savings separately to avoid counting one gain several times.

An Anthropic survey published on 16 October found that 26% of US adults using AI at work, versus 59% of Anthropic staff, said an AI-suitable task took a quarter of the time or less.[6] These are perceptions from different populations, not timed experimental effects. Do not substitute the most optimistic group’s experience for local acceptance data.

8. The product opportunity is cheaper verification with informed oversight

Good initial candidates have clear boundaries, readily verifiable outputs and a recoverable change path. Treat this as an evidence-informed operating hypothesis for a pilot to test. For unfamiliar architecture, critical permissions or concepts a novice is still learning, establish who can independently explain and accept the result before setting delegation depth.

A review interface can connect requirements, change rationale, reproducible checks and unresolved conditions. Give reviewers a useful change summary and ways to inspect counterexamples rather than another unverified confident explanation. Measure effort over the complete task, and assess understanding through explanation and modification without the tool.

Commercial value needs answers to three questions: what additional work was completed, who bears verification and maintenance, and whether the team can make the next judgement more independently. Turning coding savings into accepted value is a system-design task for product management, and is more verifiable than a universal speedup multiplier.

1. 先区分三件事：写得多、做得快、交付得好

代码行数、建议接受率和提交次数，是工具使用或产出活动指标。它们有诊断价值，但不自动等于用户问题解决得更多。同样功能可以有不同代码长度；一个改动可以拆成多个提交。若验收要求和工作粒度一直变化，采用前后的数量就缺少共同分母。

任务耗时也有两种：人实际投入的工时，与从提出需求到可用版本的日历时间。并行代理可能减少等待，却仍占用多人的审查；增加生成速度也可能让审查队列变长。本文模型只计算同一改动的预期人工投入和工具费用，不把它冒充完整团队排队模型。

2. 一项真实任务试验，为什么不能当作永久结论

METR 的早期 2025 年随机试验中，16 位熟悉各自成熟开源仓库的开发者完成 246 项任务。允许使用当时 AI 工具后，完成时间增加 19%，报告区间为增加 2%–39%。参与者事前预期节省 24%，事后仍估计节省 20%。[1] 这里测量的是所选任务的耗时，不是所有开发者的年产出。

这个结果的实用含义，是感到顺畅与实际提速可能不同。它不证明 AI 在其他代码库、任务或后续版本中无用。对于自己的产品，应把“生成得很快”的体验转化为完整计时：定义任务后开始，记录理解、交互、核查与修改，直到满足同一验收要求。

3. 2026 年的新问题：采用越普遍，比较越难

METR 于 2026 年 2 月披露，跟进研究遇到开发者不愿在无 AI 条件下工作的招募与任务选择偏差，并行代理也让工时记录更难。原参与者子样本的原始时间变化估计为 −18%（区间 −38% 到 +9%），新参与者为 −4%（−15% 到 +9%）；机构明确认为数据对当前效应的信号不可靠。[2]

不能把这些区间跨零的原始结果与上一节串成一条“已证实反转”的趋势线；也不能因为信号不可靠，就断言实际收益为零。对企业试点，未提交的任务、拒绝无 AI 的参与者和分配后未完成的工作，应进入样本流转记录。只观察成功使用者，会漏掉采用本身的选择过程。

4. 企业证据支持机会，也暴露了交付瓶颈

Anthropic 于 2025 年 12 月报告了对内部 132 位工程师与研究者的调查、53 次访谈及使用数据分析。受访者自报平均生产率提升约 50%，同时多数人称能完全委派的工作仅占 0–20%。[4] 这是前沿工具供应商内部早期采用者的经验，不是对照试验，也不能把自报百分比换算成所有公司的成本下降。

GitLab 于 2026 年 6 月公布 Harris Poll 对六国 1,528 位开发者与技术采购者的调查：79% 认同个人生产率改善没有同比例转化为整体交付加速，85% 认同瓶颈转向审查和验证。[5] 这些是受访者认同率，不是实测项目变慢的比例；报告也由销售开发平台的企业发布。

两类证据合起来，更适合形成一个待检验的经营假设：生成能力增加后，团队需要把额外能力配置到验收链条。若审查者无法获得需求背景与测试依据，再多产出也可能只是把工作从编码端移到下游。正确的试点应允许这个假设被自己的数据否定。

5. 技能形成，是另一种时间尺度的产出

Shen 与 Tamkin 的 2026 年预印本研究让 52 名有 Python 经验、但不熟悉 Trio 的参与者完成新库任务，每组 26 人。AI 组随后在无辅助测验上的表现较低；主试验任务完成时间没有统计显著差异。[3] 这针对新知识学习后的即时理解，不是长期职业能力或所有 AI 开发流程的结论。

作者对使用模式的探索分析提示，要求解释和保持认知参与的用法可能更有利于学习，但这些模式没有再次随机分配，不能当作某条提示语的因果效果。产品设计可以据此提出可测试方案：先请使用者说明预期行为、要求指出失败条件，再让其独立修改一个变体。是否有效，要另行评估。

2026 年 6 月对约 40 万次 Claude Code 会话的观察研究，还发现领域专长与会话成功相关。[7] 这支持保留领域判断的设计方向，但会话结束时的成功信号不等于长期可维护性，相关关系也不是培训收益的因果估计。判断能力不宜只靠工具是否给出了答案来验收。

6. 原创模型：50% 编码节省，如何变成 11% 成本增加

设基线编码时间为 B，验证时间为 V₀，发生一次额外返工的概率为 p₀，返工发生时的平均修复时间为 R₀。则基线预期人工分钟 H₀=B+V₀+p₀R₀。AI 情景的 H₁=B(1−s)+A+V₁+p₁R₁+L，其中 s 是编码时间节省比例，A 是主动提示与协调，L 是另计的理解或培训时间。不同阶段不得重复计时。

默认情景设 B=60、V₀=25、p₀=0.15、R₀=100，H₀=100 分钟。AI 设 s=50%、A=10、V₁=40、p₁=0.25、R₁=80、L=10，H₁=110 分钟。统一人工成本 w=60 货币单位/小时，每项任务工具费 F=1，则 C₀=100，C₁=111。编码用时减半，完整任务成本却高 11%。所有参数都是演示假设，并非来自上述样本的估计。

将 AI 验证时间从 40 分钟改为 20 分钟，其余不变，C₁ 就降为 91，节省 9%。成本相等的验证时间上限是 29 分钟：V₁*=H₀−B(1−s)−A−p₁R₁−L−60F/w。这个边界说明，检查成本需要可见；它不主张削减必要测试来追求数字上的盈利。若减少审查会提高返工概率，应同时改变两项输入。

模型假定同等要求的改动最终得到验收，返工最多另计一次；它不覆盖无限修复、永久放弃、生产事故、需求变化、多角色不同费率或日历等待。真实失败或多轮返工不能从台账中消失，应扩展模型或在试点中直接统计。释放出来的分钟，也不自动等于可减少的现金工资。

7. 把试点设计成一项可反驳的产品实验

先选择明确的任务族，而不是把新功能、迁移和紧急修复混成一个平均值。在分配工具前记录验收标准、预期难度、代码库熟悉程度与依赖。能随机分配时，按任务或团队设置合适的比较；无法随机时，至少记录选择规则、同期变化和任务结构，不把相关性写成因果性。

同时记录人工投入、需求到验收的日历时间、一次验收通过率、返工和后续缺陷。缺陷观察窗口在试点前固定，未完成任务仍留在分母中；对学习型任务，加一个无辅助迁移小测。用工时估值、交付能力和实际财务节省分别报告，避免同一节省重复计入。

10 月 16 日发布的 Anthropic 调查显示，对适合 AI 的任务，用时可降到四分之一或更少这一说法，在工作中使用 AI 的美国成年人中有 26% 认同，在 Anthropic 员工中为 59%。[6] 这是感知与群体背景差异，不是计时实验。它再次提醒管理者：不要用最乐观群体的体验替代本团队的验收数据。

8. 产品机会在于降低核查负担，同时保留判断

优先试用的任务，通常应有清楚边界、便于验证的结果和可恢复的修改路径。这是一条基于证据的工作假设，需由试点确认。对未知架构、关键权限或新手正在学习的核心概念，团队应先定义谁能独立解释和验收，再决定委派多少工作。

设计上可以把需求、改动理由、可复现检查结果和未解决条件放在同一审查界面；给审查者差异摘要与反例入口，而不是再增加一段无法核实的自信解释。是否减少工时，要按完整任务计量；是否保留理解，要让人能离开工具解释与修改。

AI 开发工具的商业化价值，最终需要同时回答“多完成了什么”“谁承担核查与维护”“团队下一次能否更独立地判断”。把编码节省转成可验收价值，是产品设计与管理的系统工作，也比承诺一个跨场景通用的提速倍数更容易被验证。