AI 解决不了 Work Theater
解读 think-twice 文：大公司失败很少是因为慢 20%，而是做错方向；agent 加速 0→1，却让「看起来很忙」的工单与 diff 更容易膨胀。
AI doesn’t solve Work Theater 把话说死了：大公司里「对客户交付真东西」常常只占工作的一小截，剩下被能写进 Jira、能在评审里听起来很重大、却不改变结果的项目填满。AI coding agent 擅长把已知方案更快变成 diff，却几乎不帮你决定该不该建这个方案。
慢从来不是主因
作者回顾大型失败时的判断：几乎没见过「方向对、只是慢了 20%」这种死因；常见的是盯错东西，而且员工、客户、论坛早就在喊。Work theater 的经典谎言是「别再问问题，埋头干」。在已有 PMF、路径清楚时有用；在还不知道建什么时，正确动作是减速、多问、拉开信息面。
Agent 把 0→1 变快，也把「运动量」变便宜：更多 ticket、更多 PR、更多看起来像进展的提交。季度末你仍可能在原地打转，只是仪表盘更热闹。这和「模型不够强」是两类问题。
管理层层数与 agent 的副作用
文中引用「Recursive Middle Manager Hell」：层级一多，浪费主要来自对齐与表演，而不是写代码的绝对速度。预测很直：超过约四层管理（含高管）的组织，agentic 工作可能只带来很小甚至负向收益：最会刷存在感的人，现在能以更低成本制造拖累全员的技术债。三层及以下的小团队，反而更可能吃到加速：更少人完成更多集成与基础能力。
对个人贡献者的落地不是「别用 AI」，而是把验收钉在用户可感知结果上：合并率、线上指标、支持工单，而不是生成行数。站内谈 agent 边界失效的另一面，见 Agent 工具边界为何失效；谈持续重构而非堆 commit，见 持续重构与 coding agent。