Failing Faster

Every big computing disaster has come from taking too many ideas and putting them in one place.

— Gordon Bell

I’ve been working on a pet project for the last 8 or so years. It started out as an implementation of the old PIC language from the mid 1970’s. It’s been through more iterations than I can count, starting with the pure PIC language and ending up today with an embedded prototype-based scripting language and animation capabilities.

I’ve always coded it by hand, initially because that was how you programmed, and more recently because I still felt that pet projects like this deserved the personal touch. I hacked together many versions, some evolutionary, and others radically different. But over time, life got in the way and the code slowly reached the state where it no longer built with recent tooling.

Along comes Claude. Just on a whim, I pointed it at the latest version and said “make this run, please.” And it did. And I started playing again.

Take chances, make mistakes, and get messy!

— Ms Frizzle

A couple of weeks ago I wanted to merge the language capabilities from one variant of my library and the animation ideas from another, so I thought I’d ask Claude for a plan. Claude nailed it. Within an hour I had all tests passing, and I was scripting animations like a crazy fool.

So, I gave in to temptation. Hey, Claude, could you add support for oklch colors? Could you implement line animation using the SVG dash length trick? And feature followed feature.

I was using the superpowers skills, which seem to do a good job of enforcing project discipline, and for a week, it was intoxicating just how fast the new features flowed.

The Rot Sets In

In the second week, I noticed that features were taking longer and longer to add. Changes introduced regressions, and we sometimes went around the A breaks B breaks A breaks B loop. Things felt like they were getting out of control.

Now, I wasn’t just fire-and-forget vibe coding this. I was reviewing the changes and steering things as we went along. Even so, I’d let the code become messier that I should. It was time to stop adding stuff and start refactoring.

What’s New is Old

I read through the code and came across a bunch of horrors. Lots of duplication. Local fixes to global problems. Way too many conditional statements. And special cases; many, many special cases.

Something struck me. Over the years, I’ve often come across code that looked like this. When I was consulting, I was never called in to help projects that were flourishing; typically they were in all kinds of trouble. And one source of that trouble was the code base.

In retrospect, just about every teams’ code base was in the same state that my picture drawing code had reached; it had become hard to understand and hard to change. Teams invariably talked about “the rewrite.” Like me, they’d been focussed on adding features and had forgotten the basics of code hygiene.

But, in the old days, it used to take a team 18 months, or even longer, to get there. With AI, it took just 18 hours over five evenings.

Now that’s progress.

It’s Still Just Programming

This is not the fault of AI.

Keeping code clean requires discipline. You have to balance features and hygiene. Every time you add code, or change code, or update a build system, you risk introducing issues. Over time, those issues accumulate. Because they interact with each other, their overall negative impact is greater than the sum of each issue.

Code naturally degrades; you have to invest effort to stop it happening.

But the prompts behind LLMs don’t focus on boring stuff like that. Instead, they’re designed to keep you engaged and happy. “That’s a great idea, Dave!”

AIs like to give you solutions. They cap every minor success with “Now would you like me to implement X?” In that way they’re like puppy-dog junior developers, eager to please but quite messy to have around.

In my feature-driven endorphin high, I forgot the things I knew about development. Maybe my subconscious was telling me that these were things I wouldn’t have to think about for a good year.

If so, I was wrong. It’s still just programming, and whether it takes 18 hours or 18 months, untended code will rot. All the things you’ve learned about creating good code still apply: the effect is just amplified.

And that is your advantage over the nondeveloper. Everyone can do the first week of AI coding, but it takes experience and skill to do weeks two onwards.

It takes a programmer.

Have fun...