AI 编程工具把代码写快以后，很多团队才发现，真正拖慢项目的不是 IDE，也不是框架，而是“到底该做什么”。
吴恩达在 The Batch 里讲的这个判断，表面看是在说工程师和产品经理的关系，往深了看，其实是在说软件团队的瓶颈迁移：当实现成本快速下降，产品判断、跨部门协同、发布节奏和风险把关，会一下子变得更贵。
代码不再最慢，慢部门就会暴露出来
过去一个功能从想法到上线，写代码常常是最长的环节。需求评审、设计讨论、开发排期、联调测试，一圈下来，工程产能天然像一道闸门。
coding agent 把这道闸门抬高以后，流水线上的其他工位就露出来了。工程师一天做出功能，市场还没想好怎么讲；代码已经跑通，法务还要一周审合规；原型能快速成型，但没人判断它到底是不是用户要的。
这不是“工程师赢了，PM 输了”。这是整个团队的节奏被重新定价。
8:1 的老配比，会被速度打穿
传统软件团队里，八个工程师配一个产品经理并不少见。这个结构成立，是因为工程实现本来就慢。PM 有时间想清楚需求，工程师排队实现。
现在问题变了：如果一个工程师用 coding agent 把实现速度提上来，PM 还按原来的节奏产出判断，队伍很快就会卡住。
于是很多团队会走向更紧的配比，甚至要求工程师自己理解用户、自己判断需求、自己完成第一版验证。Claude Code 团队里那种“工程师看到用户反馈，周末自己上线功能”的模式，背后就是这个逻辑。
产品经理不会消失，但“只转述需求”的 PM 会变弱
这件事最容易被误读成：AI 让 PM 没用了。
不对。真正变弱的是那种只收集需求、整理文档、传话排期的中间层。因为当实现速度足够快，单纯的转述会变成摩擦。
反过来，真正值钱的产品能力会更值钱：判断什么值得做，识别用户的真实压力，把功能切到足够小，决定什么不做，知道一个功能上线前需要文案、法务、运营、数据怎样配合。
代码变便宜以后，决定写什么反而更贵。这句话不新鲜，但现在开始落到组织结构上了。
小团队的优势，是端到端的人
吴恩达提到 2 到 10 人的小团队会更常见，这背后不是迷信小团队，而是小团队更容易让一个人跨越多个环节。
一个懂一点产品的工程师，不一定比专业 PM 更会做用户研究，但他能把用户反馈、技术边界和实现路径放在同一个脑子里判断。一个懂一点工程的 PM，也不一定会写完整系统，但他能更快判断需求成本和取舍。
AI 时代的通才，不是样样精通，而是能跨到相邻领域，别让交接本身变成损耗。
面对面不是信仰，低延迟才是重点
吴恩达还强调线下面对面的速度。这个判断有争议，但它真正指向的不是“必须回办公室”，而是低延迟决策。
当一个功能可以一天成型，等半天消息、等一周会议、等三轮确认，就会显得特别慢。远程也能快，但需要更清楚的协作协议：谁能拍板，哪些问题异步解决，哪些问题必须马上语音，什么状态可以直接发布。
组织速度不是靠喊口号提上去的。它靠的是决策权、反馈链路和发布机制。
下一个竞争点，是把慢环节重新设计一遍
AI 编程不是只改变工程部门。它会逼着市场、法务、设计、运营、数据分析一起改节奏。
如果代码一天能写完，宣传文案还要排一周，产品还是慢。如果功能一天能发版，合规审查没有分级机制，产品还是慢。如果工程师能快速做实验，但没人定义成功指标，产品还是慢。
所以吴恩达这次真正提醒的是：别只盯着 coding agent 的效率数字。软件团队的下一轮升级，不是把工程师变成打字更快的人，而是把产品判断、跨职能协作和发布机制一起重做。