尽管存在重大风险，但生成式人工智能工具在编程方面的效率优势实在令人难以抗拒。这意味着我们需要一种全新的人工循环软件管理方法。
有明确证据表明，结合生成式人工智能的软件开发工作中出现的错误，与人类程序员常犯的错误截然不同。然而，目前大多数企业纠正人工智能编码错误的计划，仅仅是简单地把经验丰富的人类程序员拉进这个循环。这就好比一场线索明显的火车失事。（如果你不是亚当斯家族的粉丝，那就无需深究这个比喻啦。）
经验丰富的人类程序员能够直观地分辨出人类犯的错误和走的捷径。但他们需要接受培训，以便识别软件在由人工智能创建时出现的错误类型。
AWS 首席执行官马特?加尔曼表示，他预计最早在 2026 年，大多数开发人员将不再进行编码，这无疑加速了这场讨论。
开发工具领域的众多供应商认为，可以通过使用人工智能应用程序来管理人工智能编码应用程序，从而解决这个问题。但这可能引发第二次 “火车失事”。就连金融巨头摩根士丹利也在尝试利用人工智能来管理人工智能。
实际上，唯一安全且在一定程度上可行的方法是培训编程经理了解生成式人工智能编码错误的性质。考虑到人工智能编码错误的独特性，甚至培训新人来管理人工智能编码工作可能更好 —— 那些还未深陷于发现人类编码错误模式中的人。
部分问题源于人性。人们往往会放大和误解差异。如果经理看到一个实体 —— 无论是人类还是人工智能 —— 犯了自己绝不会犯的错误，他们就容易认为这个实体在编码方面不如自己。
以自动驾驶汽车为例。统计数据显示，这些车辆比人工驾驶的汽车安全得多，而且已经持续很多年了。自动化系统从不疲倦、从不醉酒、也从不故意鲁莽行事。
但自动驾驶汽车并非完美无缺。它们犯的那种错误 —— 比如全速撞上因交通堵塞而停下的卡车 —— 会让人类争辩说：“我绝不会干这么愚蠢的事。我不信任它们。”（Waymo 那起停放汽车的灾难视频绝对值得一看。）
仅仅因为自动驾驶汽车会犯奇怪的错误，并不意味着它们就比人类司机更不安全。然而，人性却难以调和这些差异。
编码管理的情况也是如此。生成式人工智能编码模型可以相当高效，但一旦出错，就会错得离谱。
SaaS 公司 QueryPal 的首席执行官德夫?纳格一直在从事生成式人工智能编码工作，他认为许多企业的 IT 高管对这项新技术毫无准备。
纳格说：“它会犯很多奇怪的错误，就像来自另一个星球的外星人。代码的表现方式与人类开发人员完全不同。这就像是一种外星智能，思考方式与我们不同，会朝着奇怪的方向发展。人工智能会以一种病态的方式玩弄系统。”
问问汤姆?陶利吧，他写了多本关于人工智能编程的书，包括今年出版的《人工智能辅助编程：更好的规划、编码、测试和部署》。
陶利说：“例如，你可以让这些大型语言模型（LLM）创建代码，它们有时会构建一个框架或想象中的库或模块，来完成你想要它做的事情。”（他解释说，大型语言模型实际上并没有创建一个新的框架，而只是假装在这么做。）
陶利指出，人类程序员甚至不会考虑这样做，“除非（人类编码器）疯了，否则他们不会虚构、凭空创造一个想象中的库或模块。”
当这种情况发生时，很容易被发现 —— 如果有人去寻找的话。“如果我尝试安装它，你会发现那里什么都没有。如果出现幻觉，集成开发环境（IDE）和编译器会给你一个错误提示。” 陶利说。
在我看来，把应用程序的完整编码（包括对可执行文件的创造性控制）交给一个经常产生幻觉的系统，这似乎是一种可怕的做法。
更好地利用生成式人工智能编码效率的方法是将其用作帮助程序员完成更多工作的工具。正如 AWS 的加尔曼所建议的那样，把人类从这个循环中剔除出去，那将是自杀行为。
如果一个生成式人工智能编码工具让自己的思维随意游走，并创建一些后门，以便它以后可以进行修复而不必打扰人类 —— 但攻击者也可能利用这些后门呢？
企业通常在测试应用程序（尤其是本土应用程序）的功能方面非常有效，以确保应用程序完成它应该做的事情。然而，应用程序测试往往在检查它是否会做任何不应该做的事情时出现问题。这就需要一种渗透测试的思维方式。
但在生成式人工智能编码的现实中，渗透测试方法必须成为默认方法。而且，它需要由在生成式人工智能错误的奇特世界中接受过良好教育的主管来进行管理。
企业 IT 当然在展望一个更高效的编码未来，程序员将承担更具战略性的角色，他们会更专注于应用程序应该做什么和为什么要这么做，而花在费力编写每一行代码上的时间会更少。
但这种效率和战略收益将付出沉重的代价：为那些接受过更好、不同训练的人支付费用，以确保人工智能生成的代码保持在正确的轨道上。
