Title: Lecture — The Developer Toolbox & VS Code as an AI Workstation
Course: AIINFRA 100: AI Systems & Development Environments > Section: Week 06 — The Developer Toolbox & VS Code as an AI Workstation

📖 Lecture — The Developer Toolbox & VS Code as an AI Workstation

Over the last few weeks you set up the pieces of a working environment — VS Code, Python 3.11+, and Docker Desktop were installed back in Week 1, and in Week 5 you wrote your first Python for AI. This week we step back and look at those pieces as a system, then turn that plain editor into a customized AI/ML workstation.

The anatomy of a developer's toolbox

A professional development environment is not one program — it's a stack of distinct, cooperating layers. From a solo hobbyist to a 500-person engineering team, every setup is built from the same recognizable pieces:

Layer | What it does | Common example
Editor / IDE | Where you read, write, and navigate code | Visual Studio Code (VS Code)
Language runtime | The program that actually executes your code | Python
Version control | Tracks every change to your code over time | Git
Remote host | Stores and shares your version-controlled code | GitHub
Terminal | A text-based way to run commands directly | Integrated terminal in VS Code
AI coding assistant | Suggests and helps write code as you type | GitHub Copilot

A very common beginner assumption is that VS Code is the development environment. It is not. VS Code is the window you look through, but the interpreter that runs your Python, the virtual environment that isolates your project's dependencies, and the version-control system tracking your history are all separate, coordinated pieces. Learning to tell these layers apart matters: when something breaks, you'll know which layer to investigate instead of restarting everything from scratch.

Local development vs. cloud development

Once you can name the layers, notice that you can run them in two places: locally on your own machine, or in the cloud, on someone else's machine reached through a browser. Local development means every layer — editor, runtime, Git, terminal — lives on your laptop. You get full control and offline access, but your experience depends on your own hardware and whatever you have installed. Cloud/browser-based development, such as GitHub Codespaces, flips this around: you open a browser tab and get a consistent, pre-configured environment reachable from any device, identical to what a teammate sees. That's why teams favor it — nobody loses a day to "it won't install on my laptop." The trade-off: it needs internet access, and while free tiers are generous, heavier use typically needs a subscription/quota once you exceed them. Neither approach is simply "better"; professionals move between both. A related idea you'll hear about: containerization, most commonly via Docker (installed in Week 1), is how teams make "it works on my machine" reproducible everywhere by packaging code with everything it needs to run. Containers are covered in depth in AIINFRA 101; the vocabulary starts now.

Turning VS Code into an AI/ML workstation

On its own, VS Code is a fairly plain text editor — its real power for AI and data work comes from extensions. Turning that plain editor into a workstation is this week's main event. The Python extension is your foundation. The single most important extension for this course is the Python extension (ms-python.python). It turns VS Code from a generic text editor into a Python-aware IDE, giving you IntelliSense (smart autocomplete), linting (warnings about likely bugs or style problems), debugging (step through code line by line), and interpreter selection. That last piece trips up almost every beginner. A "Python interpreter" is just a specific Python program on your disk, and each one has its own separate set of installed packages. A virtual environment (venv), a Conda environment, or a uv-managed environment is each a different interpreter with different packages. VS Code does not automatically know which one you want — you tell it, and that choice is remembered per project (per workspace), not globally. (Environment and package management is Week 9's whole focus; this week you just point VS Code at the right one.) Notebooks, right inside the editor. The Jupyter extension (ms-toolsai.jupyter) adds full support for .ipynb notebook files directly inside VS Code — mixing Markdown explanation cells with executable code cells, running them one at a time, and seeing outputs (tables, print statements, charts) appear inline, right under the cell that produced them. You get the same IntelliSense and debugging in a notebook cell that you get in a regular .py file. (We go deep on Jupyter and data libraries in Week 10.) Seeing your Git history, not just trusting it exists. GitLens (eamodio.gitlens) supercharges the Git support VS Code already ships with. Out of the box VS Code can stage, commit, and push — GitLens adds inline "blame" annotations (who changed this line, and when), a searchable commit history, and repository visualizations. Git often feels like a black box for beginners; GitLens makes the history you're building visible and explorable. You'll put Git to real use in Weeks 7 and 8. AI assistants: powerful, but not infallible. AI coding assistants (for example, GitHub Copilot's inline suggestions and chat) install as ordinary VS Code extensions. They can meaningfully speed up your work, but they are not a substitute for understanding your own code. A suggestion is a probabilistic guess at what code might come next — not guaranteed to be correct, secure, or even syntactically valid for your situation. Treat every suggestion like advice from a classmate: read it, understand it, then accept, edit, or reject it. Never paste in a multi-line suggestion you can't explain in your own words.

Settings: User vs. Workspace

VS Code settings exist at more than one scope:

Scope | Where it lives | Applies to | Typical use
User settings | Stored globally on your machine | Every VS Code window you open | Personal preferences: theme, font size, keybindings
Workspace settings | .vscode/settings.json inside the project folder | Only that project | Project-specific needs: interpreter path, format-on-save, linting rules

When both are set, Workspace settings override User settings for that project. This is powerful for teamwork: because .vscode/settings.json is just a file in your project folder, you can commit it to Git and share your project's settings with every teammate (or your future self) automatically.

The integrated terminal

The integrated terminal (toggle it with Ctrl+ ) runs the exact same shell commands as a standalone terminal app, but it is "aware" of your open folder — it opens already cd'd into your workspace. With shell integration enabled, VS Code can also show command status (success/failure) and track your working directory. This is where you'll spend a lot of time for the rest of the course, running commands like python, git, and uv` directly against the project you have open.

Two misconceptions to correct

"I installed the extension, so it works everywhere now." Extensions install once and are available in every window, but the interpreter/environment an extension like Python uses is selected per project. If you open a brand-new folder and Python "stops working" or your packages "disappear," it's almost always because VS Code is pointed at a different (or no) interpreter for that folder. Always check interpreter selection first when starting a new project. "Once I save a file, it's on GitHub." It isn't. A saved local file only reaches GitHub when you deliberately commit it (a labeled snapshot) and then push that commit — syncing is an action, not a background guarantee. You'll practice this workflow directly in Weeks 7 and 8.