第一次坐下来使用 Claude Code 的 Opus 4.5 来开发软件时，我简直不敢相信它有多强大。
我接下来的想法是：这将会改变软件团队内部的动态。
角色之间的僵局
Marc Andreessen 最近把当前的局面形容为一种“墨西哥式对峙（Mexican standoff）”：
每个工程师现在都觉得自己可以做产品经理，也可以做设计师。
每个产品经理都觉得自己可以写代码、也可以做设计。
每个设计师则觉得自己也能胜任另外两种角色。
风险在于，许多个体贡献者开始认为自己不再需要其他人。
在短期内，这对团队文化来说将会非常具有冲击性。
当原本稀缺的技能变得更容易获得时，人们就会感到压力，想要“向上走一层”，以证明自己的价值。
Kent Beck 在 X（Twitter）上表达了类似的感受：
“我 90% 的技能价值刚刚跌到了 0 美元，而剩下 10% 的杠杆价值却增加了一千倍。”
我担心的是，每个人都在重新校准自己的能力，朝着同样的那 10% 靠拢。所有个体贡献者都在争相冲向同一个高杠杆层级。
在 Ben Werdmuller 的文章《AI coding works now》中，他给工程师提供了一些建议。他写道：“AI 编程正在把重心从实现（implementation）转移到判断（judgment）。”他建议工程师重点培养以下四种能力：
制定产品目标
理解用户真正想要什么
对你正在创造的体验和价值有极其清晰的认知
设计、构建并维护稳健的软件架构
然而，对 Ben 的建议提出的挑战是：很多人都认为这些能力本来就属于自己。
公司领导层认为目标和战略本来就是他们的职责。
产品经理认为自己最有资格理解用户需求。
设计师希望掌控用户体验的设计。
而市场和销售团队则希望定义产品向客户传递价值的方式。
工程师则掌握架构的规划和实现。性能、可扩展性、安全性——这些都需要真正的专业能力。
随着 AI 的出现，这些角色之间的界限开始变得更加模糊。当越来越多的人开始构建软件、开发周期不断压缩时，他们也会逐渐吸收那些原本需要同事花费几十年才能积累的经验。
最终，越来越多的人会希望拥有那个杠杆最大的身份：
“在我的角色中，我负责解决问题，并为用户创造价值。”
如果不加以管理，人们就会开始争夺位置。团队成员之间可能会出现更多的摩擦（甚至嫉妒）。
我从软件团队那里听到的情况
我开始问一些负责软件团队的朋友，他们正在经历什么。
一位创始人告诉我：
“我觉得你说得没错。我们已经开始看到这种情况了——主要是产品经理想要自己写代码。”
另一位朋友说：
“我们团队确实也有这种感觉。每个人都觉得自己可以做别人的工作。”
一家成熟软件公司的总裁也描述了类似的变化：
“我们的团队有一位产品负责人和 15 名工程师。在一些较小的项目里，他自己提交了很多 PR，甚至没有开发者参与。”
但最大的变化不仅仅是谁在做这些工作，而是他们现在在招聘什么样的人：
“真正能看到对岗位影响的地方，是我们不再招聘的那些人：专家型人才。在这个新时代，通才会胜出。”
Ghost 的创始人 John O’Nolan 也评论说：
“这确实是一个动荡的时期，但总体来说我还是挺乐观的。
我认为接下来还会发生的一件事是：除了旧的角色被压缩之外，还会出现新的角色。”
僵局之后
我希望的是，当尘埃落定之后，我们能迎来更多合作，而不是更少。与其争夺谁拥有更高的杠杆，我更希望个体贡献者能找到新的协作方式。
例如，如果产品经理和工程师一起进行更多 AI 驱动的结对编程，会怎么样？
产品经理可以专注于用户行为和产品目标。
工程师则可以评估架构、安全性和可维护性。
他们可以借助 LLM 实时协作、不断迭代。
我的朋友 Matt Stauffer（Tighten 的 CEO）说他们现在就这样做：
“我会把工作演示给我们的商务拓展经理（也是这个内部项目的产品负责人），她提出修改意见，然后我们一起实时给 LLM 提示。
我更擅长写提示词和审查代码，而她比我更了解业务领域。这样的结对编程效果很好，因为我可以快速推进，而在我后续审查和迭代时，她可以先离开。”
Ben Werdmuller 的建议在这种模式下仍然成立：“所有代码都必须有一个人类负责人，愿意为它承担责任。”在我设想的场景中，产品经理和工程师可以共同拥有一个 Pull Request。
37signals 因为他们的“两人团队模式”而闻名（一个设计师，一个工程师）。在 AI 时代，也许类似这样的协作范式会变成新的常态。
当动荡逐渐过去之后，人们需要一种新的愿景来重新定义如何一起工作。
我们该如何利用 AI，并通过新的协作方式，构建出更好的软件？