软件工程圈子里现在有个根深蒂固的假设：
只要 AI 能帮我们写代码写得更快，我们就能造出更多东西，跑得比谁都快。
但是，这个假设漏了关键的一步。
写代码，和把代码集成起来、维护它、信任它，完全是两码事。
我们正在发现一个残酷的事实：验证（Verification）的速度，根本跟不上生成（Generation）的速度。
我觉得，在这个环境下能活下来的工程师，绝不是那个能用 AI 啪嗒一下吐出最多代码的人。
而是那个能盯着屏幕上涌出来的代码，冷静地决定“什么能活，什么得死”的人。
当生成变得免费，信任就成了奢侈品
我们现在正处在生成式 AI 的大爆炸中心。
代码、图片、视频、文档，所有这些东西的生成成本，跟以前的人力成本相比，正在无限趋近于零。
在软件工程这行，能写很多代码，传统上一直被等同于“高产”，甚至等同于“有创造力”。
但这个等号，现在失效了。
我们能生成的代码比以往任何时候都多，速度比以往任何时候都快。
但这有个毛用？
数量本身已经失去意义了。
要搞清楚到底发生了什么，我们得稍微借用一下认识论的概念。
认识论是哲学的一个分支，它专门把“真知识”和“不是知识的东西”区分开来。
光有经验不是知识。
重复权威人士说的话不是知识。
基于经验瞎扯淡也不是知识。
只有当一个陈述内部逻辑自洽、能公开测试、并且能在“敌对审查”下活下来时，它才有资格成为知识的候选人。
举个很硬核的例子：军事硬件。
一辆坦克的价值，不是在设计实验室里确定的，也不是靠宣传册吹出来的。
它的价值，只有在实际战斗中扛住了攻击，才能被证明。
在没面临压力、抵抗和敌对条件之前，谁也没法严肃地宣称它有多有效。
这道理放在想法、设计和代码上，一模一样。只有在被攻击的时候，它们的价值才会暴露出来。
卡尔·波普尔把这事儿说得很绝：源头不可信。
不管一个说法是出自著名科学家、资深工程师，还是一个大语言模型，都不重要。
重要的是，这个说法能不能在“证伪”的尝试中活下来。
知识是通过猜想和反驳增长的，而不是靠自信的断言。
AI 本质上是个“瞎猜”机器
说到底，生成式 AI 就是个“猜想引擎”。
它吐出的每一行代码，都是关于“系统该怎么运行”的一个理论假设。
它给出的每一条解释，都是一种解读。
所有这些东西，都只能算临时的。
AI 生成的一切，都应该被视为一个“待定理论”，然后被扔进严酷的测试和批评里，看看能不能活。
其实在 AI 出现之前，这事儿就是真理。
这也是为什么我们发明了代码审查、Lint 工具和持续集成（CI）。
我们知道人会犯错，初稿通常都是垃圾，只有结构化的批评能救我们。
CI/CD 管道、单元测试、集成测试，本质上都是把代码扔进“敌对审查”的机制。
从这个意义上说，波普尔的认识论早就嵌入在我们的工作流里了。
但现在变的是规模。
2016 年，Hatton 教授和他的团队发表了一篇论文，研究软件代码库的长期增长率。
那时候还没有 GenAI。他们的发现惊人地一致：历史上，软件项目的增长率大约是每年 20% 的复合增长率（CAGR）。
按这个速度，一个代码库大概每 4 年翻一番。
注意，这论文描述的是历史上代码库实际是怎么长的，不是理论最大值。
现在，如果 AI 真的把开发者的生产力提上去了，会发生什么？
如果生产力翻倍，CAGR 冲到 40%，代码库翻倍的时间就缩短到大概 2 年。
如果生产力涨 5 倍，我们接近 100% 的 CAGR，代码库每年翻一番。
这复利效应是很恐怖的。一个 5 倍的生产力提升，如果持续 10 年，可能意味着代码体积增加 165 倍。
一个中等规模的 10 万行代码（LOC）项目，可能会变成 1 亿行。
为了让你有概念：Linux 内核进化了三十年，也就才到 4000 万行代码。
我们正在走向“怪兽代码库”的时代。
谁来审查审查者？
这预测肯定会有人跳出来反对。
首先，20% 的 CAGR 是 LLM 之前的旧数据，拿来预测 LLM 之后的世界，逻辑上有点硬伤。
但历史趋势就是个基准线。如果趋势没变，那啥事没有；如果趋势断了，我们就得搞懂新环境。
其次，软件的增长是受复杂度限制的，不光是打字速度。
一个 1 亿行的代码库，不管你写得多快，可能根本没法构建或者没法维护，因为集成的复杂度增长比线性快多了。
如果我们生成代码的速度，超过了我们能管理集成复杂度的速度，我们造出来的系统就会在自己的重量下崩塌。
核心问题来了：我们的验证系统能跟上吗？
以前，审查过程是可以跟代码库同步增长的。代码每年长 20%，人类的审查能力勉强能跟上。
但如果代码量是成倍增长，而不是百分比增长，旧的平衡就碎了。
我们从“增量增长”变成了“批量生产代码”。
这时候，注意力成了最稀缺的资源。
当生成的输出爆炸式增长，价值就从“生产”转移到了“筛选”。
关键问题变成了：我们要怎么把有限的人类注意力，引导到机器生成的代码海洋里最重要的风险上？
没有现实可行的路子，除非我们也用 AI 来验证。
光靠人肉审查，根本跟不上机器规模的生成。
AI 得帮我们高亮有用的东西，指出潜在的约束违规，检测行为漂移，减轻审查的负担。
验证必须部分自动化，否则系统直接瘫痪。
这时候有个最明显的反对意见：如果生成代码的 AI 有缺陷、会幻觉，那审查代码的 AI 凭啥就没缺陷？
这不是错上加错吗？这就是所谓的“无限倒退”问题——我们需要 AI 查 AI，那谁来查那个查人的 AI？
答案在于“专业化”。
审查 AI 不需要是个通用智能。
它得是个专注于检查特定属性的工具：类型正确性、项目风格一致性、架构边界违规，或者基于属性的测试抓到的行为漂移。
用来审查的模型，可以跟用来生成的模型不一样——更小、更保守。
审查 AI 不需要对代码“好不好”发表意见。
它的任务是把异常情况扔给人类看。
它就像个不知疲倦、速度极快、但最终会犯错的初级审查员，工作就是标记任何奇怪的东西，然后让高级工程师拍板。
目标不是消灭人类判断，而是聚焦人类判断。
这也是“护栏”该待的地方。
护栏主要应该坐在验证层，而不是生成层。
光想约束生成，就像想在设计图纸上阻止所有烂坦克设计一样天真。
更稳健的做法，是对每个设计进行严酷的批评和压力测试。
与其把审查模型当成主要控制机制，不如升级我们的验证方法。
反驳，才是未来的核心竞争力
还有一种反对声音来自经济学。
也许未来不是怪兽代码库，而是极小的、高杠杆的代码库。
如果代码变得不值钱了，写高效、可复用抽象的动机就变强了。
为什么要生成一千行样板代码，如果十行配置文件加 AI 就能搞定？
这有可能。
但哪怕是极小的代码库，也需要验证它那极小的一部分，而且杠杆越高，任何一个错误的爆炸半径就越大。
不管代码量是膨胀还是收缩，验证的负担只是转移了，不会消失。
稀缺的资源始终是：投对地方的人类注意力。
如果 GenAI 把猜想规模化，ReviewAI 就得把反驳规模化。
还有人会说，代码量的增长最终会遇到市场饱和。
我们没那么多有意义的问题要解决。到了某个点，生成更多代码就是制造噪音和技术债务。
但这假设是“问题表面”快饱和了。并没有。
看看印度这样的国家。大规模的基础设施缺口、污染管理、物流低效、医疗接入、教育质量、城市规划、农业优化——这些都不是边缘问题。
它们是系统级挑战，需要大规模的协调、监控、仿真、自动化和优化。这些都越来越依赖软件。
哪怕在发达国家，软件对物理系统的渗透也还没完：能源网、水务系统、公共交通、制造、气候建模、机器人、生物科技。
历史上，当产能扩张时，需求往往会扩张到以前被认为不可行的领域。
限制因素很少是缺问题，而是缺钱和缺协调。
工程这个领域，得把这个变化内化成基因。
这行一直依赖于把“能用的东西”和“看起来能用的东西”分开。
有造东西的经验不代表它可靠。
能在对抗性测试里活下来，才代表可靠。
面对代码量可能以前所未有的速度复合增长，我们没有慢慢演进化规范的本钱。
我们需要现成的、成本可控的验证工具，直接嵌入开发工作流。
我自己在做 AI 辅助代码审查时，就在构建这样的工具，当 diff 被提交到 git 仓库时自动触发审查。
想法很简单：把每一次变更都当成假设，对它进行系统的攻击。
某种意义上，这就是嵌入在 CI/CD 里的应用波普尔认识论。目标不是减慢生成，而是让批评变得丰富。
我不宣称这解决了所有问题。
工具还很早期，方法都是实验性的，无限倒退的担忧也是真的。
但我们是时候认真对待“ReviewAI”这个技术栈了。
GenAI 让猜想变得廉价。
复合错误的真实风险是存在的。
如果我们不把反驳变得同样强大和普及，我们就有可能淹没在自己的输出里。
AI 时代的工程未来，不是由我们能生成多少决定的，而是由我们多严格地决定什么能存活决定的。
而那个“什么能存活”的决定，归根结底，还是人的责任。
我个人很希望，“反驳”这个概念，在行业里能像“生成”一样被认真对待。
参考链接：
https://learningloom.substack.com/p/the-future-belongs-to-those-who-can