硅谷被人工智能灯具Andrew Ng的最新挑衅所困扰 - 它不是关于一些精彩的新模型或算法。 是的,你读得对了,在Y Combinator的创业学校最近的一次谈话中,Ng建议软件团队的传统化妆正在发生激进的转变。 根據 Ng 自己的說法: 这起作用为 在一个团队。 product managers two software developers for every one product manager “就在昨天,我的一个团队来到我身边,第一次......这个团队建议我不要有1:4工程师,而是1:0.5工程师。 雷迪特.com twice as many PMs as engineers https://www.youtube.com/watch?v=RNJCfif1dPY&embeds_referring_euri=https%3A%2F%2Fapp.hackernoon.com%2F&source_ve_path=MjM4NTE&embedable=true 这种大胆的说法与上升的 ,这是Andrej Karpathy设计的术语,用来描述使用AI来生成高级提示的代码.随着AI辅导员以闪电速度编写锅板代码,Ng认为软件开发中的瓶颈不再是工程能力 - 它是决定性的。 是的 Ng说,观察到,虽然人工智能大大加速编码,但产品决策并未加速,如果代码像便宜的糖果一样被挤出,那么任何人发现正确的糖果食谱(产品经理)都突然变得不可或缺。 “vibe coding” 什么要建 “我看不到产品管理工作以与工程技术相同的速度变得更快,我看到这个比率的变化。 “我仍然不知道这是否是一个好主意,但......在我生命中,经理们首次提出要有两倍多的总理比工程师。 这是混乱,邪教,还是两者之间的一些?Ng的声明肯定是长期以来称赞工程师为主要创作者和PM作为支持团队的行业的转折点。 ,也许真正的权力转向那些谁 让我们解开这场 PM vs Engineer 比率辩论的双方的论点,因为 Twittersphere (或 X-sphere) 和 HackerNews 评论只是在这个问题上保持沉默。 writing code on vibe 设 Ng的勇敢预测:为什么PM可能变得更重要 安德鲁·恩(Andrew Ng)没有理性地抛出2:1(Eng:PM)比率声称,核心逻辑源于简单的补充经济学。 谢谢你,必然。 换句话说,当建造事物变得容易时, 人工智能辅助编码(vibe编码的本质)可以让一个工程师完成五个或十个工作,但没有多少人工智能可以取代理解用户的需求,制定产品愿景,并定义功能 - 产品经理的面包和黄油。 (翻译:您好,PMs通过 ) “写软件,特别是原型,正在变得更便宜” “这将导致对能够决定建造什么的人的需求增加。 figuring out the thing to build becomes the critical path 正确 “这将显著增加对能够提出有价值的东西清晰规格的人的需求。 链接.com 正确 这个未来在实践中看起来是什么样子?Ng给出了上面的故事,一支AI基金团队提出了一个前所未有的计划。 一个 PM 超过工程师的场景,甚至 Ng 也承认。 ,但他正在看到这种趋势的早期迹象,而且他并不孤单。科技投资者SC Moatti在支持Ng上演: 当你有风险投资类型基本上同意 ,这是一个迹象表明这个想法不是来自左翼领域的。 1:0.5 PM-to-engineer ratio “听起来很极端” “优秀的点Andrew Ng - 我们的预测是目前的10:1工程师:PM比率将变为2:1,因为PM将能够用更少的工程师做得更多。 the PM is the new rockstar 其他产品领导者分享了类似的经验,尤其是在人工智能工具时代。 在这种情况下,PM成为了 ,而AI增强的开发团队比以往任何时候都更快地执行。 (他甚至提到他的 现在,由于AI工具 区分转向视野,优先级化和产品直觉 - 经典的PM领土。 “导航器,我指向方向,人工智能执行,所以安德鲁说的话与我共鸣。 coach and strategist “everyone codes” receptionist codes 创业者.com Ng的更广泛的观点是,AI正在重塑角色: 他甚至创建了一条在 在人工智能时代,了解人工智能(也许可以自己编写一些代码的产品经理)的需求很高,基本的推理是:如果一个具有人工智能的工程师现在可以在一天内构建一个应用程序原型,限制因素就是你能如何快速决定下一个功能或验证下一个想法。 “许多公司都有一个工程师:PM比例,比如6:1......随着编码变得更加高效,团队将需要更多的产品管理工作(以及设计工作)作为总劳动力的一小部分。 AI Product Management “编写软件正在变得越来越便宜,这将导致对能够决定构建什么的人的需求增加。 推翻:为什么许多技术人员怀疑(或恐惧) 在我们开始将首相称为新技术的国王和女王之前,让我们来解决问题。 来自许多工程师和技术观察员的想法是,每位工程师有两个PMS。 直立地把它放进去, 工程师被称为过敏 ,并认为一支围绕几位开发人员的PMS军队的想法对许多人来说是噩梦燃料。 不需要翻译。 chorus of eye-rolls and “oh please” retorts 一个救世主 “在我在这个新的AI浪潮中看到的愚蠢的垃圾列表中,这个排名相当高。 meeting overload and micromanagement “一个工程师的两个PM?这是我的真正的噩梦。 对NG的粉红色PM重的未来的一个主要论点是 Gaurav Khanna提供了一个对比点,即Ng的假设 他指出, 在这种情况下,而不是更多的PMS来管理现在的过度生产性的开发,也许 毕竟,如果ChatGPT可以写用户故事或分析客户反馈,为什么雇用额外的人来做到这一点? AI might automate parts of the PM role too “忽略了这一事实,即相同的AI进步可以通过自动化他们工作的核心方面来减少PM的需求。 “人工智能工具越来越能够生成产品规格,根据用户数据优先考虑功能,并分析反馈,以确定改进机会。 the PMs just get smarter tools 还有一个营地,相信 当然,人工智能可以快速扫描应用程序,但经验丰富的工程师知道恶魔在于细节:调试,集成系统,处理边缘案例,扩展软件等。 嘲笑Ng的想法,说他们会爱 他们怀疑PMs谁 可以魔法 点击线: – 用 Sarcasm 滴滴,突出了 PMs (偏偏被称为“中间经理”)可以取代优秀的工程师的怀疑。 engineering won’t be as cheap and easy as Ng implies 一个愤世嫉俗的黑客新闻评论家 “不管这个家伙在吸烟,原因是下午1点到5点的工程师在那里有一定的头脑腐烂的疯狂。 “不要在项目上成为网络负面” “通过把一堆LLM幻觉的垃圾扔到墙上来建立杰克希特。 “当然,开发者是那些将被无知的中间经理取代的人,他们只是为了浪费每个人的时间而存在。 另一个观点是 :AI将暴露弱 PMs 微弱的工程师,正如一个观察者所说, 换句话说,如果编码变得更容易,也许工程师会自己开始侵入产品草原(因为他们可以处理更多的产品思维,当他们脱离草原编码时),或者简单地说。 毕竟,如果一个工程师可以要求人工智能生成十种特征的变异,也许他们会更少依赖PM来指定一切。 PMS 解雇 survival of the fittest 和 “或者是相反的方向? ...如果技术上尖锐的设计师和圆满的开发人员实际上最终把无能的经理赶出去呢?” bad PMs will have nowhere to hide 过度 让我们不要忘记纯粹的文化抵抗:许多开发者只是不想要更多的PM监督。 任何在会议繁重,经理繁重的环境中工作过的人都可以与恐惧有关。 PMs的倍增可能会引入通信过度,矛盾的指令和官僚主义的暴露 - 与多年来一直在软件开发中所倡导的敏捷、薄弱的团队完全相反。 “他们都有不同的产品愿景,但不会彼此交谈 - 他们都只是告诉你忽略对方并做他们想要的。 too many cooks in the kitchen 平衡(但繁荣):谁对未来的团队比例是对的? 像大多数技术辩论一样,真相可能在中间的某个地方 - 但倾向于Ng的愿景,比怀疑论者可能承认的要多。 这是一个想法的挑衅性月光,有时你需要说出极端来激发讨论。 Ng is onto something real, but the 2:1 ratio is an exaggerated scenario 在暴力方面,很难否认Ng的核心洞察力。 在许多情况下,构建软件更快,更便宜。曾经需要团队几周的原型现在可以由熟练的总理或设计师在一天内用AI助理打破。Ng的自身组织,AI基金,显然正在看到团队在现实生活中使用PM重型模型进行实验。 而且我们已经看到专门针对以人工智能为中心的PMs的课程,研讨会和角色的扩散。 has “AI产品管理有光明的未来!” 然而,暴力并不意味着戴眼镜,这是完全可能的。 也许明天的“工程师”也正在做很多产品工作(写规格,选择功能),明天的“PMs”更技术(能够做轻量级编码或至少AI辅助原型)。 生产力较大,但双方都更有生产力。 取决于项目阶段:有时它会提出正确的想法(PM-heavy),有时它会执行一个复杂的技术细节(engineer-heavy)。 we won’t literally see teams with 2 PMs per engineer across the board. still have a 5:1 or 4:1 ratio bottleneck might shift 值得注意的是,并非所有的产品管理尺度都与工程输出线性,而且还有一定数量的用户研究、设计洞察力、战略思维以及 人工智能可以帮助但不能完全取代这些人力元素 - 至少还没有,所以对强有力的产品思想家的需求确实会增加,正如LinkedIn的一位评论员在辩论中指出的那样:即使每天使用人工智能,它 换句话说,人工智能可以帮助总结和加快任务,但它不能(目前)真正同情用户的疼痛点或拥有杀手功能的eureka时刻。 human judgment “在整个过程中,它仍然需要大量的投入,以提供任何具有真实和特定的价值的东西......它还没有真正了解用户。 l 与此同时,工程师也不会消失 - 但是他们的角色正在演变。 有人可能会设想一个未来,一个“工程师”监督多个AI编码代理 - 有效地管理更高的输出 - 而总理同时监督多个产品方向或实验。 . technical directors or editors team structure becomes more fluid Ng的极端比率示例可能不会在任何地方成为规范,但它表示方向: 他的挑衅可能是为了唤醒公司去投资产品战略,而不仅仅是把更多的编码器扔到一个问题上。 the relative importance of pure coding vs. product thinking is shifting 更多 PMs,更多代码,更多问题 安德鲁·恩(Andrew Ng)基本上打破了问题,预测一个世界,产品经理比今天要多得多 - 而且可能更为关键 - 这是一个代码便宜的世界,“振动”是新的规格,最好的想法(或最好的提示)赢得了。 在平均初创? 色彩我怀疑,但不拒绝。 我们可能会看到 我们可能会看到团队在不同时刻需要沉重的产品输入和沉重的工程输入之间波动,我们几乎肯定会看到许多尴尬的实验(以及失败的实验),因为公司找到了正确的组合。 每个工程师的两个PM new hybrid roles 但是作为一个观察技术趋势的人(从浏览器战争到社交媒体蓬勃发展)走来走去(再回来),我会这样说: 一年前,很少有人想象非编码器可以通过自然语言构建功能性应用程序,现在它正在发生,所以如果安德鲁·恩(Andrew Ng)预料到一个未来,PMs正在涌现,这至少是我们应该为之准备的未来,即使只是为了确保我们不会陷入“PM地狱”工程师的恐惧。 never bet against a paradigm shift when AI is involved 最终,无论你是团队总理还是团队工程师,聪明的举动是 如果你是一名开发人员,请与人工智能编码助理保持舒适,也许可以磨练那些产品感官技能,如果你是一名产品经理,那么更好地磨练你的技术切片,并学习如何在工作流中利用人工智能。 每个人 - 编码员和PMI一样 - 都应该学习使用人工智能,因为它正在改变游戏规则。 embrace the tools and level up your game “每个人都应该学会编码” 因此,将经典 大拇指的规则是传真机的方式吗?可能至少,我们将在五年内以非常不同的方式谈论产品团队的组成。 如果人工智能正在自动化基础工作,那么让我们重新聚焦人类天赋在真正重要的地方:创造性、战略性、同情性的产品领导。 高层次的工程创造力:无论是意味着更多的PM,更少的PM,还是简单地说。 PM和工程师们,这场辩论中有一点是明确的: “一个 PM 到 7 工程师” It’s about time we re-thought how we build products 和 聪明 “vibe coding” is changing the vibe of software teams, and none of us can afford to ignore it. 观看整个演讲: https://www.youtube.com/watch?v=RNJCfif1dPY&embedable=true https://www.youtube.com/watch?v=RNJCfif1dPY&embedable=true&transcript=true&video=false
