AI正在重组产品团队！Instagram掌门人：十几人的配置砍到6-7人，工程师的重心开始转向规划和审查

“工程师过去可能把40%到60%的时间用来写代码。现在很多人把大部分时间花在规划任务和审查代码上。”

说这句话的人，是Instagram掌门人Adam Mosseri。

最近，他聊到一个正在Instagram内部发生的变化。

过去，大公司的标准产品团队通常有十几个人：Android、iOS和服务端各有两三名工程师，再加上产品经理、设计师、数据科学家和研究人员。

现在，Instagram开始尝试一种更小的Pod，核心通常只有6到7个人。

4到6名通才工程师，再配1名“产品参谋”。

定价、复杂交互等专业问题出现时，才请资深专家加入。

团队少了一半，工作并没有跟着少。产品需求、交互、数据分析和用户研究，开始被交给同一支小队。

就连开发者接到的也不再只是一张写好验收标准的需求单。

这场访谈谈的是Instagram本身，但问题却很容易延展到每一支正在使用Coding Agent的团队里：代码越来越容易生成以后，一名开发者的责任边界到底划在哪里？

以下内容根据访谈翻译整理。

十几人的标准团队，核心缩到6到7个人

Mosseri回忆了大公司的传统配置。

Android、iOS和服务端通常各有2到3名工程师，再加一名通才工程师、产品经理、设计师、数据科学家。有条件的团队还会配研究员和内容设计师。

他用了一个短语来形容这个规模：“a baker’s dozen”，也就是大约13个人。

显然，这样的配置有它的道理。

每种技术栈都要有人熟悉代码库，也要有人互相做代码审查。产品、交互、数据和用户研究由不同角色负责，大家沿着一条固定流程把功能送到线上。

问题也很明显。每多一次交接，团队就要多对齐一次。

一个功能从产品文档走到设计稿，再进入客户端、服务端和数据团队，常常还没开始实现，会议已经排了几轮。

Mosseri：Instagram今年开始采用Pod。每个Pod配“four to six engineers”，这些工程师更偏通才，再加入一名由产品经理演化而来的“产品参谋”。

Mosseri介绍4到6名通才工程师组成的Pod

Pod并没有把专家全部赶出团队。

碰到定价问题，资深数据科学家会进来；遇到复杂、全新的交互，资深产品设计师仍然要参与。

区别在于，专家不再固定驻扎，而是围绕任务临时加入。

专家按需加入，核心团队通常只有6到7人

这是一套正在Instagram内部发生的组织实验，不能直接外推成所有公司的裁员公式。它至少给出了一个清晰信号：AI进入开发链路后，公司开始重新计算一支产品团队需要多少人、哪些岗位必须全程在场。

“产品参谋”出现，PM、设计和数据开始合流

Pod里最陌生的角色叫Product Staff，也就是“产品参谋”。

它仍然兼具产品经理的职责，却可以借助AI做一部分设计、数据分析和用户研究。

团队遇到问题时，可以不先把任务转交给另一个职能部门，产品参谋可以先完成原型、整理数据、查找用户反馈，再决定是否需要专家介入。

主持人追问：一个只有五六个人的团队，究竟少了谁？

Mosseri：它可能只有4名工程师和1名产品参谋，没有固定的数据科学家、设计师、研究员或内容设计师。

这种变化称为“all the functions are starting to bleed into each other”。过去清晰的职能边界，正在相互渗透。

Mosseri谈产品、设计、数据等职能的合流

对开发者来说，这意味着需求来到手里时，完成度可能会比过去低。

假设团队要改一套新用户引导。

以前，产品经理会交付流程和验收标准，设计师给出完整交互，数据团队定义指标，开发者负责实现。

Pod里的工程师可能从原型阶段就加入：先用AI做出几个版本，接上埋点，和产品参谋一起看数据，再决定哪一版继续投入。

工程师不必变成资深设计师或数据科学家。可他得听得懂这些问题，也要知道什么时候自己的判断已经不够，需要把专家叫进来。

工程师写代码的时间，已经让给规划和审查

Mosseri把工程师的变化说得更具体。

过去，写代码可能占一名工程师40%到60%的时间。到了大量使用AI的团队，工作重心已经转向规划和代码审查。有人会喜欢这种变化，也有人会怀念长时间沉在编辑器里写实现的日子。

Mosseri谈工程师从编码转向规划和审查

Coding Agent接过的主要是执行环节。

任务从哪里切开，哪些目录可以修改，要跑什么测试，失败后停在哪里，仍然需要开发者提前安排。

Agent交回结果后，diff是否合理、抽象是否多余、性能和安全有没有变化，也要有人检查。

以前，写得快是一项很显眼的优势。

现在，第一版代码来得太快，另一组能力更重要了：能不能把任务讲清楚，能不能及时发现方向错了，能不能在几千行改动里找到那个不该合并的决定。

Mosseri观察到，同一批工具也在重新排列人的表现。过去写代码不快、但擅长规划和判断的人，可能突然变得更有效率；喜欢独自实现、不愿意做审查和协调的人，工作体验则会明显改变。

AI没有把工程岗位变简单。它只是把时间从键盘上挪开，放到了任务开始之前和代码生成之后。

AI能跑执行，战略仍然要人做取舍

主持人问Mosseri：当AI逐步接管产品开发流程，人脑会在哪些地方继续值钱？

Mosseri给出的两个词是“taste”和“judgment”，品味与判断。他尤其强调战略判断。

Mosseri谈AI时代仍由人负责的品味与判断

他尝试过把市场、竞争对手、业务指标和增长数据交给AI，让模型帮助制定战略。

按理说，模型掌握的信息足够多，应该很擅长这件事。实际使用时，如果人不持续调整方向，答案很容易滑向正确但无用的套话。

Mosseri对战略有一个很实在的要求：一个合理的人应该能够不同意它。“成为最好”“做出优秀产品”都算不上战略，它必须明确选择一条路径，也意味着主动放弃另外几条路。

这和开发者给Agent派任务很像。

只说“把性能优化一下”，模型会自己填补大量空白；把目标、延迟上限、可修改范围、兼容要求和回滚条件写清楚，它才有机会给出可用结果。

AI可以生成方案，也能替方案找理由。选哪一条、承担什么代价，仍然是人的工作。

好的产品负责人，更像“策展人”

Mosseri还谈到一个容易被忽视的产品能力。

优秀的产品负责人未必每天都能提出新点子。很多人更像策展人，用他的说法是“less visionaries and more curators”。他们挑选人才、想法、技术和策略，再让团队围绕被选中的方向工作。

Mosseri谈优秀产品负责人的“策展人”角色

这套能力放进Agent工作流，也很容易理解。

几名Agent可以同时给出数据库迁移方案、页面实现和测试用例。

产出数量不再稀缺，团队缺的是一个能把方案放到同一张桌子上比较的人：哪份实现符合现有架构，哪项改动会增加长期维护成本，哪个看起来漂亮的设计其实解决了错误的问题。

开发者以后未必需要亲手完成每一个实现，但必须保留选择和否决的能力。否则，并行运行的Agent只会更快地制造一堆彼此冲突的半成品。

AI内容越多，身份和可信度越值钱

访谈后半段转向Instagram正在面对的另一个现实：AI生成内容越来越多。

从广告业务看，更多内容可能带来更多注意力。

可Mosseri承认，Instagram目前还不够擅长识别和排序AI内容。里面有好作品，也有大量低质内容，平台需要把用户感兴趣的那部分送到面前。

他判断，当合成内容变得充足，人们会更主动地寻找创造力、真实性和具体的人。

Mosseri谈合成内容增加后的真实性需求

Instagram从来不只展示一条内容，也展示内容背后的人、发布动机和个人视角。AI生成降低了生产门槛，这些身份信息便承担了更多信任功能。

Mosseri：我不赞成仅凭制作工具给内容定性。平台应该标出内容是否由AI生成，同时提供更多账号信息：账号注册了多久，是否频繁修改资料，发布者是谁、来自哪里。用户拿到这些线索后，再决定要不要相信。

Mosseri谈AI标识与发布者可信度

这部分同样与开发者有关。

内容平台、企业知识库、社区产品接入生成式AI后，不能只增加一个“生成”按钮。来源记录、AI标识、账号历史、内容审核和申诉机制都要跟上。模型回答得再流畅，用户仍然需要知道信息从哪里来、由谁发布、能否追溯。

代码生成越来越便宜，开发团队需要更严格的审查；内容生成越来越便宜，产品也要建立新的信任机制。两边遇到的其实是同一类工程问题：产出激增之后，怎样判断哪些结果可以进入真实系统。

写在最后

Instagram的Pod没有消灭设计师、数据科学家和研究员。专业问题出现时，这些人仍然要进入团队。

变化发生在核心小队：固定角色减少，按任务调用的能力变多，每个人都要把工作往前后多推一段。

对开发者而言，这段距离可能是先做出原型，也可能是补上埋点、读懂用户反馈、检查Agent生成的代码，或者在上线前叫停一个看似完整却方向错误的方案。

过去，一名工程师可以把“代码已经写完”当作交付节点。进入6到7人的Pod后，产品有没有解决问题、上线后是否稳定、团队是否愿意长期维护，都会更快回到同一批人面前。

AI把第一版实现压缩到了几分钟。接下来拉开差距的，是谁能把这几分钟产生的东西变成一个经得住用户、数据和时间检验的产品。

参考链接：

https://www.youtube.com/watch?v=yQ_EWmtfWvQ 

文章来自于"51CTO技术栈"，作者 "姜篇"。