How to Run Parallel Claude Code Sessions Like Karpathy

The Mental Model Shift

Andrej Karpathy hasn't written code manually since December 2024.

Instead, he runs multiple Claude Code sessions in parallel - one window per feature - and manages them like a small engineering team. He reviews diffs. He merges outputs. He handles the architecture while the agents handle the implementation.

At YC's AI Startup School, he described what this unlocks: a solo founder who ships what used to require a 50-person team.

This is not a productivity hack. It's a mental model shift - from "I am a coder" to "I manage AI agents that code." And once you see it, you can't unsee it.

The Core Idea: Parallelism Over Sequencing

Most developers use Claude Code the way they used to use their own brain: one task at a time, sequentially. Start a feature. Wait. Review. Start the next.

Karpathy's insight is that this is leaving enormous leverage on the table.

LLMs don't get tired. They don't get demoralized. They don't context-switch badly. They can work on three independent features at the same time while you review the output of a fourth.

From his own words:

"It's so interesting to watch an agent relentlessly work at something. They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago. You realize that stamina is a core bottleneck to work."

The leverage comes from treating each Claude Code session as a junior engineer you've delegated to - not a tool you're operating.

The Setup: Multiple Sessions, One Per Feature

The workflow is simple. The discipline is not.

Step 1: Break Your Work Into Independent Tracks

Parallelism only works when tasks don't depend on each other. Before opening any Claude Code window, identify which features or fixes can run concurrently.

Good candidates for parallel tracks:

• Independent UI components
• Backend route + frontend integration (if the API contract is agreed on)
• Test writing + feature implementation (Claude writes tests, you review, another session makes them pass)
• Documentation + refactoring
• Bug fixes in separate modules

Avoid parallel tracks for: anything that shares state, requires sequential migrations, or where a decision in track A changes the scope of track B.

Step 2: Open One Terminal Window Per Track

Karpathy uses Ghostty with multiple tabs/windows. The specific terminal doesn't matter. What matters is visual separation - each window is a distinct agent working a distinct problem.

A practical setup:

• Left half of screen: 3-4 Claude Code sessions in a tiled terminal
• Right half: your IDE for reviewing diffs and making manual edits

This mirrors the setup he described: "a small few CC sessions on the left in ghostty windows/tabs and an IDE on the right for viewing the code and manual edits."

Step 3: Give Each Session Success Criteria, Not Instructions

This is the most important part, and where most people get it wrong.

Don't tell Claude what to do. Tell it what done looks like.

Instead of: "Add input validation to the signup form"

Write: "The signup form should reject empty email fields with an inline error message. Write tests first that fail, then make them pass. Don't touch any other form elements."

Success criteria let the agent loop independently. Weak imperative instructions require you to babysit every session - which kills the parallelism advantage.

Step 4: Manage Like a Tech Lead, Not a Coder

With 3-4 sessions running, your job changes. You are no longer the implementer. You are:

• Reviewing diffs as they come in
• Unblocking sessions that get confused (asking a clarifying question is faster than letting it spiral)
• Merging outputs that are finished
• Deciding which track to spawn next

The mental model: you are the senior engineer. Each Claude Code window is a junior who needs occasional direction but can execute independently.

What to Watch For

Parallel sessions multiply your output - and multiply your mistakes if you're not paying attention.

Karpathy is explicit about this:

"If you have any code you actually care about, I would watch them like a hawk."

The failure modes in parallel workflows are different from single-session failure modes:

• Diverging assumptions: Two sessions make different assumptions about a shared interface. Catch this during scope-setting, not during merge.
• Silent overreach: One session "improves" something in scope of another session. Use the Karpathy CLAUDE.md rules to enforce surgical changes across every window.
• Compounding errors: A subtle mistake in session A gets imported into session B before you've reviewed it. Review in small increments, not at the end.

The review cadence matters. Don't let sessions run for 30 minutes unattended. Check in every 5-10 minutes - it takes seconds and prevents expensive rewrites.

The CLAUDE.md Layer

Running parallel sessions without consistent behavior rules is asking for chaos.

Drop the andrej-karpathy-skills CLAUDE.md file into your project (or install it as a Claude Code plugin) to enforce four behaviors across every session:

1. Think Before Coding - state assumptions, surface tradeoffs before writing anything
2. Simplicity First - minimum code that solves the problem, nothing speculative
3. Surgical Changes - touch only what the request requires
4. Goal-Driven Execution - loop until success criteria are met

With these rules applied globally, parallel sessions behave consistently. You're not re-explaining the same constraints every time you open a new window.

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

See our full breakdown of the four principles for installation details and what each rule does.

The Bigger Picture

Karpathy named something important at YC AI Startup School: software is entering a third era.

Software 1.0 was explicit code. Software 2.0 was neural weights. Software 3.0 is natural language - you describe what you want, the model figures out how.

The builders who win in Software 3.0 are not the ones who are best at writing code. They are the ones who are best at managing AI agents - breaking problems down, writing sharp success criteria, reviewing outputs quickly, and knowing when to intervene.

Running parallel Claude Code sessions is practice for that skill. The mechanics are simple. The leverage compounds fast.

Karpathy put it plainly: LLMs have crossed a threshold of coherence. The intelligence part is ahead of everything else - the integrations, the workflows, the organizational processes. 2026 is about the industry catching up.

You might as well start now.

AI Builder Club runs weekly workshops on workflows like this - real builders, real tools, this week's techniques. Join 1,200+ members shipping AI products.