永恒的 Sloptember：为什么 AI Agent 可能是软件工程中最昂贵的错误

AI Agent 在软件开发中的承诺通常被描绘为向全面生产力的飞跃——一个工程师只需描述功能，Agent 即可实现的境界。然而，George Hotz (geohot) 认为这种轨迹并非向前迈进，而是一个代价高昂的错误。他认为 AI Agent 实际上并不“编程”；相反，它们是模仿编程分布的复杂统计模型。

这种区别至关重要。当一个模型模仿编程时，它产生的输出看起来是正确的——语法有效，语法专业——但在人类越来越难以检测的方面存在根本性的缺陷。Hotz 将这种现象称为“slop”，并警告说我们正在进入一个“永恒的 Sloptember”，即生成的代码量远超人类验证其能力的范畴。

进步的幻觉

对于许多人来说，与 AI Agent 的初步体验是令人陶醉的。它们提供即时的进步感，以荒谬的速度冲破样板代码和原型。但正如 Hotz 所观察到的，这种进步是前置的。一旦初始结构就位，过程往往会退化为一种“老虎机”模式，开发者不断拉动杠杆（重新提示词），希望 Agent 最终能达到生产级软件所需的完善度和正确性。

这创造了一个危险的悖论：这些工具足够快，可以在几分钟内构建出原本需要数天才能完成的原型，但它们在达到最终 5% 的质量要求时却显得力不从心——而这部分正是稳定性、边缘情况和长期可维护性所在之处。

组织风险：高绩效者 vs. 平均水平

讨论中最具挑衅性的观点之一是，AI Agent 将对大型组织的影响比对个人或小型、高绩效团队的影响更大。其逻辑在于错误修正的反馈循环。

高绩效者： 通常具备强大的错误修正能力。他们将 AI 视为一种“外骨骼”——一种加速意图实现的工具，而非取代批判性思维的工具。他们会阅读并理解 Agent 产生的每一行代码。
大型组织： 通常面临反馈循环较慢和一致性较低的问题。在这些环境中，表现不佳的员工可能会利用 Agent 产生 10 倍于以往的代码量，却不进行必要的自我检查。

结果是，组织的平均输出可能会向“slop”偏移。当表现不佳的员工产生大量看似合理但脆弱的代码时，组织的整体技术债务会呈指数级增长，即使“生产力”指标（如代码行数或功能开发速度）看起来在上升。

“正确的问题”与品味的侵蚀

除了技术漏洞，还存在更深层的架构风险。社区讨论中一个反复出现的主题是“解决正确的问题”这一概念。

解决正确问题的能力是区分顶级资深工程师的关键…… AI Agent 掩盖了错误设计带来的摩擦力。它们并不修复它；它们只是让这种成本被推迟了。

在传统的工程实践中，一个糟糕的设计选择会产生摩擦力，从而减慢开发速度，这本身就是一种自然信号，提示设计需要重新审视。AI Agent 移除了这种摩擦力。它们可以极其高效地实现一个糟糕的设计，以至于开发者在系统达到灾难性规模之前，根本无法意识到设计存在缺陷。这面临着培养出一代从未开发出健全架构的“品味”或直觉的风险，因为他们从未因设计选择的后果而挣扎过。

反方观点： “10x”差距与领域特定性

并非所有人都认同这种悲观的观点。许多开发者认为，AI 的效用完全取决于用户的技能水平和任务的领域：

弥合差距： 对于那些不是“10x”大神级别的工程师，Agent 可以弥合差距，允许他们在时间限制内实现复杂的系统（例如一个 Debian package caching proxy），这在以前是不可能的。
领域差异： 低层级系统编程（如 USB reverse engineering）与高层级应用开发（如 Node.js CRUD apps）之间存在显著差异。在后者中，模式高度重复且样板代码繁多，AI Agent 通常被视为不可或缺的工具。
审查流程： 有人认为问题不在于 AI，而在于缺乏纪律。如果一个团队维持严谨的 diff reviews，并为每个 Agent 会话定义严格的范围，那么无论初始代码是由谁（或什么）编写的，代码库的质量都能保持稳定。

结论：过程至关重要

归根结底，这场辩论的核心在于编程是否是一种统计学练习，还是一个推理过程。如果编程仅仅是 token 的分布，那么 LLMs 几乎已经做到了。但如果编程需要一个“世界模型”——即对系统在物理或逻辑环境中如何运行的理解——那么基于当前的 RL-based models 则是从根本上受限的。

随着我们进入 AI 辅助开发时代，真正的挑战将不在于模型的能力，而是使用它们的人类的纪律律。目标是避免“AI 精神病”，即对速度的追求压倒了理解的必要性，导致软件世界变成一个由偶然因素驱动运行、由设计缺陷驱动崩溃的世界。