Claude Code会威胁团队协作吗

我第一次坐下来用Claude Code的Opus 4.5来构建软件时，简直不敢相信效果有多好。

随之而来的想法是：这将改变软件团队内部的动态。

角色之间的僵持

Marc Andreessen最近把这一刻描述为一种"墨西哥僵局"：

每个工程师现在都认为自己可以是产品经理和设计师。

每个产品经理都认为自己可以编码和设计。

每个设计师都认为自己可以做其他两件事。

风险在于，许多个人贡献者相信他们不再需要其他人。

短期来看，这对团队文化将产生极其破坏性的影响。

当稀缺技能变得更容易获得时，人们会感到压力去"向价值链上游"移动，以证明自己的价值。

Kent Beck在X上表达了这种想法：

"我90%的技能价值刚刚跌到零。我剩余10%的杠杆作用提升了一千倍。"

我的担忧是，每个人都在向同样的10%重新校准。个人贡献者都在竞速朝向同一层杠杆奔去。

在Ben Werdmuller的文章"AI coding works now"中，他专门为工程师提出了建议。他评论道，"AI编码将重心从实现转移到判断"，并建议工程师专注于这四项技能：

为产品制定目标

理解用户真正想要什么

对你正在创造的体验和价值清晰明确

设计、构建和维护健壮的软件架构

Ben建议的问题在于，很多人都认为自己拥有这些技能。

公司领导层想拥有目标和战略。

产品经理认为自己是唯一有资格理解用户想要什么的人。

设计师想控制用户体验的塑造。

营销和销售想定义如何向客户表达价值。

工程师掌控架构的规划和实现。性能、可扩展性、安全性——这些都需要真正的专业知识。

有了AI，所有这些角色都变得更加流动。随着更多人构建软件、迭代周期压缩，他们开始吸收同事花了数十年才学到的经验教训。

最终，更多人会想要拥有最高杠杆的身份："在我的角色中，我解决问题，为用户创造价值。"

如果不加以制约，就会出现位置争夺。团队成员之间可能会产生更多敌意（和嫉妒）。

我从软件团队听到的

我开始问一些运营软件团队的朋友他们在看到什么。

我认为你在这点上是对的。我们已经在看到它了——主要是产品经理想要编写代码。

我们的团队确实在经历这种情况。每个人都觉得自己可以做其他人的工作。

一家成熟软件公司的总裁描述了类似的转变：

"我们的团队是一位产品负责人和15名工程师。在规模较小的项目上，他自己提交了大量PR，开发人员完全没有参与其中。"

但最大的变化不仅在于谁在做工作。而是在招聘策略上：

"在我们公司，真正看到对工作影响的地方是那些我们不再招聘的人：专家。在这个新时代，通才赢了。"

Ghost的创始人John O'Nolan评论说：

这肯定是个动荡的时期——但总的来说，我很乐观。

我预期将来会发生的事情是，除了旧角色被压缩外，新角色会应运而生。

我的希望是（一旦尘埃落定），我们会走向更多的协作。与其为杠杆竞争，我希望个人贡献者能找到新的合作方式。

例如，产品经理和工程师能否开展更多AI驱动的配对编程？产品经理可以专注于客户行为和产品目标。工程师可以评估架构、安全性和可维护性。他们可以使用LLM实时迭代。

我的朋友Matt Stauffer是Tighten的CEO，他评论说他们现在就在做这件事：

我向我的业务发展经理（这个内部项目的产品负责人）演示工作，她提出改动，然后我们一起实时向LLM提示。我更擅长提示和审查，她对领域的了解比我深。这种配对编程很棒，因为我行动很快，然后当我进行审查、迭代等时，她可以稍后离开电话。

Ben Werdmuller的建议仍然适用："所有代码都必须有一个人类所有者来负责它。"在我的场景中，产品经理和工程师会共同拥有这个pull request。

37signals因拥有两人团队（一名设计师，一名工程师）而闻名。在AI世界中，也许这样的范式会成为常态？

一旦动荡平息，人们将需要一个关于如何合作的新愿景。我们如何利用AI并以帮助我们构建更好软件的方式进行协作？

干杯，

Justin Jackson

在Hacker News上讨论此话题

联系我： 🦋 Bluesky 💼 LinkedIn 🐘 Mastodon 🧵 Threads