软件工厂为何失败或：Harness工程并不足够 注意，我经营着一家公司（HumanLayer），专注于人类与代理协作领域的工具开发，所以我下面要说的内容可能有点偏见。尽管如此，我希望你能觉得这个话题有帮助，或者至少觉得它和我一样有趣。-Dex 我想我们现在正在进行循环。我们都在争着将AI编码投入生产。关于循环工程已经有很多讨论，主流观点是我们或许应该写更多的循环。 StrongDM写到了他们的无人值守软件工厂，那里没有人阅读代码，也没有人编写代码。这个叙述大概是这样的：你是瓶颈。模型已经足够好了。代码是免费的。只需发布更多的东西。Ryan Lopopolo来自OpenAI在二月份对此进行了讨论，并在四月份关于OpenAI的软件工厂Symphony发表了演讲。这些人都非常聪明，我对他们有很大的敬意。但这里最愤世嫉俗的看法或许是这只是又一个借口，让风险资本投入更多的“垃圾炮”。我们的朋友Mario在AI Engineer Europe的会上恳请我们放慢速度——因为一些根本不该因为编码代理故障而发生故障的公司，实际上发生了由于编码代理故障的故障。正如Matt Pocock所说，代码库的崩溃速度比以往任何时候都要快。我没有找到StrongDM关于整个黑暗工厂的确切数据/发现。今年二月到六月之间的天气报告只有几条零散的更新。Faros AI发布了一份报告：自从我们在一月和二月开始使用这些AI编码工具以来，拉取请求的审查质量大幅下降。评论增加，评论变长，而大量的PR在没有任何审查的情况下就被合并。事件数量大幅上升。每个开发者的Bug数量大幅上升。这份报告更像是一个相关信号，而不是一个可验证的确凿证据，而这篇文章的全部观点是在对“垃圾数据”保持警惕，但根据我所看到的，它似乎在方向上是有效的。 '你握错了'（其实你并没有）很多人会告诉你这是一个技能问题——如果你没有获得好的结果，那就是你的错。但无论你选择什么方式...嗯...握住它，我保证你会被告知，如果token-maxxing对你不起作用，那就是一个技能问题。你只需要花更多的token。放弃阅读代码。如果你刚开始接触这个，我保证这也是进步的一部分。去年的夏天我也是这样想的。不幸的是，我决定说的关于“如何更好地握住它”的一些愚蠢话被录下来了，现在在YouTube上有大约一百万的累计观看次数。我并不是想自夸，分享这一点只是为了证明我在使用编码代理的最佳方式上已经深入探索很久，并发现了一些许多人实际上发现有用的东西。 满足编码代理的高级上下文工程 不允许有气氛——解决复杂代码库中的难题 我们对RPI的所有错误认识 不管怎样，我们被迫忍受的所有在线“只需更好地token”的漫谈，简而言之是：通过足够的Harness工程，我们可以获得两个世界的最佳结果：10到100倍的速度，又高质量，而且不会有人不得不做那个我们都讨厌的代码审查。我们所需要做的就是配置更多的linter，并在足够的PR审查机器人上撒上“对抗性审核”这样的魔法词汇，我们的软件将愉快地自行构建，而不会出现问题。这不是一个技能问题 我想向你证明的是，没有多少Harness工程或loopsmaxxing可以解决一个根本上是模型训练的问题。为了弄清这一点，我必须深入了解编码模型如何实际训练和评估——无论是在RLVR方面还是基准测试方面。在这篇文章中，我将逐步介绍： 软件工厂起源于1968年，它们是如何演变的，AI又是如何改变它们的 为什么模型能够生成大量的垃圾尽管在基准测试中表现优秀（甚至是全新的“前沿”基准） 尽管如此，你可以以相当快的速度前进，而不会让你的代码库着火 我将努力切断每日新兴技能插件的炒作以及AI-心理病-tokensmaxxing建议流行病的干扰，并通常讨论那些有效的事物，而不提及任何特定的技能或框架。 视频版本：这篇文章是基于（并扩展于）我在2026 AI工程师博览会上的主题演讲。感谢@addyosmani，@CyrusNewDay，@HamelHusain，@zeeg，@dillon_mulroy，@nayshins以及@jeffreyhuber对这篇文章的反馈。 顺便说一句：这与气氛编码毫无关系。 Addy Osmani理清了一个值得强调的观点：一名开发者为一个十几个人才能运行的边项目进行气氛编码，而一个团队保持一个十年的企业系统在再活四分之一，它们几乎没有值得命名的约束。