代码越来越便宜,软件工程为什么没有?

代码便宜了，什么变贵了

截至2026年8月6日，Meta的Muse Code产品页把三个卖点放在了一起：多Agent并行、后台reviewer、全过程可审计。OpenAI和Anthropic的编码产品页也不再只谈生成代码，而是谈复杂重构、测试、代码评审、CI/CD和提交PR。这个变化很值得琢磨。当头部厂商开始把reviewer和audit写进编码Agent的首页时，它们实际上承认了一件事：生成代码已经不够稀缺，把代码变成可信结果才是下一段竞争。^[1]

AI编程的进步没有争议。自动补全已经走向自主Agent；开发者可以让多个Agent在不同worktree并行修改代码，人在睡觉时任务也能继续。Meta当前页面列出的Muse Spark 1.2贡献者档，输入和输出价格分别低至每百万Token 0.10美元和0.20美元；这是Meta Model API的模型计价，不是Muse Code的独立席位或任务价格。即便把产品价格与模型价格严格拆开，代码的边际生产成本继续下降这一方向仍然清楚。^[1]

但软件项目从来不是一台代码打印机。项目经理先确定OKR，产品经理把目标变成产品方向，架构师判断新功能如何进入现有系统；然后才轮到开发。代码完成后，还有评审、测试、安全审计、上线、运行监测和业务验收。AI目前最明显地压缩了其中一个环节，却常被拿来代表整条链条的效率。

我在项目里越来越警惕这种替代。复杂工程最早断裂的地方，往往不是模型不会写代码，而是参与者对OKR、业务目标和验收标准理解的不是同一件事。目标经过产品语言、技术设计、代码和测试断言层层转译，语义会损失。最后，系统可能通过所有测试，却没有完成最初要解决的业务问题。

接下来还会出现第二重成本。因为组织不能默认信任AI生成的结果，它必须补齐边界条件、异常路径、权限、依赖、数据状态、安全审查和责任证据。写代码容易了，证明它正确、可上线、可维护、可追责，反而成为复杂而昂贵的工作。

这篇文章把这笔成本称为“验证税”。它不是为了证明AI编程不值得用，而是要把账算完整：代码生成节省了什么，成本转移到了哪里；什么时候净收益为正，什么时候产出越多，下游越堵；又该怎样把验证也变成可以工程化、自动化和分级治理的能力。

AI没有消灭工程成本，而是在重新分配工程成本。

提交活动累计估计约180%，发布约30%

2026年5月发布的NBER Working Paper 35275，为这场争论提供了一组很少见的全链路数据。研究者连接了超过10万名GitHub开发者的公开活动、Microsoft内部编码工具的使用遥测，以及四个应用市场的数据，观察自动补全、同步编码Agent和异步编码Agent三代工具。主要方法是匹配事件研究：采用工具的开发者，与一年前同周活跃度接近的开发者比较采用前后的变化。^[2]

结果不是“代码行数增加180%”。更准确的口径是：论文图1把自动补全、同步Agent和异步Agent按实际叠加关系汇总后，对提交活动给出约40%、140%和180%的累计估计；这三项不是可以再次相加的独立增量。同一累计口径向上游汇总后，distinct repositories约为50%，releases约为30%，也不能写成“异步Agent自身让发布增加30%”。另看论文表5的独立处理效应：在采用后第21至30周、按处理组采用前均值归一化时，同步Agent对应的每周代码行变更、PR和release估计分别为741.3%、65.5%和20.3%。^[2]

这组数字不能证明AI一定制造了低质量代码，也不能把180%减去30%就叫作150%的浪费。工作论文采用观察性事件研究，不是随机实验；工具采用时间仍可能与开发者状态相关，公开仓库也不能代表所有企业私有项目。作者做了平行趋势、安慰剂和不同匹配方式等稳健性检验，但没有因此获得无条件的因果外推权。

它真正有价值的地方，是把软件生产的不同层次分开了。代码提交是活动，PR和项目是协作单元，release更接近交付，应用市场里的真实使用才接近消费者价值。研究者看到新应用供给增加，却没有在上市后的前三个月观察到总使用量的可检测增长。产出、交付和价值，不是同一个变量。

NBER作者的解释也比“AI无效”谨慎。他们认为，代码产生之后仍要经过评审、测试、集成和发布，这些环节比生成代码更难并行，也更难自动化；当上游产能快速增加，下游薄弱环节就会限制产出向价值转化。与此同时，30%的发布增益本身仍然很大，未来工具如果继续进入评审和测试，衰减也可能缩小。^[2]

所以这组数据不是判决书，而是一张工程剖面图。它提示管理者：当代码活动增长远快于发布，应该先检查交付系统，而不是继续采购更多代码产能。

NBER W35275：代码活动、项目和发布是不同统计对象；图中为跨代累计估计，不代表业务价值同比例增长。

代码提交是活动，发布是交付，用户采用才接近价值。

不要再用“开发效率”代替工程效率

软件行业早就知道，开发者生产率不能由一个指标代表。ACM Queue发表的SPACE框架把开发者生产率放在满意度与福祉、绩效、活动、沟通协作、效率与流动五个维度中衡量。作者特别提醒，提交数、PR数和代码行数等活动指标不能孤立使用。高活动可能来自更流畅的系统，也可能来自低效蛮力和更多返工。^[5]

AI编程把这个旧问题放大了。代码生成变得便宜以后，最容易上涨的恰好是最容易计数的东西：Token、补全接受率、代码行、提交和PR。它们能说明工具被使用，却不能证明客户问题解决得更好，不能证明系统更稳定，也不能证明团队交付了更多可维护的软件。

一项2022年的随机实验曾给出非常积极的结果：95名受试者被随机分组，实现一个标准化JavaScript HTTP server；完成任务的70人中，使用GitHub Copilot的一组平均快55.8%。这个结论在它的边界里成立。任务目标清楚、技术栈固定、验收容易，是AI最容易把局部速度转成完成时间的环境。^[4]

METR在2025年做了另一项随机对照试验。16名开发者在自己熟悉多年、平均约2.3万GitHub stars的成熟开源仓库里完成246个真实issue，每个预先定义的任务随机允许或禁止AI。允许AI时，实测完成时间反而增加19%。更有意思的是，开发者事前预计AI会让自己快24%，试验结束后仍觉得快了20%。^[3]

这两项实验并不互相否定。它们测量的是不同工作：一个是边界清晰的标准任务，一个是高上下文、成熟代码库里的真实变更。样本、模型年代和工具都有限，任何一项都不能代表全行业。放在一起看，结论反而更有价值：AI的净收益高度依赖任务结构、开发者上下文和交付环境。

当一家公司说“开发效率提升了50%”，至少要继续追问：提高的是谁，在什么任务上，以什么结果为终点；评审、测试、返工和事故成本有没有进入分母。没有这些信息，百分比只是活动层的宣传材料。

第一道断点：OKR不是验收规范

复杂项目的第一道断点发生在代码之前。OKR描述组织希望改变什么，产品需求描述用户需要什么，技术规格描述系统必须满足什么，测试断言描述在特定输入下什么结果算正确。它们相关，却不能互换。

Anthropic在2026年6月对约40万次Claude Code交互会话、约23.5万名用户做了隐私保护的产品遥测分析。典型会话里，人约做出70%的规划决策，Claude约做出80%的执行决策。它不是随机实验，也没有观察代码是否最终形成业务价值，但至少说明截至这批真实使用数据，Agent更常接管“怎么做”，而“做什么、采取哪条路径”仍主要由人决定。^[14]

NASA系统工程手册对“验证”和“确认”的区分很精确。验证证明产品符合已经批准的需求，也就是逐条满足shall statement；确认判断产品在预期环境中是否实现预期目的，是否满足客户和其他利益相关者的期待。前者接近“是不是按规格做对了”，后者接近“做的是不是对的东西”。^[6]

这一区分揭示了AI编程最容易被忽略的风险。测试可以证明实现满足已写下的断言，却不能自动证明断言完整表达了业务目标。如果OKR被错误拆解，或者验收标准漏掉一个重要场景，AI完全可能写出结构漂亮、测试全绿、部署成功的错误答案。

软件测试研究把这个困难称为test oracle problem。给定一个输入，系统如何知道观察到的行为是不是正确？测试预言机调查指出，规范、契约、模型和蜕变关系可以自动化一部分判断；但当正式信息不充分时，最终预言机仍来自掌握非正式需求的人。换句话说，模型可以生成测试，不能凭空生成组织真正想要的正确答案。^[7]

自然语言目标到代码断言，至少会丢失六类东西：第一，为什么做以及什么不做；第二，用户在异常环境中的真实行为；第三，跨系统状态和时间顺序；第四，性能、隐私、兼容性等非功能约束；第五，组织可以承受多大风险；第六，谁有权在冲突发生时作最终解释。

这也是为什么“先让AI写，写完再测”在复杂项目里会越来越贵。目标歧义没有在上游消失，只是被包进更多代码，再由评审者和测试人员从实现中反向猜测。当生成速度翻倍，猜测工作也被放大。

AI最明显地压缩了开发环节，但目标、架构、验证、上线和业务验收仍然共同决定交付。

测试只能证明实现满足已写下的断言，不能证明断言完整表达了业务目标

不信任不是情绪，而是一套工程机制

讨论AI代码时，“不信任”很容易被误解为保守或技术焦虑。企业里的信任不是一种感受。它是组织在拥有足够证据之后，允许某项变更进入生产并承担后果的决定。

人类工程师写的代码也必须评审和测试。AI并没有发明软件风险。变化在于，生成速度、变更体量和自主程度上升后，原来依赖共同语境、团队经验和作者责任吸收的歧义，需要更多地外显为规格、权限、日志、测试与签收证据。AI不会因为代码进入生产而自动承担客户损失、合规责任或事故处置。组织只能用控制机制补上这段责任距离。

我所说的验证税，不是AI项目发生的全部验证支出，而是在业务结果、变更范围和风险等级可比时，AI方案相对非AI基线在目标澄清、评审、测试、安全审计、验收、返工和缺陷预期损失上的净增量。净增量为正，才叫验证税；如果AI生成测试、静态检查和运行时控制让这笔净增量为负，那就是验证红利。

截至2026年8月6日，还没有一项公开研究直接证明AI会普遍抬高端到端验证成本。本文提出的是一个需要按项目、风险和结果测量的条件性判断，不是一条技术定律。很多验证工作本来就存在，不能因为代码由AI生成，就把全部质量成本记到AI账上。

IBM与Oxford Economics在2026年1月至4月调查了33个地区、19个行业的2,000名技术高管。77%的受访组织表示AI采用速度已经超过当前治理能力，只有11%认为自己为下一年的Agent规模做好了充分准备。受访组织过去一年平均经历54起需要人工纠正的AI Agent事件，其中17%被报告为需要超过四小时控制的高严重性事件。^[11]

这项调查研究的是广义企业Agent，不是AI编程，数据也是高管自报，不能拿来推算代码缺陷率。它仍能说明一种组织现象：能力进入生产的速度可以超过身份、权限、可观测性和事故处置机制的建设速度。当控制落后，所谓效率往往只是把成本推迟到事故和返工。

评审债是验证税最先暴露的一种形态。AI可以并行生成多个PR，评审者却必须在有限注意力里恢复需求背景、理解架构影响、检查实现与测试，再决定是否承担合并风险。如果PR到达速度长期高于评审和集成能力，队列只有三种结局：等待时间变长、审查变浅，或者更多工作被退回和重做。代码库存看起来增加了，可信变更没有同步增加。

AI生成的变更还可能提高上下文重建成本。人亲手实现时，设计取舍和失败尝试通常留在作者脑中；Agent生成时，评审者如果拿不到目标、约束、替代方案和证据链，就只能从diff反推意图。好的Agent应当同时提交变更理由、需求追踪、测试证据和已知边界，而不是只把更多代码推给人。否则评审者承担的是一次小型逆向工程。

验证税也不能靠无限增加人工审核解决。人会疲劳，注意力会被大量低价值变更稀释；如果同一名评审者既要重建需求上下文，又要检查实现、边界、安全和合规，单位代码变便宜之后，人的瓶颈反而更突出。正确做法是把验证分层，把可自动证明的部分交给工具，把不可替代的业务判断留给责任人。

信任不是相信AI不会犯错，而是组织拥有足够证据承受一次授权。

复杂度为什么会把验证空间撑大

复杂软件不是功能清单，而是一组相互作用的状态。用户角色、权限、设备、网络、数据版本、依赖服务、配置开关、并发顺序和历史状态都可能改变同一段代码的结果。单个条件看起来正常，组合在一起才出现故障。

如果一个系统只有20个彼此独立的二元条件，理论状态已经有1,048,576种。真实系统的变量当然不都独立，也不需要把每一种组合都跑一遍。这个数学例子只说明状态空间可以组合增长，不证明测试成本必然按同样速度指数上升。工程的任务恰恰是用模型、分层和抽样压缩它。

NIST的组合测试项目汇总了多年软件故障研究，指出大量故障由一个到六个变量的交互触发。它发展t-way覆盖和ACTS工具，目的是用远少于穷举的测试数量覆盖高风险交互。这个来源支持“交互复杂性存在”，也同时反驳“因此必须穷举所有边界”。^[8]

AI生成代码会不会让验证空间扩大，取决于五个乘数：变更量、目标语义不确定性、系统耦合度、失败后果和AI自主程度。它不是经过统计估计的物理公式，而是一张管理检查表。任何一项很低，验证可以更轻；多项同时很高，人工评审、回归测试、审计和运行监测会互相叠加。

代码量本身还可能诱发第二个问题。过去因为开发资源昂贵而被放弃的微小功能、低必要性重构和定制需求，现在都变得“顺手可做”。每个变更都看似便宜，但它会增加未来的接口、配置、测试、文档、依赖和维护面。低成本供给如果没有价值门槛，组织得到的可能不是更快交付，而是更大的变更库存。

所以“复杂产品的测试成本指数增长”不能作为无条件事实写进预算。更准确的判断是：潜在状态空间会组合扩张，验证复杂度可能非线性上升；实际成本取决于架构隔离、风险分级、自动化覆盖和能否在上游消除歧义。

状态空间可能组合扩张；工程任务不是穷举，而是用风险分层、t-way覆盖和自动化证据压缩验证成本。

复杂度的危险不在代码更多，而在状态、权限和依赖开始相互作用。

反方成立：AI也可以降低验证税

如果文章停在“AI写得越多，测试越贵”，结论同样片面。代码生成模型可以写单元测试、补边界用例、做静态分析、解释依赖、生成变更摘要，也可以作为第二评审者检查兼容性。Meta把后台reviewer放进默认多Agent流程，OpenAI把综合测试和代码评审列为Codex能力，Anthropic声称Claude Code能够从issue一路运行测试并提交PR。产品竞争已经进入验证层。

NBER作者也明确留下了这个反方：生产力衰减可能是阶段性的。当前工具对写代码的提升最大，当AI逐渐自动化评审、测试和部署，代码活动向发布的转化率可能提高。今天观察到的瓶颈，不能被写成技术永远无法跨越的边界。^[2]

Meta在2026年发布的RADAR研究给出了一项更直接的生产反例。该系统不是让一个reviewer Agent检查所有代码，而是用作者与来源资格、静态规则、风险评分、LLM评审和确定性验证组成漏斗，把高风险变更送回人工流程。论文覆盖53.5万多个RADAR评审diff和33.1万多个落地diff；对被筛选出的低至中等复杂度变更，观察到中位评审壁钟时间比人工评审diff低35%。由于变更并非随机进入RADAR，风险和复杂度选择会影响结果，这组数据不能外推为所有AI代码都能安全免审。它证明的是更窄、也更有用的一点：当oracle清楚、风险可分层、门禁不可绕过时，验证差额可以转为红利。^[15]

问题是，多一个Agent reviewer不等于得到独立真相。生成者和评审者如果共享相同模型、上下文和错误假设，失败可能高度相关。它们可以发现语法、模式和局部逻辑问题，却可能一起接受错误的目标、缺失的业务场景或不真实的测试预言机。多Agent提高发现错误的概率，不自动证明规格正确。^[7]

降低验证税需要不同证据相互制约。编译器、类型系统、静态分析和确定性规则提供一种证据；属性测试、模糊测试、组合测试和差分测试提供另一种；架构约束、沙箱与最小权限缩小损害半径；灰度放量、可观测性、自动回滚和事故演练提供运行时证据；涉及资金、权限、敏感数据和客户承诺的变更，仍要由明确责任人签收。

NIST的SSDF把安全软件开发分为准备组织、保护软件、生产安全软件和响应漏洞四组实践。需求来源、威胁建模、代码审查、来源证明、发布完整性和漏洞响应跨越整个生命周期。AI可以执行其中很多动作，但它无法通过多写几行测试，把整个生命周期压缩成一次代码生成。^[9]

如果开发链路本身包含生成式AI，NIST 2024年的生成式AI风险管理剖面又把治理、内容来源认证、部署前测试和事件披露列为四项重点，并要求持续监测和定期复查。它的逻辑与本文一致：可信不是上线前盖一次章，而是在开发、部署和运行中持续产生证据。^[13]

因此，真正值得投资的不是更多人工检查，而是低成本、可重复、与风险匹配的证据生产系统。验证税应该下降，但下降的方式是改造工程系统，不是把测试工作藏到另一个Agent里然后宣布问题消失。

AI首先降低了门槛，还没有普遍抬高复杂工程上限

低复杂度、目标清楚、依赖少、错误可逆的项目，正在被AI快速普惠。一个非专业开发者可以做内部工具、数据处理、个人网站或一次性自动化；专业开发者可以更快完成脚手架、测试样板和局部重构。GitHub Copilot标准任务实验与NBER对低活跃开发者更大的估计效应，都支持“门槛下降”这一方向。^[2][4]

高复杂度、高交付难度、高经济后果的项目不是简单地需要更多代码。它需要把模糊的组织意图变成可执行规格，在历史系统中保持兼容，让多个团队对接口和责任达成一致，并在资金、权限、隐私、客户承诺和关键基础设施上留下足够证据。这里的稀缺资源是上下文、判断、协调和责任。

但项目不能只分成“简单低价值”和“复杂高价值”两类。经济价值与技术复杂度并不总是同向。一个规则清晰的批处理任务可能创造很高价值；一个技术复杂的炫技功能可能没有客户。更可执行的分级有三条轴：目标语义有多不确定，系统耦合与交付路径有多复杂，失败后果有多大且是否可逆。

三条轴都低，可以让AI自主完成并自动验证；语义清楚但耦合较高，适合AI实施、人审核架构与集成；语义模糊但后果可逆，适合用AI做原型和探索，不应把原型直接当生产规格；一旦涉及资金、权限、敏感数据、客户承诺或关键基础设施，即使改动很小，也要提高验证和签收等级。

截至目前，头部厂商已经把“最复杂工作流”“最难问题”和“端到端任务”写进产品定位。这证明技术目标在向复杂工程推进，不证明复杂工程的组织上限已经被普遍抬高。公开证据仍主要测量任务完成、代码活动或局部工作流，独立、长期、风险调整后的端到端业务验收数据仍然稀缺。

所以我更愿意把当前阶段概括为：AI编程正在显著降低软件能力的获得门槛，也在局部提高专业团队的速度；它还没有证明，仅凭更强的编码Agent就能稳定抬高复杂工程的交付上限。

低风险、可逆改动优先自动化；涉及资金、权限、敏感数据和关键基础设施的变更保留强审查与人工签收。

把指标从代码量改成“被业务接受的变更”

管理指标必须跟着瓶颈移动。代码昂贵时，开发工时和交付量是重要指标；代码越来越便宜时，组织应该衡量一项变更从目标到生产的完整转换效率。

本文把“被业务接受的变更”定义为：满足业务验收与技术门禁、进入生产，并在约定观察窗口内没有因为重大缺陷回滚或返工的变更。这个定义不是行业标准，团队可以根据产品调整观察窗口和严重性阈值。它的作用是迫使代码活动、生产稳定性和业务签收进入同一个分母。

单位被接受变更的完整成本，应当包括模型与算力、产品和规格澄清、开发、评审、测试、审计、部署、运行监测、失败重跑、返工、回滚和事故处置。McKinsey在2026年7月讨论Agent经济性时也强调，应把业务结果与完整运营成本比较，而不是只看Token。该文估计约60%的Agent任务成本与答案修正有关，并称相同编程任务的完成成本可相差30倍；由于原始样本和复现细节在公开页不充分，本文只把它当作行业信号。^[12]

验证税率可以作为一个内部管理比率：规格澄清、评审、测试、审计、返工和责任证明的成本，除以完整交付成本。它没有一个适用于所有公司的合理目标。更低也不必然更好，因为组织可能只是少测了。真正要观察的是，在风险和质量稳定的前提下，它是否随着工具与流程成熟而下降。

至少还要同时看八个结果：业务验收一次通过率、PR评审时长、返工率、缺陷逃逸率、变更失败率、回滚率、严重事故和从目标确认到生产的lead time。代码行、提交和Token可以保留，但只能作为诊断指标，不能单独成为绩效。

DORA在2025年把AI称为组织系统的放大器：它会放大强项，也会放大弱点。价值流管理的作用，就是防止一个环节的局部提速变成下游混乱。AI编程的ROI不在编辑器里结算，而在这条价值流的终点结算。^[10]

软件工程的新稀缺资源，不是代码，而是被业务接受、可上线、可维护、可追责的变更。

在AI写代码之前，先签一份“验收合同”

复杂项目不应该从prompt开始，而应该从一份验收合同开始。它不是把几十页PRD重新喂给模型，也不是让产品经理提前写完所有测试。它要把最容易造成责任分歧的内容变成共同基线。

第一，写清业务目标和非目标。目标必须对应可观察的业务状态变化，非目标负责阻止模型顺手扩大范围。第二，写出角色、场景和关键例子，特别是正常路径之外的异常、取消、重复、超时和并发。第三，给每条关键需求定义可判定的验收标准，并标明哪些是自动断言，哪些必须由业务负责人判断。

第四，列出架构约束和现有系统事实：权威数据源、接口契约、依赖版本、兼容要求、数据迁移和容量边界。第五，把安全和权限写成不变量，例如任何情况下都不能越权读取、不能绕过审批、不能把敏感数据写入日志。第六，定义上线证据：测试报告、代码评审、来源记录、观测指标、灰度范围和回滚条件。

第七，明确责任人。产品负责人签收目标和用户结果，架构负责人签收系统适配，安全或合规负责人签收高风险控制，工程负责人签收实现和运行准备。低风险项目可以一人承担多个角色，高风险项目不能让“AI说测试通过了”代替责任签收。

这份合同还应该区分确定与不确定。已确认需求可以进入自动实现；尚未确认的业务假设先进入原型、实验或影子模式。很多昂贵返工不是开发做错，而是组织把尚未形成共识的假设伪装成了确定需求。

验收合同不会消灭变化。它的价值是让变化有版本、有来源、有影响分析。当OKR改变时，团队可以追踪哪些产品规则、测试、权限和监测指标必须一起改变，而不是等到代码上线后才从用户投诉里发现语义已经漂移。

按风险分配自主权，而不是给所有代码同一套流程

过度治理同样会毁掉AI编程的价值。文档改字、隔离环境里的原型、可自动回滚的低风险重构，没有必要复制资金系统的审批强度。统一增加人工评审，只会让工程师绕开正式工具，形成新的影子开发。

更合理的是四级自主阶梯。第一级是建议模式，AI只读上下文、生成方案，不修改代码库；适合目标仍在讨论的工作。第二级是影子实现，AI可以在隔离分支完成代码和测试，但不发起合并；适合学习代码库和建立基线。

第三级是监督执行，AI可以创建PR、运行CI并处理低风险反馈，关键架构、权限和发布动作由人确认。第四级是有边界的自主交付，只对目标明确、隔离良好、验证充分、失败可自动回滚的变更开放；一旦异常率、成本或风险超过阈值，自动降级到监督模式。

高风险并不意味着每一行都要人工阅读。资金、权限、敏感数据、客户承诺和关键基础设施更需要的是独立证据：强类型和形式化约束、不可绕过的策略检查、双人审批、不可篡改日志、分阶段放量和自动停止。人工精力应该投向目标、架构、例外和责任，不该浪费在机器可以稳定证明的格式问题上。

AI治理的目标不是增加摩擦，而是把摩擦放在正确的位置。越可逆、越隔离、越容易自动判定，流程越轻；越模糊、越耦合、越不可逆，签收越强。

这套判断怎样被推翻

“验证税会吞噬编码收益”必须是一项可证伪判断，不能成为所有失败项目的万能解释。最直接的办法，是按相近复杂度和风险给项目分层，在四到六周内比较AI采用前后，或者比较两支流程相近的团队。

实验至少记录：模型和工具成本、规格澄清时间、开发时间、评审时长、测试与审计时间、业务验收一次通过率、返工、缺陷逃逸、回滚、事故，以及单位被接受变更的完整成本。只比较开发时间，会把问题预先裁成对AI有利的形状。

如果在同等复杂度和风险下，AI让单位被接受变更的总成本持续下降，lead time缩短，业务验收、稳定性和事故风险没有恶化，那么“验证税吞噬生成收益”的判断就应该被缩小。若AI生成的测试、评审和运行时控制还能让验证税率同步下降，说明工具已经开始跨越下游瓶颈。

相反，如果代码和PR显著增加，业务验收没有改善，评审排队、返工、缺陷逃逸和回滚上升，问题就不是开发者“不会用AI”，而是组织把局部产能误当成了完整交付能力。

这套判断也不适用于所有工作。探索性原型、个人创作和一次性分析没有严格生产验收；公开数据上的低风险实验不需要企业级审计。治理必须证明它降低了风险调整后的总成本，否则验证税本身就会变成没有价值的流程税。

下一轮竞争，不是谁生成更多代码

AI编程正在做一件很重要的事：它把软件能力从少数专业团队手里释放出来，也让专业工程师不必把时间浪费在大量重复实现上。这一轮普惠不会停止。

但复杂工程的主要矛盾正在改变。代码供应不再稀缺以后，组织意图能否被准确表达，规格能否成为可靠预言机，架构能否吸收更多变更，验证证据能否低成本生产，出错后谁能停止、回滚和负责，会决定AI产能能不能变成业务结果。

这也是企业采购AI编程工具前应该先问的五个问题：目标由谁解释，验收由谁签收，架构约束怎样进入Agent上下文，自动证据覆盖哪些风险，失败后谁能叫停和回滚。五个问题没有答案，更多Agent席位只会更快地制造待验证库存。

我的判断不是AI只能做简单项目。相反，编码Agent会不断进入测试、评审、架构分析和部署。真正的分水岭在于，企业能否把目标、上下文、证据和责任一起工程化。谁能用更低的验证成本，把更多代码转化为可信变更，谁才获得了AI工程生产力。

代码会越来越便宜。软件工程不会因此自动变简单，因为软件最终要进入真实组织、真实系统和真实责任。AI编程的下一阶段，不是比赛谁能写得更多，而是比赛谁能证明得更快、交付得更稳、对结果负责。