GitHub Copilot’s New /worktree and /rewind Commands: A Beginner’s AI Coding Experiment Checklist for 2026

On August 7, 2026, GitHub published a Copilot update that looked like a bag of small conveniences: a /worktree command for isolated code experiments, /rewind for restoring a session and its files, /side in the Copilot app, and /btw in VS Code for asking a parallel question without interrupting the main task.

I think those features point to one bigger problem in AI-assisted coding:

Exploration contaminates the real project surprisingly fast.

You ask an innocent question about a different database. The agent edits three configuration files to “show you.” You ask whether the screen would be cleaner with another navigation pattern. The agent starts refactoring the current layout. Ten minutes later, your working app has become a museum of half-decisions.

The beginner mistake is not exploring. Exploration is useful. The mistake is exploring in the same lane where your last known-good version lives.

The durable lesson behind GitHub’s update is simple: separate a question, an experiment, and a product change before you ask AI to act.

What GitHub actually changed

GitHub’s August 7 weekly release added several ways to keep work from colliding:

• Copilot CLI’s experimental /worktree command creates an isolated Git worktree from the current HEAD and starts a separate conversation there.
• /rewind can return a conversation and its file state to an earlier point without requiring Git in every mode.
• The Copilot app’s /side and VS Code’s /btw let you ask a related question without redirecting the main task.
• VS Code 1.132 also added element-level browser feedback, so a builder can point at the exact page element that needs attention instead of asking for a broad redesign.

These are not proof that an agent can safely run wild. They are controls for keeping different kinds of work separate.

If you are still turning a rough app idea into one controlled first build, my AI App Builder Starter Prompts are free. They help you define the job, boundaries, and proof before an AI coding tool starts changing files.

The three lanes I would give every beginner

You do not need enterprise process. You need three labels.

1. Question lane

Use this when you want an explanation, comparison, or second opinion but do not want files changed.

Examples:

• “What are the tradeoffs between a tab bar and a navigation drawer for this app?”
• “Why did this test fail?”
• “Would local storage still work if I add accounts later?”

The output is knowledge. It is not permission to edit.

A side chat is helpful here because it can share enough context to answer the question without hijacking the agent’s current turn. But the tool is optional. The operating rule matters more: a question stays read-only until you explicitly promote one answer into an experiment.

2. Experiment lane

Use this when the answer must be tested in code.

An experiment should have its own branch or worktree, one hypothesis, and a discard option. The official Git documentation describes worktrees as multiple working trees attached to one repository, each with its own checked-out state. It specifically notes that a throwaway worktree is useful for experimental changes that should not disturb current development.

That is perfect for questions such as:

• Can this list render 1,000 records without stuttering?
• Can I replace this API client without changing the screen contract?
• Does the new layout make the primary action clearer on a small phone?

The experiment exists to answer one question. It does not earn a place in the product merely because the code runs.

3. Product lane

This is your last known-good version plus changes that passed a stated check.

The product lane should be boring. It should not contain abandoned files from three possible stacks, half of a visual redesign, or a package that was installed “just to see.”

Only promote an experiment after you can name:

• the user outcome it improves;
• the exact files or behavior it changes;
• the evidence that it works; and
• the experiment files you are deliberately leaving behind.

The seven-step AI coding experiment checklist

Here is the checklist I would use before letting an AI tool explore a real app.

1. Mark the last known-good state

Before the experiment, make sure you can identify the version that currently works. For a Git project, that usually means a clean status and a named commit.

Write down one sentence:

Last known-good proof: [workflow] passed at [commit or checkpoint].

If you cannot identify the starting point, you will not know whether the experiment improved the app or merely changed it.

2. Write an experiment card

Use this tiny template:

Question:
[What are we trying to learn?]

Allowed change:
[Files, screen, component, or service the experiment may touch]

Must not change:
[Working behavior that must remain intact]

Pass evidence:
[Visible result, test, timing, or user-flow proof]

Exit decision:
[Merge, revise, or discard]

This is more useful than “try another approach.” It gives the AI a finish line and gives you a way to reject an impressive detour.

If you want guided language for defining those boundaries, use the free AI App Builder Starter Prompts and turn the relevant planning prompt into your experiment card.

3. Decide whether the task needs code

Keep comparisons and explanations in the question lane. Move to an isolated experiment only when the uncertainty requires a running result.

This sounds obvious, but AI tools make editing so easy that builders use code changes as a substitute for thinking. You do not need to install a second backend to understand its tradeoffs. You need an experiment only when documentation and reasoning cannot answer the product question.

4. Isolate the file changes

Create a separate worktree or branch before the agent edits. GitHub’s current Copilot CLI reference says /worktree leaves uncommitted changes in the current worktree and begins the separate task from HEAD.

That detail matters: isolation is strongest when the starting point is intentional. If your main workspace already contains five unrelated unfinished changes, an experimental branch does not magically clarify them.

One experiment should have one name. “test-auth-error-copy” is better than “ai-idea-4-final-new.” Your future self is already tired. Be kind to that person.

5. Ask side questions without changing the mission

During the experiment, questions will appear. Ask them without silently replacing the original goal.

Keep the experiment card visible and use this sentence:

Answer this as a side question. Do not edit files or change the experiment goal.

GitHub and VS Code now provide dedicated side-question surfaces, but this sentence works as a policy in any capable AI coding tool.

6. Review the experiment as a decision, not a demo

Run the pass evidence from the card. Then compare the experiment with the last known-good state.

Ask:

• Did the target workflow improve?
• Did a protected behavior change?
• Did the experiment add a dependency, migration, or maintenance burden?
• Can I explain the diff without asking the agent to explain its own explanation?
• Would I choose this result if the code had taken a human two days to write?

That last question removes the “AI made it quickly, so we may as well keep it” bias.

7. Merge deliberately or discard completely

There are three honest outcomes:

• Merge: the experiment passed and the diff belongs in the product.
• Revise: the idea is useful, but the implementation or proof is incomplete.
• Discard: the question was answered and the product should remain unchanged.

Discarding code is not wasted work. The experiment bought information without charging the main branch for maintenance.

Why /rewind is a recovery tool, not a backup plan

The new /rewind command sounds comforting, but GitHub’s rollback documentation includes an important warning: a Git-based rewind can restore the entire workspace snapshot, including manual edits and new files created after that point. Rewinding also removes later session history, and the rewind itself cannot be undone.

That is the tradeoff beginners can miss.

An undo button is useful. It is not a substitute for a known-good commit, an isolated worktree, or a reviewable diff.

My rule would be:

Isolate before the experiment. Rewind only when you understand what the chosen checkpoint will remove. Verify the repository afterward.

GitHub recommends checking status, the current commit, and the diff after a rollback. The larger lesson applies to every AI coding tool: never treat a recovery message as proof that your project state is correct.

What you should do next

Before your next AI coding experiment, draw three lines in your task note:

Question: What do I need to understand?
Experiment: What isolated change would prove it?
Product: What evidence would earn the change a merge?

Then refuse to skip a line.

That habit survives every tool update. GitHub may rename a command. Another AI coding tool may use sessions, branches, sandboxes, or checkpoints. The control stays the same: questions may inform experiments, and experiments may inform the product, but neither gets to become the product by accident.

For the immediate guided action, AI App Builder Starter Prompts is free and helps you turn a rough idea into bounded, testable work.

For the organized path from idea through architecture, QA, deployment, and publication, AI App Builder From Zero is the deeper build-along field manual.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/