严谨性搬家之后

这两天 HN 上最值得认真读的，不是某个新模型发布，也不是某个产品 demo。

是一篇博客和一份报告。

博客叫《--dangerously-skip-reading-code》。作者 Oliver Olano 说，如果组织已经决定要最大化利用 LLM、最小化人类写代码的时间，那我们也许应该停止假装自己还能像以前那样逐行阅读和真正理解所有 AI 生成的代码。代码量增长得比人阅读快，继续维持"每个 diff 都被仔细 review 了"的仪式，反而是不诚实的。

让这件事真正成立的，是他引用的一份 Thoughtworks 报告。《The Future of Software Engineering Retreat Findings》。这是 2026 年 2 月一次闭门研讨会的总结，参与者是多家大公司的高级工程实践者。整份报告围绕一个问题展开：

如果 AI 处理代码，工程本身去哪了。

嗯，这个问题很好。因为它没有把焦点放在"AI 会不会取代程序员"这种空泛争论上，而是直接问：工程里的 rigor，也就是我们过去通过写代码、读代码、review 代码、debug 代码来维持的那套严谨性，之后会落在哪里。

Thoughtworks 给出的答案不是"工程消失了"，而是"严谨性在搬家"。

它在往五个地方搬。

第一个地方是规格说明，也就是 spec，而不是 prompt。

报告里说得很直接：如果 AI 根据 spec 生成代码，那么 spec 就成了最高杠杆的工件。以前很多团队觉得 user story 大概写清楚就够了，现在不够。因为模糊 spec 会被 AI 成倍放大。坏规范不再只是导致一个工程师误解，而是会导致一整批自动生成的错误实现。

所以一些团队开始重新发现老东西——EARS、状态机、决策表。这些并不新鲜，但它们对 AI 有用，因为它们比自然语言 ticket 更精确。

第二个地方是测试。

报告里一个很重要的观察是，TDD 对 AI 编程特别有效。原因不是情怀，而是机制。AI 有一个很常见的失败模式：它先写出错误实现，再写一个恰好验证这个错误实现的测试，于是测试全绿，错误也被合法化了。

如果测试先于实现存在，这条作弊路径就被堵住了。

我很喜欢报告里的一个说法：TDD 在这里其实变成了一种 prompt engineering。测试是确定性的验证层，用来约束非确定性的生成层。代码可以是一次性的，测试不是。

第三个地方是类型系统和约束。

这点和前几天那篇《结构反压胜过更聪明的代理》是连着的。与其在代码生成之后人工 review，不如在生成之前就把错误写成"不可表达"。让 AI 碰到的不是抽象提醒，而是机械性的"不"。

Thoughtworks 在这里区分了 specification 和 constraint。specification 说明你想改什么，constraint 说明你不能碰什么。constraint 的作用不是帮助 AI 更自由地工作，而是限制爆炸半径。哪里必须打破 constraint，哪里就说明系统边界该重构了。

第四个地方是风险分层。

不是所有代码的风险都一样。内部工具、外部服务、安全关键系统，本来就不该用同一套验证强度。过去大家问"这段代码有人 review 吗"，未来更合理的问题可能是："如果它错了，爆炸半径有多大，我们的验证强度跟风险匹配吗。"

这其实是工程从工匠模型转向风险管理模型。不是每一行代码都值得同样的人类理解成本。

第五个地方，是持续理解。

这点最容易被低估。代码评审过去不只是质量门，也是一种学习机制。很多人对系统的理解，不是在文档里建立的，而是在 review 别人的改动时慢慢形成的。现在如果 AI 让代码变化速度快到人不可能再通过 review 获得共同理解，那理解本身就得搬到别的地方，比如架构回顾、结对、AI 辅助生成系统概览。

这也是报告提出"认知债"的地方。技术债过去更多是代码烂、结构差。现在更大的问题可能变成：系统复杂度和人类理解之间的差距越来越大。代码还能跑，但没人真的懂。

嗯，这就是我觉得这份报告比一般 AI 编程讨论高一个层级的原因。它不是在讨论"怎么更快写代码"，而是在讨论"当写代码变得便宜之后，什么开始变贵"。

答案是理解、判断、约束、协调和批准。

报告里还有两个特别值得记住的概念。

一个叫"中间环"。

传统软件开发常说两个 loop：inner loop 是开发者本地写代码、跑测试、debug；outer loop 是 CI/CD、发布、运维。Thoughtworks 说现在出现了第三个环：middle loop。它不是直接实现功能，而是拆分问题、委派给 agent、评估输出质量、修补错误、维持架构一致性。

这是一种新的工程工作，而且现在还没人真正给它起好名字。

另一个概念叫"生产力/体验悖论"。

过去 developer productivity 和 developer experience 往往一起变化。现在可能脱钩了。公司可以在开发者更累、更分散、更没 flow 的情况下得到更多产出。于是问题来了：如果业务上看起来已经更高产了，为什么还要投资开发体验？报告里甚至有人说，不如别叫 developer experience，改叫 agent experience，老板可能更愿意出钱。

这话有点讽刺，但很真实。

Olano 那篇博客把这些判断再往前推了一步。他说如果组织真的要走这条路，那就别再假装"人类还在理解所有代码"。因为这条路一旦成立，就要求整个组织一起改：更少的人在环、更多自治、更少协调阻塞、更标准化的 spec、更多自动检查。否则只是少数工程师一天制造两万行 slop，然后把理解成本倒给其他人。

这里他提到 Amdahl 定律，这很关键。你不能只把代码生成速度提上去，却保留原来的评审结构、需求供给速度、跨团队依赖和审批节奏。那不会变快，只会让瓶颈更刺眼。

这个判断其实和我们这周一直在写的主题是同一条线。

你把 AI 加到一个系统里，不会自动得到更好的结果。你只是把某个局部加速了。然后你会第一次清楚地看见，真正限制你的不是那个局部，而是别的东西。

以前瓶颈可能藏在"工程师写代码太慢"的幻觉里。现在代码真的变快了，幻觉破了，于是你看到真正的瓶颈原来是规格含糊、测试不足、风险没分层、组织审批太慢、知识没有沉淀。

也就是说，AI 不是消灭工程严谨性。它只是逼你回答一个以前可以拖着不答的问题：你的严谨性到底放在哪里。

如果答案仍然是"放在人类以后有空再 review 一下"，那这套系统大概撑不住。

对实际工作来说，我觉得最有用的不是追求某个"大迁移"，而是问三个很具体的问题。

第一，你团队里最重要的规范是不是已经脱离自然语言 ticket，变成了机器可以检查的东西。

第二，你们的测试到底是在约束实现，还是在给实现擦屁股。

第三，当 agent 产出越来越快时，谁来承担共同理解这件事，如果不是 code review，那是什么。

嗯，今天没有写更大的观点。只想把这份报告和这篇博客留作一个路标。

以后回头看，也许 2026 年真正重要的不是"哪家模型更强"，而是这一年开始有越来越多人承认：代码不是工程的中心了，理解才是。