Designing and building with Claude Code

“Zero lines of hand-written code” gets thrown around loosely, so here’s what it actually covers: I read every diff Claude Code produces, I reject a good number of them, and I’m making architectural calls the whole way through. What I don’t do is type the implementation. That’s a real shift. It is not magic.

The products exist mostly so I can show rather than tell how the process runs. A claim about a workflow is worth very little next to eight things you can go use.

The title has been around for a while in design-systems teams, where someone had to own both the component’s behaviour and its API. What changed is that Claude Code collapsed the cost of the code half, so the role is now reachable for designers who would never have written a production component by hand.

It isn’t a designer who can read CSS. The job is owning the outcome in the running product. All of it.

I held the opposite view for a long time and I’d rather say that plainly than pretend consistency. When learning to code meant a year of syntax before you could build anything anybody wanted to use, the trade was bad for most designers and I said so at length. The time cost dominated.

That trade changed. What’s left to learn in Claude Code is judgment about software rather than syntax, and designers turn out to be well equipped for it.

This is not a claim that every designer must. Plenty of excellent work needs none of it.

Design thinking is the constant here. AI makes building cheap, which makes knowing what to build the expensive question, and cheap building raises the stakes on the framing rather than lowering them, because a bad idea now reaches production before anyone has time to object to it.

In practice this means a brief before a prompt. What problem, for whom, what does good look like, what are we deliberately not doing. Ten minutes of that saves a day of well-built wrong, which is the whole reason Klarita exists.

Vibe coding is genuinely useful for exploring. It’s how you find out in twenty minutes whether an idea has legs, and I do it constantly. The trouble starts when the exploration gets shipped, because nobody can maintain a codebase whose shape nobody ever actually chose, and six months on that becomes somebody’s whole job.

The distinction has nothing to do with how much you type, given that Michael Angeles types almost none of it these days. It’s about whether anybody is accountable for the structure once the exploring is over.

The hardest discipline is keeping the first version small enough that you’re willing to throw it away. A prototype you’re attached to stops being a prototype and starts being a commitment you made without meaning to.

Klarita came out of this problem directly. It walks a team through the thinking before anyone opens a design tool, and shows reviewers what a prototype was meant to do before they react to it, so what comes back is judgement rather than preference.