One Dev Environment for Humans, Agents and CI – Svetlin RalchevSkip to content

CTRL K

Blog

One Dev Environment for Humans, Agents and CI<br>The Third Axis of Drift<br>Where Docker Stops and Nix Starts<br>The Devcontainer as the Shared Contract<br>The Connective Tissue<br>A Worked Example<br>What Agents Need<br>Why the Setup Is Worth It

Integrating Bounded Contexts

Managing Domain Complexity with Bounded Contexts

Discovering Domain Knowledge

Deconstructing Strategic Design into Subdomains

Hello World!

About

Contact ↗

LightDark<br>System

Light

Dark

System

Blog<br>One Dev Environment for Humans, Agents and CI

One Dev Environment for Humans, Agents and CI

May 20, 2026<br>For years, &ldquo;works on my machine&rdquo; was a two-audience problem. A human ran the code on their laptop, a CI runner ran it in a clean VM, and most of the engineering effort around dev environments was about closing the gap between those two. We got pretty good at it. Lockfiles, container images, build matrices, hermetic toolchains. By 2024 a serious team could plausibly claim that a green CI build was a fair predictor of what would happen on a colleague&rsquo;s machine.<br>That two-audience model is now obsolete.<br>AI agents are the third audience now. They open pull requests, run the test suite, edit code, and expect the repository to behave like a place where work happens. Most of the time the failure has nothing to do with the model. The agent runs just test and gets &ldquo;command not found.&rdquo; It opens a Go file and the language server isn&rsquo;t there. The model is fine; the repo was never set up for it.<br>I want one dev environment that works for all three audiences out of one config, with no per-audience special cases. The pattern I keep coming back to is devcontainer + Nix + Docker , plus two small tools — devcontainer-env and devcontainer-ci — that fill in what the devcontainer spec doesn&rsquo;t cover. The rest of this post walks through that layering and ends with a worked example you can copy.<br>The Third Axis of Drift

Drift, in the dev-environment sense, is the divergence between where code is written and where code is run. The two-audience era worried about two kinds of drift: human-to-human (different laptops, different macOS versions, different Homebrew states) and human-to-CI (the laptop has a stale node_modules, CI starts from scratch).<br>Agents introduce a third kind, and it behaves differently. A human contributor will eventually notice when their tools are missing. They read the error, install the dependency, move on. CI is the opposite extreme: it always starts from nothing and is forced to declare every dependency explicitly. Agents sit awkwardly between the two. They have enough autonomy to keep trying when something breaks, but almost no ability to fix the underlying environment. So they fail in subtler, more expensive ways: they invent a workaround, or they edit the code to compile against whatever Go version happens to be on the host. The pull request looks plausible. The drift is invisible until a human reviewer notices the assumptions baked into the diff.<br>The cheaper fix is to take the variable away. If the agent boots into the same environment the human uses and CI verifies, all three failure modes collapse into one: the environment is wrong. Fix the environment, and everyone benefits at once.<br>Where Docker Stops and Nix Starts

The first time I sat down to design this seriously, I spent an embarrassing amount of time arguing with myself about whether the answer was Docker or Nix. They solve different problems, and the layering matters.<br>Docker is the container. It decides what kernel runs, what filesystem you see, what user you are, what network you can reach. It&rsquo;s great at isolation and portability across operating systems, and mediocre at reproducibility. A Dockerfile that ran fine in March will pull a different apt package in May because Debian&rsquo;s index moved. Pinning every apt version is possible but brittle, and nobody actually does it.<br>Nix is the toolchain inside the container. It pins the language runtimes and CLIs at exact versions through flake.lock, which is a content-addressed snapshot of every package the shell needs. Re-evaluating the same flake on the same lock produces the same closure today and in five years. Nix is excellent at reproducibility, and mediocre at isolation: a Nix shell on a Mac is still subject to whatever the Mac decides to do with file permissions, code signing, and the dynamic linker.<br>Stacked, the two layers cover what neither does alone. Docker provides the kernel and OS surface, so the same instructions behave the same way on a Mac, a Linux laptop, and a GitHub-hosted runner. Nix puts the toolchain inside that surface, so everyone ends up with the same Go, the same Hugo, the same just, lockfile-pinned. The split I use: kernel, filesystem, and network are Docker&rsquo;s problem; which version of which CLI lives on the path is Nix&rsquo;s.<br>The Devcontainer as the Shared...