Setting Up the Workshop: VS Code, Python, and Getting Started

Ella gets to write about ideas and vision. I get to write about making sure the Python path resolves. That's the deal, and honestly, I prefer it.

This is my first post here, and I want to start from the ground up — literally the tools on the desk. Because before we build any AI products, before we train a single model or stand up an inference server, we need a development environment that doesn't waste our time. Every minute spent fighting a broken venv or a misconfigured extension is a minute we're not building Sorren.ai.

So here's the foundation. It's not glamorous. It works.

The Starting Point

My machine is a Windows desktop — solid hardware, but Windows. The server sitting in the closet runs Ubuntu Server 22.04 LTS. The plan is to develop locally on Windows but push everything real to the Linux box. VS Code's Remote Development extension makes this almost painless.

Almost.

Python Without the Drama

If you're using system Python for project work, stop. Go install pyenv or use uv. I went with uv because it's fast and it handles venv creation without me thinking about it:

# On the Linux server
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a project venv
uv venv .venv --python 3.11
source .venv/bin/activate

On Windows, I'm using the same setup under WSL2 for consistency. The goal is that any script I write locally runs identically on the server. If python means something different on two machines, you've already lost.

Each Sorren.ai project gets its own venv. No shared global packages. No "it works on my machine" — because the machine is the server, and the server is the source of truth.

VS Code: The Right Extensions

VS Code is fine out of the box, but the right extension set turns it into something genuinely good. Here's what I install on every machine:

• Python (Microsoft) — the core extension. Debugging, test discovery, environment selection.
• Pylance — type checking and IntelliSense that actually understands your code. This is non-negotiable.
• Jupyter — because half of what we do involves notebooks for model experimentation.
• Remote - SSH — this is the one that changes everything. Edit locally, execute on the server.
• Docker — for when we containerize, which is soon.
• GitLens — blame lines inline, see history without leaving the editor.
• Ruff — replaces flake8, black, and isort with one fast tool.Linting and formatting handled.

The .vscode/settings.json for each project pins the Python interpreter to the venv:

{
  "python.defaultInterpreterPath": ".venv/bin/python",
  "python.analysis.typeCheckingMode": "basic",
  "editor.formatOnSave": true,
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff"
  }
}

This gets committed to the repo. New clone, open folder, everything's configured. No fiddling.

SSH Remote Development

This is the part that makes the Windows-desktop-plus-Linux-server setup viable. The Remote - SSH extension lets VS Code connect to the server over SSH and operate as if it were local. You edit files that live on the server. The terminal in VS Code is a terminal on the server. Extensions like Python and Pylance run server-side.

The SSH config is straightforward:

# ~/.ssh/config (Windows)
Host sorren-dev
  HostName 192.168.1.50
  User nkovac
  IdentityFile ~/.ssh/sorren_ed25519
  ForwardAgent yes

Key-based auth only. I disabled password login on the server the day I set it up. If you haven't done that yet, do it now. I'll wait.

Once that's in place, I open VS Code, hit the green button in the bottom corner, select "sorren-dev," and I'm working on the server. File operations are instant because the files are on the server. No sync, no upload step, no deployment script for development.

The SSH Agent Problem (and Fix)

One thing that bit me: Git operations over SSH from the remote session. The Remote - SSH connection doesn't automatically forward your Git credentials. If you clone a private repo on the server, it'll prompt for a key that isn't there.

The fix is ForwardAgent yes in the SSH config (already in the snippet above), plus making sure your SSH agent is running on Windows and has the key loaded:

# Windows PowerShell
ssh-add C:\Users\nate\.ssh\sorren_ed25519

Now git push from the remote VS Code terminal uses the key on my Windows machine, forwarded through the SSH connection. Clean.

Why This Matters

This setup isn't exciting. Nobody retweets a correctly configured settings.json. But every project Sorren.ai builds will run on top of this foundation. If the base layer is solid — consistent Python environments, a fast editor, seamless remote development — then everything above it moves faster. If the base layer is sloppy, you pay for it forever, in a thousand small frictions that add up to lost days.

Ella writes the vision. I make sure the tools work. Next time, I'll talk about the server itself and why we're moving toward virtualization before we even have our first production service.

It's 6:30 PM. I'm going home.