This is a little long, but I hope it serves. After 3.1 where Jake showed how to build a site with Claude, I took it one step above the build I did while learning. Below is the process Claude and I went through. Claude did all based on the lesson, though the site is far more complex, so we built pages in sections. I'm a yoga teacher, not a developer. Over the past two days I rebuilt my retreat center website end-to-end using Claude Chat as the architect and Claude Code as the worker. Sharing the process because the patterns that emerged were unexpected and probably useful to anyone doing similar work. Before: khanomyoga.com — a Kajabi template, generic, full of invented specifics and dated styling. After: khanom-yoga.netlify.app — Astro + Tailwind, real photos, voice-aligned copy, layered JSON-LD, four-bucket inquiry forms, decision-complete brand reference. 15 routes, ~17 commits, 9 numbered build sessions plus 4 cleanup passes. Source on GitHub (private). The architect / worker split The single most important structural choice was separating planning from execution into two different Claude contexts. - Architect (Claude Chat in a project with a custom system prompt): writes briefing docs, PRD, per-session prompts, brand reference, cross-project bridges. Does not write production code. - Worker (Claude Code in the actual repo): scaffolds, edits, builds, commits, pushes. Reads the architect's prompts and the project's CLAUDE.md. The two never share a context window. The architect's outputs travel through the filesystem as markdown files the worker can read. The architect's job is to spend thinking before spending tokens — analyze, scope, write the prompt with explicit boundaries, surface the load-bearing decisions for owner approval. The worker's job is to execute that prompt without scope drift. The session pattern Every build session followed the same shape: 1. Architect drafts a numbered prompt — 05-session-2-prompt.md, 06-session-3-prompt.md, etc. Each prompt has: scope, hard rules, what NOT to build, three questions to ask before coding, after-session deliverables. 2. Owner pastes the prompt block into Claude Code. 3. Worker asks the three questions — usually variations on confirming defaults the architect proposed, but worker is empowered to push back. 4. Owner approves or amends in chat. 5. Worker builds, commits, pushes — single commit per session with a structured message. 6. Worker hands back a summary with commit hash, what landed, what's stubbed, what surprised them. 7. Architect reviews the summary, lines up the next session.

Six months in, I noticed I was outsourcing the thinking, not just the tasks to AI. I'd open a chat before I'd actually sit with the problem. I put the friction back deliberately: reading without it, first drafts without it, 20 minutes on a problem before I touch anything. I still use AI constantly. But I've found the line between tool and crutch is entirely about what you let it replace. Anyone else drawing lines like this? What did you fence off?