" 我现在就下判断：把 AI 代理引入软件开发，将是这个领域历史上代价最昂贵的错误之一。" 说这话的是乔治 · 霍茨（George Hotz），文章《永恒的劣质九月》（The Eternal Sloptember）开篇即抛出这句断言。该文发布于 2026 年 5 月 24 日，次日即被 Decrypt 与 The Decoder 报道。

这篇文章距今已有五个月。其中反复被引用的一句是：" 输出是坏的，但坏的方式正变得越来越难以察觉。"

当时的多数回复都在争论霍茨 " 代理不会编程 " 这个判断对不对。这个争论点其实不是最有意思的部分。更锋利的主张埋在文中几段之后，讲的是谁来承担这些坏代码的代价。

霍茨到底说了什么

霍茨不是站在场外说这话。他称自己花了大约六个月，跨不同模型、不同执行框架和提示词，试图让代理真正跑起来。他用在了自己的深度学习框架 tinygrad 的部分工作上，也用在逆向一款 USB 转 PCIe 芯片的固件上。他写道，每一次他都觉得自己亲手做会更好、更快。

他对这种模式的描述，跑过真实代码库的人不会陌生。用他的话说，" 代理把所有进展都前置了。"大部分工作看起来出现得很快。然后你就像在拉老虎机拉杆，指望最后那段打磨能自己冒出来。按他的说法，它始终没能真正冒出来。

他认为，强工程师会仔细读代码并持续修正，这本身就是一道自检。" 表现最差的那批人不会有这道自检。" 这些人如今能产出比过去多得多的代码，他预计随着产出量上升，大公司的平均代码质量会下滑。他还反问了一句：" 你觉得 macOS 在未来两年会变好还是变坏？"

霍茨还表示，他现在站在 "LeCun/Marcus 阵营 " 一边：他认为真正的编程代理需要世界模型，而不是更好的语言模型。

乐观派说的其实是同一件事

安德烈 · 卡帕西（Andrej Karpathy）站在另一边。他一直主张代理已经改变了软件的写法。在霍茨发文五天前，他加入了 Anthropic 的预训练团队。

在红杉资本的 AI Ascent 2026 活动上，卡帕西与 Stephanie Zhan 对谈时这样描述代理写出的代码：" 有时候我会有点心脏病发作的感觉，因为它未必总是特别出色的代码。它非常臃肿，有大量复制粘贴，还有一些别扭又脆弱的抽象。"

同一场对谈里，他说人类最终要握住的东西是：" 你基本上仍然要负责审美、判断、品味，还有一点点监督。" 他还转述了一条推文的说法：" 你可以外包你的思考，但你无法外包你的理解。"

把两段话并排放。悲观者说输出坏得难以察觉。乐观者说输出能用，但臃肿、复制粘贴、脆弱，必须由一个具备理解力的人来把关。他们对趋势的判断不同，描述的却是同一种代码。

霍茨和卡帕西描述的是同一个缺陷。差别在于，谁看得足够仔细，能把它看出来。

买单的不是模型

霍茨预测的代价，最终落在一个 " 批准 " 动作上。某个分不清脆弱代码和好代码的人，在一个看起来没问题的 diff 上点了合并。模型产出了 bug，批准动作把它放进了生产环境，而运行这段代码的团队来买单。

霍茨自己的表述就指向这里。高绩效者能抓出错误，是因为他们知道在那个代码库里 " 正确 " 长什么样。卡帕西用自己的话说的是同一件事：你无法外包理解。两个人都没有说，解法是换一个更好的模型。

所以大多数团队拧的那个旋钮，拧错了方向。代理的推广按席位数量来规划：谁拿到许可证、每天跑多少任务、允许用哪些代理。这些都没有回答一个问题——批准这个 diff 的人，自己能不能写出这段代码。

更该拧的旋钮，是按代码区域划分的自主权，并与审查者对该区域的熟悉程度挂钩。这不需要新工具就能起步。GitHub 已经支持按路径路由审查，一个放在.github/下的 CODEOWNERS 文件就能指明谁拥有哪些路径：

/src/billing/ 归支付团队

/src/auth/ 归身份团队

/firmware/ 归固件团队

在分支保护规则里打开 "Require review from Code Owners"，一个动到计费模块的 diff，就必须由拥有计费模块的团队批准才能落地。这条规则不关心 diff 是人写的还是代理写的，只关心有没有那个团队的人签字。

Hermes 的位置

我开发 Hermes IDE，读这一节时请把这一点考虑进去。Hermes 是一个桌面应用，让 Claude Code、Codex 这类代理在各自的终端里运行，每个任务落在独立的 hermes/ 分支和 worktree 上。

与这里相关的是审查环节。霍茨的抱怨有一部分是关于体量：代理把大量改动前置，而大 diff 正是坏代码藏身的地方。Hermes 保存代理的每一轮输出，因此你可以对单轮做 diff 或恢复，并支持撤销。Review Desk（macOS 上⌘ G，Windows 和 Linux 上 Ctrl+Shift+G）按轮次或按文件展示改动，带风险标记，你还可以把行内评论发回给写下那一行的代理。

逐轮阅读，正好对应上面那张表。代码所有者可以让代理一次跑更大的轮次，然后逐轮读。对代码更陌生的人，则可以把轮次压小，把疑问以行内评论的形式推回去，而不是批准自己没看懂的东西。

Hermes 并不知道代码对不对。风险标记只是把你的视线引向某处，它替代不了对代码库的了解。Hermes 可免费下载，源码在 BSL 1.1 下开放，支持 macOS、Windows 和 Linux。它与 Nous Research 及其 Hermes Agent 没有关联。

霍茨哪里说过头了

" 代理不会编程 " 是关于模型的判断。他的证据却是关于具体工作的：一个他自己写的、了如指掌的框架，以及固件逆向——这大概是离样板代码最远的一类工作。在这些工作上，他正是最有条件看出代理错在哪里的审查者，而他决定宁愿自己动手。对他而言这是合理的判断。但这推不出 " 任何人任何地方都不该用代理 "。

卡帕西的立场覆盖了另一种情况：代理有用，而人类仍然拥有判断权。当批准代码的人对眼前这段代码不具备那种判断力时，两种立场会以同样的方式失效。

如果霍茨的预测成真，它会一次一次合并地成真——由某个写不出这个 diff 的人批准，发生在一个按席位数量统计推广成果的团队里。