I thought I’d go deeper into system iteration – one of the lessons I’ve been learning as I’ve been working on Claude Code.
During my first day, I spent a lot of time figuring out errors. Let’s imagine them to be holes in the ship. I’d point them out to Claude Code and I would get suggestions for changes. We’d keep trying to fix the holes in the ship.
However, I’d keep finding old problems recur because fixing one hole often created new ones. And, sometimes, they reopened old ones.
This process became a lot better when I adopted a three-step workflow.
First, use Claude to figure out what was missing and what the gaps were relative to the spec. Claude would identify a lot of the issues.
Second, throw those issues back to Claude Code and ask it: “What changes do I need to make structurally in my spec for this to never happen again?” It would come back with a set of improvements.
Third, ask Claude to make the changes, put it back, and have Claude Code run the job again.
Once I got this workflow going, new issues started coming up instead of the old ones.
It reminds me of a story about two men by a river who saw kids struggling in the current – it was as if they were thrown overboard. One man started jumping in to catch the kids and bring them to the bank. The other started running upstream.
The first man shouted, “What are you doing? Why don’t you help me?”
The other replied, “I need to find the jerk who’s throwing these kids into the water.”
It’s a visceral story but makes the point.
It’s important to solve problems upstream and structurally if you want the fixes to last.
Beware plugging holes in the ship.
A Learning a Day 