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

我在上一篇文章的总结中说，假设我们不再需要担心阅读和调试我们的代码，这是不负责任的——假设法学硕士出现的任何问题都能够为我们解决。这让人感觉不负责任，因为到目前为止，理解和维护源代码一直是程序员的工作，作为理解和维护软件系统的代理。我们对法学硕士的产出负责。但如果情况不再如此呢？如果我们尽职尽责地向我们的组织领导层传达风险和权衡，而他们仍然想承担这些风险，该怎么办？这并非闻所未闻：公司，尤其是科技初创公司，经常做出短期妥协，以提高生产力、击败市场竞争、吸引投资者等。如果有组织要求利用法学硕士来最大限度地减少编码时间，那么这就是我们可以应对的新限制。我们可以弄清楚在这种情况下优秀的工程是什么样子的。我们可以停止阅读 LLM 生成的代码，就像我们不阅读汇编、字节码或转译的 JavaScript 一样；我们的高级语言源现在将是另一种形式的机器代码。在阅读 Thoughtworks 的静修报告后，我终于明白了这一点。法学硕士产生不确定性的输出并生成代码的速度比我们阅读它的速度快得多，因此我们不能再认真地期望有效地审查、理解和批准每个差异。但这并不一定意味着我们不再严谨，这可能意味着我们应该将严谨转移到其他地方。不过，重要的是要明白，这不是个人或团队的决定：它必须是组织的决定，不仅仅是因为风险管理和责任，而是因为阿姆达尔定律。如果我们只是最大限度地提高代码生成速度而不重新安排我们工作所嵌入的组织结构和流程，那么就不会有任何切实的生产力提升。我们不能让一些开发人员每天抽取 20,000 行代码，然后期望其他人仍然阅读和理解它，更不用说批准它了。如果我们的工作单元仍然是“向 RESTful API 添加新端点”，我们就无法利用代理。如果每个工程师一次可以承担四项任务并让代理在下班时间运行，我们就不能指望产品负责人能够分流足够的工作来让两个披萨团队保持忙碌。相反，我们需要消除人为因素，减少协调、摩擦、官僚主义和把关。我们需要几乎无限的需求供应，工程师充当伪产品设计师，拥有整个工作流，并有权做出自主决策。返工几乎是免费的，因此我们不应该努力防止错误工作的发生。那么严谨到哪里去了呢？与 Thoughtworks 报告类似，我的第一个赌注是规范（与提示不同）和测试（与 TDD 不同）。如果我今天必须推出这样的开发流程，我会将标准化的 Markdown 规范作为软件项目的新知识单元。产品所有者和工程师最初可以就该规范和测试用例进行协作，以执行业务规则。这些应该与实现代码一起签入项目存储库。需要进行自动拉请求检查，不仅验证测试是否通过，而且验证代码是否符合规范。团队需要理解、审查和负责的是这个规范，而不是具体化它的代码。 ← 世界地图和领土 BATLEXP G350 设置说明 → Facundo Olano 如果我们尽职尽责地将风险和权衡传达给我们的组织领导层，而他们仍然想要承担这些风险，该怎么办