Claude Code Projects Explained — The AI You Talk To Doesn't Have to Do All the Work

There's a trap hidden in the phrase "I work with an AI." If the model you talk to also does all the execution, you've built a company where the manager writes the code, runs the tests, and takes the meeting notes. It doesn't run well, and in practice it doesn't.

This post has three parts: the role-splitting structure I'm actually running right now, Claude Code Projects — Anthropic's product version of that structure, released in beta on September 17 — and the places where a human still belongs. I don't have beta access yet, so the Projects section is based on the announcement and documentation. I'll update it once I've used it.

What Happens When One Model Does Everything

Run strategy, scripts, and review in a single chat and three things follow.

• The conversation context bloats with execution logs. The strategy discussion gets buried under file lists and error messages.
• Your most expensive model does your most repetitive work. Same output, different invoice.
• Nothing runs in parallel. One task has to finish before the next starts, and the one waiting is you.

Ask your smartest colleague to do copy-paste and the result is identical — only the cost changes. Models are no different.

Splitting Roles — Who Does What

Here's the structure I use. One model talks to the human. That model breaks the work up and hands it to the others.

Role	What it needs	Model	Analogy
Strategy, conversation, reporting	Full context, the human's intent	Fable	Chief of staff
Judgment, design, review	Deep reasoning	Opus	Senior
Repetition, loops, structured tasks	Fast and consistent	Sonnet	Line worker
Sorting, cleanup, summaries	Cheap and plentiful	Haiku	Intern

The principle fits in one line: model tier matches the type of work, not a person's seniority. Put Opus on a repetitive loop and it doesn't get better — it gets more expensive. And if you swapped Sonnet for Opus because Sonnet "wasn't reliable," it's far more often an instruction problem than a model problem.

This split isn't decided fresh in every conversation. It goes into the instruction file ahead of time. The instructions are the org chart.

Hand repetitive, structured work to subagents. Loops go to Sonnet; design and judgment go to Opus. Review subagent output yourself first, and report only what deviates from the strategy. Every report carries one recommendation. Never forward raw logs.

One Full Loop — An ERP Design-System Overhaul

I'm currently overhauling the company-wide design system of our ERP. In the past this meant assembling a project team, negotiating a launch date with operations, and flipping everything on D-Day while everyone scrambled to verify. This time I'm doing it alone, in slices. The flow has five steps.

Step 1 — The human and Fable set the pattern

Strategy conversations happen with one model only. Which screens change in what order, what must not be touched, what format the reports should come back in. The output is a "pattern," and that pattern is the yardstick for every step below.

Step 2 — Sonnet runs a sample of ten

The pattern doesn't go straight to everything. I pick about ten screens and Sonnet applies the pattern by script. It's repetitive work — Sonnet is enough, and I don't need to sit next to it.

Step 3 — Review, then revise the strategy

I look at the sample and adjust the pattern. Opus makes the first-pass judgment, and that judgment is cross-checked against a different set of criteria. The point is not to take one model's "looks fine" at face value. If the strategy changes here, I go back to step 1. That's why the sample is ten: rolling back is cheap.

Step 4 — Roll out section by section

The revised pattern spreads one section at a time. There is no D-Day. Apply a section, verify it, move to the next — so operations never has a single moment where everyone holds their breath.

Step 5 — Put agents on before/after verification

Comparing before and after used to mean a person opening screens one by one. Now the preview survey, pattern application, first-pass judgment, and cross-check each have an assigned model and assigned criteria, and agents run them. What reaches me isn't a log. It's "three items in this section fell outside the criteria, and here's the recommendation."

The one-line result: work that used to mobilize a team became a one-person job done in slices, and the hours spent frantically checking screens dropped sharply. While things run in parallel, I don't have to be parallel. That's the heart of it.

Claude Code Projects — This Structure as a Product

Claude Code Projects, released by Anthropic on September 17, is close to putting a name on the structure I've been assembling by hand. A single conversation acts as coordinator, breaks work into threads, and each thread runs as a cloud session on its own branch. Anthropic's phrasing: "threads do the work, Claude directs it."

What I did by hand	The Projects component
Strategy conversation with Fable	Coordinator conversation — always on
Subagents	Threads — each a cloud session on its own branch
Instruction file + decision records	Shared memory — decisions, dates, feature status
Fable's report	Overview panel — only items needing attention

Three things are new. It's always on, so you can steer from your phone (what the Dispatch post described becomes the default). Model and effort can be set per thread — the role table above, but in the UI. And Anthropic states plainly that concurrent threads burn through usage limits faster.

Three things aren't there yet. It's cloud-only, with local execution "coming very soon." It can't reach local files or internal network tools. And it started as a beta for a subset of Pro and Max subscribers, with Team and Enterprise to follow. For work that has to live inside a corporate network — like an internal ERP — waiting for local support is the right call.

Anthropic says to use it "the way you'd brief a chief of staff." That's the first row of the role table.

Where a Human Still Belongs

Build an AI team and your job doesn't disappear — only the manager's job is left. And the manager's job was never the easy one. Three places remain.

1. The brief. Goal, constraints, definition of done, report format. No model writes this for you. A weak step 1 means a weak step 5.
2. Decisions. The recommendation attached to a report is a recommendation. Section order, irreversible changes, promises to operations — those are yours. Write them down as decision records so the next thread doesn't ask the same question.
3. Budget. Model allocation is a cost decision, and thread count is spend rate. "How parallel do we go" is not a technical setting. It's a budget line.

Wrapping Up

• The model you talk to and the model that executes are different jobs. One model doing both is expensive, slow, and wrecks the context.
• Split work by type — Fable for strategy, Opus for judgment, Sonnet for loops — and a team-sized job becomes a one-person job done in slices. Start with a sample of ten, roll out by section, and D-Day disappears.
• Claude Code Projects gives that structure a product name. The human's role doesn't shrink; it moves to the brief, the decisions, and the budget.

References: Anthropic — Projects, redesigned · VentureBeat coverage