危险地跳过阅读代码：AI Agent 时代严谨性的转移
危险地跳过阅读代码：AI Agent 时代严谨性的转移
软件工程师的传统角色长期以来一直以阅读、理解和维护源代码的能力为中心。在这种范式下，代码是理解软件系统的主要代理。然而，随着大语言模型 (LLMs) 和自主 Agent 开始以远超人类阅读能力的速率和规模生成代码，这一模型正面临崩溃点。
当一个 Agent 可以在几分钟内产出数千行代码时，传统的 pull request (PR) 审查过程就成了瓶颈。如果我们坚持审查每一行生成的代码，就会抵消 AI 带来的生产力提升。这引出了一个挑衅性的问题：如果我们完全停止阅读代码会怎样？
代码即机器码假说
有一种日益增长的观点认为，我们应该将 LLM 生成的代码视为一种“机器码”，而不是人类可读的源码——类似于开发者对待汇编、字节码或转译后的 JavaScript 的方式。在这种观点下，高级语言 (Python, TypeScript, Rust) 不再是人类意图的主要载体；它仅仅是 AI 产生的实现细节。
为了使这一模式奏效，行业需要重新定义“严谨性”。工程师不再需要验证“如何实现” (the how, 即代码)，而应专注于“实现什么” (the what, 即规范) 以及“结果” (the result, 即测试)。
转移知识单元
为了实现这一转变，项目的“知识单元”将从源代码转移到标准化的规范 (specification)——可能以 Markdown 编写。在这种提议的工作流中：
- 协作式规范： 产品负责人和工程师协作编写详细的 Markdown 规范，并制定一套执行业务规则的测试用例。
- 自动化实现： AI Agent 根据规范实现代码。
- 验证： 自动化检查确保测试通过且代码符合规范。
- 问责制： 团队对规范和测试套件负责，而不是对生成的代码负责。
组织层面的指令
这种转变不能由单个开发者或团队做出决定；它必须是一项组织层面的指令。根据 Amdahl's Law，如果不重新调整组织结构，仅靠最大化代码生成速度是无法获得实质性生产力提升的。
如果工作单元仍然是“为 API 添加一个新端点”，那么协调和官僚主义带来的摩擦力仍将限制吞吐量。为了真正利用 Agent，组织需要：
- 在处理琐碎实现时移除“人在回路” (humans-in-the-loop)。
- 将工程师转型为“伪产品设计师”，让他们负责整个工作流。
- 接受“重做几乎是免费的”这一事实，从而减少为防止每一行错误的逻辑代码被写出来而花费的精力。
关键的反驳点与风险
虽然极速开发的愿景很诱人，但社区对这种方法的长期可行性提出了重大质疑。
“认知债务”陷阱
一个主要的担忧是认知债务的积累。如果开发者停止阅读代码，他们就会失去调试复杂、系统性故障的能力。正如一位评论者所言，如果 LLM 犯了一个根本性的架构错误——例如为了短期便利而将数据库去规范化 (denormalizing)——系统可能会通过所有测试并符合规范，但由于没有人理解底层结构，导致系统在后期无法演进。
规范悖论
软件工程中有一个反复出现的论点：“足够精确的规范即是代码”。如果一份规范必须详细到足以确保 LLM 不会产生幻觉或偏移，那么编写该规范所需的精力可能等于甚至超过编写代码本身的精力。在这种情况下，这种转变并不是生产力的提升，而仅仅是向一种新的、更冗长的编程语言的迁移。
“品味”的丧失
有人认为，代码审查不仅仅是为了发现 Bug，更是为了应用“品味”——确保代码是可维护的、优雅的且符合架构模式的。通过将代码视为构建产物 (build artifact)，我们面临着创造出功能正确但结构混乱的系统的风险，从而导致一个“充满了无法修复的未知 Bug 的代码库”的未来。
实践落地
尽管存在风险，一些开发者已经开始采用“计划优先” (Plan-First) 的工作流来缓解这些问题：
"始终让 Agent 创建一个计划文件 (spec)... 让 Agent 在计划文件上进行迭代，直到它完整且详尽... 一旦计划确定，再让 Agent 实现它。在实现提交 (impl commit) 时同时提交该计划。计划才是真正的知识单元，因为它编码了意图。"
其他人建议在规范中使用 RFC 关键字 (MUST, SHOULD, MAY) 来为 LLM 提供更清晰的约束，从而有效地将规范转变为正式的合同。
结论
将代码视为一次性产物是一种高风险、高回报的策略。虽然它为实现前所未有的开发速度提供了路径，但它威胁到了系统理解的基础。现代工程师面临的挑战在于，确定“高效速度”与““不负责任的疏忽”之间的界限在哪里，以及规范的严谨性是否真的能够取代深入研究源代码的严谨性。