Lernnotiz aus dem Projektzeitraum Juni und Juli 2026, aufgeschrieben im November 2026. Teil der Reihe Vom Werkzeug zur Souveränität, Etappe 2.
Als Codex CLI herauskam, habe ich mich anfangs nur getraut, es in einer eigens dafür eingerichteten Linux-VM laufen zu lassen. Die Frage, was ein Agent darf, hatte ich also schon im Hinterkopf, bevor ich ihm viel zugetraut habe. Im Sommer ist daraus der Schritt von der Experimentierphase zu einer systematischen Entwicklung geworden.
Vom Experiment zum System#
Von der VM ging es zu Containern und später zur Docker Sandbox, in der die Umgebungen sogar selbst Container bauen dürfen. Das war einfach der logische nächste Schritt, um Projekte sicher aufbauen zu können. Ein wichtiger Teilschritt war eine Inventur: Rund vierzig Projekte lagen verstreut über Cloud-Ordner, Mac und Heimserver, seitdem hat jedes einen festen Ort und wenige feste Regeln, die jede Agentensitzung automatisch erbt.
Drei Stufen#
Stufe 0: direkt am eigenen Rechner. Das ist die normale, gemeinsame Arbeit. Jedes Projekt bringt eine Erlaubnisliste mit: Lesen, Suchen, Testen und Committen gehen ohne Rückfrage, alles andere fragt nach. Der Agent kann hier Zielsysteme direkt verändern, deshalb schaue ich bei jedem Schritt mit hin.
Stufe 1: Entwicklung im eigenen Netz. Sie steht exemplarisch für Softwareentwicklung im Netz und im Unternehmen. Der Agent läuft in einer kleinen virtuellen Maschine, einer microVM von Docker Sandboxes, und sieht nur die Ordner, die ich ihm freigebe. So lässt sich klar steuern, auf welche Daten und Ressourcen er zugreifen kann. Innerhalb dieser Wand arbeitet er ohne Rückfrage, installiert Werkzeuge und baut Container.
Stufe 2: wie ein Softwarelieferant. Die Entwicklung findet auf einem getrennten System statt, das nicht an interne Systeme und Daten herankommt, und als Ergebnis wird Software ausgeliefert, in meinem Fall über git. Bei mir ist das in kleiner Form nachgestellt, mit einem eigenen Server im Heimnetz.
Container und Infrastruktur als Code machen in den Stufen 1 und 2 das Deployment auf die Zielsysteme einfach und schnell. In Stufe 0 greift der Agent dagegen direkt ein und braucht dafür mehr Überwachung.
Der Gedanke dahinter ist schlicht: Ich muss nicht jede einzelne Handlung freigeben, wenn ich weiß, was der Raum überhaupt zulässt.
Der Probelauf und seine Stolpersteine#
Im Juli habe ich die microVM an einem echten Projekt erprobt, einem Archiv für alte Festplatten aus rund dreißig Jahren. Der Agent setzte einen Meilenstein samt Tests autonom in der Sandbox um, danach ließ ich die Tests auf meinem Rechner noch einmal laufen, las den Code und committete selbst. Drei Meilensteine wurden so an einem Tag fertig, und Stufe 1 läuft seitdem in der microVM.
Die Wand hat aber zwei Seiten, denn was draußen bleibt, fehlt drinnen auch. Die Anmeldung meines Abos liegt im Schlüsselbund des Mac, also melde ich mich in jeder Sandbox einmal an. Die Python-Umgebung im Projekt ist für macOS gebaut, also legt sich der Agent drinnen eine eigene an.
Und die übergreifenden Regeln erreichen die Sandbox nicht. Dort muss die Anweisungsdatei des Projekts für sich allein tragen. Das empfinde ich inzwischen als gute Probe: Was ein Agent ohne Hintergrundwissen nicht versteht, versteht der nächste Mensch vermutlich auch nicht.
Aus heutiger Sicht#
Später kam die Frage, ob ein Agent aus der Sandbox heraus auf meinen Heimserver zugreifen darf. Die Antwort war eng: ein Schlüssel, der nur git kann, für ein einziges Repository, mit einem Protokoll jeder Ablehnung. Ein vollwertiger Zugang hätte die Wand der microVM für diesen Server aufgehoben. Und nicht alles gehört in die Sandbox: Einen Lauf von etwa neunzig Stunden habe ich bewusst direkt auf dem Rechner gestartet, damit er nicht an der Laufzeit der VM hängt.