The most eye-catching detail in Boris Cherny’s Claude Code setup is the number five. Five terminal sessions, with more work running elsewhere. It is also the easiest detail to copy and the least useful one to copy blindly.
Running five related sessions creates a queue of branches and assumptions to reconcile. The simplest collision is also common: two otherwise independent tasks both edit the same configuration file and cannot be merged in either order. Parallelism therefore demands better planning, isolation and verification before it improves delivery.
What makes Cherny’s workflow interesting is the system around those agents.
A Field Report, Not a Recipe
In that January 2026 thread, Cherny called his setup “surprisingly vanilla” and explicitly said there was no single correct way to use Claude Code. Later threads covered team practices, customisation and worktrees.
The dates matter. Models change, commands move and product features get renamed. Copying his exact model choice or terminal shortcut months later would be cargo culting. The durable part is how the work is organised:
- plan before allowing broad edits;
- isolate concurrent changes;
- turn repeated corrections into shared instructions or automation;
- give the agent a way to test what it claims;
- keep a human accountable for the result.
My interpretation is that Cherny treats agent work as capacity to schedule, rather than a conversation that must occupy his full attention. That is a useful shift, but only after the surrounding engineering can absorb the extra output.
Cherny also reported using the most capable model available to him, despite its higher latency, because it needed less steering and used tools better for his work. This is another place where copying the label misses the decision. The relevant measure is not seconds per response or price per token. It is the total cost of reaching a reviewed result: model usage, retries, human interruptions and rework.
That calculation changes with the task. A strong model may be cheaper for a difficult migration if a smaller one repeatedly wanders off course. The smaller model may be perfectly adequate for a constrained, mechanical edit with excellent tests. Model selection is part of scheduling capacity; it is not a declaration of loyalty. Measure it against the work you actually do, and repeat the measurement when the models change.
Plan Before You Spend
Cherny reported starting most implementation sessions in plan mode and iterating until he liked the plan. That can sound like ceremony. With one agent it is cheap insurance; with several, it is traffic control.
A useful plan should make four things visible before files change:
- the outcome and acceptance criteria;
- the files or components likely to change;
- the dependencies on other pieces of work;
- the commands or observations that will prove the result.
The plan is not valuable because an agent wrote it. It is valuable because we can reject a misunderstanding while it is still prose. Once five sessions have implemented five different interpretations, finding the misunderstanding becomes rather more expensive.
There is a limit. Planning can turn into an attractive substitute for delivery. A spelling fix does not need a design document, and a speculative plan is not evidence that the implementation will work. I would spend planning effort in proportion to ambiguity, blast radius and the number of workers involved. If execution exposes a false assumption, stop and re-plan. Do not keep prompting a broken plan towards completion because it already consumed an afternoon.
This is the same research, plan and implement cycle described in The Only Workflow That Works, except that parallel work makes the boundaries less forgiving.
Parallelism Moves the Bottleneck
Cherny’s original setup used separate checkouts. His team later highlighted Git worktrees, and Claude Code now documents several parallel execution options and their different coordination costs. The important property is isolation: two workers should not share a mutable working directory and hope good manners will prevent collisions.
Worktrees solve file-system interference. They do not solve conceptual interference. Two tasks may be assigned to different folders and still make incompatible assumptions about an API, schema or user journey. Before dispatching them, I would ask:
- Can the tasks be merged in either order?
- Do they rely on the same contract?
- Will one task invalidate the other’s tests?
- Who will reconcile the results?
If the answer to the first question is no, the work is probably sequential, however tempting those idle agent slots look.
There are less obvious costs too. Parallel sessions multiply token use. They generate notifications and status checks. Most importantly, they produce review work faster than a person can build a reliable mental model of it.
Start with two genuinely independent tasks. Measure the time from dispatch to reviewed, integrated change, not the time until an agent says it is done. Add another lane only when integration remains comfortable. Five is a report about Cherny’s workload and environment, not a target.
Make Corrections Compound
The strongest practice in the workflow is almost boring: Cherny’s team keeps project instructions in the repository and updates them when Claude makes a recurring mistake. During review, a correction can become a change to the shared CLAUDE.md, so the next session sees it too.
This turns feedback into infrastructure. A comment in one chat fixes one run. A concise, reviewed rule can prevent the same class of mistake for the whole team.
It can also go wrong. A long instruction file becomes context tax, and a rule written in anger after one odd failure may encode the wrong lesson. “Never touch authentication” is not a useful project convention. “Changes under src/auth require the threat-model check and these two test commands” is closer.
For each correction, decide where it belongs:
- A stable project fact or convention belongs in repository instructions.
- A repeatable procedure belongs in a skill or command.
- A mechanical invariant belongs in a formatter, linter, type or test.
- A one-off task detail belongs in the task, then disappears.
The last distinction matters. Agents are probabilistic; build tools are much less so. If a formatter can settle an argument, use the formatter. Cherny described PostToolUse formatting hooks for this sort of routine. Claude Code’s hooks documentation also makes the boundary clear: hooks can run deterministically at lifecycle events, but they remain code we must inspect, maintain and secure.
The same test applies to commands and subagents. Cherny turned frequent inner-loop tasks into shared commands and used specialised subagents for simplification and application verification. A named workflow can make a repeated procedure visible and reviewable. A subagent can keep noisy exploration or test output out of the main context. Neither is automatically an improvement. Automating an unsettled process freezes its confusion; adding a specialist for a task that takes two minutes creates another interface to maintain.
Wait until a pattern has repeated and its success criteria are clear. Then encode it. The attractive alternative is to build an elaborate agent organisation on day one. I would reject that alternative for the same reason I reject premature service decomposition: we do not yet know where the useful boundaries are.
Verification Is the Centre
Cherny called verification his most important tip: give Claude a way to verify its work. He attached a large quality estimate to that advice, but it was his practitioner estimate, not a controlled benchmark. We do not need the number for the principle to hold.
An agent without feedback can only make a plausible change and describe it confidently. An agent with a test suite, compiler, browser, simulator or reproducible command can observe a failure and try again.
The verification must match the claim. A formatter proves formatting. A unit test proves the examples encoded in that test. Neither proves that a checkout flow works in a browser or that a migration is safe on production data. For a typical change, the ladder might be:
- focused tests for the changed behaviour;
- type checking, linting and the relevant wider suite;
- an end-to-end exercise through the real interface;
- human review of the diff, assumptions and evidence.
This is where many agent workflows become theatre. “Run the tests” is added to the prompt, the agent reports green, and everybody moves on. Ask for the exact command and meaningful output. Make sure it ran after the final edit. Check that the test would fail if the implementation were broken. For visual or interactive work, inspect the behaviour rather than accepting a screenshot chosen by the same agent that wrote the code.
Verification costs time and compute, and that cost is part of delivering software. Running five agents while giving none of them a credible feedback loop merely manufactures uncertainty faster.
Interactive or Overnight?
Cherny’s published setup was highly interactive: several sessions advance in parallel, and notifications bring the human back when one needs attention. Jamon Holmgren’s Night Shift workflow sits at another point on the supervision spectrum. Holmgren spends the day writing specifications and thinking through the system, then lets an agent execute a documented loop overnight. The loop writes tests, uses several review personas, validates the result and leaves a concise report for the morning.
These approaches look opposed, but they rely on the same foundations: explicit intent, repository knowledge, strong tests and a human review boundary. The difference is where supervision occurs.
Interactive orchestration suits ambiguous work where new information should change the direction quickly. Asynchronous execution suits well-specified work with excellent automated feedback. Holmgren’s loop relies on repository documentation, tests written before implementation, repeated agent reviews and thorough human checking the next morning. That preparation and review are easy to omit when admiring the overnight result.
There is no prize for maximising autonomy. Choose the least supervision that still gives you evidence you trust. For an unfamiliar codebase or risky change, that may mean one agent and frequent checkpoints. For a mechanical migration with strong tests, it may mean a batch of isolated workers. Autonomy is an output of a good system, not a setting that creates one.
What I Would Steal
I would not begin by recreating Cherny’s terminal layout. I would begin with a much smaller operating loop:
- Write the outcome, constraints and verification commands.
- Review the plan before implementation starts.
- Run one task in an isolated branch or worktree.
- Require the agent to produce verification evidence.
- Review the diff and the behaviour.
- Turn any recurring correction into a rule, procedure or automated check.
Once that loop is dependable, run two independent tasks. If the review queue stays manageable, consider more. If quality drops, improve the harness before buying more capacity.
The next problem is less visible: even when all of those changes work, do we still understand the code they produced?