Configure it once.
Then let it work.

That sentence is a trade, so let us do the trade arithmetic. A working year, counted as five days a week for fifty weeks, is 250 days. Twenty minutes lost each of those days is 20 × 250 = 5,000 minutes, which is 83.3 hours — about 10.4 eight-hour working days, or two working weeks a year, spent inside a tool that could have been configured before lunch.

Where do twenty minutes a day actually go? The source names four frictions: no autocomplete, no type hints, no inline errors, manual formatting. Here is one plausible split of a single day — illustrative, not measured, but every line of it is the kind of minute you will recognise:

Notice what that arithmetic does not include: the expensive version of the same mistakes. A stale file because you forgot to save starts a run with yesterday’s code. A typo in a keyword argument survives until the data has loaded and the first batch is on the GPU. At an invented example rate of $2.34 per GPU-hour, one three-hour run that dies at minute 90 wastes about 1.5 × 2.34 ≈ $3.51; avoid fifty of those in a year and the squiggle in the margin is worth roughly $175. The price is a label for the arithmetic, not a quote — the point is that editor mistakes and GPU mistakes are the same mistakes, priced differently.

Here is the machinery behind all four frictions. The editor does not know Python; it knows how to talk to something that does. That something is a language server — for Python in VS Code, Pylance — and the conversation follows a standard called the Language Server Protocol (LSP): the editor asks for completions, type information or diagnostics, the server answers, and neither side needs to know how the other is built. That split is why a Python language server (Pylance where it runs; pyright or pylsp in Neovim) can serve VS Code, Cursor and Neovim, and why the lab below is a two-panel conversation rather than a single box.

Layer 1 — the base editor. The source recommends VS Code, and gives four reasons: it is free, it runs on every OS, it has first-class Jupyter notebook support, and its extension ecosystem covers everything an AI workflow needs. Nothing in this lesson is about taste; it is about the ecosystem and the notebook support being where the rest of the course already lives.

Layer 2 — the extensions. Eight of them, and the source’s table maps each to a job: Python (language support, virtual-env detection, run/debug), Pylance (type checking, autocomplete, import resolution), Jupyter (notebooks and the variable explorer), GitLens (who changed what, inline blame), Remote SSH (a folder on a GPU box as if it were local), Debugpy (step-through debugging), Black Formatter (auto-format on save) and Ruff (fast linting). Without layer 2, layer 3 has nothing to configure.

Layer 3 — the AI-specific settings. Five keys, chosen because the work is Python that runs for hours: type checking on basic, format on save, rulers at 88 and 120, notebook output scrolling, and auto-save. This is the layer where the editor stops being a text box and starts knowing things about your code.

Layer 4 — terminal integration. Training scripts, environment management and GPU monitoring all happen in a shell, so the shell lives inside the editor: a default profile per OS, a readable font size, 10,000 lines of scrollback, and split panes — one for the run, one for watch -n1 nvidia-smi.

Layer 5 — remote development. The layer that matters most for AI work and the one no screenshot can show: over SSH (Secure Shell, the encrypted protocol for logging into another machine) the project folder, the interpreter, the GPU and the debugger live on a remote machine, while the window you type into stays on your laptop.

Step 1 — the editor. Download VS Code from code.visualstudio.com and install it. The source’s reasons are worth repeating because they are why this course standardises on it: free, every OS, first-class Jupyter notebook support, and an extension ecosystem that covers AI work. Then verify that the command-line tool exists — because every subsequent step uses it:

Step 2 — the extensions. Open the integrated terminal inside VS Code with Ctrl+` — the same chord on every platform — and paste the eight commands. This is the moment the setup starts paying: eight marketplace searches, eight Install clicks and eight reload prompts collapse into one paste of code --install-extension lines.

What each one buys, in the source’s own framing:

The source ships a longer recommendations file, code/.vscode/extensions.json, and VS Code will offer to install it when you open the project folder. It lists the eight above plus five optional entries: ms-vscode-remote.remote-containers (Docker, which has its own lesson), the Jupyter helpers ms-toolsai.vscode-jupyter-cell-tags and ms-toolsai.vscode-jupyter-slideshow, and redhat.vscode-yaml plus tamasfe.even-better-toml for config files. Optional means optional — nothing in the course is blocked without them.

Settings live in JSON, and there are two scopes. User settings belong to your machine — open the command palette with Cmd+Shift+P (or Ctrl+Shift+P) and choose “Preferences: Open User Settings (JSON)”. Workspace settings live in .vscode/settings.json inside the project and travel with it; that is the file the source ships, and the one the rest of this chapter quotes. The format is JSONC — JSON with comments allowed — so you may leave notes to your future self in the file.

1 · python.analysis.typeCheckingMode: “basic” — the highest-value line in the file. Pylance compares what you write against what it knows: the function’s signature, the types on the arguments, the names of the keyword parameters. A call that says epoch=3 where the signature says epochs: int = 1 is flagged at the keystroke, not after the data loader has finished. The setting has three values — off, basic and strict — and the source chooses the middle one on purpose: strict mode on an untyped research script produces so much noise that people turn checking off entirely, which is the one outcome worse than basic.

2 · editor.formatOnSave: true — every save runs the formatter, which the source pins to Black with "black-formatter.args": ["--line-length", "88"]. In this lesson’s playground the long line is 102 characters, so Black rewrites it into a wrapped block the first time you save. The workspace-level benefit is larger than the aesthetic one: when everyone’s file is formatted by the same tool, a diff shows what changed in the code instead of who prefers which spacing.

3 · editor.rulers: [88, 120] — two vertical guides. Black wraps code at 88, so the first ruler is the “this line will be rewritten” marker. The second, at 120, marks the outer limit for the lines Black does not reflow: comments and docstrings. The lesson’s comment line is 125 characters — code under 88, prose past 120, and both facts visible at a glance instead of in review.

4 · notebook.output.scrolling: true — a training loop prints one line per step. Ten epochs of 1,248 steps is 12,480 lines in a single output cell; at roughly 48 bytes per line that is about 585 KiB of text the notebook would otherwise render at once. Scrolling, plus notebook.output.textLineLimit: 500, shows the last 500 of those lines — about 23 KiB, a twenty-fifth of the text — while the rest stays available on the scrollbar.

5 · files.autoSave: “afterDelay” — with files.autoSaveDelay: 1000, the file on disk catches up with the buffer one second after you stop typing. This is the setting that prevents the classic AI-lab failure: you edit the training script, switch to the terminal, launch the run, and discover an hour later that the process read the version from before your edit. Auto-save makes “the file on disk is current” the default instead of a habit.

The integrated terminal opens with Ctrl+` — the same chord on every platform, which is why the source prints it identically in both columns of its shortcut table. What it saves is the context switch: no separate terminal window to alt-tab into, no re-typing the path you just clicked in the explorer, and a shell that inherits the project’s working directory automatically.

Why 10,000 lines of scrollback? Because the line you need is always the one that scrolled away. A training run prints a line per step, an nvidia-smi watcher prints a table every second, and the stack trace you care about appears once, above thousands of loss lines. Ten thousand lines at a rough 80 bytes each is about 780 KiB of terminal history held in memory — an estimate, and a cheap price for being able to scroll back to the first NaN without re-running anything. The default is far smaller, and people discover the limit exactly once: when the line they needed was silently discarded.

Why split panes? A training run occupies its terminal until it finishes; a GPU monitor occupies its own forever. Splitting gives each one a pane, so the run keeps printing while the GPU stays visible — and you catch the moment utilisation collapses instead of finding out from a wall-clock time. The source offers two monitors: watch -n 1 nvidia-smi, which re-runs the command every second, and nvidia-smi -l 1, where the card loops on its own. Either way, the useful columns are the same three: the GPU name, memory used out of total, and utilisation as a percentage of the last second.

The other two chords in the source’s table create and split terminals, and the split is the one that differs between keyboards:Cmd+\ on macOS, Ctrl+Shift+5 on Linux and Windows. If you forget, the command palette is the escape hatch — type “split terminal” and it shows the chord you could have pressed.

Without it, remote work is a loop of copying files: edit locally, upload, run over SSH, paste the traceback back, edit locally again. With it, the remote filesystem appears in the explorer, the remote Python interpreter answers the language server, the formatter runs next to the code it rewrites, the debugger pauses the remote process, and the terminal you type into is a shell on the box. The window, the cursor and your keystrokes stay on your laptop; everything else moved.

Setup, in four steps — the source’s Step 5, unchanged:

1. Install the Remote SSH extension (it is in the eight above).
2. Press Cmd+Shift+P — or Ctrl+Shift+P — and type “Remote-SSH: Connect to Host”.
3. Enter user@your-gpu-box-ip.
4. VS Code installs its server component on the remote machine automatically on first connect.

That works with a password. For passwordless access — the version you want for a box you connect to every day — the source adds two commands and one config file. The key has two halves: a private key that never leaves your laptop (here ~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub) that ssh-copy-id appends to the remote account’s ~/.ssh/authorized_keys. After that, the remote recognises you without a prompt, and Remote SSH connects instantly.

The Host gpu-box line is a nickname: it is what you type in the explorer, in ssh gpu-box, and in every other command. ForwardAgent yes forwards your SSH agent so that, once you are on the box, further SSH hops (pulling a private repository, for example) can use the same key without copying it to the remote disk.

Two things about the remote split are worth internalising. First, extensions run remotely too: Pylance indexes the remote project, Black formats the remote file, the debugger attaches to the remote process. That is why a remote session takes a moment to set up on first connect — the server side has to be provisioned — and why the extensions you installed locally appear on the remote end of the session. Second, the run is not your laptop’s problem: the training process lives on the box, so closing the lid or losing Wi-Fi does not kill it. Reconnect and the terminal shows what happened while you were away.

A fork is a copy of a codebase that then evolves on its own. Cursor and Windsurf are VS Code forks with AI generation added, which has two consequences that matter here. The first is compatibility: because they inherit the extension host and the settings schema, the eight extensions install, .vscode/settings.json is read, and Remote SSH works the same way. The second is that the material in this lesson is not a VS Code lesson at all — it is an editor-workflow lesson, and it survives the switch.

Neovim is the real alternative. If you already live in it, the source says to stay — and lists the minimum for AI Python work. Five pieces, each doing one of the jobs the eight extensions do in VS Code:

Notice the shape of that table: the same five jobs, different packaging. Which is the deeper point about LSP — the editor is a client, the language server is a separate process, and the protocol between them is standardised. That is why a Python language server (Pylance where it runs; pyright or pylsp in Neovim) can serve VS Code, Cursor and Neovim with the same answers, and why moving editors does not mean learning a new type checker.

Then the source’s advice, which is worth quoting rather than paraphrasing: “If you do not already use Vim, do not start now. The learning curve will compete with learning AI engineering.” That is not a judgement about Vim. It is the same 20-minute arithmetic from chapter 01 with different numbers: a week spent learning modal editing and plugin configuration is a week not spent learning tensors, and the setup’s whole purpose is to stay out of the way.