“征服熵增”系列的一部分

我对AI生成代码的大多数问题都与信任有关。我信任编写这张工单的人吗？我信任打开这个PR的工程师理解了工单并正确指导编码代理实现它吗？我信任编码代理的实现吗？我信任我们的测试套件能在回归问题进入生产环境前捕获它们吗？我信任我们的CI/CD能正确构建、测试和部署我们的变更吗？我信任我们的可观测性设置能在AI生成的代码导致生产环境故障时提醒我们吗？我信任AI SRE（站点可靠性工程师）能正确诊断问题并帮助我们缓解它吗？我信任Git Hub不会在我们最需要它的时候发生事故吗？信任难以建立，易于失去。所以我认为在工程团队内培养信任文化至关重要。你必须信任工程师做正确的事。

鼓励问责制

我发现明确传达类似这样的信息很有帮助：“你对发布的内容负责。如果这破坏了生产环境且你编写了PR，你应该在场修复它。”

如果工程师对他们发布的代码负责，他们应该被赋予使用其首选方法生成代码的自主权。即使你不痴迷于AI，你也不得不承认AI代理确实能非常快地生成大量代码。代码仍然需要生成，而现在的预期是生成大量代码变得很廉价。为了应对这一点，工程师必须被允许采取一些措施来确保代码库的质量不会下降。在健康的组织中，工程师应该互相信任，只推送质量合理的代码。我说合理是因为痴迷于质量并试图总是发布100%完美的代码是不务实的。即使在编码代理出现之前，大多数代码已经是一团漏洞百出的烂摊子！所以当交付“足够好”的解决方案时是可以理解的。通常，我们用交付速度换取质量，并承担一些技术债。

以下是我发现在这个编码新时代促进工程问责制的一些有用实践：

编码指南

制定清晰的技术策略：花些时间决定什么对你的代码库很重要，并投资于清晰的指南。既为人类也为编码代理。即使人类不读指南，他们的编码代理会读，并会（大多）遵循它们。

确定性工具

大量使用确定性工具来确保代码质量。类型化语言、linter、死代码检测、安全扫描、CI/CD等。所有这些工具在编码代理出现之前就已存在，并帮助我们对抗垃圾代码。（敬请期待后续文章的具体推荐！）

强制小PR

授权工程师拒绝不可审查的PR。如果可能，将此标准编码化，以便任何不可审查的PR被立即拒绝。当然，要为例外情况留出空间。

掌握测试

手写测试用例。这类似于业务分析师的工作。深入思考功能并定义适当的测试场景。在团队内讨论这一点。编码代理可以实现测试，但测试应由人类定义。

产品品味

与产品团队协同工作，拥有连贯的产品愿景。用AI疯狂实现脑海中出现的任何功能非常容易。确保你只实现真正为用户带来价值的有用功能！

原型

一次性代码。既然代码现在很容易生成，这是尝试不同方法的好机会。不要只让编码代理生成一种解决方案。例如，尝试三种截然不同的方法，并选择最适合问题和现有系统的一种。

关注结果

对结果保持务实。有时代码不是结果。结果是一份报告，或一个帮助你完成其他事情的工具。对于这种情况，只要结果有用，代码质量就不那么重要。