智能体循环很棒，直到它们从你最糟糕的代码中学习

Steinberger上周末发文称他不再写代码，只设计智能体循环。Anthropic的Boris Cherny也表达了类似观点。他不向Claude提问，只创建循环，剩下的由它们处理。如果你在Anthropic工作且token几乎免费，那当然可以让它整天循环。但我们大多数人都在为智能体读取的每个文件支付真金白银。 完全披露：我经营一家软件交付公司，我们做了大量棕地项目，所以这是我这边看到的情况。 上个季度，我们在客户的核心产品上设置了智能体循环。智能体速度很快。一周内交付了四个功能。PR看起来整洁，CI通过，团队对此很兴奋。 然后安全审查发现了问题。所有四个功能都使用了团队两年来一直试图摆脱的模式。旧模式分布在代码库中的40多个文件中。新模式可能只存在于6个文件中。智能体查看了最常见的模式并遵循了它。 我是说，它为什么不呢？它不知道你的团队有迁移计划。它不读你的架构决策记录。它读你的代码。而你的代码告诉它已弃用的方式才是正确的方式，因为代码库大部分都是那样的。 代码审查中也没有人发现，因为每个PR都是功能性的。代码能工作……它只是以一种只有你知道团队正在积极放弃该模式时才会注意的方式错误。 在绿地项目中，智能体只能依据你的提示和系统指令。你控制上下文。在棕地项目中，代码库就是上下文，它会淹没你在提示中写的任何内容。40个文件每次都胜过一段指令。 每个人都在谈'88%的智能体项目在生产前失败'的统计数据。我认为有一个更糟糕的数字没人跟踪。有多少项目达到了生产环境并在所有可见指标上成功，同时却重新引入了团队本试图偿还的技术债务。因为我一直在看到这种情况。功能交付，速度在冲刺评审中看起来很出色，而代码库却在底层不断恶化。 我每周都会总结我们在100多个工程项目中看到的情况，[点击这里](https://thefoundation.limestonedigital.com/p/not-every-codebase-deserves-loops)如果你想了解更多这个话题。 总之，我不是说不要使用循环。我是说在将循环指向现有代码库之前，要弄清楚里面有哪些你不想让它学习的内容。因为它会从所有内容中学习。它不会区分哪些是好是坏。