信任 AI 处理您的代码？先阅读这个

我听到同样的问题在董事会和工程团队中被低声讨论。代码生成工具真的可以被信任吗？

当然，演示视频看起来很有希望。哪个团队不想在短短几分钟内生产出一个全栈应用程序呢？但问题依然存在，这一切会不会好得令人难以置信？

我经常提醒人们，如果某事看起来好得令人难以置信，那通常就是如此。这种情况也不例外。尽管如此，这些工具的好处是真实的，而且在许多情况下，它们带来的益处比你预期的还要大。

理论上的情况

代码生成工具已经以惊人的方式改变了工程师的工作方式。

麦肯锡报告指出，开发人员使用这些工具完成任务的速度最多可提高一倍。Stack Overflow的一项独立调查发现，开发人员在使用人工智能辅助时，效率提高了三分之一。

这些工具还降低了非技术贡献者的门槛。作为一名连接技术和业务的领导者，我对同事们在不编写一行代码的情况下所构建的成果印象深刻。

我团队中的一位产品经理自己创建了一个可用的原型，而不需要依赖我们已经很忙的工程师。在董事会会议上，我也注意到那些早期采用这些工具的公司对创新有了新的认识。

投资者通常将此视为前瞻性进步的信号。

实践中的情况

然而，当涉及到这些工具实际生成的代码时，结果参差不齐。

是的，代码是可以运行的。但质量从混乱到不稳定不等。

仅用这些工具构建的原型虽然运行良好，但不应被误认为是可用于生产环境的系统。

没有明确规范或强大审查实践的团队容易产生薄弱、不可靠的代码。没有纪律性，问题会成倍增加而不是得到解决。

何时可以信任代码生成

我确实相信这些工具是可以信任的，我鼓励团队使用它们。但重要的是要有适当的条件来确保它们成功。

技术娴熟的工程师可以使用它们来加速工作，前提是规范明确，提示经过深思熟虑，并且审查彻底。在这些情况下，我发现这些工具始终能节省时间而不损害质量。

信任的源泉在于周围的系统。

执行明确流程和问责制的领导者为这些工具增加价值创造了条件。

领导者需要解决的风险

风险是巨大的，值得认真关注。如果这些工具被用作真正工程的替代品，而不是技能的增强，代码质量将会受损。

问题可能一开始是隐藏的，但一旦系统承受真实压力，它们就会显现出来。

延迟峰值、微妙的逻辑错误和操作失败通常会在后期出现，此时修复它们的成本更高。

安全漏洞是另一个主要关注点。斯坦福大学的研究表明，人工智能编码工具经常生成不安全的代码。代码可以运行，但它悄悄地暴露了使业务面临风险的弱点。

还有技能侵蚀的风险。过度依赖人工智能会削弱开发人员的判断力。

当工程师停止对代码本身进行批判性思考时，组织会随着时间的推移失去深度和弹性。

脆弱性还是加速

有了正确的结构和问责制，代码生成可以加速交付。没有这些护栏，它只会扩大脆弱性。

区别在于领导纪律，而不是工具本身。人工智能代码生成工具将继续进步。

它们将生成更干净的代码，更深入地集成到开发环境中，并减少基本错误。但即使是这些改进也不会取代对结构的需求。

获胜的组织将是那些将工具视为现有实践加速器的组织。