Wie devenv meinen AI-Coding-Workflow repariert hat
Ich nutze Claude Code als meinen primären Coding-Partner. Es schreibt Features, fixt Bugs, führt Tests aus, liest die Ausgabe und iteriert. Je enger diese Feedback-Schleife, desto schneller liefere ich. Aber wochenlang hat ein fragmentiertes Dev-Setup alles heimlich verlangsamt.
Das Problem: Tod durch tausend Skripte
Mein Test-Setup war organisch gewachsen. devenv kümmerte sich um PostgreSQL — und sonst nichts. Alles darüber waren Bash-Skripte: API starten, Migrationen ausführen, Datenbank seeden, Frontends hochfahren. Die Skripte funktionierten, meistens. Aber sie waren undurchsichtig.
Das eigentliche Problem war nicht, dass Dinge kaputtgingen. Es war, dass die Konfiguration über mehrere Dateien verstreut war, mit impliziten Abhängigkeiten. Welches Skript startet was? In welcher Reihenfolge? Was muss laufen, bevor die E2E-Tests starten können? Ich kannte die Antworten, weil ich die Skripte geschrieben hatte. Claude Code nicht.
Wenn ein AI-Agent dein Dev-Setup nicht verstehen kann, kann er nicht autonom iterieren. Er startete Tests bevor die API bereit war, überging Migrationen oder vergaß die Datenbank zwischen Runs zurückzusetzen. Jeder gescheiterte Versuch kostete Zeit — nicht nur den Testlauf, sondern auch das Hin-und-Her um zu diagnostizieren, was schiefgelaufen war.
Die Lösung: Eine Datei, ein Befehl
Ich habe alles in eine einzige devenv.nix konsolidiert. Datenbank, Build, Migrationen, Seed-Daten, API-Server, Frontend-Dev-Server — alles an einem Ort deklariert, mit expliziten Abhängigkeiten.
Der Schlüssel ist die process-compose-Integration. Jeder Prozess deklariert, wovon er abhängt:
backend-prepare = {
# Warte auf PostgreSQL, baue JAR, führe Migrationen aus, seede DB
process-compose.depends_on.postgres.condition = "process_healthy";
availability.restart = "no";
};
backend = {
# Starte den API-Server
process-compose.depends_on.backend-prepare.condition = "process_completed_successfully";
};Im Test-Modus setzt backend-prepare automatisch die Datenbank zurück, bevor irgendetwas anderes passiert — Schema droppen, neu erstellen, migrieren, seeden. Kein veralteter Zustand zwischen Runs.
Der Test-Einstiegspunkt wartet darauf, dass alle benötigten Ports verfügbar sind, bevor Playwright startet:
enterTest = ''
wait_for_port 20000 # API
wait_for_port 3005 # Management-Frontend
wait_for_port 3001 # PWA
npx playwright test
'';Der gesamte E2E-Zyklus ist jetzt ein einziger Befehl: devenv test. Er startet alles, wartet bis der Stack gesund ist, führt die Tests aus und liefert die Ergebnisse.
Warum das für AI-gestützte Entwicklung wichtig ist
Eine gute Iterationsschleife für Claude Code ruht auf drei Säulen:
Eine deklarative Umgebung. Eine .nix-Datei ist lesbar. Wenn Claude Code verstehen muss, wie der Stack funktioniert, liest es eine Datei und weiß alles — Ports, Abhängigkeiten, Startreihenfolge, Umgebungsvariablen. Kein Herumirren durch ein Labyrinth von Shell-Skripten.
Strukturierte Ausgabe. devenv test produziert vorhersagbare Ausgabe. Tests bestehen oder scheitern mit klaren Fehlermeldungen. Der Agent liest die Ausgabe, versteht was kaputtgegangen ist und versucht einen Fix. Kein Raten, ob der Fehler ein echter Testfehler oder ein Setup-Problem war.
End-to-End-Tests als Feedback-Signal. Unit-Tests sind schnell, aber eng gefasst. E2E-Tests zeigen dem Agent, ob das Feature tatsächlich aus Nutzersicht funktioniert. Kombiniert mit einer zuverlässigen Testumgebung werden sie zum primären Feedback-Mechanismus des Agents.
Das Ergebnis: Claude Code führt devenv test aus, liest die Playwright-Ausgabe, passt den Code an und startet erneut. Die Schleife, die früher manuelles Eingreifen erforderte, läuft jetzt autonom.
Fazit
- Deklarativ schlägt imperativ — besonders wenn ein AI-Agent dein Setup verstehen muss. Eine
.nix-Datei ist Dokumentation und Konfiguration in einem. - Ein Befehl, vorhersagbare Ausgabe. Wenn dein Test-Workflow Stammwissen erfordert, kann ein Agent ihn nicht nutzen.
- In Dev-Tooling zu investieren zahlt sich doppelt aus — einmal für dich, einmal für jeden AI-Agent der in deiner Codebase arbeitet.
Die Ironie: Alles was ich getan habe, um mein Setup für Claude Code besser zu machen, hat es auch für mich besser gemacht. Es stellt sich heraus: Was für eine AI lesbar ist, ist auch für einen Menschen lesbar, der nach zwei Wochen Pause zum Projekt zurückkehrt.