企业如何适应软件工厂时代

过去两年，软件工程师经历了诸多变化，从手写代码转向通过本地交互式提示来引导 agent，这也是当前的范式。起初，工程师对提示驱动开发持怀疑态度，但如今这已成为标准做法，总的来说，大家似乎已经很好地适应了以这种方式与 agent 协作。

下一个范式是软件工厂，agent 在整个软件生命周期中承担越来越多自主工作。从我与客户的交流以及对 Warp 自身团队的观察来看，完成这一转变可能比上一次更具挑战性。但采用工厂模式带来的生产力、成本管理和控制方面的收益是深远的，因此我相信这一转变不可避免。

对于“软件工厂”的含义，目前尚无普遍共识，有些人设想的是完全无需人工监督的“黑暗”工厂。如果不需要人类，工程师自然会问自己的工作是什么。最终你会得到一个士气低落的团队，他们觉得自己不再被需要。企业领导者可能想要黑暗工厂，但这在目前并不现实，追求它可能导致工程人才流失。

在工厂中，默认所有工作都是公开的，包括过去在开发者“内循环”中属于私密的工作。这与工程师习惯的方式截然不同——他们通常在本地进行更改，团队第一次看到这些更改是在将其作为 PR 推送进行审查时。公开工作不仅暴露你构建了什么，还暴露了你如何工作，这可能会让人不适。更复杂的是，工作会被度量，从 token 使用角度很容易看出每个工程师的效率。这让我们都感觉自己像是机器上的齿轮。

此外，“工厂”这个比喻本身就有点令人沮丧。感觉作为工程师，你的工作要么是在流水线上干活，要么是在建造那条让你自身才能变得多余的流水线。如果你使用“AI 队友”的比喻（我也不喜欢这个说法），那感觉就像工程师变成了谄媚且有些无能的下级工程师的管理者。对于那些以构建手艺为傲的人来说，这一切都像是软件创造的商品化。

在 Warp，我们的全部重心是构建技术基础设施 Warp Factories，使团队能够过渡到这种新的工作方式，但我们也在深入思考它如何赋能与工厂协作的工程师。我为感兴趣的团队编写了一份指南，介绍采用工厂基础设施的爬行、行走、奔跑阶段。

在 Warp，我们向工程团队明确表示，他们现在有两个主要工作：构建产品，以及构建构建产品的工厂。

我们的工程团队仍然对产品的质量和实用性负责——这不能委托给 agent。他们将继续提示和引导 agent，确保构建正确的东西，并确保它对用户有效。

这就是“产品工程”，人类将继续从事这项工作。人类具有独特的优势，知道该构建什么、各部分应如何组合、产品体验应该是什么、什么构成好的设计。人类有品味，而且目前人类比 agent 拥有更多上下文，这使得他们更有可能构建有用的东西。

不过这里有两个注意事项。首先，有些类型的产品工作完全不需要任何人工输入，可以完全自动化。想想修复服务器崩溃、简单 bug、小的 UX 瑕疵、依赖升级等。这个比例一开始很低（对 Warp 来说，起始约为 20-30%），但会随时间增长。事实上，推动它增长是工程师第二项工作的一部分，我稍后会谈到。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）