DHH 质疑逐行审 AI 代码,责任链却没有一起自动化

AI 写代码的速度已经快到足以改变分工。软件团队还没有把验证、上线和事故责任交给同一套自动流程。

DHH 质疑把“人类必须逐行审查 AI 代码”当成固定规则。他的判断很激进：AI 不该只被当成普通工具，代码也不必由人类逐行过目。

回复很快把问题拉回工程现场。有程序员承认 AI 读写代码更快，却坚持自己要审查、测试并理解每一行。另一位开发者说，AI 让他入职第一天就能参与遗留项目，传统的漫长熟悉期正在缩短。

逐行审查当然可能变成低效动作。对重复代码、机械重构和边界清楚的小改动，工程师把时间耗在逐字阅读上，未必能换来同等收益。

真正危险的是，团队把“少看几行”误写成“少承担一层责任”。代码进入仓库前，仍要有人确认它改了什么；测试通过后，仍要有人判断测试覆盖了什么；准备上线时，仍要有人知道出错会影响谁。

少一次人工阅读，可以是流程优化。少一个能解释、能回滚、能负责的人，才是事故的起点。

37signals 在一档 2026 年播客中谈到自己的经验。AI 生成的代码可能能运行，却会损伤性能、破坏架构或留下安全问题。团队后来要求 Ruby 和 JavaScript 的改动由他人检查。

这条经验说明，审查并不只是在代码里找拼写错误。审查者要把新改动放回旧架构，判断数据边界，检查异常路径，还要知道哪些测试根本没有覆盖。

模型可以读完一个仓库，不等于它承担了这个仓库的历史。它可以生成一段看似完整的实现，不等于它知道哪种失败会在凌晨三点变成线上事故。

低风险改动可以减少逐行阅读，把检查集中到类型检查、自动化测试、差异审查和小范围发布。高风险改动则需要更强的人工介入。权限、支付、数据迁移、核心业务规则，都不能只用“测试通过”四个字收尾。

这不是给所有开发者加一道形式主义门槛。它要求团队先标出风险，再决定谁审、审什么、如何回滚。把所有代码一律逐行看一遍，和把所有代码一律交给模型，都是懒惰的流程。

DHH 把旧规则推到了墙上。墙后面的问题更具体：当代码生产变得廉价，理解系统、验证结果和承担后果，谁还被写进流程里？