AI 写代码越快，软件却越容易坏：一位开发者给“代理编程热”泼了盆冷水

过去一年，AI 编程代理像突然闯进办公室的新同事：干活快、不嫌累、还能 24 小时在线。OpenAI、Anthropic、Cursor 这波工具把“让机器写完整项目”从演示视频变成了不少开发者的日常体验。很多人第一次感受到那种近乎魔术般的爽感：一句需求丢过去，几小时后，一个网站、一个 App、一个后台系统竟然真能跑起来。

问题也正出在这个“竟然真能跑起来”。奥地利开发者 Mario Zechner 最近写了一篇火药味很浓的文章，核心观点其实很朴素：软件行业可能该慢下来一点了。因为 AI 代理正在把代码生产速度推到前所未有的高度，但我们的理解、审查、维护能力，并没有同步升级。结果就是，代码越来越多，系统越来越脆，出了问题也越来越不知道该怪谁。

当“能跑”代替“可靠”，软件世界开始变脆

Zechner 的观察很尖锐：今天的软件，像是进入了一种集体发虚的状态。大厂服务的稳定性时不时掉链子，UI 会冒出匪夷所思的小毛病，用户经常在更新后撞上一些本该由 QA 提前拦下的低级错误。单个案例当然不能证明一切，但把这些现象串起来看，很难不让人怀疑，AI 正在改变软件生产的底层节奏。

这件事真正危险的地方不在于“AI 会犯错”——人类程序员也会。危险在于，AI 犯错的方式和人不一样。人写错几次，通常会被线上事故、同事 code review、甚至自己的痛苦教育一遍，慢慢知道哪些坑不能踩。AI 代理没有这种天然的学习闭环。它会重复犯同一类错，而且因为速度太快，错也能像流水线产品一样批量复制。

一个人类工程师一天写 500 行问题代码，已经够团队头疼了；一个代理系统半天吐出 2 万行“勉强能跑”的代码，那就不是头疼，是技术债开闸泄洪。更糟的是，团队往往要到几周或几个月后，才会真正感受到这笔债的利息有多夸张。

代理不是同事，它更像一台没有疼痛感的代码打印机

这几年 AI 创业圈里最流行的叙事之一，就是“软件工厂自动化”：把任务拆给一群代理，让它们自己搜索代码、自己修改、自己测试、自己提交，最后人类只负责点头验收。听上去很像工业革命进入软件业，实际落地常常更像“把初级工程师、架构师和实习生的工作，全外包给一个记忆不稳定的概率模型”。

Zechner 批评的，正是这种“人退出回路”的冲动。今天很多团队迷恋的并不是 AI 本身，而是那种几乎上瘾的速度感：今天做十个功能，明天再接二十个需求，反正代理会写。于是 code review 变成走过场，架构判断交给模型，产品边界也逐渐失守，最后项目里堆满了一大堆用户压根没要过的功能。

这让我想到前几年互联网行业也经历过类似的效率幻觉：低代码平台曾承诺“人人都是开发者”，微服务曾被滥用到“一个按钮也要拆三个服务”，如今轮到代理编程把这种幻觉推向极致。技术史一直在重复一个朴素规律：凡是把“产量”误当成“能力”的阶段，后面总有人回来收拾残局。

真正的问题，不是代码臭，而是你已经看不懂它为什么臭

文章里有个说法我很认同：AI 代理会成为“复杂性的商人”。这不是说模型天生喜欢把事情搞复杂，而是它从训练数据里继承了大量现实世界的软件坏习惯——过度抽象、层层封装、重复造轮子、为了“最佳实践”而最佳实践。模型不知道你的系统为何存在，它只能根据局部上下文，拼出“像那么回事”的结构。

一开始，这些问题看起来都不大。多几个重复方法，多一个没必要的类型，多一层无意义封装，似乎也不会立刻把产品拖死。但当这些“无伤大雅”的小毛病，以代理的速度持续积累，代码库很快就会变成一团看似井然有序、实则谁也不敢碰的毛线球。

更麻烦的是，AI 代理对大型代码库的理解能力，并不会随着代码量线性增长。它需要先“找到”相关代码，才能修改正确的地方。无论你给它 ripgrep、LSP、向量数据库还是花里胡哨的代码索引，本质上都绕不过一个问题：代码库越大，检索召回越差。找不全，就会遗漏已有实现；遗漏已有实现，就会重复造一份；重复一多，不一致也就冒出来了。最后，测试也未必可信，因为测试本身可能也是代理写出来的。

这就是今天很多团队最隐秘的焦虑：不是系统坏了，而是没人再敢说“我知道它为什么坏”。

那 AI 编程代理还有没有用？有，但它更适合当副驾，不适合接管方向盘

Zechner 并不是反对 AI 写代码。他反对的是，把判断力、边界感和系统设计统统交出去。这个区分很重要。因为现实里，AI 代理当然有价值——尤其是那些边界清晰、可验证、就算出错也不会直接伤筋动骨的任务。

比如写内部小工具、做一次性脚本、尝试性能优化思路、快速搭原型、整理文档、补测试、阅读陌生仓库时做“橡皮鸭式”讨论，这些都很适合交给 AI。Karpathy 那类自动研究工具之所以有意思，就在于它们往往有明确评估函数：启动时间是否变短，loss 是否下降，基准成绩是否提高。模型只要围着单一指标打转，就有机会把人类从重复劳动里解放出来。

但一旦任务变成“定义系统长什么样”“API 应该如何设计”“哪些功能根本不该做”，这就不再只是编码问题，而是产品判断、工程经验和审美的问题。至少在今天，这些能力还远不是主流模型能稳定替代的。你可以让 AI 帮你搬砖，但别让它替你决定房子怎么盖，门该开在哪儿，承重墙能不能拆。

慢下来，可能是 2026 年最不性感、却最重要的工程建议

我很喜欢这篇文章最后的态度：慢一点，不是保守，而是重新把人的责任感放回软件开发里。写得慢一点，意味着你有时间问一句“这个功能真的需要吗”；让代理少生成一点，意味着你还来得及认真 review；架构自己来，意味着出了故障你还能进去修，而不是站在一团陌生代码前祈祷下个模型版本更聪明。

这在当下尤其重要。因为整个行业都在被“AI 提效”这件事推着向前冲，谁不用代理，仿佛谁就落伍了。可软件不是短视频平台，不能只比产量和更新频率。用户真正记住的，从来不是你一周上线了多少功能，而是关键时刻它会不会崩、数据会不会丢、界面会不会突然抽风。

如果说 2023 年到 2025 年是大家争先恐后把 AI 引入开发流程的阶段，那么 2026 年也许会进入一个更现实的周期：哪些任务适合代理，哪些环节必须保留人为摩擦，哪些团队已经因为“过度自动化”开始返工。行业总会从狂热回到常识，只是这次，学费可能是用线上事故和不可维护的代码库来交。

说到底，AI 编程最该节省的，不是思考，而是无聊劳动。把最珍贵的判断力也一起外包掉，才是真正昂贵的地方。