Cleaning up after AI rockstar developers

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

We’ve all worked with a rockstar developer. They joined the team years ago, full of energy. They had great ideas about new tech, new paradigms, new architectures. Their cutting-edge ideas left everyone else feeling a bit behind and outdated. 我们都曾与所谓的“摇滚明星”开发者共事过。他们几年前加入团队时充满活力，对新技术、新范式和新架构有着宏大的构想。他们那些前沿的理念让其他人感到自己有些落伍和过时。

They rewrote most of the company’s core architecture. They introduced new build processes, new tools, new languages. They rejected most pull requests, raising the bar on what was expected of everyone else. Nobody understood the code they wrote but nobody would admit it. All the hardest tasks were assigned to the rockstar. They’d have it done faster than anyone else. The engineering always sounded very impressive, even if the rockstar was the only one who knew how it fit together. Everyone else was moving a lot slower in comparison. Everyone was struggling to keep up, to learn the new libraries, and to do things the rockstar way. 他们重写了公司大部分的核心架构，引入了新的构建流程、工具和语言。他们拒绝了大多数合并请求（PR），提高了对所有人的要求。没人能看懂他们写的代码，但也没人敢承认。所有最艰巨的任务都交给了这位“摇滚明星”，他们完成的速度比任何人都快。这些工程方案听起来总是令人印象深刻，即便只有他们自己知道这些代码是如何拼凑在一起的。相比之下，其他人的进度慢得多，大家都在挣扎着跟上节奏，学习新库，并试图用“摇滚明星”的方式去工作。

A few years after they joined the team, suddenly they were gone. They had gotten bored, and wanted a better job working on a more challenging project at a bigger company. 在加入团队几年后，他们突然离职了。他们感到厌倦，想要去更大的公司寻找更具挑战性的项目。

Dealing with the aftermath

处理后续影响

Suddenly, you were asked to take over the rockstar’s projects. You dug into the code, and you found yourself buried alive. The flow of data was so hard to follow, it seemed like someone was trying to cover up a murder. You started with trying to fix a simple bug. Just getting the code to run on your laptop took a week. Half the code was written in a language you didn’t understand. The other half was written using libraries you never heard of. You tried to tell your boss that you think the code needs a rewrite. They didn’t believe you, because it was written by the rockstar himself. As you waded through the slop, you browsed job postings and fantasized about leaving. 突然间，你被要求接手这些项目。当你深入研究代码时，发现自己简直被活埋了。数据流向极其晦涩，仿佛有人在刻意掩盖犯罪现场。你试图修复一个简单的 Bug，但光是让代码在本地运行起来就花了一周时间。一半的代码是用你看不懂的语言写的，另一半则使用了你闻所未闻的库。你试图告诉老板代码需要重写，但他们不相信你，因为这是那位“摇滚明星”亲手写的。当你在这堆烂摊子里挣扎时，你开始浏览招聘信息，幻想自己能早日离开。

Cleaning up after a rockstar

清理“摇滚明星”的烂摊子

I’ve worked with many teams and agencies who needed me to clean up after these rockstars. I actually love the challenge of trying to understand and rescue a messy codebase. It’s like sitting down with a box of tangled string lights, and pulling it apart until they’re usable again. As I’ve gone through the process, I’ve seen some patterns. These rockstars absolutely love coding, learning, and using new paradigms, and it shows. They’re always pushing themselves to the edge of their abilities, writing the most clever code they can. They are focused on moving as fast as they can. Unfortunately, the last thing these rockstars care about is writing code that others can work with. 我曾与许多团队和机构合作，帮他们清理这些“摇滚明星”留下的烂摊子。我其实很享受这种理解并拯救混乱代码库的挑战。这就像面对一盒缠绕在一起的灯串，一点点将其理顺，直到它们能再次使用。在这一过程中，我发现了一些规律：这些“摇滚明星”非常热爱编程、学习和使用新范式，这一点显而易见。他们总是将自己推向能力的极限，写出尽可能精巧的代码，并专注于以最快的速度推进。遗憾的是，他们最不在乎的就是编写让别人也能协作的代码。

Along comes artificial intelligence

人工智能的介入

In the past years, most teams have been overwhelmed by an army of rockstars. Every time someone starts a new chat, there’s the risk of adding a rockstar to the team. The agent doesn’t remember anything it did yesterday. It happily generates tens of thousands of lines of code in minutes. It works to complete tasks as fast as unhumanly possible. It doesn’t care whether this code will fit with all the other code in the system. It also doesn’t care whether the system is becoming more understandable, or worse. 过去几年里，大多数团队都被一支“摇滚明星”大军淹没了。每当有人开启一个新的对话窗口，就等于给团队增加了一位“摇滚明星”。这个 AI 代理不记得昨天做过什么，它能在几分钟内欢快地生成数万行代码，以非人的速度完成任务。它不在乎这些代码是否与系统中的其他部分兼容，也不在乎系统是变得更易理解了，还是变得更糟了。

The AI has a toolbox of best practices that probably don’t apply here. It insists on the “belt and suspenders” way of doing things, even when the complexity outweighs the benefit. When asked to review your code, it comes up with a long list of improvements, many of which you disagree with. The bar has been raised for everyone, and many feel they need to use LLMs or else they’ll fall behind forever. (Though I believe it’ll be those who let LLMs write all their code who will ultimately be left behind.) With so much generated code, the complexity of a system can grow exponentially. It can be so complex that the only way to make sense of it is to use an LLM. Developers, teams, whole companies can become addicted and dependent on generative AI. AI 的工具箱里装满了可能并不适用的“最佳实践”。它坚持“双重保险”的做事方式，即便复杂性远超收益。当你让它审查代码时，它会列出一长串改进建议，其中许多你并不认同。所有人的门槛都被提高了，许多人觉得必须使用大语言模型（LLM），否则就会永远落后。（但我认为，最终被淘汰的恰恰是那些让 LLM 代劳所有代码的人。）随着大量生成式代码的涌入，系统的复杂性呈指数级增长。它可能变得极其复杂，以至于唯一能读懂它的方法就是再用一个 LLM。开发者、团队乃至整个公司都可能对生成式 AI 产生依赖。

Cleaning up after hundreds of AI rockstars

清理数百个 AI “摇滚明星”的烂摊子

Sitting down with a pile of slop isn’t as fun as cleaning up after a rockstar. At least the rockstar had some kind of design in mind, and was trying to do their best. A vibe coded pile of slop wasn’t written by a single artificial developer. It was generated across many different chats, and many different contexts. It’s like a codebase written by hundreds of different rockstars, one feature or bugfix at a time. Sometimes there’s so much technical debt that it can never be paid off. 面对一堆 AI 生成的垃圾代码，远没有清理人类“摇滚明星”留下的代码那么有趣。至少人类“摇滚明星”心中还有某种设计蓝图，并且在尽力做到最好。而这种“凭感觉编码”产生的垃圾，并非由单一的 AI 开发者编写，而是在许多不同的对话和语境下生成的。这就像是一个由数百个不同的“摇滚明星”共同编写的代码库，每次只负责一个功能或一个 Bug 修复。有时，技术债务多到永远无法偿还。

Building software that lasts

构建持久的软件

There are many ways to use an LLM that don’t allow it to act like a rockstar. You can lead the engineering, and guide the LLM to generate small snippets at a time. You can ensure that the software is written in a way that everyone on your team will be able to understand and work with it easily. If you find yourself lost, unable to understand what the LLM is doing or why, tap the brakes. It’s okay to move slower, to ensure the software you’re generating is high quality. It’s also okay to prevent over-engineering, to simplify and simplify until the architecture matches the complexity of the problem. It’s also okay to leave your LLM in the toolbox sometimes, and to write code yourself. Craftsmanship will always be in our hands, it’s one thing we can never outsource to a machine. 有很多使用 LLM 的方法可以避免它表现得像个“摇滚明星”。你可以主导工程设计，引导 LLM 每次只生成一小段代码。你可以确保软件的编写方式让团队中的每个人都能轻松理解并协作。如果你发现自己迷失了，无法理解 LLM 在做什么或为什么这么做，那就踩下刹车。慢一点没关系，这能确保你生成的软件质量更高。防止过度工程化、不断简化架构直到其与问题复杂度相匹配，也是完全没问题的。偶尔把 LLM 放回工具箱，亲自编写代码也未尝不可。工匠精神永远掌握在我们自己手中，这是我们永远无法外包给机器的东西。