- -危险地跳过阅读代码 – olano.dev

# --dangerously-skip-reading-code 来源：https://olano.dev/blog/dangerously-skip/ 我在上一篇文章（https://olano.dev/blog/tactical-tornado）的结尾指出，假设我们不再需要担心阅读和调试代码——假设任何出现的问题 LLM 都能帮我们修复——是不负责任的。之所以感觉不负责任，是因为到目前为止，程序员一直承担着理解和维护源代码的责任，以此作为理解和维护软件系统的代理。我们需要为 LLM 的输出负责。 但是，如果情况不再是这样了呢？假如我们尽职尽责地向组织管理层传达了风险和权衡，而他们仍然愿意承担这些风险？这并非闻所未闻：公司，尤其是科技初创公司，经常会做出短期的妥协来提升生产力、在市场竞争中胜出、吸引投资者等等。 如果组织要求利用 LLM 来最小化编码时间，那么这就是我们可以与之合作的新约束。我们可以找出在这种背景下优质工程是什么样的。我们可以停止阅读 LLM 生成的代码，就像我们不阅读汇编、字节码或转译后的 JavaScript 一样；我们的高级语言源码现在变成了另一种形式的机器代码。 在阅读 Thoughtworks 的复盘报告（https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf）后，我恍然大悟。LLM 产生非确定性的输出，并且生成代码的速度远超我们阅读代码的速度，因此我们再也无法认真指望能够有效审查、理解和批准每一个 diff。但这并不一定意味着我们不再严谨，而可能意味着我们应该将严谨性转移到别处。 不过，必须理解的是，这并非个人或团队的决定：它必须是组织层面的决策，不仅因为风险管理和问责制，还因为阿姆达尔定律。如果我们只是一味提高代码生成速度，而不重新调整我们工作所嵌入的组织结构和流程，就不会有实际的生产力提升。 我们不能让一些开发人员每天输出 2 万行粗糙代码，而期望其他人仍然去阅读和理解它们，更不用说批准了。如果我们的工作单元仍然是“给 RESTful API 添加一个新端点”，我们就无法利用 agent。如果每位工程师能同时承担四个任务并且让 agent 在非工作时间持续运行，那我们也无法指望产品负责人能提供足够的工作流来让一个“两个披萨团队”保持忙碌。 相反，我们需要消除人在回路，减少协调、摩擦、官僚主义和关卡。我们需要几乎无限的需求供给，工程师充当伪产品设计师，拥有整个工作流的自主权，并能做出自主决策。返工几乎免费，所以我们不应该努力阻止出现有缺陷的工作。 那么严谨性去哪里了？和 Thoughtworks 的报告类似，我的首选会是规范（specifications，与提示词不是一回事）和测试（与 TDD 不是一回事）。如果我今天要推行这样的开发流程，我会把标准化的 Markdown 规范作为软件项目的新知识单元。产品负责人和工程师可以首先协作编写这个规范以及强制执行业务规则的测试用例。这些内容应该与实现代码一起检入项目仓库。还需要有自动化的拉取请求检查，不仅要验证测试是否通过，还要验证代码是否符合规范。这个规范——而非实现它的代码——才是团队需要理解、审查并负责的。