在最近的一集《总统柯蒂斯》中，总统在两个不同场合试图开门时都遇到了困难。这些门无法打开，是因为存在障碍物：最初是一个人体，随后是价值约十亿美元的黄金。在这两种情况下，面对挫败感，角色都嘟囔着“愚蠢的东西真糟糕”。这并不是一个合理的门模型！门不应该莫名其妙地“糟糕”！我发现这些时刻极其荒谬地有趣¹，但也许我愚蠢的脑子只是很糟糕。

Jev：制造更多“糟糕”的互联网对Jev议论纷纷，Jev是由Type Safe AI开发的AI模型，它返回带有概率估计的类型化值。据我所知，Jev的重要之处在于：它快速且便宜，你可以快速在其上构建，它很快，而且很便宜。我并不特别擅长理解什么技术会被采用。我仍然不理解² Slack。等等。你仍然需要做那困难的部分吗？也许我的问题是期望产品能够正常工作。没有人购买这个是运行评估的。他们只是把不透明的问题交给Jev，并得到不透明的响应。

宽容地说，这让他们可以勾选“AI驱动”的框，并在周五之前发货，当这破坏了下游逻辑时，他们总是可以耸耸肩说“嗯，AI会犯错。”错误预算？失败模式？测试集？所有这些都可以稍后处理。用户可以自己发现失败率！你已经发货了！

虚假的自信“哦，”那个回应我帖子的稻草人说，“你没有考虑到Jev给你置信度分数的事实！”你要用这些做什么？要对置信度分数做出合理的处理，你需要既理解这些置信度分数的校准情况，同时也需要一个关于不确定性成本的模型。

在校准方面：Jev的顶部广告文案主要是关于他们在各种基准测试中表现如何良好，但没有关于他们的置信度分数校准得如何。有一本关于使用置信度分数来遍历分类树的食谱，但这根本上并不是关于置信度分数有多好。最好情况下，人们以一种 cargo cult 方式使用置信度分数。最坏情况下，人们用它们作为API调用失败的借口。模型只有73%的置信度！这意味着我的错误预算是27%！

问责制当一个网站上的按钮坏了时，我有一个关于应该发生什么的模型。某个地方的合同被破坏了。我的DNS坏了。有人发布了一些只在某些路径上带有Java Script语法错误的垃圾代码。一个处理器抛出了一个不被期望抛出的异常。我可能无法调试只是一个HTTP 500状态码，但我期望有某个人 whose job 是去理解为什么端点是500。所有权虽然不透明，但定义明确³。

然而，对许多用户来说，实际的体验大致只是“愚蠢的东西真糟糕。”软件已经显得反复无常；更多的失败只是改变了挫败感的频率。似乎移除将失败追溯到具体原因的可能性并没有多大损失。有时事情就是很糟糕。这导致了难以解释性的正常化。

我的担忧并不是当事物被LLM驱动的开发加速时会有更多东西会失败。它们会的。它们已经这样了。这是以新颖方式构建事物的代价的一部分。我的担忧是“有时它只是很糟糕”将越来越成为调查的接受终点。这是令人悲伤的，因为LLM加速的开发确实可以帮助我们解决其中一些问题。有许多自动QA工作流程因为缺乏工程时间而没有被编写。那个能让你大部分取代（甚至只是证明使用）Jev的评估可能只需几个提示词的距离。

当今软件工程的悲剧在于，我们正在积极构建一些系统，在这些系统中，用户和构建者似乎都没有兴趣去检查门后是否有一个身体。我们只是...