给 AI「明星开发者」收拾烂摊子:被外部化的技术债
Jesse Skinner 把 AI 编码工具比作一支随叫随到的「明星开发者」大军:产出飞快,代码却没人维护得起。真正的工程难题不在写得多快,而在谁来兜底。
概述
Jesse Skinner 写了一篇短文《Cleaning up after AI rockstar developers》(给 AI 明星开发者收拾烂摊子),被 Hacker News 顶到 486 赞。文章结构很简单。它先回忆那种典型的「明星开发者」:精力旺盛、痴迷新技术、重写整个核心架构、引入一堆别人没听过的语言和库、把大多数 pull request 都打回去、把团队的标准抬得越来越高,然后某天突然嫌无聊跳槽去了更大的公司,留下一堆没人看得懂的代码。接手的人想修一个小 bug,光是把代码在自己笔记本上跑起来就花了一周。他向老板提议重写,老板不信,因为「那可是明星本人写的」。
文章的转折在于,Skinner 说,过去这些年,大多数团队已经被「一支明星开发者大军」淹没了。每开一个新的对话窗口,就有可能往团队里加进一个新的明星。这支大军就是 LLM 编码 agent,它一分钟生成上万行代码,只想把任务以「非人类的速度」完成,不在乎这段代码能不能跟系统里其它代码融洽相处,也不在乎系统是变得更好懂还是更难懂。这篇文章真正的价值不在于它骂了 AI,而在于它精准地指认了一个被产出数字掩盖的问题。AI 编码工具放大的不只是写代码的速度,还有技术债和维护负担的累积速度。Skinner 借「明星开发者」这个所有工程师都吃过亏的旧形象,把一个新现象讲清楚了。
他抓住了真问题,但诊断里混进了一部分其实是「人和组织」的老问题。下面分开看。
争的是什么
表面上争的是「AI 写的代码到底是不是 slop(垃圾)」,但这不是最有价值的那一层。真正在争的是两件事。
第一件:成本到底有没有被外部化。Skinner 的核心控诉是,明星开发者(以及 AI)把愉快的部分留给了自己,把痛苦的部分甩给了团队里的其他人。愉快的是飞快地产出、用最聪明的写法、不停尝新;痛苦的是读懂、维护、清理技术债。他说自己接过很多帮人「收拾明星烂摊子」的活儿,而收拾 AI 生成的烂摊子比收拾真人明星的还难。真人明星至少心里有一个设计,是在认真做事;而一堆 vibe coding(凭感觉编程)出来的 slop,是几百个不同对话、不同上下文里、一次一个功能拼出来的,等于一份由几百个互不通气的明星各写一段的代码。他甚至说,有时候技术债多到永远还不清。这个「外部化」的指控,是全文最经得起推敲的部分,因为它说的不是代码质量的绝对值,而是成本的转移方向:谁享受了速度,谁承担了后果。
第二件:这到底是 AI 的问题,还是人和组织的问题。HN 上的评论几乎立刻把矛头从 AI 转向了管理。一位高赞评论者 wccrawford 说得很直白:你不该「替他们收拾」,你该「让他们自己收拾」,从一开始就不让烂摊子进系统。他回忆自己带新人时,如果对方反复犯一堆错,他就只看到第一个错误就打回去,逼对方学会别再把一堆错误丢给评审者。这其实是在说,问题不在 AI 写得烂,而在评审这道闸门被打开了。
谁更有理
两边各对一半,而把两半拼起来,才是这件事的全貌。
Skinner 对的地方,在于他指出了「速度」与「可维护性」之间被 AI 重新拉开的剪刀差。HN 上有人把这一点讲得比原文还清楚。评论者 sumeno 说,LLM 能以过去不可能的速度生成「立刻就需要重构」的代码;过去一天里能制造的技术债是有物理上限的,现在这个上限提高了十倍甚至一百倍,而它被制造出来的速度远快于它被修复的速度。另一位 andwur 补充了两个新变量。其一,AI 生成代码库的增长速度远超人类,过去要几年才能堆出来的烂摊子,现在几天几周就能堆出来。其二,过去的大型烂代码库里通常混着不同水平的开发者,总有几个能把局面拉回来,而纯 AI 生成的代码里这种「理智的线头」更少。这些都是对 Skinner 的有力支持。他不是在怀旧,他指出的是一个量变到质变的拐点。
但反方也抓到了 Skinner 没说透的地方。HN 上反复出现的一句话是,这是「人的问题」,不是「AI 的问题」。一位被 SEV-0 事故折磨到只睡了两小时的工程师 elzbardico 说,他并不反 AI,反而感谢 AI 帮他「放大战斗力」,但人「仍然」得审那些代码,而审代码的人「仍然」得自己有能力写出来才行。真正逼疯他的,是公司勒令他把仓库设置改成「一次 AI 评审就够了」,也就是把人类评审这道闸门直接拆掉。还有评论者 piva00 描述了更上游的压力:他的经理被上面下了「必须开始写代码」的指标,整个团队都不想这样,只能帮经理凑出点东西给高层看,免得因为某个 C-level 对 AI 的焦虑而失去一个好经理。这些都在说明,AI 没有创造一个新问题,它放大了一个旧的组织纪律问题,即谁在抬高产出指标、拆掉评审闸门、放任「能跑就行」的代码进生产。Skinner 把病灶定位在工具上,HN 的工程师把病灶定位在管理上。后者其实更接近根因,但前者点出的「速度差」是这个根因在 AI 时代被放大的具体机制。两者不矛盾,合起来才完整。
为何重要
对工程团队来说,这件事重要,是因为它把一个一直存在、但现在变得致命的管理选择摆到了台面上:你要不要为 AI 产出设一道真实的所有权和评审闸门。
过去,一个不负责任的明星开发者,产出速度终究受限于一个人的手速;现在,任意一个团队成员配上一个 coding agent,就能以远超团队消化能力的速度往代码库里灌东西。这意味着,「代码评审」「代码所有权」「可维护性」这些一直被当成软约束、可松可紧的东西,现在变成了硬约束:松一寸,技术债就以十倍速涌进来。HN 上 SlinkyOnStairs 的一条评论点破了一个更冷的现实:技术债之所以长期赖着不走,往往不是因为没能力清理,而是因为组织不愿承担「动了那段冷代码」的责任。「它在生产环境跑得好好的,你一碰就坏了,以后别碰任何东西」这种动力学,不会因为换成 AI agent 就消失。换句话说,指望「让 AI 自己去还技术债」是个幻觉:还债的障碍从来不是产能,是问责。
对做 coding agent 产品的 builder 来说,这篇文章其实是一份需求清单,值得反过来读。Skinner 抱怨的每一条,都是产品该解决而大多没解决的。agent「不记得昨天做了什么」,对应跨会话的记忆与一致性缺失;它「不在乎新代码跟系统其它部分合不合得来」,对应缺少对整体架构的感知与约束;它默认「belt and suspenders(双保险)」式的过度工程,对应缺少对复杂度与收益的权衡;它一审代码就甩一长串你并不认同的改进建议,对应评审噪音和缺乏对项目语境的尊重。HN 上已经有人在描述应对方式。kaydub 说他接受「每写一段就要一到五段提示词来清理」,会让 agent 自己拆成多个子 agent 去查重复代码、坏架构、可测试性。evilturnip 说他会让模型「把整个系统讲回给他听」,把这段对话留在上下文里,模型重构时反而更准。这些都是用户在产品缺位的地方手动打的补丁。谁能把「让 agent 产出天然满足可维护性约束」做进产品,而不是把这件事甩回给用户用提示词硬凑,谁就抓住了下一阶段 coding agent 的真正护城河。这一波的胜负手正在从「能不能写出来」转向「写出来的东西团队接不接得住」。
该忽略什么
有几条声音应该打个折扣。
第一,「AI 生成的代码就是垃圾、应该被彻底废弃」这种全盘否定。HN 上确实有评论者(如 349187)期待早晚能 publish「生成式 AI 就是垃圾」的不加掩饰的观点,但这既不是 Skinner 的立场,也不站得住。Skinner 自己的结尾恰恰相反。他列了一整节「怎么用 LLM 而不让它变成明星」:你来主导工程、引导 LLM 一次只生成一小段、确保代码写成全队都能看懂和维护的样子;迷路时就「踩刹车」,慢一点没关系,反对过度工程、把架构简化到与问题复杂度相匹配。把这篇文章读成「AI 编码无用论」,是误读。
第二,另一个极端同样要忽略,就是「再扔 AI 进去就能解决」。HN 上有人(pu_pe)设想未来会有「技术债 agent」通宵跑着清债,bigstrat2003 的回应一针见血:用「不会做好工程」的 AI 制造的债,解法是「再扔更多 AI」?这让人想起那句关于「精神错乱的定义」的老话。结合前面 SlinkyOnStairs 关于「问责才是障碍」的观察,这条该忽略的理由很清楚:技术债不是算力问题。
第三,关于「这根本不是新问题」的争论,要分清哪部分该听、哪部分该放下。多位资深评论者(AndrewKemendo 反复强调)说,清理别人的烂代码、refactor(重构)老项目,是过去三十年软件工程的日常,跟当年清 VB 或 PHP 的意大利面条代码没本质区别;penultimatename 则指出,现代工程组织本来就不爱重构能跑的东西,因为重构很难对齐「交付价值」。这部分洞察是对的,值得听。它提醒我们别把组织老毛病当成 AI 新罪状。但「没有任何新东西」的结论该放下:正如 sumeno 和 andwur 指出的,速度和规模本身就是质变。该忽略的不是「这是老问题」这个事实,而是「所以不必特别对待」这个推论。
对建设者的影响
如果你在做面向团队的 coding agent,这篇文章和它底下的几百条评论是一份免费的、带情绪的用户访谈。最该记住的不是「开发者讨厌 slop」,而是他们已经自发形成了一套手动流程来兜底:接受多轮清理提示、让 agent 自审并拆子 agent 分工、让模型复述系统再动手重构、用 lint 和类型检查当闸门。这些流程现在是用户的负担。谁能把它们变成产品的默认行为,谁就站到了正确的一侧。所谓默认行为,是让 agent 默认就生成小而可读、契合既有架构、附带可测试性的代码,并把「让人类保有所有权和评审权」设计成不可绕过的环节。反过来,任何鼓励用户「拆掉评审闸门、一次 AI 评审就够了」的产品设计,都是在帮客户加速积累那种「永远还不清」的债,短期好看,长期会反噬口碑。craftsmanship(手艺)这件事,正如 Skinner 所说,是少数无法外包给机器的东西。聪明的产品不替用户把它外包掉,而是帮用户更省力地保住它。
来源
无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。