Model Jockey Playbook

Ship a Web App with Claude Agent Teams: A Guide for Apprentice and Veteran Model Jockeys

15 min readApr 16, 2026

Part 1 of the Model Jockey Playbook, the how-to companion to the Model Jockey Manifesto series. (New to the Manifesto? Start here.)

The Model Jockey Manifesto established the theory of model jockeying: what the job is, why the human in the loop matters, and how you measure it. This series is different. This one is a recipe.

In this first article, I’m going to walk you, step by step, through exactly how I start a brand-new web app project from absolutely nothing. No spec, no wireframe, no clever idea written down on a napkin. Just a hunch, a folder, and Claude Code. By the end, you’ll have an app being built while you’re asleep, which is objectively the most fun way to make software.

Think of this as the Lego instructions. Each step has a prompt you can literally copy and paste. Most of those prompts ask Claude Code to interview you one question at a time, because the blank page is where most projects die, and a good interview is the easiest cure I’ve found.

Let’s go.

Step 1: Open a Terminal and Install Claude Code

We’re going to run Claude Code from the command line, for two reasons: (1) it reminds me of being twelve and thinking hacking was the coolest thing in the world, and (2) if anyone walks past your desk while a dark window full of green text is scrolling by, they will assume you are a genius. This is science.

To start, let’s open your terminal:

On macOS: Open Terminal (Cmd+Space, type “Terminal,” hit Enter)
On Windows: Open Windows Terminal or PowerShell (press the Windows key, type “Terminal” or “PowerShell,” hit Enter)
On Linux: Who am I kidding, if you’re on Linux, you already wrote your own guide.

If you don’t already have Claude Code, go get it. As of April 2026, Anthropic recommends the native installer over the old npm path. Copy and paste the one-liner for your platform into the terminal and run it:

macOS / Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell):

irm https://claude.ai/install.ps1 | iex

Full install docs live at code.claude.com/docs/en/setup. You’ll need a paid Anthropic plan to use Claude Code; check claude.com/pricing for the current options. Once you’re installed, follow the instructions on your screen to sign in with your Anthropic account, and you’re ready.

The installation happens automatically, but you must close and reopen your terminal after installing. If you don’t, your computer won’t recognize the claude command.

Claude Code also needs Git installed to track changes and safely undo mistakes. The good news: you probably already have it. On Mac, the first time you use a git command, macOS will offer to install it for you. On Windows, the Claude Code installer checks for Git and will prompt you if it’s missing. If for some reason you need to grab it manually, git-scm.com has you covered. You don’t need to know how to use Git, Claude handles that part.

Step 2: Create your project folder and launch Claude Code

Now that your terminal is open, navigate to wherever you keep your projects, create a folder (name it something you won’t be embarrassed to find in six months), and initialize git:

cd /path/to/your/projects
mkdir my-new-app
cd my-new-app
git init

A tip for the cd command: type cd (with a trailing space) and then drag the folder from Finder (Mac) or File Explorer (Windows) onto the terminal window. Your system will paste the full path for you.

That git init at the end tells Git to start tracking this folder. You won’t need to think about Git again. Claude Code uses it behind the scenes to checkpoint your project so it can undo mistakes cleanly. Think of it as giving Claude a save button.

Now launch Claude Code:

claude

You should see Claude Code come to life inside your project directory. Good. Now the fun starts.

Take a quick moment to select the most capable model. Anthropic continuously updates its models, but for tasks requiring sophisticated reasoning and coordination (like building an entire app!), you want the best.

Type:

/model

Then choose Opus. Think of this as putting the smartest possible brain in the loop.

Step 4: Let Claude interview you

This is where most people go wrong. They sit down and try to type out the full vision for their app in one heroic prompt, and the result is a disjointed mess of half-baked ideas and technical contradictions.

Don’t do that. Let Claude pull the vision out of you.

Paste this into Claude Code:

I’d like your help shaping the user experience for a new web app I want to build. Instead of me dumping the full requirements on you at once, I’d like you to interview me, one question at a time, to discover what we’re building. Start with the basics: who is this for, what problem does it solve, what does success look like? Then get progressively more specific about my vision. When it makes sense, offer me multiple-choice options so I can answer quickly. This should be a fairly long conversation, so don’t wrap it up early. Before you draft anything, ask me if there are any other requirements I haven’t mentioned yet. When we’re done, write a markdown file called EXPERIENCE.md that captures the user experience we’re building.

Now just answer the questions. This is the part of the process I genuinely love. Claude will ask you things you hadn’t thought about, force you to pick between options you had only loosely defined, and basically save you from yourself. By the end you’ll have a much clearer vision than the one you walked in with, and, critically, it will be written down.

Step 5: Clear the context

Now you’re holding a nice EXPERIENCE.md and you’re also holding a context window that is getting full. Claude’s performance starts to slip when the context window gets bloated, and the interview you just did was long on purpose. Time to give Claude a clean desk.

Type:

/clear

Your new session has no memory of the interview. That’s the point. From here on out, Claude works from the document you wrote together, not from a fading memory of the conversation.

Step 6: Turn the experience doc into user stories

One of the best perks of being a Model Jockey is that you can get real work done while you are, technically, napping. But only if you tee things up properly. The next few steps are the tee-up.

First we want a user story document. These are small, discrete chunks of work Claude can build without hitting a context wall, ordered by dependencies, with parallelizable stories clearly marked so we can hand them to an agent team later.

Paste this into your clean session:

There is a document called EXPERIENCE.md in this folder that describes a user experience I want to build. Please read it carefully, then draft a new file called USER_STORIES.md containing user stories. Requirements: (1) each story should be small enough to be completed by a single AI agent without hitting context window limits; (2) order the stories so that dependencies are respected; (3) clearly mark which stories can be built in parallel, because I’ll be using Claude Code agent teams to implement them; (4) before writing the doc, interview me one question at a time (multiple-choice when possible) to fill in any gaps, especially around coding standards, testing expectations, tech stack preferences, and what “done” means for a story. When we’re done I want a comprehensive, well-ordered backlog.

Same drill. Answer the questions. Make it earn the doc.

Step 7: Create a CLAUDE.md

So far we have an experience doc and a user-story doc. Now we’re going to give Claude a cheat sheet that gets loaded into its context on every single call: CLAUDE.md. Done well, this file is the difference between a session that “gets it” and one that needs to be re-onboarded every time.

Two rules for a good CLAUDE.md: it has to be concise (it rides along on every call, so bloat is expensive) and it has to stay current (stale instructions are worse than no instructions).

Clear the context again:

/clear

Then paste:

Please create a CLAUDE.md file in this folder. First read EXPERIENCE.md and USER_STORIES.md so you understand the project. Then draft the file. Requirements: (1) keep it concise, it will be loaded into your context window on every call, so every line has to earn its place; (2) include the purpose of the app, the tech stack, the structure of the code, and any conventions a future session absolutely needs to know; (3) include a standing instruction to future sessions (you) to keep this file up to date, prune outdated info, add new conventions as they emerge, and treat it as a living document, not a snapshot.

Step 8: Give Claude the permissions it needs to actually work

By default Claude Code will ask for your blessing before running commands or hitting the web. That’s sensible when you’re pair-programming, and deeply annoying when you’re trying to go take a nap. For a scoped project folder, you want to loosen the leash.

Paste:

I’m about to hand you a lot of coding work in this folder and I don’t want to babysit the permission prompts. Please search the web for the current recommended way to configure Claude Code permissions via settings.json so that, when launched from this folder, you can (a) run any shell commands needed and (b) perform web searches without asking me each time. Then make the changes. Explain what you changed and where, so I can audit it later.

Claude will need to do a web search to look up the latest permission docs, and it doesn’t have web search permission yet, that’s what we’re setting up. So yes, it will ask you to approve that first search. Just say yes. It’s the last time you’ll have to babysit a permission prompt from this folder.

A serious note wrapped in a friendly warning: this step gives Claude the ability to run any shell command in your project folder without asking. That’s powerful and convenient, but it means you’re trusting it not to do anything catastrophic. Do not do this on a machine where your project folder is next door to your tax returns, your company’s production credentials, or anything that would make you cry if it disappeared. This is a permission you give to a dedicated project folder on a machine you’d be fine factory-resetting. If the words “I’m sure it’ll be fine” are forming in your head, that’s exactly the feeling that precedes every IT disaster story ever told.

Step 9: Enable agent teams

Agent teams are what turn one Claude Code session into a coordinated pod of them. One session plays team lead, assigning work and synthesizing results; the others work independently in their own context windows.

As of April 2026, agent teams require Claude Code v2.1.32 or later and are gated behind an experimental flag (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) that you set either in your shell environment or your settings.json. Rather than me spelling out the exact JSON (which Anthropic has been tweaking), let Claude do it with the following prompt:

Please search the web for the current instructions to enable Claude Code agent teams, including any required version, environment variable, or settings.json changes. Then make the necessary changes in this project so agent teams are enabled when I launch Claude Code from this folder. Tell me the version I need and confirm what you changed.

If Claude tells you your version is too old, upgrade before moving on. Old version + new feature = a confusing afternoon.

Step 10: Launch the team, build the app

Exit the current session:

/exit

Now relaunch Claude Code with teammate mode turned on. From your project directory:

claude --teammate-mode in-process

in-process means all your teammates run inside this one terminal window. You can cycle between them with Shift+Down (it wraps around back to the lead after the last teammate). It’s the simplest mode to start with. Once you’re comfortable you can explore split-pane mode, but one window is plenty for a first run.

Paste:

I want to build a web app. In this folder you’ll find EXPERIENCE.md and USER_STORIES.md. Create an agent team to build this efficiently using multiple Claude Code sessions working in parallel where dependencies allow, coordinating through you as the lead session. Give each teammate worktree isolation so they don’t create file conflicts. Please review both documents and the CLAUDE.md, then produce a concrete build plan before you start: which stories go to which teammate, in what order, which ones can run in parallel, how you’ll verify each story is done, and what “done” looks like for the whole app. Ask me any clarifying questions one at a time before you begin building.

Review the plan when it’s ready. Push back on anything that looks wrong. When you’re happy, give it the green light to start building.

Then go take that nap. Genuinely. That is the entire point.

Step 11: Wake up, try the app, fix the bugs

When you come back, Claude should be in some state between “almost done” and “already done and quietly waiting for you.” If your terminal closed while you were away — laptop went to sleep, cat found the keyboard, power blinked — don’t panic. Just open a new terminal, navigate back to your project folder, and run:

claude -c

That picks up your most recent session with full context. One caveat: resuming will restore the lead session, but any in-process teammates will be gone. Just tell the lead to spawn new ones and pick up where they left off. Your user-stories doc and CLAUDE.md give it everything it needs to reorient.

If the session is still running and waiting for you, great. If it hasn’t told you how to run the app yet, just ask:

How do I launch the app locally to try it?

You will absolutely hit bugs and weirdness. That’s fine. That’s the iteration loop from Article 2. Describe what you’re seeing in plain English, paste in any error messages, and work through it together. The Model Jockey’s real job starts here: interrogating the output, catching the things that are technically-working-but-actually-wrong, and pushing until it’s good.

When you’re done and the app is in good shape, don’t forget to ask the lead to clean up the team. This shuts down all teammates and removes the shared coordination resources so you don’t end up with orphaned sessions lurking in the background:

Please shut down all teammates and clean up the team.

Bonus: Get it deployed without touching a browser

If you actually want people to use the thing, you’ll want to deploy it. I try to do as little of this in a browser as possible, because the browser is where I go to be unproductive. Start a fresh session and paste:

I want to deploy this web app but I’d like to minimize the amount of work I do in a web browser. I’m happy to give you CLI access to a cloud provider that you recommend. First, interview me one question at a time, multiple-choice when possible, to figure out the right provider and setup for this project (traffic expectations, budget, database needs, region, custom domain, etc.). Then walk me through deployment one step at a time, waiting for me to confirm each step is done before moving to the next.

The one-step-at-a-time pacing matters. Deployment is where “helpful 40-step guide” becomes “wait, which of those 40 steps broke the thing.” Slow it down.

A few closing thoughts

A few things I’ve learned doing this enough times to have opinions:

The interview steps are not optional. The temptation to skip the one-at-a-time interview and just dump your vision in a paragraph is strong. Resist it. The interview is where your own thinking gets clearer, not just Claude’s.
/clear more often than feels right. Context is the single biggest lever on quality. A fresh session reading a good doc beats a tired session that “remembers everything.”
Treat CLAUDE.md like a living org chart. When your project changes shape, update it. When a convention gets established, add it. When something’s no longer true, delete it. The file should always fit on a screen. Pro tip: Before running /clear simply ask it Claude to update CLAUDE.md.
Review the plan before agent teams run. Agent teams are powerful and they burn tokens fast. Ten minutes of reviewing the plan saves you an hour of untangling parallel work that went sideways.
Get comfortable walking away. This is the hardest one. The whole point of this setup is that it keeps working when you stop watching. If you can’t actually leave the keyboard, you’re not getting the leverage the job promises.

This is the flow I use for almost every new project now. It is not the only way, but it’s the one that most reliably gets me from “I have a feeling there should be an app for this” to “here’s a working thing you can try” in the shortest amount of active-human time. Which, per the third article in the Manifesto, is the whole game.

Go build something. I’ll be over here, napping professionally.

Have your own “zero to app” flow? I want to see it. Send me the prompts you can’t live without and I’ll feature the best ones in a future edition.

Appendix: Command cheatsheet

A quick recap of every command used in this article, what it does, and when you reach for it.

Terminal navigation

cd path/to/folder — “Change directory.” Moves your terminal into the given folder. Everything you run afterwards runs from that folder, which matters because Claude Code treats the folder you launch it from as the project.
pwd (macOS/Linux) — “Print working directory.” Tells you where you currently are. Useful for confirming you’re in the right folder before launching anything.
mkdir my-new-app — “Make directory.” Creates a new empty folder. You can also do this in Finder/File Explorer if you prefer clicking.
git init — Initializes a Git repository in your current folder. Claude Code uses Git behind the scenes for checkpoints and undo. You don’t need to know Git; just run this once when you create the project.

Launching Claude Code

claude — Starts Claude Code in your current folder. This is the default, single-session mode.
claude -c — Resumes your most recent session with full context. Use this if your terminal closed while Claude was working, or if you exited and want to pick up where you left off.
claude — teammate-mode in-process — Starts Claude Code with agent teams enabled, with every teammate running inside your single terminal window. Use Shift+Down to cycle through teammate views (it wraps around). Simplest way to try agent teams without setting up split panes.

Slash commands (type these inside a Claude Code session)

/clear — Wipes the current conversation’s context window. The session is still running, but Claude has no memory of what you’ve discussed. Use this between major phases so Claude starts the next phase with a clean, focused context. It’s the single biggest quality lever you have.
/plan — Enters plan mode. Claude can read files, search the web, and think, but cannot edit files or run commands until you approve the plan. Perfect for “design before build” steps. On older versions of Claude Code (pre-v2.1.0), press Shift+Tab twice instead.
/exit — Closes the current Claude Code session and drops you back at your terminal prompt.
/model — Selects the underlying AI model for the current session. For complex tasks like this one, select Opus to ensure you are using the most powerful and capable brain Anthropic offers.

Files Claude Code cares about

CLAUDE.md — A markdown file at the root of your project that gets automatically loaded into Claude’s context on every call. Use it for the stuff every session needs to know: purpose, stack, conventions, gotchas. Keep it short. Keep it current. Treat it as a living doc.
settings.json — Claude Code’s config file. This is where permissions live (what commands Claude can run without asking), along with feature flags like the one that enables agent teams. You don’t usually edit this by hand — you ask Claude to edit it for you.

Concepts worth knowing

Context window — The amount of conversation and file content Claude can “see” at once. It’s finite, and quality drops as it fills. /clear is your reset button.
Subagents — Short-lived helpers spawned inside a single Claude Code session. They report back to the main session and then disappear. Great for focused sub-tasks.
Agent teams — Multiple full Claude Code sessions coordinating with each other, each with its own context window. One acts as team lead. Better than subagents when teammates need to work in parallel on independent chunks of a project. Requires a recent Claude Code version and an experimental flag to be turned on.
Worktree isolation — Gives each teammate its own copy of the codebase (via git worktree) so they can edit files in parallel without overwriting each other’s work. You don’t need to set this up manually; just include “give each teammate worktree isolation” in your prompt and the lead handles the rest.
Plan mode — A read-only state where Claude designs work without executing it. Use it whenever the cost of a wrong move is higher than the cost of reviewing a plan first. For anything involving agent teams, always plan first.

Sources & further reading