清理AI摇滚明星开发者留下的烂摊子

我们都曾与一位“摇滚明星”开发者共事过。他们几年前加入团队，精力充沛，满脑子都是关于新技术、新范式、新架构的好主意。他们那些前沿的想法让其他人感觉自己有点落后、过时。他们重写了公司大部分的核心架构，引入了新的构建流程、新工具、新语言。他们拒绝了大多数拉取请求，提高了对每个人的期望标准。没人理解他们写的代码，但也没人会承认。所有最难的任务都分配给这位摇滚明星，他们完成得比任何人都快。每次技术汇报听起来都非常令人印象深刻，即使只有摇滚明星知道代码各部分如何拼凑在一起。相比之下，其他人的速度慢得多。每个人都在挣扎着跟上，学习新的库，按照摇滚明星的方式做事。几年后，他们突然离开了——他们厌倦了，想要去一家更大公司做一个更具挑战性的项目。

应对后果 突然之间，你被要求接管摇滚明星的项目。你深入代码，发现自己被活埋了。数据的流向如此难以追踪，简直像是有人在试图掩盖谋杀。你开始尝试修复一个简单的 bug。仅仅是让代码在你的笔记本上运行起来就花了一周。一半代码用一种你不懂的语言写成，另一半用你从未听说过的库写成。你试图告诉老板代码需要重写，但他们不相信你，因为那是摇滚明星本人写的。当你艰难地穿梭在代码泥潭中时，你浏览着招聘信息，幻想着离开。

清理摇滚明星的烂摊子 我与许多团队和机构合作过，他们需要我清理这些摇滚明星留下的烂摊子。实际上，我很享受理解并拯救混乱代码库的挑战——就像坐下来摆弄一盒缠在一起的灯串，把它们拆开直到重新可用。在这个过程中，我观察到一些模式。这些摇滚明星绝对热爱编码、学习和使用新范式，这很明显。他们总是把自己推向能力的极限，写出他们能想到的最聪明的代码。他们专注于尽可能快地推进。不幸的是，摇滚明星最不关心的是写出别人能协作的代码。

人工智能来了 在过去几年里，大多数团队已经被一群摇滚明星淹没。每次有人开始一个新的聊天，就有风险给团队增添一位摇滚明星。AI 代理不记得它昨天做了什么。它愉快地在几分钟内生成成千上万行代码，以非人类的速度完成任务。它不在乎这些代码是否与系统中其他代码兼容，也不在乎系统是变得更易理解还是更糟。AI 有一套最佳实践工具箱，而这些实践可能根本不适用。它坚持“双重保险”的做法，即使复杂性超过了收益。当被要求审查你的代码时，它会列出一长串改进建议，其中很多你并不同意。标准被提高了，许多人觉得他们必须使用大语言模型，否则就会永远落后。（不过我相信，最终落后的是那些让大语言模型编写所有代码的人。）随着生成代码的增多，系统的复杂性会呈指数级增长。它可能变得如此复杂，以至于理解它的唯一方法就是使用大语言模型。开发者、团队、整个公司都可能对生成式 AI 上瘾并依赖它。

清理成百上千个 AI 摇滚明星的烂摊子 面对一堆由“氛围编码”产生的垃圾，可不如清理一位摇滚明星的烂摊子那么有趣。至少摇滚明星心里有某种设计，并尽力做到最好。而一堆由“氛围编码”产生的垃圾并非出自某一个人工开发者之手。它是在许多不同的聊天会话和不同上下文中生成的。就像是由成百上千个不同的摇滚明星编写的一个代码库，一次一个功能或 bug 修复。有时技术债务如此之高，以至于永远无法还清。

构建持久的软件 有很多使用大语言模型的方式不会让它表现得像个摇滚明星。你可以主导工程设计，引导大语言模型每次只生成一小段代码。你可以确保软件以团队中每个人都能轻松理解和协作的方式编写。如果你发现自己迷失了，不理解大语言模型在做什么或为什么这样做，那就踩刹车。放慢速度是可以的，以确保你生成的软件质量高。防止过度工程化，简化再简化，直到架构与问题的复杂性相匹配，这也是可以的。有时把大语言模型留在工具箱里，自己动手写代码，也是可以的。工艺永远掌握在我们手中，这是机器永远无法替代的。