7 月 3 日，HashiCorp 联合创始人 、Ghostty 作者 Mitchell Hashimoto 发了一条推文，“I read the code”，获得近 83 万次浏览。
20 天后，Robert C. Martin，也就是《代码整洁之道》的作者、写了六十年代码的 Uncle Bob，给出了一个截然相反的答案：“我完全不去读 Agent 写出来的任何代码。”
两条推文，两位世界级开发者，两种完全相反的做法，把整个开发者圈卷进了一场持续数周的混战。
“我读代码”：理解仍然是工程责任的一部分
AI 写出来的代码，Mitchell Hashimoto 会自己读。
当时 Anthropic 的 Fable、GPT-5.6 等新模型刚刚发布，编程智能体的能力不断提升，Vibe Coding 的拥护者正觉得，“跟着感觉写代码”这条路已经得到了新一轮验证。于是，原本只是在陈述个人工作习惯的三个词，很快被解读成了对 Vibe Coding 的公开反驳。
那么，AI 写出来的代码，人到底还要不要读？
有人认为，读代码是开发者不可放弃的职业底线。只要代码最终由你提交、部署和维护，你就必须理解它在做什么，也必须有能力在出错时接手调试。有人则认为，逐行阅读正在变成一种刻舟求剑的工作方式：AI 生成代码的速度早已超过人类检查代码的速度，假如仍然要求开发者逐行读完，刚刚被释放出来的生产力，很快又会被人工审查的速度重新限制住。
分布式系统工程师、《分布式系统可观测性》作者 Cindy Sridharan 给出了一个很强硬的立场：“每当我听见有人说，‘代码全是 Claude 写的，我不知道它是怎么工作的’，我就会认定，这个人根本没有能力调试这些代码。没什么好争的。你调试不了它，就没资格说自己拥有它、掌控它。而一套代码连你自己都掌控不了，那么任何真正看重可靠性和稳定性的人，都不可能信任你这样的供应商。”
在她看来，能否调试代码，是开发者是否真正掌控代码的一条明确界线。她经常看到开发者直接采用 Claude 生成的错误修复方案，而一旦遇到稍微棘手的 Bug，他们往往需要反复尝试好几轮，才能真正定位并解决问题。
开源软件工程师 Christine Lemmer-Webber 则把这种现象称为 “Vibe 滑坡”：一开始，人们只是谨慎地借助 AI 写代码，也会认真做代码审查；但随着速度越来越快，审查会一点点被放松，最后一路滑向完全凭感觉写代码的 Vibe Coding。她认为，这个过程很多时候并非开发者主动做出的选择，更像是顺着惯性越滑越快。
“人们对这段旅程的掌控力，远不如他们自认为的那样强大。”
在追求速度的过程中，每一个环节的监督都可能被进一步削弱，现实中也很难找到一个真正有效的刹车点。更麻烦的是，即便经验丰富的程序员，也未必能发现一个只有 100 行代码的程序里所有的 Bug。如今，大语言模型一次就能生成远超 100 行的代码，人类想要完整审查这些不断膨胀的输出，也会变得越来越困难。
“我不读”：Uncle Bob 用约束取代逐行审查
20 天后，另一个更具分量的声音加入了这场争论。
Robert C. Martin，也就是开发者熟悉的 Uncle Bob，《代码整洁之道》的作者。从 20 世纪 60 年代末开始编程，至今已经从事编程超过 60 年。面对“你是否阅读 AI 生成的代码”这个问题，他的回答很干脆：“我不读。”
起因是另一位开发者 Ori Pomerantz 在 X 上发了一段话：“我正试着让 Claude 帮我写点东西，但我总觉得让 AI 直接编辑我的文件不太舒服。有人有同感吗？如果我要对代码负责，我就必须理解它，哪怕只是心理上需要这么做。”
他还补了一句：“1983 年开始编程，算老了吗？”
Uncle Bob 回复说，自己开始写代码的时间比 Pomerantz 还早得多，从事编程已经超过 60 年了，但他现在采取的策略，是“完全不去读 Agent 写出来的任何代码”。
他的做法是给 Agent 设置极其严格的约束，包括单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及大量其他机制。当 Agent 生成的代码通过这些约束和测试的重重考验后，他便会对最终结果抱有“很高的信心”。
不过，Uncle Bob 的回复并没有结束这场争论，反而招来了更多追问。他这条推文也因此获得了超过 480 万次浏览，远远超过 Mitchell Hashimoto 那条“I read the code”。
其中一个提问是：如果真正保障质量的是那些约束，那么谁来保证约束本身是可靠的？
有开发者追问道，如果单元测试、质量指标和检查工具承担了主要工作，那么这些约束的质量，岂不是成了真正的工程难题？Uncle Bob 的回答是，他同样让智能体去编写检查约束的工具。这些工具是确定性的，规模相对较小，可以用来检查代码质量、测试覆盖率，或者对代码进行修改，再观察是否能暴露错误。
随即又来了一层追问：那你会审查这些检查工具的代码吗？
Uncle Bob 依然回答：“不会，还是同样的流程。”这些工具也会被大量单元测试和验收测试包围。对他来说，判断工具是否可信的依据仍然是它能否持续通过验证、稳定完成任务。
这听起来近乎无限递归：智能体写代码，智能体写测试，智能体再写工具检查测试与代码。Uncle Bob 的做法，是用变异测试、QA 流程、Gherkin 测试等方式，把测试体系做得非常严密。智能体需要修改的并不只是一项测试，而是一大批相互关联的测试，这会显著增加篡改测试来蒙混过关的难度。同时，他也会亲自检查 Gherkin 验收测试和 QA 流程，根据任务的关键程度进行全面审核或抽查，并定期做最终的人工测试。
有意思的是，他这套思路很快被其他开发者做成了可以直接使用的工具。开发者 AmazingAng 推出了一个名为 old-coder 的开源 Skill，核心理念直接取自 Uncle Bob：不要逐行阅读 Agent 生成的代码，而是让代码先闯过一整套验证关卡。
来源：https://github.com/AmazingAng/old-coder/tree/main
还有人问，测试或许可以保证产品功能符合预期，但代码本身的质量怎么办？既然如今修改代码已经如此便宜、容易，代码是否整洁、结构是否清晰，还像过去那样重要吗？
在这个问题上，Uncle Bob 认为“代码质量依然重要，而且重要得多”。混乱的代码不仅会拖慢人，也会拖慢 Agent。他见过 Agent 被自己制造的混乱结构困住，来回折腾却始终无法解决问题，最后仍然需要他亲自介入，把这些乱麻重新理顺。
因此，他会对函数长度、圈复杂度和测试覆盖率设置极其严格的限制，尽量从一开始就阻止智能体制造难以维护的结构。在他看来，这些约束能够让智能体持续顺畅地推进任务。
读代码是旧世界的习惯？！
互联网上的技术争论，很容易被简化成非黑即白的两派：读代码还是不读？立场越极端，声音越大，中间那些复杂的考量反而被淹没。围绕 AI 代码吵了这么久，背后其实是一个更根本的问题：你认为自己写的代码究竟有多重要？
如果把代码的重要性想象成一条光谱：一端是粗制滥造的个人项目，另一端是支撑关键基础设施、医疗设备等不能轻易出错的系统。后者每一行代码当然都很重要，毕竟一旦弄错，真可能造成严重后果。但大多数开发者生活在两端之间，既容易高估自己代码的重要性，也没有充分意识到，今天已经可以生成大量“不那么重要”的代码。
t3.gg 创始人 Theo 的观点是：对绝大多数工程师来说，目前阅读的代码比例很可能太高了，但生成的代码还远远不够多：我们应该从 AI 生成的代码中获得尽可能多的价值。
如果你真的在编写极其重要的代码，反而更应该生成大量一次性代码，去测试那些真正不能出错的部分。这个思路与 Uncle Bob 用约束和验证体系替代逐行理解的做法，本质上相通。
在那个写代码成本很高、所有合并代码都很重要的时代，我们必须花时间阅读其他人大量编写的代码。为了验证一行核心代码是否正确而写 1000 行测试代码，完全不划算。但现在，情况已经变了，代码便宜多了。让 AI 瞬间生成 1000 行测试代码，成本近乎为零。你可以为每一行生产环境的核心代码生成 100 行、1000 行、甚至 1 万行验证代码，用来做压力测试、做变异测试、做专门的运行时分析器。
定制 lint 规则？过去一辈子只写过一两条，现在随时生成。一次性调试工具？以前只会依赖浏览器自带的工具，现在可以构建专属的调试器和编译器 Hook。过去做压力测试需要协调人员和环境，现在可以让智能体直接启动云资源，反复探测系统极限。
当代码的生成成本下降后，“代码”便不只指最终合并进主干的产品代码。它还可以是一次性实验、临时脚本、边缘情况测试、替代实现，或者为了回答某个问题而存在几个小时的工具。
假设一名工程师每天仍然手写并逐行验证 80 行核心代码，这部分标准完全不必降低。但在此之外，他还可以让 AI 生成 800 行甚至 8000 行代码，用来验证那 80 行。这些代码不会进入产品，却能测试更多边缘情况，暴露隐藏问题，提升核心代码的可信度。
没有人会主张把心脏起搏器里的代码交给 AI 随意生成。但如果一套系统真的重要到不能出错，那么为它建立更庞大的验证体系，也应该同样值得。关键代码越重要，围绕它生成的测试、模拟和验证代码就应该越多。
可以把代码分成四个层级。最顶层是纯粹的垃圾代码，写出来只是为了整理文件或回答某个一次性问题，看一眼都觉得被冒犯；第二层是希望它能正常工作，出了问题会很烦；第三层是它最好别出问题，否则可能会被解雇；最底层是它一旦出错，可能有人死亡。
过去，手写代码的成本太高，以至于大家几乎把所有时间都花在最底层和第三层，根本没有余力去上面两层做探索。而现在，AI 让上面两层的代码变得几乎免费——你应该大量进入这些上层区域，用廉价的代码去验证昂贵的代码，而不是用“所有代码都很重要”这个理由把自己锁死在底层。
就是 Uncle Bob 那套“无限递归”测试策略的延伸：用大量廉价代码构建一个测试金字塔，在底部堆满垃圾，用这座塔去保护塔尖上那一小撮真正不能出错的东西。