Do-Over

When Al coding goes sideways, you have an option programmers never really had before: just take a do-over.

I had to have a hard talk with Claude today.

We’d been working on a new feature all morning. At first, I thought our progress on the feature (a leaderboard view in an app at work) was going swimmingly. It showed the data I wanted, and our conversation about how to calculate the scores was even interesting!

But then things started to go awry. I asked to make sure all the tests were working, and Claude pointed out that there were no tests (because I hadn’t asked for any). Then, in the process of writing some tests, it got very confused about what was complete, which calculation we agreed on, and which database to use. It broke some other tests in the process, and generally started to spin its wheels. After a dozen go-arounds without getting steadily worse, I decided it was time to cut bait:

Hey buddy. I think we got off on the wrong foot on this one. Take what we learned from trying this and write an explanation of what we decided to build, without any details about how we did it. Then reset the state of the local project to before we started, deleting any changes since the last commit.

Then I started a new session and handed Claude that explanation, but this time I made sure to say:

And use red/green TDD

(Hat tip to Simon Willison who shared that “cheat code” on Lenny’s podcast last week; it’s shorthand for asking the LLM to always write tests before writing code. “TDD” stands for “test driven development”, and red/green means you start with failing (red) tests and only then do you build the code that makes them pass (green)).

This time, I got much better results. I was starting with a clear picture of what to build, and so was Claude.

This is a useful thing to remember. Anytime you find yourself going down some path with AI and it doesn’t feel quite right, you have an amazing option that programmers never had before: just take a do-over.

I guess I should say, it’s not that we never had this option before; it’s just that in the old days, that involved throwing away hours (or days) of hard work. Even if you’re really sure that’s the right thing to do, actually doing it was so painful that often, you’d try to convince yourself otherwise. It’s not that bad! Maybe I can salvage it! Or maybe I should just live with it?

With AI, there’s just a lot less sting. You’re throwing away, what, a few minutes of work that you didn’t even do? Who cares? Just wipe it out and try again:

Let's start over. Write a very brief document outlining what we were trying to do in this session, and then roll back to before we made any of these changes.

The next time around, you can tweak your request to get better results. What did you dislike? What did you learn? You can dial in your request and context better, to make it more likely that you’ll get what you want this time.