GuideIntermediate

Claude in VS Code · put 3 AIs to work in parallel and move three times as fast

When your project grows, a single AI doing one thing at a time falls short — you want to move faster and try several things at once. Here's the trick the people who build seriously use (and that we use): you open SEVERAL AI sessions in parallel, each in its own isolated version of the project. One builds a feature, another fixes something else, another tries a new idea — the three advancing at the same time, without stepping on each other and without touching your main version. And each one, when it's done, gets audited with the C-A-R protocol and merged into the project only once it turned out flawless. Result: you move three times as fast, with a safety net. These live copies are called worktrees, and with Claude inside VS Code creating one is a single command. Here you'll understand the benefit, how it works without the jargon, and the prompt to set it up.

Jun 21, 202612 min

Who is this for?

For anyone already building with a coding agent (like Claude Code) who wants to move faster by working like a pro — without writing extra code. It's the natural sequel to the [GitHub guide](/recursos/guarda-todo-en-github-antes-de-que-la-ia-lo-rompa): there you learned to save your work and roll back; here, you learn to work on several fronts at once.

When does the need show up? (the exact moment)

The moment arrives when your project grows and a single AI, doing one thing at a time, isn't enough anymore. You want to move faster: while one session builds a feature, another fixes a bug and a third tries out a new idea — all at once. It also shows up when you're torn between two paths ("should I do it this way or that way?") and want to see both before deciding. Or when you want to try something risky without touching what already works. In every one of those cases, going one thing at a time on your single version is slow and fragile.

The pain it's born from · slow and scared

Two pains at once. The speed one: with a single session you advance single-file — you finish one thing so you can start the next, and a big project turns painfully slow. And the fear one: since everything happens on your one good version, you're afraid the AI will break something while "improving" something else, so you ask for timid changes. Working in parallel, on isolated versions, kills both: you move on several fronts at once AND without risk.

What is a "worktree"? (in plain terms)

In the GitHub guide you saw branches: parallel copies of your project. A worktree takes that one step further: it lets you have several of those branches open and live at the same time, each in its own folder, without one touching the other. While one AI works on "idea A", another can be on "idea B", and your main version stays untouched. It's not one at a time — it's all of them at once.

Picture it like this · living photocopies

Your main project is the original document. A worktree is a photocopy that takes on a life of its own: you can scribble all over it while the original stays clean on another desk. And you can have five photocopies at once, each with a different idea. In the end, the one that turned out well you copy back to the original; the rest go in the trash. The original was NEVER at risk.

The superpower · one branch per idea, with Claude in VS Code

Claude Code has an official VS Code extension (it also works in Cursor and compatible editors). From there you open several AI sessions in parallel, each in its own worktree, and you see the changes it proposes with a visual diff (side by side) that you approve or reject. Best of all: creating an isolated worktree is a single command.

Create a worktree for an idea (one command)bash

claude --worktree mi-idea-arriesgada

That creates an isolated copy of your project (at .claude/worktrees/mi-idea-arriesgada/) on a new branch, without touching your main version. You work the idea there; if it works out, you merge it in; if not, you delete it and nothing happened. You can open another session with claude --worktree otra-idea and have the two competing at the same time.

Don't memorize commands · just ask your AI

As in the whole series: if you don't want to touch the terminal, just talk to your agent. "Open a worktree to try out [your idea] without touching my main version" — and it does it. You just decide which idea to try and which one you keep.

3 scenarios where this saves you

1 · The risky change

You want to redesign something big but you're afraid of breaking what works. You do it in a worktree: if it turns out well, you merge it; if it turns out badly, you toss it. Your good version never even noticed.

2 · The two paths (this way or that way?)

You don't know whether a feature should be built one way or another. You open TWO worktrees, let the AI try each approach in parallel, compare them with real results, and keep the winner. You decide with evidence, not with hunches.

3 · The stuck session

A conversation with the AI got tangled up or went down the wrong path. Instead of losing it, you open another session in parallel (its own worktree) and carry on fresh, without throwing away the first one's work.

This is how we work · several sessions at once (the big accelerator)

This is the biggest benefit, and it's exactly how we build: instead of a single AI advancing single-file, we have several sessions working in parallel, each in its own worktree. Session 1 builds one part of the product, session 2 puts together something else, and a session 3 could be trying out a new idea — the three advancing AT THE SAME TIME, without stepping on each other. It's like having three employees instead of one, each at their own desk, out of each other's way.

The full flow (parallel + C-A-R + merge)

The key to keeping this from becoming chaos: each session wraps up its work properly before merging it. The cycle: (1) each session works on ITS OWN branch/worktree · (2) when it finishes something, you apply the [C-A-R protocol](/recursos/protocolo-car-construir-sin-bugs) to it — you audit, debug, leave it flawless · (3) only then do you merge that branch into the main one · (4) repeat with the next one. That's how you move three times as fast, but each piece enters your good version clean.

The rule that prevents disaster · push to YOUR branch, not the main one

The classic mistake when working in parallel: pushing to the main branch from a half-finished session and clobbering someone else's work. The golden rule: each session saves and pushes to ITS OWN branch, never straight to the main one. The main branch only receives things via merge, and only after auditing. If in doubt, ask your AI: "push to this session's branch, not to main".

Picture it like this · several cooks, one orderly kitchen

Three cooks bumping into each other in the same kitchen is chaos. But if each one has their own counter (their worktree) and only brings the dish to the main table when it's finished and tested (the merge after C-A-R), the kitchen flies: three dishes come out in the time of one, and none comes out half-done. That's parallel work done right.

The visual review · you approve or reject, you're in charge

Inside VS Code, when the AI wants to change a file, it shows you a side-by-side comparison: what was there vs. what it's proposing. You decide: accept, reject, or tell it what to change. Nothing gets modified behind your back. It's like having your employee show you every change before applying it, instead of touching everything and letting you find out afterward.

Honest expectation

The review is file by file (side-by-side diff, accept/reject), not a perfect "approve everything in one go" just yet. And merging branches sometimes has conflicts that get resolved with the normal git flow — though the AI helps you in plain language. No smoke and mirrors: it's powerful, but it's a work tool, not one-click magic.

The golden routine · move in parallel without chaos

The habit

One session = one branch/worktree: each work front in its own isolated copy. Never several on the main version.

Push to YOUR branch, never to the main one: each session saves to its own; the main one only receives via merge.

Audit with C-A-R before merging: no branch enters the main one without passing its audit/debug first.

Review the diff in VS Code before accepting — you're in charge, not the AI.

Merge only what turned out flawless: the finished, audited piece gets merged; the ideas that didn't pan out get deleted, guilt-free.

Ready-to-use prompt · set up your parallel workflow

Copy it and paste it to your coding agent so it guides you to work on several fronts at once, without you having to learn any commands:

Paste it to your agent · working across several sessions in paralleltexto

I want to move faster on my project by working across SEVERAL sessions in parallel, each in its own isolated version (worktree), without them stepping on each other or breaking my main version. Guide me in simple language, assuming I don't know git.

1. Explain in one sentence what a worktree is (a live, isolated copy of my project).
2. I'm going to work on these fronts at once: [list your tasks, e.g.: "1) redesign the home page, 2) fix login, 3) try a new idea"]. Create a dedicated worktree for each one, branching from my stable version.
3. Tell me how to open VS Code in each worktree to see the diff and approve/reject the changes visually.
4. IMPORTANT RULE: each session must push to ITS OWN branch, NEVER to the main one (main). The main branch only receives things via merge.
5. When I finish a task in its worktree, before merging it: apply the C-A-R protocol to it (audit, debug, leave it flawless). Only then merge that branch into the main one, and resolve any conflict in plain language.
6. If an idea didn't pan out, help me discard its worktree without my main project ever noticing.

Golden rule: I move in parallel, but only audited work enters the main branch, via merge — never half-done.

In NeuralOS, the isolation comes built in

In NeuralOS, every work session with an agent is already born isolated — you try things out without them stepping on each other, without having to think about worktrees or branches. The idea of "experiment in parallel without fear" is part of how the product is designed. If you want that superpower without the learning curve, that's the shortcut.

Save everything to GitHub · the foundation of all this

Worktrees are built on top of git branches. If you skipped the GitHub guide, start there.

The C-A-R protocol · audit every branch before merging

Before merging an idea into your main version, audit it with C-A-R. It pairs perfectly with parallel work.

#claude-code#vscode#worktrees#productividad

Ready to build?