What I let Claude Code do, and what I don't

Every system on this site was built with Claude Code as a pair. That is easy to say and easy to misread, so here is the actual split.

What stays with me. The architecture and the data model: I decide what the system is before anything is generated. The scope: every change starts as a short written brief with the constraints spelled out, and the model works inside it. The review: I read every diff, and code I don't understand doesn't ship, however clean it looks. And the decision to ship, with the standard it has to meet.

What I hand over. Implementation inside a scoped step, with tests written alongside. Refactors under an explicit plan where the target shape is already decided. Migration scripts, boilerplate, first drafts of documentation. Exploring an unfamiliar API before I commit to it. And a second opinion on my own design, to argue against rather than accept.

Why the split is there. Generation is now cheap. Judgment is not. The expensive mistakes on this site were never "the model wrote bad code"; they were cases where a decision got made implicitly because nobody wrote it down. So the scope is written, the decisions are written, and the limitations are written, on every project page, before the work is called done.

What it changed. One person can design, build and run a CMS, a reasoning service, a retrieval layer, a design-token system and an analytics pipeline. The pace has a cost: it outruns documentation unless the reasoning is captured as you go. That is the real discipline of working this way, and it is the one I'd hold a team to as well.