We're All Axl Rose, Now

In 2008, Guns N’ Roses finally released Chinese Democracy. Work on it had started in the mid-90s. By the time it came out, it had reportedly cost more than $13 million, gone through a revolving door of guitarists, studios and producers, and become a punchline. Dr Pepper even promised a free soda to everyone in America if it came out that year. They had to pay up.

I’ve been thinking about that album a lot lately. Not because I’ve been listening to it. My old college roommate and I had listened to more Guns N’ Roses than was strictly reasonable, considering we were in school in the late 90s, right at the band’s cultural low point. So it made sense that we’d give it a try upon release, but it never clicked for us beyond picking apart how overproduced it was.

So why am I bringing this up now? I feel like we’re all a little bit in danger of becoming our own Axl Rose.

Fourteen Years of “Just One More Session”

The story of Chinese Democracy isn’t really about a lack of talent or money. It’s about the opposite. Axl had a big budget, a lot of skilled people, and studio time. So much studio time. Every track could always be re-recorded, re-layered, re-mixed. There was always another guitar part to try. And beyond that, when one was complete, another track could always be started. Axl Rose and the band worked on roughly 50 to 70 tracks across multiple years of sessions, with Rose himself mentioning numbers around 32 to 36 finished tracks at various points.

It Used to Be Too Much Work

For most of my career, the thing that stopped me from endlessly polishing a project was simple: it was a lot of work. If I wanted to rework a settings screen, that meant an afternoon. If I wanted to try three different approaches to a layout, that was three days I’d have to justify to someone, even if that someone was just me.

Effort was the natural inertia. It forced me to question whether it was worth it. Much of the time the answer was no, and the project shipped.

Prompt-assisted development removes that limitation. Trying another version of something costs a sentence and some tokens. Want the sidebar collapsible? Done. Want it collapsible but remembering its state per user? Done. Want a keyboard shortcut for it? Sure, why not.

Every one of those changes is reasonable on its own, but that’s what makes it dangerous.

I know this because I’m doing it right now. I’ve been working on a personal project called Butler’s Book, a compendium of information about your home. It isn’t a product, and I’m not really trying to make it one. I’m getting it ready to launch for one household. Just mine.

That’s about as low as the stakes get. No customers, no launch announcement, nobody waiting on it. And I still find it hard to pull the trigger. There’s always one more reasonable thing to try first, and trying it costs almost nothing. That’s exactly the problem.

A Cautionary Tail

It is a software truism that the first 80% of a project takes 20% of the time, and vice versa. There’s a long tail to every project. It takes a lot of time to add the refinements and bug fixes that make a project ready to ship. In the past, you’d hit that last little bit and have to make a hard choice about whether it was time to ship. Sometimes the train has to leave the station! Now, the tail is cheap to chase, so you chase it. And you chase it. And you keep chasing.

Here’s what that looks like in practice:

Settings multiply. Instead of making a decision, you ask for an option. Then that option gets another option. And so on.
Edge cases get features. You handle the scenario that one hypothetical user might hit once. Repeat, and repeat again, and all of a sudden you’ve got a Franken-app.
Design gets re-litigated. The spacing on that card has been adjusted five times, even though each version was basically fine.
The scope quietly grows. You started building a simple tool. Now it has import, syncing and messaging systems – because it was all just a prompt away.

Inscrutable, Obtuse & Overwrought

There’s another risk here. It’s not just that you’ll never finish; it’s what the project turns into while you’re laboring over it.

An app built from a few hundred small, individually sensible requests can end up being hard to understand. For users, that means screens full of toggles and features that don’t quite add up to a clear idea. For you, it means a codebase that you can’t hope to understand.

When I wrote code by hand, I knew why every piece was there. When I prompt my way through a long tail of refinements, I sometimes look back at the result and have to reconstruct the reasoning. Comments get muddy. Context gets lost. That’s not a great feeling in a project that’s supposedly mine.

You’re left with something byzantine and complex, but not fully coherent. Plenty of craft went into it. Sound familiar? Chinese Democracy never seemed to know what it wanted to be, and it’s remembered more for how long it took than for any single song.

Knowing When to Stop

If we are no longer constrained by how hard it is to do something, we have to constrain ourselves. Here are some ideas.

Decide what “done” means before you start. Write it down. Start with an actual damn project plan! (I know, so novel!)
Keep a “later” list. When a good idea shows up mid-project, it goes into a future milestone, instead of immediately into a prompt.
Ship, then let real use decide. Agents and bots can only do so much. Get your product into the hands of real people, and see what they need.

None of this is new advice. It’s the same discipline good teams have always needed. The difference is that we used to get some of it for free, just because building things was slow. Now we have to supply it ourselves.

(One final note: this blog post took me ages. I’m not sure why that is. It’s not terribly profound, and it’s certainly nothing that others aren’t also noticing. The amount of time it took me to agonize and labor over it seems appropriate, though, given the subject matter. It’s time to click “Publish”, Axl.)