On this page
My dev setup for AI agents
I hardly write code by hand anymore. Most of the time several Claude Code agents work on different repositories at once, and I read, steer and decide. To make that work without handing the agents my entire digital identity, I built myself an environment. These pages describe it.
This is not an installation guide. Guides go stale faster than you can write them. What you’ll find here is the target architecture: which building blocks exist, what role they play, what they’re good for, what the alternatives are and why I chose the way I did. Where commands show up, they are illustrations.
For your AI: There is a compact version of these docs at /en/docs/dev-setup/llms.txt. Hand the link to your language model (“read this, then let’s talk about this setup”) and grill it. The full text is at llms-full.txt.
Video
A quick overview in under three minutes: the architecture of this setup as an animated explainer. The voice is AI-generated.
Podcast
Rather listen than read? Two hosts spend about a quarter of an hour talking through this setup, its architecture and the reasoning behind it. The voices are AI-generated.
The picture
Tap a building block or a channel.
Three load-bearing principles
Almost every decision in this setup follows from one of three principles.
1. Agents get only as much identity as they need
An agent working on repository A needs access to repository A. It doesn’t need my GitHub account, my SSH keys or my access to the production server. So agents get narrowly scoped tokens instead of my credentials: only for the repos of their environment, and only from a socket that exists solely inside that environment. As long as it runs, the agent has continuous access through it; I can revoke that immediately at any time.
2. Environments are reproducible and disposable
Every working environment is built from the repository’s own devcontainer.json. It
can be deleted and rebuilt at any time. Whatever has to survive (the code, the Claude
login, the agent’s memory) lives outside the container on the host. That’s why an
agent may do anything inside its environment: it is the sandbox.
3. Anything sensitive needs the human
My SSH key lives in the Secure Enclave of my Mac and asks for my fingerprint every time it’s used. An agent can’t do anything with my identity behind my back – at most it can ask me. That’s occasionally annoying and exactly the point.
The building blocks
- Compute: a powerful server instead of a powerful laptop.
- Network: a tailnet provides reachability, not security.
- Hatchery and drones: one container per repository, managed by a small tool.
- Identity and access: two separate channels for agent and human. The heart of it.
- Workplace: SSH, zellij, many agents in parallel, steering from the phone.
- Native apps: Android on the server, iOS as a side note.
- Boundary to the deploy stack: where this setup ends.
- FAQ
All tools mentioned here that are mine are open source: hatchery, dotfiles, devcontainer-template and this website itself.