TL;DR: Run Source Control → New Worktree (or git worktree add ../experiment-X feature-X) to create an isolated working copy on a branch. Point the agent at the worktree; if the experiment fails, delete the worktree — your main branch never touched it.
When you want the agent to try something speculative — a rewrite, a tricky migration, a "just see if this works" change — don't let it loose on your main branch. Fork a worktree, let it experiment, merge only what you want.
AI agents are at their most useful when you let them try something you wouldn't write yourself — a speculative refactor, a tricky migration, a "just see if this works" pass. The catch: trying things on your live working tree is risky. If the agent goes off the rails, it corrupts the same files you're trying to ship from. Your build breaks. Your editor's open chat is now confused about which version of the code is real.
The instinctive answer is "use a branch." That's not wrong, but it doesn't actually isolate anything. Switching branches in your main checkout drags your dirty files along, resets your IDE state, and forces context-switching in the AI chat. A branch is a name for a chain of commits; it's not a place. You can't be in two branches at once.
A worktree is git's real answer to "I want two places at once." It's a second physical checkout of your repository, pointed at a different branch, sharing the same .git store. Two trees, one history. You can have the agent rewrite something in tree B while you keep editing in tree A — separate windows, separate files, no contamination. This tutorial is about reaching for that when the stakes feel high enough to want isolation, and merging back selectively when the experiment lands.
Switching branches in your main checkout drags your in-progress work along — your dirty files follow you, your IDE state resets, the AI's open chat tab is now talking about different code. For a quick fix that's fine. For a high-risk experiment, it's friction.
A worktree is a second physical checkout of your repo, pointed at a different branch, sharing the same .git store. Two trees, one history. You can have the agent rewrite something in tree B while you keep editing in tree A.
In the left sidebar, click the Workspaces tab. You'll see your current project listed with its active branch, plus a + New Worktree button at the top.
Workspaces is also where shadow worktrees show up — the implicit isolated trees the agent uses when it wants to try a tool call without touching your real files (more on that below).
Click + New Worktree and pick a mode:
Pick New branch for this tutorial. Name it something like try-async-await. LingCode runs git worktree add under the hood and opens the new tree in a fresh window.
In the new window, the AI panel is talking about the worktree's files. Give it the speculative prompt: "Convert all of NetworkManager to async/await, no completion handlers." Whatever it changes is local to this tree. Your main branch is untouched.
You can also flip permission mode here to acceptEdits without worrying — auto-accept is a lot safer when the surface is contained.
When the agent finishes, open the diff view from the Workspaces panel — right-click the worktree and choose Compare with main. You'll see every file the experiment touched.
Walk the diff. Some changes will be good; some will be bizarre. That's expected — this is the whole point of doing it in a worktree first.
Two patterns:
This is the part git CLI makes painful and LingCode makes obvious — you can adopt the agent's good ideas without inheriting its bad ones.
Right-click the worktree in the panel and choose Remove worktree. LingCode runs git worktree remove, which deletes the working files but leaves the branch in git history if you committed. If you want the branch gone too, also choose Delete branch.