返回资讯中心
外部精选
软件工程
#开发者实时流

工程师建软件工厂为何重蹈旧覆辙

来源标题:What makes a good software factory

给一百名开发者配备 Claude Code 只会产出一百条各自为战的产线,代码在评审环节积压,交付速度并未真正提升。文章指出,多数工程师搭建的“软件工厂”只是把旧问题抬升了一层:需求仍按 2005 年的方式提前写死,懂业务的人依旧缺席。智能体能自主运行多久,取决于团队测试与上下文的质量。

Hacker News 最新youngbrioche2026/11/13 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

一百台笔记本运行编码 agent,就是一百条生产线。工程师们建造的工厂大多在一个层级之上重蹈旧错。要把产品思维转化为一个部分自主运行的交付系统,需要什么。

给一百个开发者配 Claude Code,你会得到一百个人产出多得多的代码。你的产品更快到达用户手中了吗?质量更好了吗?大多没有。代码在评审环节堆积,旧的交接流程原封不动。

一个 agent 能自主完成多少工作,取决于它周围的团队。有好的测试和好的上下文,开发者可以让它跑一个小时。没有这些,同一个开发者就得坐在 agent 旁边,每隔几分钟纠正一次。

无论哪种方式,一个半自主的交付系统看起来都不一样。在那里,agent 能自行完成整个变更。而当我纠正我的 agent 时,你的 agent 也能获得同样的纠正。

所以现状是:每个人都在建工厂了。很好!

但我一直看到同样的事情发生。工程师们把工作提升一个层级(正如我们告诉他们的那样),进入工厂,却把旧的弊病一并带了过来。规格说明书仍然像 2005 年那样事先写死。理解领域的人,再一次,在设计工厂时不在场。

这真的很可惜,因为工厂可能是我们有史以来最大的杠杆,用来将恰当的产品思维扩展为一个部分自主运行的交付系统。

以下是我所寻找的十三个要点,我们称之为原则。

“但我们已经共享了 AGENTS.md!”我经常听到这句话。AGENTS.md 是仓库中每个 agent 都会读取的指令文件,而且流水线中通常还有一个评审机器人。这是一个好的开始。它给每个人相同的规则。

但它没有告诉你某条规则为什么存在,或者它是否曾经修复过任何问题。而且当出问题时,没有一个单一的地方可以让你停下工作并为所有人修复。你仍然有一百个独立的设置,只是每个里面放了同一个文件。

实践中是这样的:一个 agent 总是搞错某条领域规则,我在自己的会话中纠正它,主要是通过提示词。我的纠正也许会进入共享文件,也许不会。

即使进了,之后也没人能检查它是否起了作用。我知道发生了什么,因为我修复了它。你不知道。

我在五月份写过这个问题,此后并没有好转。

如果你逐行阅读 agent 提出的每一个变更,你就是在紧密循环中工作,工具再好也没用。对于高风险或探索性工作来说完全没问题!

只是它无法扩展。把一百个人放进紧密循环,你得到的是一个非常非常长的评审队列。

另一种选择是灯火通明的工厂。灯一直亮着,因为人们仍在里面工作。agent 自主实现更大的变更,独立的检查(确定性的和 agent 式的)在不同层面给 agent 反馈。人们仍然决定 agent 是否接到了正确的任务,以及结果是否适合发布,团队事先就这些决策在哪里发生达成一致。

这种自主性来自 agent 周围的设置。仅靠更好的模型是得不到的,至少现在不行(我们将在原则 12 中讨论移除部分设置)。

那么假设评审不再是你的瓶颈。那么集成就是。每个变更在发布前都必须构建和测试,这需要时间和机器。如果你的构建需要 45 分钟,而你有三台机器来运行它,你每小时大约能通过四个变更,世界上最好的评审也无法让它变成五个。

但大多数组织更早就卡住了。他们只是不够清楚地知道自己想要构建什么。

这就是意图:某个人真正想从一个变更中得到什么。

agent 在这方面可以帮很大忙。给它们一段混乱的研讨会对话,它们会将其转化为初步规格,并且提出房间里没人问过的问题(总有几个)。它们构建出人们可以点击浏览的变体,然后才决定选哪个。一旦变更上线,团队可以利用生产环境中发生的情况来决定下一步构建什么。

工厂必须支持所有这些。而工程师无法单独设计那部分,因为他们通常不是主持研讨会或决定下一步的人。

如果只有工程师设计工厂,它就从现成的工单开始。弄清楚要构建什么仍然是别人的问题,一如从前。

你的 AI 工具有一个使用仪表盘,显示谁烧了多少 token。知道也不错,但这只是活动量。问它某个变更在通往生产的过程中发生了什么,它什么也答不上来。

工厂恰恰记录了这些,对每个变更,从产品负责人提出的要求到上线前发生的一切。每个决策都附带原因。所以几个月后,你仍然可以查是谁决定了什么以及为什么,以及这个变更实际花费了多少,哪怕所有相关人员早已忘记。

而这段历史对另一件事也很有用。它帮你发现工厂自身的错误。

如果同一个问题出现在二十个变更中,你可以追溯到它的根源并一次性修复。没有历史记录,就有人不停地手动修复,一个变更接一个变更,修二十次。

我见过的大多数工厂最终都能把共享规则和每个变更的记录做对。然后就停在那里了。对产品负责的人对工厂如何运作仍然几乎没有发言权。

John Cutler 最近写到软件工厂是一种身份防御,工程师向上移动一个层级以保持对生产资料的权威:

这些新兴的“工厂”大多似乎止步于现有职业的边界。

这与我从六月新书发布以来以及九月再次表达的观点一致。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →