Cleaning up after AI rockstar developers: an army of unreadable code

Software engineer Jesse Skinner has spent years being called in to rescue codebases left behind by “rockstar developers” — the highly productive engineers who rewrite a company's core architecture, introduce new tools and languages, reject most pull requests and then leave for a bigger challenge. In an essay published on his blog, he argues that AI coding agents now reproduce the same pattern at a much larger scale.

The rockstar pattern

The classic rockstar, Skinner writes, joins a team full of energy and ideas, rewrites most of the company's core architecture, raises the bar for everyone else and takes on the hardest tasks. The code is impressive, but nobody else really understands it — and nobody admits it. When the rockstar moves on, the team is left with a codebase where the flow of data is hard to follow: half of it written in an unfamiliar language, the rest built on libraries no one has heard of. Even getting the project to run locally can take a week, and a suggestion to rewrite it is often rejected because the code was written by the star.

An army of rockstars

Skinner says most teams are now facing “an army of rockstars”. Every new chat with an LLM carries the risk of adding another one: the agent does not remember what it did yesterday, can generate tens of thousands of lines of code in minutes, and works as fast as possible without caring whether the result fits the rest of the system or whether the codebase becomes easier to understand. It also arrives with a toolbox of best practices that may not apply to the project, and insists on belt-and-suspenders solutions even when the added complexity outweighs the benefit.

The result is that complexity can grow exponentially, to the point where the only practical way to make sense of a system is to ask an LLM about it. Developers, teams and entire companies can become dependent on generative AI, he warns.

What to do instead

Cleaning up after hundreds of AI rockstars is less satisfying than fixing a single human's work, Skinner writes: at least a rockstar had a design in mind. A vibe-coded codebase, by contrast, is generated across many chats and contexts — like a project written by hundreds of different rockstars, one feature or bug fix at a time — and the technical debt can become impossible to repay.

His advice is to keep the LLM in a supporting role: lead the engineering yourself, generate small snippets at a time, and make sure everyone on the team can understand the result. If you cannot follow what the model is doing, he says, tap the brakes; it is fine to move more slowly, to strip out over-engineering and to simplify until the architecture matches the complexity of the problem. Sometimes it is also fine to leave the LLM in the toolbox and write the code yourself. “Craftsmanship will always be in our hands,” he concludes.