Wheel-of-Hats Friday
Six months ago I would have told you there's a lot of value in crafting a custom harness to drive a reliable development flow. Claude Code was good, but it lacked guardrail loops. If you wanted acceptable quality software at scale, you needed to define your own flows, ensure automated gates existed, and you had to put the work in defining a spec with verifiable outcomes. You could certainly be terrifyingly fast using such a platform, but the work was taxing and from a human capital PoV inefficient.
Today I'd say something pretty similar, sort of. There are some key carveouts I'd make based on more recent coding sessions. First for contained digital products where you have a handful of datasets/APIs/domains, I've found that using a conversational approach to a Plan - Build - Verify - Verify Again flow will produce an output that I'm comfortable with. I don't need a harness (beyond Claude Code) spinning agents into a frenzy; I just have to keep an eye on context, and ensure that Claude is actually following instructions.
Secondly I've come to embrace the human inefficiency. Using a conversational approach vs a hard upfront spec has its risks; what can I use to drive quality if I don't have measurable outputs that another agentic loop can evaluate? Not emphasizing the upfront spec work doesn't mean that I'm giving up project level expectations for development like DRY or A11y or defensive coding; they're just part of the ongoing conversation, something that I need to bring to the table.
What's become clear to me is that one aspect of the value I bring to this agentic-lead development flow is my wandering brain. In the before times, it was common for me to first focus on understanding the problem space, then I would match a solution pattern to the discovered domains, and then the most important phase...
Huh, I wonder... Wait... Okay, but... I see that, but now I'm losing the thread... Hold on... Well crap, I wish we'd known that before...
What I'm finding incredibly useful is to step out of the flow with Claude, spin up a new window and just start asking questions. This is especially useful early in a project's evolution before things get too baked-in, but even for non-greenfield projects, the ability of an LLM to analyze a code base with a specific intent is likely more valuable than its ability to mimic code.
For the projects I'm dabbling in these days, I'm swapping out my old habit of Doc-Fridays where I would spend time creating formal and informal technical documentation with Wheel-of-Hats Friday, where I try to untether myself and come at the project from as many points of view as possible, putting on all the hats. Something of a distant cousin to Eno's oblique strategies. I take an all questions are good questions mentality and chat a model through a code base to see what shakes out.
Sometimes it leads to code or process improvements, but just as often it just adds another pebble to my long-term that's a good thing to know bank. Just like every other remember to stop and smell the roses / touch grass mantras, it really is important to embrace your natural inefficiencies and let your mind wander.