On this page
Mein Dev-Setup für KI-Agenten
Ich schreibe kaum noch Code von Hand. Meistens arbeiten mehrere Claude-Code-Agenten gleichzeitig an verschiedenen Repositories, und ich lese, lenke und entscheide. Damit das funktioniert, ohne dass ich den Agenten meine komplette digitale Identität überlasse, habe ich mir eine Umgebung gebaut. Diese Seiten beschreiben sie.
Das hier ist keine Installationsanleitung. Anleitungen veralten schneller, als man sie schreiben kann. Beschrieben wird die Zielarchitektur: welche Bausteine es gibt, welche Rolle sie spielen, was sie bringen, welche Alternativen es gibt und warum ich mich so entschieden habe. Wo Kommandos auftauchen, sind sie Illustration.
Für deine KI: Unter /de/docs/dev-setup/llms.txt liegt eine kompakte Fassung dieser Doku. Gib den Link deinem Sprachmodell („Lies das, dann lass uns über das Setup reden“) und frag es aus. Den vollen Text gibt es unter llms-full.txt.
Video
Knapp drei Minuten Überblick: die Architektur dieses Setups als animiertes Erklärvideo. Die Stimme ist KI-generiert.
Podcast
Lieber hören als lesen? Zwei Stimmen unterhalten sich eine Viertelstunde lang über dieses Setup, die Architektur und die Gründe dahinter. Die Stimmen sind KI-generiert.
Das Bild
Tipp auf einen Baustein oder einen Kanal.
Drei tragende Prinzipien
Fast jede Entscheidung in diesem Setup folgt aus einem von drei Grundsätzen.
1. Agenten bekommen nur so viel Identität wie nötig
Ein Agent, der an Repository A arbeitet, braucht Zugriff auf Repository A. Er braucht nicht meinen GitHub-Account, nicht meine SSH-Schlüssel und nicht meinen Zugang zum Produktionsserver. Deshalb bekommen Agenten eng geschnittene Tokens statt meiner Zugangsdaten: nur für die Repos ihrer Umgebung und nur aus einem Socket, den es ausschließlich in dieser Umgebung gibt. Solange sie läuft, hat der Agent darüber durchgehend Zugriff; entziehen kann ich ihn jederzeit sofort.
2. Umgebungen sind reproduzierbar und wegwerfbar
Jede Arbeitsumgebung entsteht aus der devcontainer.json des jeweiligen Repositories.
Sie kann jederzeit gelöscht und neu gebaut werden. Was überleben muss (der Code, der
Login bei Claude, das Gedächtnis des Agenten), liegt außerhalb des Containers auf dem
Host. Dadurch darf ein Agent in seiner Umgebung alles: Sie ist die Sandbox.
3. Was heikel ist, braucht den Menschen
Mein SSH-Schlüssel liegt im Secure Enclave meines Macs und verlangt bei jeder Benutzung eine Bestätigung per Fingerabdruck. Ein Agent kann also nichts heimlich mit meiner Identität tun: Er kann mich höchstens fragen. Das ist ab und zu lästig und genau so gewollt.
Die Bausteine
- Rechenleistung: ein kräftiger Server statt eines kräftigen Laptops.
- Netz: ein Tailnet sorgt für Erreichbarkeit, nicht für Sicherheit.
- Hatchery und Drohnen: ein Container pro Repository, verwaltet von einem kleinen Werkzeug.
- Identität und Zugriff: zwei getrennte Kanäle für Agent und Mensch. Das Herzstück.
- Arbeitsplatz: SSH, zellij, viele Agenten parallel, Steuerung vom Handy.
- Native Apps: Android auf dem Server, iOS als Randnotiz.
- Grenze zum Deploy-Stack: wo dieses Setup aufhört.
- FAQ
Alle erwähnten Werkzeuge, die von mir sind, sind Open Source: hatchery, dotfiles, devcontainer-template und diese Website selbst.