How I Work With Claude Code

Most of what I've built in the last year was written by Claude Code. Orchid Recipe and Trader Rush are native Swift apps whose code I didn't type, Lingisa is a 3D modeller that runs in the browser, and the Kivo kit-operations dashboard shipped into a production Django and React codebase the same way. That fact is spread across separate case studies, a sentence or two at a time. This note puts it in one place, because the way I work is the same on every project.

The loop

Orchid Recipe is where the loop took shape. I design a feature in Figma, describe it to Claude Code, iterate on the implementation, and push it to TestFlight, where my wife uses it in her own kitchen. Figma is still where I decide what something should be. Claude Code turns it into something real fast enough that I can be wrong about it on a phone instead of in a mockup. TestFlight is where the opinion that matters shows up: someone who isn't me, using it to make dinner.

The loop is fast, and that's the risk. When building costs almost nothing, the bottleneck moves to judgment: what to build, and whether what came back is actually right.

Nothing is done until a person says so

Lingisa made that explicit. When its agent finished working on a comment, the comment marked itself resolved. That felt wrong, because the person who asked should be the one to decide. Done work now waits in "awaiting review" until someone chooses Accept or Not quite…

I hold my own process to the same rule. On Lingisa the working agreements were written down: an ordered task list where every item had a reason, a proposals list where nothing started until I marked it approved, and a history file with the write-up for every decision, retractions included. A build number stayed on screen so I always knew whether I was reviewing the new build or a cached one. When we reversed the web plan, the old reasoning stayed at the top of the document instead of being deleted. The decision log is the part I'd keep if I lost everything else, because the wrong turns are where the learning is.

Did / decided

Trader Rush gave me the format I now use in every case study: one line for what Claude Code did, one for what I decided. Claude Code wrote the Swift: chart rendering, historical data processing, game state and animation timing. I decided the arcade look, the leverage unlock tiers, the 0.5x to 10x playback range, and when the timing finally felt right.

That last one matters most to me. Claude Code could change the timing a hundred times in an afternoon. It couldn't tell me when it felt right. Kivo was the same. AI code review caught real bugs, but the clearest problem was a rule, not a bug: the shipping queue treated every returned kit as a reason to ship another. The query was doing what it was told. Fixing it meant deciding what a return means, and that was my job.

The split is also just honest. A portfolio that says "I built this" without saying how invites the wrong question. Saying exactly what the tool did and what I did answers it up front.

Where I stand

Claude Code writes the code; I own every decision about what it should do and when it's done.