Mitchell Hashimoto 在 5 月 16 日的一条 X 帖文里用了一个很重的词：一些公司正处在严重的“AI psychosis”里。

他的意思不是 AI 编程工具没用。更准确地说，他担心一些软件组织开始相信：bug 可以被 agent 用人类做不到的速度和规模修掉，所以前面的设计、测试和理解可以放松一点。

这个判断有意思的地方在于，它不是在讨论“AI 会不会写代码”。它问的是另一个问题：如果一个团队把“修得快”当成质量本身，系统会不会变得更脆？

Hashimoto 没有点名具体公司或个人，也没有给出行业调查数据。所以这件事不能写成“行业已经大规模失控”。目前能看到的，是一名基础设施老兵对工程组织心态的提醒。

Hashimoto 真正反对的，是把 MTTR 当免死金牌

Hashimoto 是 HashiCorp 联合创始人，长期参与基础设施自动化工具建设。Terraform、Vault 这类产品，正是云基础设施自动化浪潮里的代表性工具。

也因为这个背景，他把 AI agent 开发热和一个老问题放在一起看：MTBF 与 MTTR。

MTBF 关注“怎么少出故障”。MTTR 关注“出了故障怎么快点恢复”。

云基础设施普及后，工程团队早就接受一个现实：复杂系统不可能完全不坏。监控、回滚、自动扩容、故障迁移，都是现代系统能力的一部分。

问题在于，MTTR 有时会被误读。

合理的说法是：系统难免出错，所以要能快速恢复。危险的说法是：反正恢复很快，所以前面可以坏得随意一点。

Hashimoto 担心 AI agent 放大了后一种心态。团队可能会觉得，带着 bug 发版没那么可怕，因为 agent 能很快补测试、修代码、提交 patch。

这就把“恢复能力”偷换成了“质量豁免”。

路线原本价值被误用后的风险
MTBF：减少故障强调设计、测试、边界控制可能过度保守，拖慢迭代
MTTR：快速恢复强调监控、回滚、自动化修复可能纵容脆弱架构
AI agent 修复提升局部定位和改代码效率可能掩盖系统理解下降

这张表的重点不是说 MTTR 没价值。相反，MTTR 很重要。

但它不能单独当作质量指标。一个系统修得快，不等于它设计得对；一个团队关单很快，也不等于它还理解自己的代码。

云时代的旧教训：自动化越强，误伤也可能越快

基础设施团队对这件事应该不陌生。

自动化让系统更可靠，也让错误更容易规模化。一个错误配置可以被自动部署到多个区域。一个脚本缺陷可以在几分钟内影响大量实例。一个流水线规则写错，可能比人工操作更快扩大事故半径。

所以云时代的经验并不是“自动化越多越安全”。更准确的经验是：自动化必须和边界、审计、回滚、权限一起设计。

AI agent 进入开发流程后，同样如此。

它可以改一个函数，补一段测试，解释一个报错，甚至跨文件生成修改。但很多软件风险不在局部 diff 里，而在全局关系里。

比如支付状态、权限边界、数据迁移、缓存一致性、向后兼容、跨服务契约。这些东西不一定马上变成 bug 报告。它们更像暗线，等需求叠加到一定程度才爆出来。

这也是 Hashimoto 提醒里最有价值的一层：测试覆盖率上升、bug 报告下降、平均修复时间变短，都只能说明局部指标变好。它们不能自动证明系统整体安全。

原因很简单。

测试覆盖率可能覆盖了浅层路径。bug 报告下降，可能是问题还没暴露，也可能是用户路径变少。修复时间变短，可能是 agent 对局部问题很强，也可能是团队把问题拆得越来越碎，没人再看系统整体。

指标有用，但指标不等于理解。

最该调整动作的，是管理者和平台团队

这场讨论最该影响两类人：软件工程管理者，以及基础设施/平台工程团队。

他们不只是“用不用 AI 工具”的决策者。他们还在决定：哪些代码能让 agent 改，哪些变更能自动合并，哪些指标能进入团队考核。

如果团队正在采购或扩展 AI 编程工具，比较现实的做法不是立刻停掉，而是延后把它接进关键路径的速度。先把边界画清楚，再扩大自动化范围。

比如可以这样分层：

场景可以更积极使用 agent需要人工兜底的部分
单元测试、文档、样板代码让 agent 提效，降低重复劳动检查测试是否覆盖真实业务路径
普通 bug 修复允许 agent 给 patch 和解释人要确认根因，不只看 diff 是否通过
权限、支付、数据迁移、核心链路可让 agent 辅助分析不能自动合并，必须有人负责语义判断
平台脚本、部署配置、基础设施变更可用于生成草案和审查建议必须保留回滚、审批、影响面评估

这对管理者的影响很具体。

不要只给团队设“修得更快”的目标。还要问四个问题：谁理解这次变更的业务含义；谁能解释它影响哪些系统；出问题怎么回滚；类似问题为什么会出现。

对平台团队也一样。

如果 GitHub Copilot、Cursor、Devin 这类工具已经进入开发流程，平台团队要做的不是简单放开或封死。更现实的动作，是建立分级规则：低风险改动可以快，高风险改动必须慢。

这听起来不性感，但很工程。

接下来真正该观察的，也不是哪家公司宣布 agent 写了多少代码。那类数字容易好看，也容易误导。

更该看三类信号：

  • 重大故障是否和自动生成改动、自动合并流程有关；
  • 代码评审是否从“理解逻辑”退化成“看看 diff 和测试绿不绿”；
  • 平台团队是否还能解释核心系统为什么这样设计，而不是只会说“现在跑得没问题”。

如果这些问题答不上来，MTTR 再短也只是救火更快。火为什么总烧起来，还是没人负责。

Hashimoto 这条帖子的价值，就在这个提醒上。

AI agent 会继续进入软件开发，这是大方向。但工程组织不能把它当成质量外包。工具能帮人写代码，不能替团队理解系统。

回到开头那个词，“AI psychosis”刺耳，但它指向的不是 AI 本身。它指向的是一种熟悉的懒惰：把速度当判断，把指标当理解，把修复当韧性。