Poorly Structured Notes on AI Part 8 - The Mundanity of Ralph Wiggum

Last year Geoffrey Huntley created a stir with his Claude Code workflow, which he named after Ralph Wiggum.

There is much emphasis on the idea that it’s “basically just a loop”:

In its purest form, it’s a simple while loop that repeatedly feeds an AI agent a prompt until completion.

I hereby charge that this is a completely inaccurate summary, it emphasises the wrong thing, and it seems almost designed to send people in the wrong direction mentally. I don’t know why everyone is describing this idea so poorly, because it’s at root extremely simple and makes perfect sense, in ways that mostly have nothing to do with a while-loop. Huntley himself talks like a mystic guru.

Last week he put out a video which again embraces misdirection with gusto, saying things like “deterministically malloc-ing the array” (Okay, thanks?) but once he starts actually going through his workflow, it all falls into place and becomes much clearer. Whenever he stops talking, the value of his approach is manifest, and it is simplicity itself.

The motivating idea is as follows: Assume you’re on the Pro plan, which means Claude can do about 10 minutes of quality work, while you babysit it and stop it going off in crazy directions, and then seizes up for 5 hours. So how do we work around that?

Don’t interactively work with Claude making direct changes to your codebase. Just enlist Claude to help you work on your PRODUCT SPECIFICATION.

Yes, folks, the core idea here is the most boring, old-fashioned, consigned-to-the-scrapheap-of-history, waterfally approach ever:

• You are going to maintain a complete specification of your product requirements in a plain English (or your preference) living document of markdown files, tied together by a README.md.
• Huntley calls this a “pin”, but he saves it in a folder called specs, so I’m definitely not hallucinating this. After showing a round of spec editing, he is much clearer about this being the central activity. All your decisions and constraints, everything you care about, goes into the spec. This is your life now. Get out of the coding business, get into the spec-writing business.
• You instruct Claude not to edit your code, but to help you edit your spec. Tell it what you want to add, ask Claude to interview you about the details to pin everything down, the answers go into the spec, not immediate code changes.
• If you run out of Claude allowance, you roll up your sleeves and edit the spec yourself. It’s not hard, it’s just like writing lots of prompts, but you think about exactly what you want in as much detail as you can muster, all the ways in which you could be misinterpreted.
• On the other hand, don’t go nuts. Refer casually to general engineering knowledge about how things are usually done; Claude has spent $1.5bn on books and has read them all (just not in that order), so there’s a lot you don’t need to spell out, just set the direction.
• If you care about the screen layout, do some ascii art or include a .jpeg or something (Claude can see them).
• If there are technical features that need to convert A into B, include some test files and explain how to check that B is correct relative to A.
• Maybe install the playwright MCP or similar and tell Claude how to play with your product’s UI in the browser to make sure it hasn’t totally broken everything.

Now, once you have this specification, which is where you put all your effort and input, this is what gives you the opportunity to “leave Claude to it.” It can work from the specification by itself. If it hits the usage limit, it can wait a while and then automatically carry on, while you sleep.

Because all the information is in the spec, you don’t have to “resume sessions”. You might want to resume your spec-editing session but keeping it purely for that task, laser-focused on spec editing only. The actual implementation effort happens in a whole new claude session so it only sees the spec, not all the drivel that went into creating the spec.

Something absolutely not stated clearly in the video, but just hinted at right at the end, is when he adds the instruction to his prompt:

update the implementation plan when the task is done

and makes the cryptic remark:

“And this sets up our state checkpoints.”

My interpretation of this is that associated with (or incorporated into) the spec is some way of tracking what work has already been done. I’ve run with this hint and chosen to sprinkle emojis in my spec next to feature headings. ✅ means the task is done, 🟦 means it isn’t.

## 🟦 Removing Tags

1. **Click the × button** on any tag chip
2. Tag is immediately removed
3. No confirmation dialog

## ✅ Opening PDFs

PDF files (MIME type `application/pdf`) show a "Read" button in addition to Download and Rename. Clicking Read opens the PDF viewer, replacing the file list view.

So Claude can find things to work on by searching for 🟦. I tell it how to do this in a custom slash-command called /implement.

• My CLAUDE.md file explains the whole approach
• The /implement command

The command is written to emphasise picking just one feature, getting it done, committing it to git, and quitting.

Then we finally get to the famous loop, which I implemented by asking Claude:

Great. Next I want to create a node.js script that executes claude code as a command-line tool and makes it run the /implement command. It should do this in a loop. If the output of the claude execution includes “Spending cap reached” then it should sleep for an hour before resuming the loop. If the output includes the string “NO_REMAINING_WORK”, the loop should exit.

The result is an hilariously verbose-looking take on the while loop pattern, called auto-implement.js, but I don’t care what it looks like, I just leave it running. (I use node almost exclusively for such scripting tasks because it’s the most ubiquitous cross-platform way to script something, and Claude tends to get it right first time without falling over platform-specific escape character issues.)

So you run the loop, in my case (vault being the latest fun project within my monorepo):

node auto-implement.js vault

It executes each iteration in a fresh claude -p session, meaning all new context every time. The shared memory is in the specification (and of course supported by the code, but Claude is free to rearrange that however it likes.)

So when you wake up the next morning you have a little git commit history of various features that have been added to your product. You can play with them, figure out why they’re broken, use some of that hard-earned technical expertise of yours (Good news! You’re still essential in some way!) and get yourself all fired up for another round of exciting spec-editing. Maybe a feature turns out to be a terrible idea in practise. So do a revert-commit, delete it from the spec, move on.

Whenever you have an idea, you just get it into the spec. You don’t have to wait for your Claude allowance to reset itself. Let your codebase automatically drift into alignment with your current spec, as and when it has the credits to do so, usually while you’re asleep. Your spending limit is no longer that much of a limit.

Yes, yes, this is an absurd oversimplification because you are still going to find issues, and some things are still awkward to fully automate so there will still be some interactive working with Claude to troubleshoot things. But as these are the outliers against a background of generally amplified efficiency, the net benefit is immediately apparent.

IMPORTANT: If Anthropic’s next move is to make Pro equivalent to Max, and suddenly the usage limits melt away, does any of this idea still matter? Yes. The original motivating idea is kind of a red herring.

This approach effectively replaces much of the structure that Claude attempts to follow by default:

• resuming
• prompting
• planning
• todo lists
• working from the accumulated, ephemeral, session-bound context
• compaction, i.e. throwing away information without you having any control over what is thrown away.

Of course many of those standard things will still happen within each invocation of claude, but they are only relevant to each single invocation within the loop, which you don’t directly observe, because you are asleep at that point. You just see the resulting git commits the next morning.

Viewed from this specification-aligned vantage point, all of the standard features of Claude Code seem to be about getting you to provide important steering information, constraints, etc. using it once and then throwing it away. Yes, it’s gone into the codebase, so it’s not lost in that sense, but it has been blown up into a far more detailed, boilerplate expansion in which far distant places in the code have to correlate (the format written over here has to match the format parsed over there, etc.) The original, succinctly stated, form of the information is lost.

As an analogy, it’s like throwing away the source code and only keeping the binary of a compiled app. Yes, it still runs, the information hasn’t been lost as such, but it has undergone a transformation that leaves it horribly less modifiable. As I tend to emphasise until people are bored, the most fundamentally valuable quality of software is ease of modification, which is something every programming language feature invented since 1950 exists to support. That is why we don’t work in machine code, even though that’s all everything ends up as. By keeping your description of the software at a higher level, you make it easier to modify.

As I said at the start, this is ultimately the revival of a very boring old concept, one that in recent decades has been banished, except when working with offshore contracting teams. You have to pin down the spec with those guys, as if you leave them to work overnight on some vague instructions, the next morning (when they’re asleep and all you have now is a trail of baffling commits) you might be in for an awkward surprise. But other than that scenario, no one these days takes the idea of writing a spec seriously. It’s so… not agile!

But with the arrival of AI, this is just another assumption that must be tossed out. For a small monthly fee, you have an offshore team that works tirelessly while you sleep, and is extremely well read, and sometimes makes quirky assumptions. The way you keep this team focused is with a living specification document.