On April 10 I was trying to clean up my Instagram.Tighten the cover graphics. Build a repeatable system. Stop redesigning the same template every week. A one-afternoon job. What actually happened was the first real test of an architecture I had been sketching for writing work — and I tested it on design. I built a sandbox, gave it a governing file, separated references from working material, wrote one clean brief… and let it run. Fifty covers came back in minutes. Same palette. Same typography. Same visual language. None off-brand. That was the moment something shifted. Not because of the output — but because of what it proved: Once an architecture is clear enough, the question is no longer “what can I delegate?”It becomes “what is now worth building?” In 21 days, that small test turned into: - Three working teams (orchestrator, content, design) - Four books shipped or shippable - A new website - Two additional teams already scoped Same operator. Same hours in the day. For those who asked about mindset and process — this is the real answer: 1. I stopped thinking in prompts and started thinking in systems.The model is not the asset. The structure around it is. 2. I separated thinking from doing.The orchestrator doesn’t write. It reads, structures, briefs, and validates.The workers execute. They don’t improvise outside their lane. 3. Everything moves through briefs.No direct “do this” requests. Every handoff is:task → context → scope → acceptance → return checklist.That alone removed most iteration cycles. 4. Context is layered, not dumped.Reference material lives separately from working material.The model doesn’t have to “figure out what matters” — it’s already decided. 5. The human sits outside the system.Not inside prompting.Outside — validating outputs and deciding what ships. The clearest proof this wasn’t theory came from the hardest task I’ve ever tried to coordinate: Mapping TCM meridians, Thai Sen lines, and Anatomy Trains on the human body — in one consistent visual language.

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.