为什么软件工厂失败（或者：利用工程还不够）

为什么软件工厂失败或：利用工程是不够的注意我经营一家公司（HumanLayer）在人类/代理协作领域构建工具，所以我下面要说的可能有点偏见。也许尽管如此，我还是希望您觉得这个主题有帮助，或者至少您觉得它和我一样有趣。 -Dex 我想我们现在正在循环我们都在竞相将人工智能编码投入生产。关于循环工程已经说了很多，普遍的看法是我们应该编写更多的循环。 1 StrongDM 描述了他们的关灯软件工厂，那里没有人读取代码，也没有人编写代码。叙述是这样的：你是瓶颈。模型足够好。代码是免费的。多运送点东西就可以了OpenAI 的 Ryan Lopopolo 在 2 月份写了相关文章，并在 4 月份发表了有关 OpenAI 的软件工厂 Symphony 的演讲。这些人都非常聪明，我非常尊重他们。但最愤世嫉俗的说法是，这是向污水大炮注入更多风险投资资金的另一个借口。我们的朋友马里奥在欧洲人工智能工程师站起来，恳求我们放慢速度——因为那些没有业务因编码代理事故而造成停机的公司，现在……因为编码代理事故而造成停机。正如 Matt Pocock 所说，代码库的崩溃速度比以往任何时候都快。我无法从 StrongDM 中挖掘出任何关于整个黑暗工厂如何运作的明确数据/调查结果。今年二月至六月期间的天气报告有一些稀疏的更新。 Faros AI 的人员发布了一份报告：自从我们 2 早在 1 月和 2 月就开始使用这些 AI 编码工具以来，拉取请求审核质量就大幅下降。更多的评论、更长的评论以及大量的 PR 被合并，根本没有任何评论。事故数量大幅上升。每个开发人员的错误数量大幅增加。这份报告更像是一个相关信号，而不是一个可验证的确凿证据 3 ，这篇文章的重点是对溢出数据保持警惕，但根据我所看到的情况，它感觉有方向性。 “你的做法是错误的”（你没有） 很多人会告诉你，这是一个技能问题——如果你没有得到好的结果，那是你的错。但无论你选择......呃......持有它，我保证你被告知，如果令牌最大化不适合你，这是一个技能问题。你只需要花费更多的代币。放弃阅读代码。如果你刚刚到达那里，我保证这是进步的一部分。去年夏天我也是这么想的。不幸的是，对于我的自尊心来说，我决定说的一些关于“如何更好地保持它”的愚蠢内容被记录下来，现在在 YouTube 上的累积观看次数约为 100 万次。我并不是想在这里吹牛，我分享这一点只是为了证明我长期以来一直在深入研究使用编码代理的最佳方法，并且发现了一些许多其他人认为真正有用的东西。编码代理的高级上下文工程不允许产生共鸣 - 解决复杂代码库中的难题我们对 RPI 的一切都错了无论如何，我们被迫忍受的所有在线“只是象征性的更难”的叫喊的承诺是，简而言之：通过足够的利用工程，我们可以两全其美：速度提高 10 到 100 倍，高质量，而且没有人必须做我们都讨厌的称为代码审查的事情我们所要做的就是配置更多的短绒，并在足够多的公关审查机器人上撒上一些像“对抗性审查”这样的魔法词，我们的软件就会很高兴地自行构建，不会发生任何事故。这不是一个技能问题。我要尝试让您相信的是，再多的线束工程或循环最大化也无法从根本上解决模型训练问题。为了解决这个问题，我必须深入研究编码模型的实际训练和评估方式 - 涉及 RLVR 和基准方面。在这篇文章中，我将介绍： 软件工厂可以追溯到 1968 年，它们是如何演变的，人工智能是如何改变它们的 为什么模型可以在 ace-ing 基准（甚至是全新的“前沿”基准）的情况下生成大量的斜坡 尽管如此，你可以快速移动而不会让你的代码库着火 我将尝试消除每个日常新兴技能插件的炒作和 ai-psychosis-tokenmaxxing 建议流行病，并谈谈概括地讲，在不涉及任何特定技能或框架的情况下，可以工作的事物类型。视频版本：这篇文章基于（并扩展）我在 2026 年人工智能工程师世界博览会上的主题演讲。感谢 @addyosmani 、 @CyrusNewDay 、 @HamelHusain 、 @zeeg 、 @dillon_mulroy 、 @nayshins 和 @jeffreyhuber 对本文的反馈。旁白：这与氛围编码无关 Addy Osmani 理清了值得强调的事情：一个开发人员对一个十几个人将运行的副项目进行氛围编码，而一个团队让一个已有十年历史的企业系统再存活一个季度，几乎没有任何值得命名的约束