AI Agents 正在让重构彻底消失
AI Agents and the Refactoring That Never Happens
日常使用 AI Agents 时，我观察到一个令人担忧的趋势：连资深工程师也悄悄放弃了重构那些最混乱的代码。过去，当人类无法在脑海中理清复杂逻辑时，这种“迷失感”会触发重构的本能。但 AI Agents 没有人类的工作记忆限制，它们能轻松驾驭混乱的系统，继续添加分支，却永远不会发出“代码已失控”的警报。这导致人类逐渐丧失了对代码的掌控力，代码审查沦为形式，团队开始盲目信任 Agent。更糟糕的是，混乱的代码不仅让人类难以理解，也会增加 Agent 的上下文负载和出错概率。我们必须在 Agent 无法自我反思时，重新建立人工检查点，主动询问是否该重构，否则我们将失去对系统的理解能力。
工具不再会因为迷路而提醒你该重构了，所以必须由你来主动提出这个问题。
HN 评论区
64- bunderbunder
我不同意“AI Agent 不会迷路”的说法。我观察到的实际情况是，它们不会体验到“迷路”的感觉。这完全是两码事。
今年夏天，我花了不少时间用一个编程 Agent 帮我梳理一个深层且复杂的数据处理流水线。这个流水线本身也是由 Agent 在极短的时间内构建出来的。但很明显，它漏洞百出，产生了大量错误数据。
我很快发现，我提出的问题中，高达一半会收到非常自信但完全错误的答案。而且，即使我终于诊断出当前正在处理的问题，也很难信任 Agent 去修复任何 Bug。因为它在追踪数据流方面比我还要吃力（借此机会提个建议：快并不一定代表好），它正逐渐变成一个“猴爪”（注：指实现愿望却带来灾难性后果的魔法物品）。是的，它会修复我要求它修复的确切 Bug，但通常在这个过程中会引入新的缺陷。是的，我在所有最新最强大的模型上都遇到了同样的挣扎。
我最终得出结论：在这个代码库中，Agent 确实是彻底、绝望地迷路了。（编辑补充：而且这个代码之所以一开始就烂成这样，很可能是因为当初构建它的 Agent 已经迷路很久了，但它们无法意识到这个问题，也无法提醒操作员。）
- joshstrange
与此同时，我正在尽可能多地重构那些由人类编写了数年（甚至数十年）的代码。将我从继承、参与创建或在其基础上构建的混乱局面，转变为干净 pristine 的状态，可能是我最喜欢的 LLM 用途。个人项目也是如此，那些在我有空闲时随时间演变、没能保持我期望的“整洁”的代码库，现在终于可以被清理了。
我一直_希望_我的代码干净易懂，但生活、截止日期、不断变化的优先级等等总是阻碍了我。现在，我终于可以实现我的个人涅槃了。
不过话说回来，我不得不引导模型避免过度抽象或类似的做法，因为这会让代码变得难以理解。
- simonw
我发现，能够使用编程 Agent 让我对那些可以重构的糟糕代码模式变得容忍度极低。
重构曾经有着非常真实的成本——这意味着必须从开发新功能的时间中挤出大量时间。
现在，我一旦发现潜在的重构机会，就可以向异步编程 Agent（或在工作树等环境中）发送一个提示，然后 20 分钟后再回来，要么接受它，要么稍微调整一下，要么直接放弃。这几乎不花我任何成本。
- joshka
很多情况感觉都归结于 Agent 的训练方式：它们被训练生成满足各种基准测试的代码，并对那些以前被视为不适应的行为做出反应。也就是说，这些行为是在后训练阶段被明确从模型中剔除的。我认为，模型默认写代码的方式中，似乎缺少了很多长期软件工程原则。
我有个推测：也许负责模型后训练的人往往是年轻的研究员，他们没有在大型复杂软件系统上工作过，因此在这方面对于“什么才是重要的”这一点的品味尚未成熟。
但这一个领域是可以通过适当的早期指令来引导的（“在选择实现权衡时，优先考虑代码的长期可维护性和可读性，而不是仅仅实现解决当前问题所需的精确代码。等等。思维链中往往包含未来 Agent 会话中需要重复的信息，请确保将其持久化到代码或外部文档中，以尊重未来会话和用户的理解。”）。
这也可以作为变更后的步骤来完成，效果类似。你可以利用你的 Agent 将这一层构建到你处理生成代码“罪行”的通用操作模式中。但所有 AI 实验室都应该做的一件事是，将真实项目中的 AGENTS.md 视为真实项目失败模式的硬性表达……
- moezd
AI Agent 经常迷路，特别是当代码库已经失控蔓延时。
你的自律只有在以下情况下才会奏效：你在开启功能开发狂热之前，已经理解了自己的代码和/或建立了清晰的标准基线。而且，这需要每一步都强制执行，否则代码生成的洪流会轻易地撞开大门。