单披萨工程团队开始兴起

毫无疑问，使用像 Claude Code 这样的 AI 工具可以让我们更快地编写代码。

但是，问题是，这将如何影响其他一切？

在大多数团队中，编码（阅读、编写和调试代码）曾经是工程师花费时间最多的部分，但现在这不再是 瓶颈。

限制理论 指出，每个系统都有一个瓶颈，因为没有瓶颈，系统将以无限的速度运行，这是不可能的。

让我们看看 新的瓶颈，它们对工程团队规模和角色以及为什么亚马逊的两个披萨团队规则（“团队应该足够小，可以被两个大披萨喂饱，理想情况下由 5-8 人组成”）正在被淘汰的影响。

设计师和产品经理将继续存在，但不会成为特定团队的一部分。这个图表显示，我们仍然需要设计师。

目前，LLM 对产品经理和设计师的帮助不如对工程师的帮助大。

在设计师方面，他们难以创建出色的原型。你会注意到，每个 AI 产品首页看起来都一样。我认为这是 LLM 的一个局限性：它们倾向于生成训练数据的中位数附近的想法，这可以防止糟糕的设计，但也限制了真正创新的概念。

在产品经理（PM）方面，LLM 可以收集数据和洞察力，但 PM 最耗时的部分是与客户沟通和交谈，这不能被有效地自动化。

这就产生了一个新的瓶颈：项目输出开始依赖于产品规格和线框图的交付速度。

而且情况变得更糟：通常，你有 4-7 名工程师，但只有一个（有时是共享的）PM 和设计师在一个团队中，造成了不平衡。

AI 编码让每个 PM 都感到意外——“我们需要一个更大的路线图”。

一些公司认识到这种不平衡，并问道：“如果工程师参与产品和设计，而不仅仅是接收产品规格呢？”然后他们开始招聘 产品工程师。

这不是一个新概念；这个角色已经存在超过 16 年了。但我强调这一点是因为他们现在比以往任何时候都更相关。

已经有“产品工程师”的招聘趋势。来源：Hacker News Big Query 表

好吧，那么什么是产品工程师？他们是被授权处理一些 PM 和设计师职责的软件工程师，平衡了这些角色。

产品工程师承担传统的 PM 角色，包括拥有路线图、与用户互动、分析数据、确定机遇和决定要构建什么。然而，他们并没有取代 PM。PM 仍然提供背景，但不再是实施的主要驱动力。

在设计师方面，他们还组装设计系统的构建块。设计师仍然创建这些块并与 UX 流程合作，但他们不再负责生产“像素完美的原型”，工程师必须遵循。

并不是每个人都应该或会成为产品工程师。

但传统的软件工程师，即“万能的工匠，但没有专长”，将无法超越“专长”的工程师。

AI 擅长产生可接受的质量代码，但很少是优秀的。你不能简单地提示和合并它到成熟的代码库中，而不进行深入的人工审查。

AI 编码有很多问题：

• AI 经常粗心地对待编码，忽略二阶效应：它修改或删除基本代码而不考虑后果。
• 为了让 LLM 修复 bug，它们需要有意义（而且对于那些能够穿透抽象层的 bug，它们很少有意义），所以你不能仅仅拥有一个完全使用 AI 的团队，而没有对使用的工具有深入的理解。
• AI 将复制代码库中的破坏性模式，随着时间的推移导致代码质量下降，因为没有人会检测和修复它们。

因此，我们需要 专家 来管理平台代码。这并不意味着他们不会使用 AI，但他们将在审查过程中充当守门员，防止糟糕的模式被合并到代码库中。

我们可能会看到更少的全栈工程师职位开放，更多的后端和前端工程师职位。这并不意味着他们只会做其中之一，但他们将被期望在某一领域成为专家。

除了之前提到的不平衡之外，大型团队还面临两个主要挑战：沟通开销和将工作分配给团队成员，使他们能够独立地朝着共同的目标努力。

对于第二个问题，这还不是太糟糕。我们可以将工作分解为史诗般的任务，这些任务需要工程师两周才能完成，他们可以独立地完成。但现在两周的时间感觉很长。

另一个问题是，AI 在给定问题的更广泛上下文时表现最佳，这反过来使得将工作分配给团队成员更加困难。

理想的团队规模现在似乎是 每个项目 2-3 名工程师。即使有一个更大的团队，你也可以将其分成 2 名工程师的小组，观察他们的进度。

但是，避免将大项目分配给单个人员。长时间独自工作而没有人可以头脑风暴、审查代码或合作将会很有挑战性。

根据我的经验，个人贡献者的挫败感会随着时间的推移而增加，当他们独自工作时。另外，开发人员需要保持和提高他们的沟通技巧，这对于成长是必不可少的。

我在 Reddit 和 LinkedIn 上收到很多私信，推销 AI 管理工具，用于跟踪“生产力”和使用 AI“评估”工程师的表现。

大多数工具在概念阶段就失败了。管理性能工具并不是新鲜事物，但它们都试图智胜管理者。AI 永远无法拥有管理者需要的 40% 的上下文。它只能评估“量化”指标。

但是，不会编码的经理将变得罕见：随着团队规模的减小，他们在人员方面的责任减少，腾出了时间用于“编程”方面。

我已经解释了“定义良好的工程经理角色”是一个神话，工程管理始终涉及适应团队，因此这将始终保持不变。

AI 使得工程经理更容易参与编码。他们已经知道如何将更大的问题分解为较小、可审查的目标，就像任何高级工程师一样。

所以你提示 Claude，参加会议，然后在返回时审查代码！

但是，经理的角色将与工程师不同。他们不会被分配相同的任务，因为需要经理关注的情况将始终优先。因此，避免可能阻塞团队的工作至关重要。

我相信这只是变化的第一波。

我的帖子假设 AI 不会在当前状态之外有太大改进，这似乎是一个安全的预测。进步并不是来自更好的 AI 模型，而是来自我们如何使用它们（工具、思维能力）。

我们还看到在设计师和 PM 工具中投入了大量资金，AI 不是核心，而是补充。我想知道他们还能改进多少。

有很多未知数我没有解决，因为它们仍然不确定，例如 QA：AI 能够接管多少 QA 工作，QA 工程师的角色将是什么？

你认为还会有什么变化？如果你知道，请留下评论。