和往常一样，这里表达的观点完全是我自己的。在这篇文章中，我并不是在倡导采用自主工程。我假设你选择尝试它，或者有人为你做出了决定。Matt Levine 经常写到加密货币如何从第一原理重新发现现代金融。在类似的语境中，当人们对改善自主工程的方法感到兴奋时，我不禁想，他们只是在谈论我们作为软件工程师本应已经具备的做法。我们通常因为时间压力而省略的那种工作。一个经典的例子是使用问题跟踪器来组织变更的细节并描述需求，以便你可以将工作交给一个代理。这样代理可以在问题上评论提问，并在他们工作时更新状态。这只是正常的软件工程。一些更多的例子：方法上的文档字符串。描述性的拉取请求。保持文档更新，甚至一开始就编写文档。编写有意义的测试，或者仅仅拥有测试。自动化的代码检查以确保一致性，或者仅仅是拥有一致的代码约定。在实施之前进行规划、架构和获得设计反馈。记录会议的笔记，并确认每个人对决定达成一致。与其仅发送私信，不如在开放且可搜索的频道中进行对话。再次强调，这些都是正常的软件工程实践。我很高兴看到人们现在对此感到兴奋。只不过我感到沮丧的是，变革需要自主工程的推动。为什么我们对机器人持有更高的标准而不是对自己？一位同事最近说：我审查了一份拉取请求，注意到在指导原则上缺少一些背景。我现在正在对文档进行修改，将这些原则编码，以便其他工程师的代理将来能尊重它们。在这种情况下，我们以前可以更新文档，但实际上不会有什么太大效果。这需要与整个团队进行对话，以确保他们将其记住。现在，有了适当的文档结构，所有工程师的代理都会阅读并遵守文档。软件工程师自古以来就一直在自动化他们的工作。我并不反对我们在 CI 中进行代码格式检查。如果我要划定一个何时自动化的界限，我会参考 James C. Scott 在《从国家的角度看》中的 mētis：“mētis 更好地理解为那种只能通过在类似但很少完全相同的任务中长时间实践而获得的知识，这需要不断适应不断变化的情况……知道如何以及何时在具体情境中应用经验法则是 mētis 的本质。” mētis 总是与特定情境相关。代码语法是一种描述良好的人工构造。其他工程原则是自由形式，因此更难以规定并使其清晰。书面形式的这些规则在处理特定问题的细微差别时始终会变得不那么灵活。书面规则并不是一种判断。可以肯定的是，一个固定的可读系统总比没有强大。记住，编程总的来说很糟糕。一位在努力应用人工智能工具的公司的朋友告诉我，他不得不丢弃一堆代理输出：我不得不做一个小重构，因为我的团队决定在没有沟通的情况下，在我的一个依赖项上，对其中一个进行改动，在冲刺中。如果“自主工程仅仅是带有机器人的正常工程”，那么我也有一个推论：任何使工程变得更困难的事情都使自主工程变得更加困难。代理没有像人那样导航情境的 mētis。如果你在自主工程上遇到困难，请停下来思考一下，正常的软件工程是否也对你的公司很困难。将人工智能应用于一个功能失调的系统，无论是人还是软件，都无法解决你的问题。自 1975 年以来，我们就知道在延迟的项目上增加更多的人只会使它们更加延误。增加一个虚假的人没有更好。以及反复犯同样的错误。