Escaping the Claud-ottery

Claud-ottery
also clottery /ˈklɒt.ər.i/ (KLOT-uh-ree)

noun
1. The feeling generated by claude code, similar to a slot machine, where you don't know when it's done whether you're going to have won big or lost.
2. Applying Vibe-coding to what should still be a software engineering approach.

Many of you remember that feeling of doing the first few rounds of incremental development with Claude code and being surprised and impressed with what it was able to accomplish. The natural next step would be to start to push it further and further - to see how far it could go.

Quite often it would come back and have successfully accomplished the task (at least that’s what it said) and it would be your job to figure out what the task it actually accomplished was.

Did it actually do what I had intended it to do? Did it give up on something hard and just stop? Did it do something that looks like it works but is just a pile of craziness underneath the hood?

What was interesting is that I never knew exactly what I was going to get - sometimes I’d get lucky, and win the Claud-ottery, but most times it would do some things right and some things wrong, and I’d have to unwind a few things and try again.

The main thing however, was that I had no idea what would be waiting for me when I got back to my computer nor did I know how long claude would be puttering away for.

At first, this would feel like a thrill - hey, humans love lotteries - but quickly it got pretty annoying. After all, I just wanted to ship working code and not spend my time babysitting the LLM.

The pattern that followed for me, which I imagine might resonate with many of you, was that I slowly put a process in place that helped the whole thing run in a much more clockwork fashion. Things might take a little bit longer because of all the process constraints that slowly got added in, but at least I would have a pretty good idea of what it was going to do while it was wasting all those gallons of water.

This really came down to three things:

1. 1 -
   Getting an intuitive sense for how much was reasonable for the LLM to tackle in one batch, avoiding the lobotomy that a compaction would bring.
2. 2 -
   Crafting and reviewing plan documents at the right level of specification.
3. 3 -
   Giving the LLM the tools necessary so it could check its work - curl, playwright, storybook, e2e tests, live evals, etc - so it never came back claiming everything was fine dandy when in fact nothing worked.

Once those three things were taken care of, things got a lot less exciting, but a lot more productive and a lot more useful. I’ve since ended up with a significantly more involved process, but the above 3 bullet points probably account for 80% of gains.

I highly recommend you try to escape the Claud-ottery as soon as you can. Remember, you can always go back and tell it to one shot some crazy feature if you want to feel that thrill again.