← Back to Autonomy

Field Note · AI Tooling

From Claude Desktop to Copilot in VS Code

A practical transition for engineers who already think in projects, prompts, and files.

By Majid Mazouchi

If you have spent the last year working inside Claude Desktop, attaching project files and asking it to think through problems, the shift to VS Code with GitHub Copilot will feel strange at first. The model is the same. The room around it is different. This note explains the new room.

1.What is actually changing

The model stays. The interface around the model is what shifts.

Claude Desktop is a chat application. You make a Project, attach files, and have conversations. The model reads what you attached. It cannot see your filesystem. It cannot run commands. When it writes code, you copy that code out by hand and paste it into your editor.

GitHub Copilot in VS Code is the opposite arrangement. The editor is the application. Copilot is a panel inside it. The folder you opened in the editor is what the model sees. When the model writes code, it writes to disk. When it needs to test something, it can run a command in the terminal. You review the diffs, you approve or reject, you commit through Git as usual.

Same Claude Opus underneath in both cases. Different leverage.

2.A useful analogy

A consultant who comes to your office, versus one you email files to.

In Desktop, you are emailing a consultant. You attach the documents they need, ask a question, get an answer, copy it into your work. The consultant never sees your office.

In Copilot, the consultant is sitting in your office. They can see your files. They can open drawers, read documents on your desk, run a calculator at your computer, and write notes on your whiteboard. You still review and approve everything. But the back-and-forth of attaching files goes away, because the files are already there.

This is also why the workflow changes shape. In the email model, you write long, complete prompts because each round-trip is expensive. In the in-office model, you write short prompts and iterate quickly, because the consultant can look around for what they need.

3.The three modes, explained simply

Copilot has a small dropdown that controls how much rope the model gets. Click each mode below.

The mode dropdown sits next to the model picker at the bottom of the chat panel. Start a session in Ask mode if you want to think out loud. Switch to Edit when you know the change you want. Switch to Agent when you want the model to handle a multi-step task end to end.

4.Project knowledge, in a file

The single most useful trick to learn first.

In Desktop, you attach reference documents to a Project. In Copilot, the equivalent is a single Markdown file with a specific name and location. Copilot reads it automatically every time you open a chat in that workspace.

What goes inside it: the project's purpose in two sentences, the stack and conventions you want the model to follow, hard rules about what it must never do, soft preferences for code style, and a pointer to any spec or design document. Keep it short. One page is plenty. Here is a starter:

# Agent Instructions

## Project
We are building a control diagnostics tool for an electric drive.
Read docs/BLUEPRINT.md before any non-trivial change.

## Stack
Python 3.11. Use type hints. Use pytest. Avoid new dependencies.

## Rules
- Always write tests for new modules.
- Match data structure names exactly to the blueprint.
- Plain text in any user-facing documentation, no markdown.
- No em-dashes in generated prose.

## Verify
Run: pytest tests/ -v

5.What happens when you press Send

A simplified view of the agent loop in Agent mode.

When you give Agent mode a real task, the work is not a single response. It is a loop. The model plans, acts, observes the result, and decides whether it is done or needs another round. Understanding this loop is the difference between fighting the tool and using it well.

Three implications of this loop matter for how you prompt:

First, the model can recover from its own mistakes. If a test fails, it sees the failure and tries again. You do not need to babysit it through every step.

Second, the loop has a cost. Each cycle is several API calls. Tasks that fit in one shot (a small refactor, a single function) should use Edit mode instead. Save Agent mode for work that genuinely needs the loop.

Third, ambiguous prompts produce ambiguous plans. Give the model a clear goal and a clear way to verify success, and the loop converges. Give it a vague request and it wanders.

6.Files, images, and memory

Three small things that work differently from Desktop.

Files

You stop attaching files. The workspace is already open. To point the agent at a specific file or section, type it inline:

The first form points at one file. The second scopes to a line range, which keeps context tight. The third tells Copilot to index and search the whole repo before answering.

Images

Drag any image directly into the chat input. Opus is vision-capable, so it will see what you dropped: a screenshot of a build error, a Simulink subsystem, a whiteboard photo, a UI mockup. For Simulink work specifically, screenshots of subsystem diagrams turn out to be very useful context. The model reads block names, port labels, and signal flow.

Memory

Copilot has no built-in cross-session memory. Each chat starts fresh. The replacement is a convention: keep a PROGRESS.md file in the repo that captures current focus, decisions made, open questions, and next steps. At the start of every session, ask the agent to read it. At the end, ask the agent to update it. Commit the change. Now your project has durable memory that survives restarts.

7.A small example, end to end

What a typical task actually looks like.

Suppose you want to add input validation to a Python function. Here is how the same task plays out in both worlds.

In Desktop: open Claude. Find the project. Paste the function into the chat. Ask for input validation. Read the answer. Copy the new version. Switch to VS Code. Find the original function. Replace it. Save. Run the tests yourself. If a test fails, copy the error back into Desktop. Paste. Ask for a fix. Copy that fix. Paste. Save. Repeat.

In Copilot, Agent mode: open the chat panel in the workspace where the function lives. Type:

Add input validation to validate_speed() in src/control/limits.py.
Reject negative values and non-numeric inputs. Include a test in
tests/test_limits.py. Run pytest when done.

The agent reads the file, proposes the change as a diff in the editor, you click Keep, it writes the test, runs pytest, sees the result. If a test fails, it iterates and tries again. The whole exchange is a few minutes. The copy-paste loop disappears.

This is the productivity gain people talk about. It is not the model being smarter. It is the model being closer to where the work actually happens.

8.What to do on day one

Five steps, in order, to be productive immediately.

One. Open VS Code, open the Copilot chat panel, look at the model picker at the bottom of the chat input. Confirm Claude Opus is in the list. If not, ask IT to enable the Claude policy in the GitHub Copilot admin settings.

Two. Open your first project folder. Create .github/copilot-instructions.md. Five short sections: Project, Stack, Rules, Conventions, Verify. One page maximum.

Three. Create PROGRESS.md at the repo root with three headings: Current Focus, Decisions Made, Next Steps. Leave it mostly empty for now.

Four. Open the chat panel. Select Claude Opus. Select Ask mode. First prompt: "Read .github/copilot-instructions.md and propose a starter project structure." Approve, push back, iterate.

Five. Watch the VS Code Learn series on YouTube while you wait for builds. Six short episodes, about forty minutes total. References below.