顶级开发者激辩：AI 写的代码该不该逐行读？

7 月初，HashiCorp 联合创始人、Ghostty 作者 Mitchell Hashimoto 在 X 上发出三个单词——「I read the code」，浏览量近 83 万。20 天后，《代码整洁之道》作者、有着 60 余年编程经验的 Robert C. Martin（Uncle Bob）给出了一个截然相反的答案：「我完全不去读 Agent 写出来的任何代码。」两位世界级开发者的隔空交锋，把整个开发者社区卷入了一场持续数周的争论。

Hashimoto 立场：理解代码仍是工程责任

Mitchell Hashimoto 明确表示，自己会逐行阅读 AI 生成的代码。当时正值 Anthropic、GPT 等新模型发布、编程智能体能力快速提升之际，他的表态被许多人解读为对 Vibe Coding 的一次公开反驳。

分布式系统工程师 Cindy Sridharan 给出了更激进的延伸：「每当听见有人说『代码全是 Claude 写的，我不知道它是怎么工作的』，我就会认定，这个人根本没有能力调试这些代码。没什么好争的——你调试不了它，就没资格说自己拥有它。」她认为，能否调试代码是开发者是否真正掌控代码的明确界线。

开源软件工程师 Christine Lemmer-Webber 则把这种现象称为「Vibe 滑坡」：开发者从谨慎使用 AI 写代码，到逐渐放松审查，最后滑向完全凭感觉写代码。她指出，这个过程很多时候并非主动选择，而是顺着惯性越滑越快，「人们对这段旅程的掌控力，远不如他们自认为的那样强大」。

Uncle Bob 立场：用约束取代逐行审查

Uncle Bob 的回复起因于另一位开发者 Ori Pomerantz 的吐槽：让 Claude 直接编辑自己的文件总让他感到不舒服，「既然要对代码负责，就必须理解它」。Uncle Bob 回应说，自己从 20 世纪 60 年代末就开始编程，但现在采取的策略是「完全不去读 Agent 写出来的任何代码」。这条推文最终获得了超过 480 万次浏览。

他的核心做法是给 Agent 设置极其严格的约束，包括：

• 单元测试与 Gherkin 验收测试
• QA 流程与质量指标
• 变异测试与测试覆盖率
• 圈复杂度与函数长度上限

当 Agent 生成的代码通过这些约束和测试的重重考验后，他便对最终结果抱有「很高的信心」。

针对「谁来保证约束本身可靠」的反问，Uncle Bob 的回答是：让智能体去编写检查约束的工具。这些工具是确定性的、规模相对较小，同样会被大量单元测试和验收测试包围。这构成了一个近乎无限递归的体系——智能体写代码、智能体写测试、智能体再写工具检查测试与代码。他通过变异测试、Gherkin 验收测试、QA 流程以及关键任务的人工抽查，让篡改测试来蒙混过关的难度显著增加。

值得一提的是，开发者 AmazingAng 已将这套思路实现为开源工具 old-coder，核心正是用一整套验证关卡替代对 Agent 生成代码的逐行阅读。

争论背后：代码究竟有多重要

互联网上的技术争论往往被简化为非黑即白的两派。围绕 AI 代码的真正问题其实是：你认为自己写的代码究竟有多重要？

t3.gg 创始人 Theo 提出了一个光谱视角：

• 最顶层是纯粹的垃圾代码，写出来只为整理文件或回答一次性问题
• 第二层是希望它能正常工作，出了问题会很烦
• 第三层是它最好别出问题，否则可能会被解雇
• 最底层是它一旦出错，可能有人死亡

过去手写代码成本太高，开发者几乎没有余力去上面两层探索。而 AI 让上面两层的代码变得几乎免费——更合理的做法是大量进入这些上层区域，用廉价的代码去验证昂贵的代码。

这一思路与 Uncle Bob 的「无限递归」测试策略一脉相承：用大量廉价代码构建测试金字塔，在底部堆满一次性实验、临时脚本、边缘情况测试和替代实现，让这座塔去保护塔尖上那一小撮真正不能出错的代码。

没有人会主张把心脏起搏器里的代码交给 AI 随意生成。但反过来，一套系统越重要，围绕它生成的测试、模拟和验证代码就应该越多。这场关于「读不读代码」的争论，本质上反映的是工程范式在 AI 时代的悄然转变。