VS Code is your workbench. You write code in it, run it from the terminal inside it, and read errors in it. Understanding its layout means you stop hunting for things and start working. There are only four areas that matter for Phase 1.
The four areas
Everything visible in a working session
📄 summariser.py ×
import csv
def format_client(row):
name = row['Name']
size = row['Employees']
return f"{name} · {size} employees"
# Open the CSV and process each row
with open('clients.csv') as f:
reader = csv.DictReader(f)
Terminal
jakobmollerbeck@iMac mollerbeck % python3 summariser.py
Vestas · 29000 employees
Ørsted · 7000 employees
jakobmollerbeck@iMac mollerbeck % ▋
Extensions installed
Python
Microsoft · Active
Pylance
Microsoft · Active
Activity Bar (left strip) — switches between panels: File Explorer, Search, Git, Extensions. You'll use File Explorer most.
Editor Area (centre top) — where you write code. Each open file appears as a tab. This is where you spend most of your time.
Terminal Panel (centre bottom) — the same terminal you used to run Python commands. Open it, keep it open.
Status Bar (bottom strip) — shows Python version, error count, which Git branch you're on. Glance at it; don't obsess over it.
The one thing to set up now
Open your project folder
VS Code works best when it knows what project it's in
VS Code operates on folders, not individual files. When you open a folder, it becomes your workspace — the File Explorer shows everything inside it, the terminal starts there, and the Python extension knows where to look.
Every session: File → Open Folder → navigate to ~/code/mollerbeck and open it. You'll see your files in the left panel. The terminal will start inside that folder automatically.
Every session: File → Open Folder → navigate to ~/code/mollerbeck and open it. You'll see your files in the left panel. The terminal will start inside that folder automatically.
If the terminal shows a different folder than mollerbeck, run cd ~/code/mollerbeck to get back. Check the prompt — it should say mollerbeck % before you run any Python commands.
Five actions, repeated every session. These become automatic within two weeks. Until then, treat this as a checklist you run through before writing any code.
The session routine
In this order, every time
1
Open VS Code. It should remember your last folder. If not: File → Open Folder → ~/code/mollerbeck.
2
Open the terminal. Terminal menu → New Terminal. Confirm the prompt shows mollerbeck %. If not: cd ~/code/mollerbeck.
3
Open or create your file. In the File Explorer (left panel), click the file you're working on. To create a new one: click the new-file icon at the top of the Explorer panel, or File → New Text File then save it immediately with Cmd + S and give it a .py extension.
4
Write code. Save constantly. Cmd + S after every meaningful change. VS Code shows a dot on the tab when a file has unsaved changes. If you run the script and don't see your latest changes, you forgot to save.
5
Run from the terminal. Click in the terminal panel, then: python3 yourfile.py. Output appears directly below. Errors appear in red — paste the full error text here when you need help.
Before running your script — quick check
✓ File is saved (no dot on the tab)
✓ Terminal prompt shows mollerbeck %
✓ You're running the right filename
Creating and saving files
File naming for Python
Small rules that prevent real problems
Python filenames must end in .py. Beyond that: lowercase, no spaces (use underscores instead), no special characters. Good: client_summariser.py. Bad: Client Summariser.py.
Don't name a file the same as a Python built-in. csv.py or os.py will break imports in ways that are confusing to debug.
Don't name a file the same as a Python built-in. csv.py or os.py will break imports in ways that are confusing to debug.
Save before you run. Always. Running an unsaved file runs the previous version. This is responsible for more confusion than any other beginner mistake.
Danish Mac keyboard note: some standard shortcuts are in different places. The ones below show what to press on your keyboard specifically. You don't need to memorise all of these — learn the top five first, the rest as they come up.
The five you need immediately
Learn these before anything else
Cmd + S
Save file
Save the current file. Run this constantly — after every meaningful change, before every script run.
Cmd + Z
Undo
Undo the last change. Works in the editor — not in the terminal. Keep pressing to go further back.
Cmd + `
Toggle terminal
Show or hide the terminal panel. The backtick (`) is top-left of a US keyboard — on your Danish keyboard it may not work. Use Terminal menu → New Terminal instead.
Cmd + P
Open file by name
Type the filename and jump to it. Faster than clicking through the Explorer when you have multiple files open.
Ctrl + C
Cancel terminal command
Stops a running script or clears the current line in the terminal. If your script is stuck or running forever, press this.
Useful soon
Learn these by Week 3
Cmd + /
Comment out a line
Puts a # in front of the line, disabling it without deleting it. Useful for testing — toggle code on and off to isolate problems.
Cmd + D
Select next match
Highlight a word, press this, it selects the next occurrence. Press again to select more. Lets you rename a variable in multiple places at once.
↑ (in terminal)
Previous command
In the terminal, pressing the up arrow repeats the last command. Press multiple times to go further back. Saves retyping python3 script.py every run.
Cmd + Shift + P
Command palette
Search for any VS Code action by name. If you can't find something in the menus, type it here. Also useful for selecting the Python interpreter.
VS Code shows you two kinds of problems: editor warnings and runtime errors. They look different and mean different things. Understanding which is which saves significant debugging time.
Editor warnings — before you run
VS Code catching problems as you type
The Python extension analyses your code as you write it and underlines problems:
Red underline
Definite error. Python will refuse to run this line. Fix before running. Hover over the underline to read the explanation.
Yellow underline
Warning — possible problem. The script will still run, but something might not work as expected. Common in Phase 1: unused variables.
Blue underline
Information only. Not a problem. Usually style suggestions from Pylance. Ignore in Phase 1.
⊗ 0 △ 0
Status bar error count. The ⊗ is errors, △ is warnings. If ⊗ is not 0, fix those before running. The count updates as you type.
Runtime errors — after you run
Python failing while the script is executing
These appear in the terminal, in red. VS Code didn't catch them because they only happen when the code runs — for example, trying to open a file that doesn't exist.
Typical runtime error — how to read it
Traceback (most recent call last): File "summariser.py", line 12, in <module> format_client(row) File "summariser.py", line 6, in format_client name = row['Name'] KeyError: 'Name'
Read from the bottom up. The last line tells you what went wrong: KeyError: 'Name' — Python couldn't find a key called 'Name' in the dictionary. The line above that tells you where: summariser.py, line 6. Go to that line.
When you get an error: copy the full output — everything from "Traceback" to the last line — and paste it here. Don't describe it in words. The exact text is what matters for diagnosis.
Autocomplete — help or hindrance
VS Code suggests completions as you type
As you type, VS Code will offer to complete variable names, function names, and method names with a dropdown. In Phase 1: use it to confirm spelling, not to avoid typing.
If the dropdown is in the way: press Escape to dismiss it. Press Tab or Enter to accept a suggestion.
If the dropdown is in the way: press Escape to dismiss it. Press Tab or Enter to accept a suggestion.
The right relationship with autocomplete
Autocomplete is useful once you know what you're trying to write. If you're relying on it to figure out what to write, you're bypassing the learning. Type the thing, then let autocomplete confirm it's valid. Not the other way around.
VS Code ships with more features than you need, and adds new ones constantly. Most of what you'll see is noise for Phase 1. This section names the things you should actively dismiss rather than investigate.
Ignore these completely in Phases 1–2
They exist; they're not for you yet
The Chat / Copilot panel
The right-hand pane that says "Build with Agent" or "Describe what to build." This is VS Code's built-in AI assistant. It's not Claude Code. Don't use it — it will write code you can't evaluate yet and short-circuit the learning.
Relevant from: Week 9 (and even then, you'll use Claude Code instead)
Generate Agent Instructions
A link that appears in the Chat pane. Generates configuration for AI agents. Ignore entirely — this is Phase 4 territory at the earliest, and even then you'll do it differently.
Relevant from: Phase 4
MCP Servers (in Extensions)
Visible at the bottom of the Extensions panel. Model Context Protocol — a way to connect VS Code's AI to external tools. You'll use MCP eventually, but through Claude Code, not through VS Code's built-in system.
Relevant from: Phase 3
Jupyter extension prompts
VS Code will sometimes suggest installing Jupyter. Jupyter is a different way of running Python — in "notebooks" rather than scripts. You're learning scripts. Don't install it.
Relevant from: never, for your goals
GitLens install prompts
GitLens is a powerful Git extension. You'll install and use it from Week 7 when Git becomes relevant. If it prompts you before then, dismiss it.
Relevant from: Week 7
Sign in to VS Code
Syncs settings across devices. You have one Mac. Not needed. The Sign In button in the top-right can be safely ignored indefinitely.
Relevant from: never, unless you add a second machine
Inline AI suggestions (grey ghost text)
Copilot may suggest code completions as faint grey text while you type. If you see this, it means Copilot is active. In Phase 1, dismiss these with Escape. You need to write the code yourself to build the evaluation threshold.
Relevant from: Phase 3, with caution
Remote Explorer / Dev Containers
Tools for running code on remote servers or inside Docker containers. Completely irrelevant until Phase 4, and possibly beyond it for your use case.
Relevant from: Phase 4
The general rule: if VS Code is prompting you to install something or enable a feature you haven't heard of, dismiss it and ask here before proceeding. The environment accumulates complexity fast if you say yes to everything.
This tab is for reference only — don't act on it until Week 9. What VS Code looks like and how you use it changes when Claude Code enters the picture. Read this when you get there.
Week 9 onward
VS Code as Claude Code's home
How the environment shifts in Phase 3
Claude Code runs in the terminal — the same terminal panel you've been using. From Week 9, the VS Code terminal serves a dual purpose: running your own Python scripts and running Claude Code sessions.
What changes:
The File Explorer becomes more important — Claude Code edits files directly and you'll watch them change in real time in VS Code. You'll have the Explorer open on the left, the terminal running Claude Code at the bottom, and the editor showing the files being modified.
CLAUDE.md — a special file you'll create in your project folder. VS Code shows it like any other file. It's Claude Code's instruction set for your project. You'll edit it directly in VS Code.
Git integration (left sidebar) — the source control panel (the branching icon) becomes your primary way to review what Claude Code has changed before you accept it. Each file it modifies shows a diff — what was there before vs what it changed.
What changes:
The File Explorer becomes more important — Claude Code edits files directly and you'll watch them change in real time in VS Code. You'll have the Explorer open on the left, the terminal running Claude Code at the bottom, and the editor showing the files being modified.
CLAUDE.md — a special file you'll create in your project folder. VS Code shows it like any other file. It's Claude Code's instruction set for your project. You'll edit it directly in VS Code.
Git integration (left sidebar) — the source control panel (the branching icon) becomes your primary way to review what Claude Code has changed before you accept it. Each file it modifies shows a diff — what was there before vs what it changed.
The core habit from Week 9: before every Claude Code session, commit your current state in Git. After every session, review the diff in VS Code's source control panel before moving on. Claude Code is working in your filesystem — VS Code is how you see what it did.