培养信任

“征服熵”的一部分 我对人工智能生成的代码遇到的大多数问题都与信任有关。我信任写这张票的人吗？我是否相信打开此 PR 的工程师理解该票证并指导编码代理正确实施它？我信任编码代理的实现吗？我是否相信我们的测试套件能够在投入生产之前捕获回归？我是否相信我们的 CI/CD 能够正确构建、测试和部署我们的变更？我是否相信我们的可观察性设置会在人工智能生成的代码中断生产时提醒我们？我是否相信 AI SRE（站点可靠性工程师）能够正确诊断问题并帮助我们缓解问题？我是否相信 GitHub 在我们最需要的时候不会发生事故？信任很难获得，但失去却很容易。因此，我认为在工程团队中培养信任文化至关重要。您必须相信工程师会做正确的事情。鼓励问责制 我发现清晰地传达这样的信息很有帮助：“你要对你发布的内容负责。如果这破坏了生产，而你编写了 PR，你应该在那里修复它。”如果工程师要对他们发布的代码负责，那么他们应该有权使用他们喜欢的方法来生成代码。即使你没有人工智能，你也必须承认人工智能代理确实会非常快地生成大量代码。代码仍然需要生成，并且期望现在生成大量代码的成本很低。为了解决这个问题，必须允许工程师采取一些措施来确保代码库的质量不会下降。在一个健康的组织中，工程师应该互相信任，只推送质量合理的代码。我说合理是因为过分追求质量并试图始终交付 100% 完美的代码是不务实的。甚至在编码代理之前，大多数代码就已经是一团乱七八糟的错误了！因此，当交付“足够好”的解决方案时，这是可以理解的。通常，我们会以交付速度换取质量，并承担一些技术债务。以下是我发现的一些有助于在这个编码新时代促进工程责任的实践： 编码指南 制定明确的技术策略：花一些时间来决定什么对您的代码库重要，并投资于明确的指南。对于人类和编码剂来说都是如此。即使人类不阅读这些指南，他们的编码代理也会（大部分）遵循这些指南。大量使用确定性工具来确保代码质量。类型化语言、linter、死代码检测、安全扫描、CI/CD 等。所有这些工具在编码代理之前就已存在，并帮助我们对抗溢出。 （请继续关注包含具体建议的后续帖子！） 实施小型 PR 使工程师能够拒绝未经审查的 PR。如果可能，请将此标准编入法典，以便立即拒绝任何未经审查的 PR。当然，请确保为例外情况留出空间。拥有测试 手动编写测试用例。这类似于业务分析师的工作。深入思考该功能并定义适当的测试场景。在团队内讨论这个问题。编码代理可以实现测试，但它们应该由人类定义。产品品味与产品协同工作，以获得一致的产品愿景。人们很容易对人工智能着迷并实现任何想到的功能。确保您只实现真正为用户带来价值的有用功能！原型一次性代码。由于现在代码很容易生成，因此这是尝试不同方法的好机会。不要只让编码代理生成一种解决方案。例如，尝试三种完全不同的方法，然后选择最适合问题和现有系统的一种。关注结果 对结果持务实态度。有时代码并不是结果。结果是一份报告，或者是一个可以帮助您完成其他任务的工具。对于这种情况，只要结果有用，代码的质量就不那么重要了。