高原陷阱

我最近写了一篇关于 AI 疲劳的文章，认为工程师们正在经历的不是慢性病，而是训练疼痛。突破它，适应，变得更强。

这听起来很好，也很有道理，但故事还没有结束，而且很快就变得明显了。目前面临的真正风险不是工程团队的倦怠，而是停滞不前。

新的分裂

几乎每个高级工程师现在都在使用 AI。Copilot、Claude、Cursor、Codex，你能想到的都有。这部分已经确定。如果你领导一个工程组织，你可能会看到广泛的采用率，并且对此感到满意。

但你不应该这样觉得。

采用率是无意义的。重要的是在其下面发生的分裂。你的团队正在悄悄地分裂成两个群体。有一部分工程师获得了生产力提升并稳定下来，另一部分工程师每周都在推动新的工作流程、新代理配置、新方法来分解问题让 AI 处理。

这两组都出现在你的仪表板上，显示为“AI 采用者”。但其中一组处于进步的训练计划中，另一组在第一次感觉舒适的重量后就停下来了。

六个月前，这两个群体之间的差距几乎看不出来。现在，对于任何关注的人来说，这是显而易见的。在另六个月内，它将成为结构性的。

什么是高原期的样子

停滞不前的工程师在传统意义上没有做错什么。他们是有能力的。他们交付工作。他们使用代理来完成简单的任务，并在之后清理。他们可能获得了 20-30% 的生产力提升，并认为这就足够了。

问题在于，他们旁边的工程师没有停止在那里。那位工程师现在正在运行多代理工作流程，改进验证循环，将整个功能分解成 AI 可执行的块，在架构层面而不是逐行进行审查，并以之前 2-3 倍的速度交付。这不是因为他们更有才华，而是因为他们继续训练，而其他人则休息了一天，这一天变成了一个季度。

这不是关于 AI 热情或成为早期采用者。早期采用阶段已经结束。这是关于持续适应与一次性调整。两种方法之间的差异正在变得无法忽视。

竞争压力是真实的，并且正在加速

如果你的团队有足够的时间来适应自己的节奏，高原期的问题将是一个绩效管理问题。令人沮丧，但可以管理。

但如果你看一下软件行业的更广泛情况，很可能你没有这种奢侈。

软件行业大多是为了帮助人类完成数字工作而创建的：帮助支持代理看到传入的案例，跟踪对客户的回应，管理工作流程。现在，AI 代理正在取代整个工作流程，并随之破坏了底层的 SaaS 平台。此外，随着 AI变得更加强大，你的客户开始问一个问题：“我们还需要购买这个，还是可以自己构建？”AI 已经开始在越来越多的用例中缩小“购买”和“构建”之间的障碍。保护你收入的粘性每个季度都在减弱。

你的停滞不前的工程师正在以适应竞争环境的节奏运作，这种环境已经不复存在。

那句话重新定义了我的看法

我已经多次听到这个说法了，来自产品经理，他们卷起袖子并对功能进行了编码，来自工程领导，他们重新设计了失败的架构，在不同的公司，处于不同的背景下：

“使用我的代理来迭代这个功能比使用那位工程师更容易。”

第一次听到时，我以为这是夸张的说法。第三次，我意识到这是一个领先指标。

我认为，有些工程师将在这个新世界中茁壮成长，并成为 AI 能力的“倍增器”。要做到这一点，他们需要在两个领域都很强大，这两个领域都可以通过足够的内在动机和智力好奇心自我开发：

• 他们与利益相关者（产品经理、工程经理等）“保持同步”。他们知道什么是好的样子，所以你不需要向他们解释太多。如果他们产生的误解数量与你的编码代理一样多，代理将永远赢得这场战斗。它始终可用，24/7，不会疲劳。
• 他们不断改进自己的 AI 设置，所以当你交给他们任务时，你知道它不仅会做得好（见上一点），而且也会足够快以跟上新的市场节奏。

为什么这是一个领导问题，而不是个人问题

将其框定为个人工程师的责任很诱人。“跟上或被甩在后面。”但如果你领导一个工程组织，这种框定让你脱离了责任。

你的停滞不前的工程师并不是在真空中停滞的。他们是因为没有什么东西在他们的环境中推动他们超越最初的调整而停滞的。他们获得了看似合理的生产力提升，没有人挑战他们去更进一步，惯性做了其余的事情。

那些继续推动的工程师？大多数都是自我激励的。他们无论如何都会推动。但你不能只用自我激励的先驱者来组建工程组织。领导者的问题是：如何移动中间层？

这是一个变革管理问题，我最喜欢的一个框架来自希斯兄弟的书 Switch。简而言之：你需要给人们一个明确的方向，让他们感到为什么这很重要，并重塑环境，使新的行为成为最容易的路径。应用于工程团队，这看起来像：

找到你的亮点并使其可见。 确定那些在 AI 工作流程中推动得最远的工程师，并让他们向团队演示。不是培训课程。真实工作的现场演练。当你的团队中间部分看到他们的工作流程和顶级适应者的工作流程之间的差异时，这会产生一种有生产力的不适感，这种不适感是任何命令都无法匹配的。

• 缩小变化。 “采用 AI”太抽象，无法采取行动。这一冲刺，完成端到端的代理测试，下一个冲刺将其推广到整个组织，等等。具体、可管理的步骤每次都比雄心勃勃的变革计划更好，小的胜利很重要。
• 重塑默认值。 将验证过程编码到 AI 技能中，并确保它们在整个团队和所有代理中部署。定义你的工作流程并使用支持该工作流程的工具。使新的工作方式成为最容易的路径，所以人们会自然而然地朝着它发展，而不是不得不为此而奋斗。

窗口正在关闭

这是使其变得紧急而不是仅仅重要的部分。

目前，适应差距是一个性能差异。你的停滞不前的工程师比你的适应性工程师更慢，但他们仍然富有成效。他们仍然有所贡献。你可以携带他们。

这个窗口正在关闭。随着 AI 能力的加速和竞争压力的加剧，工程工作的最低可行速度正在上升。今天的“足够好”的工程师不能保证在下个季度仍然足够好。这不是因为他们变得更糟糕了，而是因为底线已经上升了。

那些能够让整个团队沿着适应曲线上升的组织，不仅仅是早期采用者，将拥有一个结构性的优势。那些没有做到这一点的组织将发现自己为一种竞争节奏而配备人员，这种节奏已经不复存在。

每个我交谈的工程领导者都在知识上理解这一点。很少有人在回应中改变了他们的团队运营方式。理解与行动之间的差距是另一种停滞。

没有舒适的节奏

在关于 AI 疲劳的文章中，我认为疼痛是训练有效的证明。这仍然是正确的。但更难的真相是：重量不断增加。

在一个正常的健身房里，你可以选择一个舒适的重量并永远保持它。没有人会在未经询问的情况下在你的杠铃上添加重量。在当前的软件格局中，每次新的模型发布，每次新的代理能力，每次有人想出并分享新的工作流程，杠铃都会移动。保持静止，重量最终会压倒你。

软件行业目前没有舒适的空间。对于个人工程师来说，不适用；对于他们所在的团队来说，不适用；对于他们所建造的公司来说，不适用。唯一安全的位置是持续运动。对于工程领导者来说，唯一重要的问题是你的整个团队是否在移动，还是只有那些本来就会移动的人。