Wie ich mit Claude-Code-Agents baue. Arbeitsweise und Fehler.
Ich schreibe meinen Code nicht mehr allein. Claude-Code-Agents bauen mit, ich plane und prüfe. Hier steht, wie das bei mir abläuft und wo es schiefging.
- Ablauf: erst ein Plan, dann Agents parallel in getrennten Arbeitskopien, Tests lokal.
- Regel: Ich prüfe und merge selbst. Auch die nächtliche Routine öffnet nur Draft-PRs.
- Lehre: Agents machen sich gegenseitig Ärger, wenn sie dieselben Dateien anfassen. Klare Zuständigkeiten helfen.
Der Ablauf
Für größere Funktionen nutze ich vier Phasen. Zuerst sammeln parallel zwei Agents Ideen aus verschiedenen Blickwinkeln, und zwei prüfen, was technisch geht. Dann wähle ich aus: keine neuen Konten, keine neuen Kosten, jede Funktion in einer eigenen neuen Datei. Danach bauen Agents, und nur ich ändere die gemeinsamen Dateien. Am Ende testen und reparieren weitere Agents, jeder nur in seinen Dateien. Fehler in fremden Dateien melden sie, sie reparieren sie nicht.
Parallel, aber getrennt
Jeder Agent arbeitet in einem eigenen Git-Worktree. Das ist eine zweite Arbeitskopie desselben Projekts auf einem eigenen Branch. So stören sich Agents nicht gegenseitig. Vorher mache ich eine Sicherung des Projekts. Und ich füge nie alles pauschal hinzu, sondern Dateien einzeln.
Tests laufen lokal
Bei Jarvis ist das Repo privat, und die Cloud-Minuten sind begrenzt. Deshalb laufen die Tests bei mir lokal. Nach jedem Lauf prüfe ich, ob Tests echte Daten verändert haben. Warum, steht in der Notiz über Tests.
Nachtschicht
Drei Routinen laufen nachts um 03:30, sonntags nicht: eine für Jarvis, eine für Agent-Board und eine für ein privates Lernspiel. Jede nimmt das älteste offene Issue mit einem bestimmten Label, baut auf einem eigenen Branch, testet, lässt einen zweiten Agent prüfen und öffnet einen Draft-PR. Gibt es kein Issue, passiert nichts. Die Routine darf pushen und Drafts öffnen. Mergen darf sie nicht.
Ich prüfe und merge selbst
Jeder PR geht durch meine Hände. Ich schaue nach, ob die Tests grün sind und ob der Diff zur Aufgabe passt. Das klingt langsam, ist aber der Teil, bei dem ich am meisten lerne.
Wächter-Hooks vor Commit und Push
Ich habe mir ein eigenes Claude-Code-Plugin gebaut. Vor jedem Commit durchsucht es den Diff nach Schlüsseln, privaten Mail-Adressen und Telefonnummern. Bei öffentlichen Repos blockiert es dann, bei privaten fragt es nach. Vor einem Push blockiert es bestimmte Branches in öffentlichen Repos und fragt bei Jarvis immer nach. Das habe ich mit Fake-Daten live getestet. Es ersetzt kein Nachdenken, fängt aber Flüchtigkeitsfehler.
Was schiefging
- Test-Runner umgangen: Ein Agent hat die Tests über ein eigenes Skript gestartet. Dabei galt mein Datenschutz nicht, und echte Dateien wurden überschrieben. Das ist zweimal passiert. Seitdem steht die Regel in der Projektanleitung.
- Parallele Sitzungen: Eine zweite Claude-Sitzung hat bei Agent-Board mitten in der Arbeit den Branch des Hauptordners gewechselt. Seitdem prüfe ich direkt vor dem Commit, auf welchem Branch ich bin.
- Falsche Autor-Adresse: In einer frühen Fassung von Agent-Board steckte eine private Mail-Adresse in der Git-Historie. Ich habe die Historie neu aufgesetzt, bevor das Repo öffentlich wurde. Ein Web-Merge hat sie später noch einmal eingeschleppt, deshalb habe ich das Repo neu angelegt. Seitdem gilt eine feste Noreply-Adresse, und der Wächter prüft sie.
- Zu viel Automatik: Ein Sicherheits-Plugin hat in drei Tagen 222 Prüfungen gemacht und nie etwas gefunden. Ich habe es abgeschaltet.
Was ich daraus mitnehme
Agents sparen Zeit, aber sie sparen keine Verantwortung. Gute Regeln stehen in der Projektanleitung und in Hooks, nicht in meinem Kopf. Und jedes Mal, wenn etwas schiefgeht, baue ich eine Sperre dafür.
Gebaut mit Claude Code, und das schreibe ich bewusst dazu. Von Jarvis nenne ich keine Details zu persönlichen Daten.