AI 加速开发正在让软件故障变得不可解释
一扇门打不开，可能是被身体挡住，也可能是被价值十亿美元的金条挡住——两者都不是“门很烂”。软件也是一样：当按钮失灵时，我们脑中本应有一个关于发生了什么事的模型，某处有契约被破坏，某个 handler 抛出了不该抛的异常，某个人的工作就是搞清楚为什么接口在报 500。
作者 patrickxia 担心的是，这套模型正在消失。LLM 加速开发带来更多故障并不可怕，那只是用新方式造东西的代价；可怕的是“这东西就是烂”越来越经常成为调查的终点。他称之为无法解释性的正常化，并认为它和责任的正常化紧密相连。
他拿来开刀的例子是 TypeSafe 的 Jev——一个不生成文本、直接返回带概率的类型安全决策的模型。置信度分数听起来很负责任，但要真正用它，你得先知道这些分数校准得如何，还得有一套关于不确定性代价的模型。现实是没人愿意做这部分：文档里随手给出 0.5 阈值表示什么都不做、0.9 表示执行高风险操作，旁边再补一句“正确阈值取决于你的场景”。结果要么是货架崇拜式的使用，要么是把置信度当成 API 失败的借口。而糟糕的不是 AI 会犯错，而是失败可以就这样被默认容忍。
HN 上的讨论提供了另一面：有人指出智能体写出的 bug 反而修得很快，很多自动化 QA 流程之所以没被写出来，本来就只是缺少工程时间，而这恰好是 LLM 能补上的部分。作者也承认这一点——真正的悲剧在于，我们正在工程化一些既没有用户、也没有建造者有兴趣去核实门后到底有没有人的系统。
对智能体经济来说，这个问题比模型准确率更根本：信任不只意味着答对，还意味着失败可以被追溯、被归属、被解释。