AI 写代码太快，Review 都来不及了：我们是不是从一开始就算错了生产力？
AI 写代码越来越快，程序员却开始面临新的烦恼：代码生成的速度远远超过人工审查的速度。
于是有人提出，应该减少人工逐行 Review，把更多工作交给自动化测试、AI 审查、灰度发布和监控系统。
也有人坚持，Review 是软件工程的基本纪律，不应该因为 AI 提高了生产速度，就轻易放弃质量保障。
这两种观点都有道理。
但我觉得，这个问题还可以继续往前追问：
为什么 AI 明明提高了生产力，人类却还在为追赶机器的产出而烦恼？我们究竟应该追求更高的代码产量，还是用更少的劳动，获得更可靠的软件和更多自由时间？
如果从体面生活时间的角度分析，我们可能会发现，AI 编程带来的真正挑战，并不是 Review 要不要保留，而是我们对生产力的理解需要改变了。
一、代码生成速度提高，不等于人的时间得到了解放
假设过去开发一个功能，需要程序员花 8 小时编写代码，再花 2 小时测试、审查和修复问题。
整个过程需要 10 小时。
现在引入 AI，编写代码只需要 1 小时，但由于生成的代码更多、逻辑更复杂，人工审查、测试和修复问题需要 7 小时。
那么整个过程仍然需要 8 小时。
从代码生成的角度看，效率提高了 8 倍。
但从完整的软件交付过程看，总耗时只减少了 20%。
如果生成的代码中还包含大量重复实现、不必要的抽象和潜在缺陷，那么后续维护成本可能进一步增加，甚至抵消前期节省的时间。
当然，这只是一个示例，不代表所有项目的实际数据。
它想说明的是一个很容易被忽略的事实：
我们不能用某一个环节的效率，代替整个生产过程的效率。
过去，程序员的主要劳动之一是编写代码。现在，这部分劳动正在被 AI 大幅压缩，但需求分析、系统设计、验证、集成、故障处理和维护等工作，并不会自动消失。
如果我们只关注 AI 每小时能生成多少代码，就可能陷入一个新的误区：机器生产得越快，人类就必须处理越多的代码。
结果是，代码越来越多，系统越来越复杂，程序员却没有获得与技术进步相称的时间自由。
这不是生产力进步的必然结果，而是我们组织生产的方式仍然停留在过去。
二、为什么我们要用体面生活时间重新评价 AI 编程？
我们通常用几个指标评价 AI 编程：
- 代码生成速度提高了多少；
- 开发一个功能需要多少时间；
- 一个程序员能够管理多少个 Agent；
- 团队每周能够交付多少个需求。
这些指标都有价值，但它们主要衡量生产过程中的局部效率，或者企业能够获得多少产出。
它们没有完整回答另一个问题：为了获得这些软件成果，人们总共付出了多少时间？
我们可以从三个层面看这个问题。
第一，是开发者的劳动时间。
AI 是否减少了开发者的实际工作时间？还是把写代码的时间转移到了审查代码、排查故障和维护系统？
第二，是整个社会为软件付出的时间。
如果每家公司都在用 AI 重复生成相似的登录系统、权限管理、日志平台和基础组件，那么单个团队的开发速度提高了，整个社会的重复劳动却未必减少。
第三，是人们最终获得的自由时间和生活条件。
软件开发效率提高之后，产品是否更可靠、更容易维护，用户是否能以更低的时间成本获得服务？开发者是否能够减少加班，把更多时间用于休息、学习、创造和自己的生活？
这才是更完整的评价视角。
我们把为了获得体面生活而必须付出的劳动、通勤、必要事务和社会再生产时间，与必要的休息和恢复条件一起纳入分析，才能看清技术进步究竟改善了人的生活，还是只提高了生产系统的运转速度。
这里需要注意，体面生活时间不是把所有时间简单相加成一个分数。必要的付出时间与获得的休息、恢复和自主时间，是不同的维度，应该分别观察。
对于 AI 编程，我们也应该采用同样的思路：既计算生产所付出的时间，也考察由此带来的可靠性、可维护性和人的时间自由。
三、Review 的真正问题，不是人看不过来，而是整个系统产生了太多需要人看的东西
回到 Code Review。
如果 AI 生成代码的速度提高了十倍，我们很容易得出一个结论：应该让 Review 也提高十倍。
于是我们增加 Review Agent，增加测试，增加审查规则，增加新的质量门禁。
这些方法确实有用。
但我们还应该追问：为什么要让系统生产这么多需要检查的代码？
假设一个团队有三个选择。
方案 A： 让 AI 一次性生成大量代码，再投入更多人力审查。
方案 B： 让 AI 分阶段实现功能，每个阶段都有明确的接口、约束和自动化验证。
方案 C： 先检查现有系统和成熟组件，尽可能复用已有能力，只生成真正必要的新增代码。
三个方案都可以使用 AI，但它们的劳动结构完全不同。
方案 A 把更多工作推到了后面的审查环节。
方案 B 通过限制每次变更的范围，降低理解和定位问题的成本。
方案 C 则进一步减少了根本不需要发生的劳动。
如果一个成熟的组件已经可以满足需求，那么重新生成一个相似组件，再花时间审查它，并不一定创造了新的价值。
如果一个需求可以通过修改几十行代码解决，却让 AI 重新生成几千行代码，那么我们就应该问：新增的代码究竟解决了什么问题？它带来的长期维护成本是否值得？
真正高水平的 AI 编程，不只是更快地生成代码，还应该更准确地判断哪些代码不需要生成。
这与节约社会必要劳动、减少重复建设的思想是一致的。
生产力进步的意义，不是让社会能够更快地重复劳动，而是让我们用更少的必要劳动，获得同样甚至更好的成果。
四、从体面生活时间看，软件研发应该怎样重新分工？
我认为，AI 时代的研发流程应该围绕一个原则重新组织：
把可以标准化、自动化的劳动尽可能交给机器，把人的注意力留给真正需要判断的事情。
具体来说，可以分为四个方面。
1. 不要让人反复检查机器已经能够可靠检查的问题
编译错误、类型错误、格式问题、已知安全规则和大量回归场景，都可以通过自动化工具检查。
这些问题如果能够可靠地自动发现，就不应该反复消耗多个程序员的注意力。
一次人工发现的问题，应当尽可能沉淀为测试、静态检查规则或项目规范。
这样，下次遇到同类问题时，团队就不必重新支付同样的劳动成本。
自动化的价值不仅在于节省一次检查时间，更在于减少未来重复发生的劳动。
2. 人应该重点审查需求、架构和风险
自动化检查并不能证明一个功能值得开发，也不能保证一个设计适合整个系统。
因此，人类仍然需要重点判断：
- 这个需求是否真实存在？
- 有没有可以复用的成熟方案？
- 这次修改是否破坏了系统边界？
- 出错之后会影响谁？
- 哪些后果无法通过回滚恢复？
对于文案修改、低风险内部工具，可以减少人工审查。
对于权限、支付、隐私、核心数据写入和复杂并发逻辑，则应该保留严格的人工审查和独立验证。
这不是简单地在效率和质量之间二选一，而是根据不同风险配置必要的劳动。
不应该让所有代码享受同样昂贵的审查，也不能因为机器生产得快，就让高风险代码绕过必要的检查。
3. 不要只奖励代码产量，要奖励问题的解决
如果一家公司的考核方式仍然是完成更多需求、提交更多代码、管理更多 Agent，那么 AI 很可能让这种竞争进一步加剧。
程序员会被鼓励生成更多代码，而不是减少不必要的代码。
更合理的考核应该关注：
- 从需求提出到可靠交付的总时间；
- 缺陷率、返工率和线上事故；
- 长期维护所需的劳动；
- 成熟组件的复用程度；
- 用户获取和使用软件的时间成本；
- 团队是否真正减少了不必要的加班。
一个程序员用 AI 在半天内完成了原本需要三天的工作，如果最终软件质量更好、维护成本更低，这才是值得肯定的生产力进步。
反过来，一个团队每天提交大量代码，却不断制造新的故障和维护负担，就不能仅凭代码产量认定它更有效率。
4. 把节省下来的时间真正还给人
这可能是最重要、也最容易被忽略的一点。
假设 AI 让一个团队完成相同工作所需的劳动时间减少了 40%。
企业可以选择利用这部分能力承接更多需求，让团队继续以原来的强度工作。
也可以选择缩短交付周期、减少加班、改善软件质量，让开发者拥有更多时间进行技术探索、学习和休息。
这两种选择都可能提高企业的某些指标，但对人的生活产生的结果完全不同。
如果技术进步只意味着工作强度不断提高，那么劳动者虽然拥有更先进的工具，却未必获得了更好的生活。
从体面生活时间的角度看，技术进步应该创造一种可能性：当社会满足既定需求所需的劳动减少时，人们可以获得更多自主支配时间，而不必不断用新的工作填满节省出来的时间。
这不是要求企业停止发展，而是要求我们重新思考发展的目的。
五、比每家公司都提高开发效率更重要的，是减少整个社会的重复劳动
AI 编程还有一个更深层的潜力。
今天，不同公司可能都在用 AI 实现相似的基础功能。每家公司都觉得自己开发得更快了，但整个社会仍然有大量人力投入到重复建设中。
如果成熟的软件能力可以通过可靠的开放标准、共享组件和经过验证的基础设施得到复用，那么很多团队就不必反复解决相同的问题。
当然，公共组件并不能解决所有需求。不同系统仍然可能有不同的安全边界、性能要求和业务规则。但对于那些已经成熟、标准化、能够广泛复用的能力，减少重复建设往往比单纯提高生成速度更有价值。
这也提示我们，AI 时代的软件研发应该区分两类活动。
一类是成熟问题的规模化解决：优先复用已有成果，降低重复劳动。
另一类是新问题的探索：鼓励试验、创新和多样化方案，不要求所有人立即采用同一条路线。
前者的重点是减少不必要的劳动，后者的重点是创造新的能力。
如果把两者混在一起，就容易出现这样的情况：一边用 AI 追求极高的开发速度，一边不断重复制造已有的轮子；一边宣称生产力得到巨大提升，一边又把更多时间投入审查、整合和维护。
真正的进步应该是让成熟能力被更广泛地使用，让创新劳动集中到尚未解决的问题上。
六、最终，我们要优化的不是代码，而是人的生活
回到最初的问题：AI 写代码太快，Review 来不及了，要不要放弃 Review？
我的回答是：不应该放弃必要的质量保障，但应该放弃把人工逐行审查当作所有代码的统一质量标准。
更重要的是，我们不能只从代码生成的角度看待这个问题。
如果 AI 能够降低软件开发的劳动成本，我们就应该利用这种能力，减少重复劳动、缩短验证周期、提高软件可靠性，并降低长期维护成本。
如果 AI 只是让代码数量增加十倍，却让人类承担更多审查、排障和维护工作，那么它带来的生产力进步就没有得到充分实现。
如果 AI 让企业交付更快，却让开发者必须不断追赶更高的产出目标，那么技术进步也没有自动转化为人的时间自由。
真正值得追求的方向，是让软件生产体系越来越少依赖重复劳动，让成熟成果得到更广泛的复用，让必要的验证更加自动化，让人类的判断集中于真正重要的事情。
最后，我想用一句话总结：
衡量 AI 编程是否真正进步，不应该只看它让我们多快写出代码，而应该看我们能否用更少的必要劳动，创造更可靠的软件，并让人们获得更多真正属于自己的时间。
代码是手段，软件是成果，人的生活才是目的。
如果忘记了这一点，即使 AI 可以在几秒钟内生成一个完整的软件系统，我们也可能只是获得了一种更高效地制造工作、制造复杂性和制造新问题的方式。
而如果我们始终把人的时间、生活质量和自主发展放在中心，AI 才有机会成为真正解放劳动的生产力工具。