Letting Go: How My AI Workflow Has Evolved

Last year I wrote about SPECKL, a methodology I built to explore a human-first approach to AI-assisted development. The idea was lightweight specs that define boundaries — “Humans build. AI assists. Specs define the boundaries.” Even at the time, I was sceptical. I had always believed development would become AI-first, and SPECKL was an experiment to see if there was a useful middle ground — perhaps as a transition period for developers moving in that direction.

The experiment had value, and I think the approach still does for developers who want more control. But it is not where I am now.

The Shift

What changed was not a single realisation but a series of practical problems that, once solved, each removed a reason to stay hands-on. Each friction point I hit pushed me to build a small piece of infrastructure. None of them were dramatic on their own, but together they built a workflow where letting go felt less risky—and eventually, more rational than staying hands-on.

How I Work Now

I took a lot of inspiration from Boris Cherny’s setup — Boris is one of the creators of Claude Code, and his workflow resonated because it was surprisingly vanilla. Plan mode, parallel sessions, a well-maintained CLAUDE.md, slash commands. No elaborate custom tooling, just the built-in features used deliberately. I liked that. I have tried to keep my own setup in the same spirit, resisting the urge to over-complicate things.

The broad shape is: I do the thinking, Claude does the building, I review the result. The detail of how that plays out is where it gets interesting.

Plan First, Then Let Go

The thinking is still mine. I use Claude’s plan mode to define what needs to happen — the architecture, the approach, the scope. That part has not changed. What changed is everything after.

Once I have a plan, I let Claude execute it with dangerous permissions enabled and step away. When Claude finishes, I review the output and vibe code any fixes. Quick, targeted corrections rather than line-by-line supervision. The shift is temporal: instead of watching Claude work in real time, I review a completed result. Less pair programming, more code review.

Letting go like this only works because the environment makes it safe. That comes down to two things: worktrees and parallelism.

Parallelism Is The Key

If there is one thing that changed what I can accomplish in a day, it is parallel sessions. Multiple Claude instances running concurrently, each in its own git worktree, each working on a different feature or fix.

The worktree is the safety net. Each one is an isolated branch with its own demo site via HTTP over named pipes, so there are no port conflicts and no contamination between sessions or with the main repository. If Claude produces something unusable, I delete the branch. If it goes sideways, the blast radius is contained. That trade-off — some risk in a disposable environment versus the friction of approving every file operation — is worth it every time. Getting worktrees to work reliably with Claude took some effort — I wrote about keeping Claude in the right worktree and later replacing my custom skill with Claude Code hooks — but the investment paid for itself quickly.

This is not about speed per task. A single AI session might be marginally faster than writing the code yourself. But running three or four sessions concurrently while you plan the next piece of work or review what just finished — that is a genuine capability shift. It changes the unit of work from “one thing at a time” to “how many things can I effectively steer?”

Beyond The Terminal

The workflow extends past the local terminal too. Claude Code Web lets me kick off or check on tasks when I am away from my desk — reviewing a plan on my phone, adjusting scope, or starting a new session from wherever I happen to be.

The GitHub integration has been equally valuable. I can delegate issues directly to Claude for investigation. Sometimes it finds a solution and the issue gets resolved on the spot. But even when it cannot fully solve the problem, it almost always uncovers key insight — narrows the cause, identifies the relevant code paths, surfaces context I would have spent time digging for myself. Either way, it streamlines my effort. The value is not “did Claude solve it?” but “did Claude save me time?” The answer is nearly always yes.

What I’ve Learned

A few things only became clear through practice.

If you are over-explaining in your CLAUDE.md, you probably need a skill. I struggled for a while to know when custom skills were worth building. The heuristic that clicked was noticing when my project instructions were becoming unwieldy. A long, detailed section describing a multi-step process is really just a skill that has not been extracted yet. Same instinct as pulling a long function into its own method.

Infrastructure around your AI workflow deserves real engineering attention. The named pipes, the worktree hooks, the task metadata — each took time to build. But they compound. Every session since benefits from that investment. Tooling your AI workflow is not a distraction from the real work. It is part of the real work.

What I’ve Yet To Solve

I want to be honest about the gaps, because I think they are where the interesting problems sit right now.

Closing the loop. I have Claude generate tests as part of its implementation, and that catches the major things. But I do not yet have a robust way for it to self-validate meaningfully — that iterative cycle of build, test, adjust, retest is still something I do manually in the review phase. Boris handles this with background agents that verify work when a session finishes, and his advice is simple: “give Claude a way to verify its work.” That feels like the obvious next step. I am not there yet.

Parallelism has a ceiling. There is an inflection point where running more sessions flips the bottleneck from implementation to you. Three concurrent sessions feel productive. Beyond that, you start losing track of what each one is doing. You set Claude off on a task, context-switch to review another session, and by the time you come back you have forgotten the nuance of the first. The problem I solved for Claude — losing context — I have now created for myself.

Finding the right balance. More automation is not always better. Sometimes a quick course correction early saves a full rewrite at the end. But intervening means watching, and watching means not doing other work. I am still experimenting with where that line sits.

Where This Leaves Me

Looking at the arc from SPECKL to now, each step removed friction between intent and execution. Specs removed ambiguity. Worktrees removed fear of failure. Named pipes removed environment conflicts. Each one let me delegate a little more.

I do not think the destination is full autopilot. The thinking, the planning, the judgement calls about what to build and why — those are still mine, and I want them to be. But everything between having a plan and reviewing the result? That is increasingly Claude’s job.

I always worried I would miss the coding. The surprising thing is I don’t. What I actually enjoy is the feeling of delivering — shipping something that works, solving problems, seeing results. Coding just happened to be the mechanism for that. With this workflow, I deliver more than I ever did. The satisfaction is the same, the output is higher.

The hard part of AI-assisted development, it turns out, is not the AI. It is the human workflow around it.

Until next time 👋