清理AI明星开发者留下的烂摊子
摘要
本文探讨了那些编写代码巧妙但难以维护的“明星开发者”现象,并将其与AI生成代码带来的挑战进行类比,强调了可维护性和团队协作的重要性。
<p><a href="https://lobste.rs/s/uvwcdo/cleaning_up_after_ai_rockstar_developers">评论</a></p>
查看缓存全文
缓存时间: 2026/06/09 08:44
# 清理 AI“摇滚明星”开发者留下的烂摊子 —— Jesse Skinner
来源:https://www.codingwithjesse.com/blog/rockstar-developers/
*音频调音台上缠绕的线缆*
摄影:Martijn Baudoin(https://unsplash.com/@martijnbaudoin?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText),来自 Unsplash(https://unsplash.com/photos/audio-mixer-set-4h0HqC3K4-c?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
我们都曾与“摇滚明星”开发者共事过。他们多年前加入团队,充满干劲。他们满脑子都是关于新技术、新范式、新架构的绝妙想法。这些前沿理念让其他人感到自己落后、过时。
他们重写了公司大部分核心架构,引入了新的构建流程、新工具、新语言。他们驳回大多数拉取请求,提高了对所有人的期望标准。没人能理解他们写的代码,但谁也不愿承认。
所有最棘手的任务都派给了这位“摇滚明星”。他们总能比任何人都更快搞定。工程听起来总是非常惊艳,即便只有他们自己清楚整套系统是如何拼凑起来的。
相比之下,其他人进展缓慢得多。每个人都在拼命追赶,学习新的库,按照“摇滚明星”的方式做事。
几年后,他们突然离开了。他们厌倦了,想要去一家更大的公司,参与更具挑战性的项目,找一份更好的工作。
## 收拾残局
突然间,你被要求接手“摇滚明星”的项目。你扎进代码里,发现自己被活埋了。数据的流向极难追踪,简直像有人试图掩盖一桩谋杀案。
你开始尝试修复一个简单的 bug。光是让代码在你的笔记本上跑起来就花了一周。
一半代码是用你不懂的语言写的,另一半则用着你从未听说过的库。
你试图告诉老板,你觉得代码需要重写。他们不信,因为那是“摇滚明星”本人写的。当你在这堆“烂泥”中挣扎时,你翻看着招聘信息,幻想着离职。
## 清理“摇滚明星”的烂摊子
我与许多团队和机构合作过,他们需要我来清理这些“摇滚明星”留下的烂摊子。实际上,我很喜欢挑战——尝试理解并拯救一团糟的代码库。就像坐下来,面对一盒缠成一团的装饰灯,把它们一根根拆开,直到可以重新使用。
在这个过程中,我观察到一些模式。这些“摇滚明星”极其热爱编码、学习和使用新范式,这一点很明显。他们总是在能力的边缘试探,写出自己能想到的最聪明的代码。他们专注于尽可能快地前进。
可惜,这些“摇滚明星”最不关心的,就是如何写出别人能协作的代码。
## 人工智能登场
过去几年里,大多数团队都被一群“AI 摇滚明星”淹没了。每次有人开始一个新的聊天会话,就有风险给团队添一个“摇滚明星”。
这个 agent 不记得它昨天做了什么。它乐于在几分钟内生成成千上万行代码。它以非人类的速度完成任务。它不在乎这些代码是否能与系统中其他代码兼容,也不在乎系统是否变得更易理解,还是变得更糟。
AI 手里有一套最佳实践工具箱,但这些实践很可能并不适用这里。它固执地坚持“两手准备”的做事方式,哪怕复杂度远超收益。当被要求审查你的代码时,它会列出一长串改进意见,其中很多你并不同意。门槛被抬高了,许多人觉得他们必须使用 LLM,否则就会永远落后。(不过我相信,最终被落在后面的,会是那些让 LLM 写所有代码的人。)
面对如此多的生成代码,系统的复杂度可以呈指数级增长。它可能变得如此复杂,以至于理解它的唯一方式就是借助 LLM。开发者、团队、整个公司都可能对生成式 AI 上瘾、产生依赖。
## 清理成百上千个 AI“摇滚明星”的烂摊子
收拾一堆“烂泥”可不像清理一个“摇滚明星”的烂摊子那么有趣。至少“摇滚明星”心中还有某种设计,并且尽力做到最好。
而一堆“氛围编程”出来的烂泥,并不是由一个人工开发者写出来的。它来自许多不同的聊天会话,不同的上下文。就像是由成百上千个不同的“摇滚明星”一次一个功能或一个 bug 修复写出来的代码库。
有时候技术债务堆积到永远无法偿还。
## 构建经得起时间考验的软件
有很多使用 LLM 的方式,不会让它表现得像个“摇滚明星”。你可以主导工程方向,引导 LLM 一次生成一小段代码。你可以确保软件以团队中每个人都能轻松理解和协作的方式编写。
如果你发现自己迷失了,无法理解 LLM 在做什么或为什么这样做,那就踩住刹车。放慢速度是可以接受的,确保你生成的软件质量过硬。避免过度工程也是可以的,不断简化再简化,直到架构与问题的复杂度相匹配。
有时候,把你的 LLM 放回工具箱里,自己动手写代码,这也是可以的。手艺永远掌握在我们自己手中,这是我们永远无法外包给机器的事情。
发表于 2026 年 6 月 8 日。© Jesse Skinner
相似文章
那些写烂代码的智能体也正是维护它的智能体。人类清理大军在哪里?
作者认为,AI智能体既在创建也在维护代码库,质疑了关于需要人类清理大军的预测,并指出中级开发者的角色正在被压缩。
你需要能够降低维护成本的 AI
James Shore 认为,AI 编码代理必须显著降低软件的长期维护成本,才能真正带来生产力的提升,而不仅仅是加快初始代码的编写速度。文章引用了“大众智慧”对维护负担的估算,并警告称,如果不降低这些成本,团队将面临收益递减和技术债务的问题。
AI编程工具是在让开发者变得更好,还是仅仅加速了糟糕的判断?
一篇观点文章探讨了像Claude Code和Copilot这样的AI编程工具是否真正提升了开发者的技能,还是仅仅加速了有缺陷的决策,并强调了需要新的指标来评估工程中的人机协作。
我余下的职业生涯都要用来审查AI生成的代码吗?
一位开发者对AI生成代码的依赖日益加深表示担忧,担心自己的职业生涯将沦为仅仅审查AI输出的工作,而不再是参与创造性的问题解决和编码。
@saranormous: https://x.com/saranormous/status/2064510215056400652
尽管以Devin为代表的AI编程助手取得了快速进展,显著提升了代码编写和交付的速度,但本文认为,软件工程中最有价值的部分仍难以通过基准测试衡量,并且需要人类的判断和组织协调,这些是无法轻易自动化的。