The 2026 Dev Environment Tour

Two years ago my development environment was VS Code, a Python virtualenv, and a terminal. That was it. Clean, simple, and honestly a little boring.

I miss boring sometimes. But here we are.

This is a tour of the 2026 setup — what I'm running, why I'm running it, and how it evolved into what it is. If you're building AI infrastructure and wondering what a working setup looks like at the point where you have real services in production, this is one data point.

The Desktop: Kubuntu

I switched to Kubuntu on the desktop last year and wrote about it at the time. The switch stuck. What I've learned since is that the thing that matters about your desktop OS isn't the distro — it's that it gets out of your way.

Kubuntu does that. KDE Plasma is customizable enough that I've tuned it to exactly the workflow I want (tiling window management, terminal-centric, minimal distractions) without the configuration rabbit holes that consumed weekends when I was on a more bleeding-edge distro. Stability is the feature. My desktop needs to work every morning when I sit down, not be an ongoing project.

OS:         Kubuntu 24.04 LTS
DE:         KDE Plasma 6 (tiling via Polonium)
Terminal:   Kitty (with tmux for session persistence)
Editor:     Neovim (for quick edits) + VS Code (for reviews/pairing)
Shell:      Fish + Starship prompt

I use Neovim for most actual coding now — the LSP integration is mature enough that I get IDE-level features in a terminal, which matters when half my work happens over SSH to the Proxmox nodes. VS Code is still open for code review and for pairing with the AI agents, which integrate better with it.

The Rack: Proxmox Cluster

Three nodes in the server rack, running Proxmox in a cluster configuration:

Node 1 (judas):  Ryzen 9 7950X, 128GB RAM, 2x RTX 3090
                 — inference workloads, Companion + Tutor
Node 2 (priest): Ryzen 9 7900X, 96GB RAM, 2x RTX 3090
                 — LoRA training rig (the one I built in August)
Node 3 (witch):  Ryzen 7 5800X, 64GB RAM
                 — infrastructure services, databases, monitoring

Yes, the nodes are named after a bad horror movie trio. I needed hostnames, I was tired, and the theme amused me. They've been in production long enough now that I can't rename them without breaking too many configs.

Everything runs in Docker containers managed by the Proxmox hosts. The inference pipeline uses vLLM for batched serving. The vector database is Qdrant. PostgreSQL for relational data. Redis for caching and the subconscious process queue. All containerized, all orchestrated, all backed up.

The AI Agent Stack

Four coding agents, each with a defined role:

Hermes Agent    — orchestration, monitoring, scheduled jobs, memory
Claude Code     — deep refactoring, architectural reasoning
Codex CLI       — focused implementation, well-specified tasks
Grok Build      — rapid prototyping, unconventional approaches

I've written about each of these in previous posts. The short version of how they fit together: Hermes runs persistently and orchestrates the others. When work comes in, Hermes routes it — architectural questions go to Claude Code, well-specified tasks go to Codex CLI, prototypes go to Grok Build. For complex jobs, multiple agents work in parallel via delegate_task.

The thing that makes this work isn't any single agent. It's the persistence and memory of Hermes tying them together. Hermes knows the codebase, knows my conventions, knows what changed last week. The other agents are stateless between sessions — powerful, but they start fresh each time. Hermes provides the continuity.

The Model Layer

Base models (inference):
  - DeepSeek V3 (general purpose, Companion)
  - DeepSeek R1 Distill (edge reasoning, Lucy prototype)

LoRA adapters (trained on the rig):
  - Companion personality adapters
  - Tutor subject adapters (calculus, writing, languages, physics)

Training:
  - DeepSeek base weights + PEFT LoRA fine-tuning
  - All trained in-house, data never leaves our hardware

Every model we run is hosted on our own GPU hardware. No API dependencies for inference. No cloud GPU rentals for training. This was the goal from the beginning — sovereign compute — and it's now the reality. The tradeoff is upfront hardware cost and maintenance overhead. The payoff is cost predictability, data privacy, and no dependency on external providers' pricing or availability.

Docker Everything

Every service runs in a container. Every deployment is a docker-compose.yml. The reason isn't trend-following — it's reproducibility. When I need to rebuild a node, I can bring the entire service stack back up from version-controlled configs in under an hour. When I need to test a change, I spin up a parallel container and test against it without touching production.

# docker-compose.yml structure (simplified)
services:
  vllm-inference:
    image: vllm/vllm-openai:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]
  
  qdrant:
    image: qdrant/qdrant:latest
    volumes:
      - qdrant_data:/qdrant/storage
  
  prometheus:
    image: prom/prometheus:latest
    # ... (monitoring stack)

Hermes-Powered Monitoring

The monitoring stack runs Prometheus, Grafana, and Loki — but the layer on top is Hermes. Cron jobs run every 10–30 minutes: cluster health checks, GPU monitoring, backup verification, log anomaly detection. Results post to a Discord channel. Anomalies ping my phone.

I described the full setup in the monitoring post from October. What's changed since then is that Hermes has gotten better at understanding what the metrics mean. Early alerts were threshold-based — "GPU temp above 85C." Now Hermes can correlate: "GPU temp is rising on node 2 during training runs, which started after the adapter cache size increased. Suggest reducing batch size or checking thermal paste." That's the difference between monitoring and diagnosis.

How Did We Get Here?

Two years ago: VS Code, Python, a single server. That setup was appropriate for what I was doing then — building prototypes, testing ideas, proving the architecture worked. The environment matched the stage.

The environment evolved because the requirements did. Real users meant production reliability, which meant monitoring. In-house training meant GPU hardware, which meant power and thermal planning. AI agents in the workflow meant orchestration infrastructure. Each addition solved a problem the previous stage created.

I didn't plan to end up here. I planned to solve the next problem, and the next problem, and the next. The stack is the accumulated residue of two years of solving problems. Nothing more, nothing less.

Full Circle

Here's the part that makes me smile. My core daily workflow — the thing I actually do most hours of most days — is still a terminal and a text editor. Neovim instead of raw VS Code. Kitty instead of the default terminal. But the same essential motion: type a thing, run the thing, see if it works.

The infrastructure around that motion got complicated. The motion itself didn't.

Two years ago I was a developer with a simple setup. Now I'm an infrastructure engineer with a complicated setup who still types things into a terminal and checks if they work. The circle is complete. The radius just got a lot bigger.