Agent

Ein Entwicklungsagent, der Issues umsetzt und seine Arbeit selbst belegt

Für meine Arbeit im Büro baue ich mir gerade einen kleinen Kollegen: einen eigenen Entwicklungsagenten auf einem eigenen Mac, an dem ich laufend experimentiere. Im Kern arbeitet Claude Code als Entwickler, eingebettet in Skripte, die den Ablauf fest vorgeben. Das Modell schreibt den Code; Branching, Tests, Commits, PR-Texte und Aufräumen laufen nach festen Regeln. Ich baue immer wieder daran weiter und nutze ihn inzwischen sehr aktiv: Er macht gute Arbeit, und ich bekomme mehr erledigt. Er ist Teil meines Claude-Code-Setups.

Aufbau

Ein Supervisor und mehrere spezialisierte Agenten

Ein Supervisor startet in festen Intervallen verschiedene Agenten für verschiedene Aufgaben und überwacht sie. Gesteuert wird das Ganze über ein Terminal- und ein Web-Dashboard. Diese Seite konzentriert sich auf den Coding-Agenten, der Issues umsetzt; er baut an der Webanwendung und auch an unseren Apps. Jeder Auftrag läuft in einem eigenen, isolierten Git-Worktree auf dem aktuellen Entwicklungsstand, und die Regeln des Projekts in der AGENTS.md sind für den Agenten verbindlich.

Das Modell schreibt den Code. Alles drumherum läuft nach festen Regeln, und die Entscheidung trifft am Ende ein Mensch.

Steuerung

Gesteuert wird er wie ein Kollege im Ticketsystem

Die Steuerung läuft komplett über GitHub-Labels:

claude an einem Issue: Der Agent setzt das Issue um und öffnet einen Pull Request.
claude an einem Pull Request: Er liest die Review-Kommentare und arbeitet sie ein.
claude:analyze: Er analysiert das Issue, ohne etwas zu ändern, und kommentiert Ursache, betroffene Stellen und einen Lösungsvorschlag.
Rote CI: Ein eigener CI-Agent analysiert fehlgeschlagene Builds automatisch und behebt sie auf Wunsch.

Stößt der Agent bei der Arbeit auf ein Problem außerhalb seines Auftrags, ändert er es nicht mit, sondern legt dafür ein eigenes Issue an. Das ist derselbe Gedanke wie bei meinem Skill für strukturierte Issues: Was auffällt, wird festgehalten, statt nebenbei im falschen Pull Request zu landen.

Absicherung

Er hat dasselbe Handwerkszeug wie ein Entwickler im Team

Eigene Testumgebung

Jeder Auftrag bekommt eine frische Datenbank aus einem Snapshot. Die betroffenen Tests führt der Agent selbst aus.

Fail-first-Nachweis

Bei Bugfixes beweist er, dass sein Test ohne den Fix rot und mit Fix grün ist. Der Test belegt also wirklich den Fehler.

Statische Analyse

PHPStan läuft gegen die Baseline des Projekts.

Browser-Tests

Bei sichtbaren Änderungen startet er die Anwendung mit seinem Stand, meldet sich mit Testaccounts an, klickt die Abläufe in einem headless Chrome durch, prüft die Konsole und macht Screenshots.

Erst nachstellen

In Analysen und bei CI-Fehlern stellt er das Problem zuerst nach. Lässt es sich nicht reproduzieren, ändert er nichts und meldet das.

Transparenz im PR

Jeder Pull Request enthält eine Tabelle der tatsächlich ausgeführten Prüfungen, einen Browser-Bericht und eine Checkliste mit dem, was ein Mensch selbst prüfen muss.

Ergebnisse

Was er bisher geliefert hat

127 Pull Requests, davon 120 gemergt

96 % der entschiedenen Pull Requests übernommen

181 Issue-Analysen

171 selbst gemeldete Nebenbefunde

Zeitraum 12.06. bis 27.10.2026, ausgewertet aus GitHub und dem Dashboard des Agenten.

Von den 127 Pull Requests wurden 120 gemergt, 5 verworfen, 2 sind noch offen. In Summe sind das rund 19.800 geänderte Zeilen. Die Quote von 96 % enthält Review-Runden: Nicht jeder Pull Request passt im ersten Wurf, aber fast immer entsteht etwas, das nach dem Review übernommen wird. Verworfen habe ich vor allem Änderungen aus Aufgaben, die nicht klar umrissen oder größer waren, und das noch in der Zeit, bevor der Agent das Frontend selbst testen konnte.

Insgesamt hat der Agent 316 Aufträge abgeschlossen. Von seinen 171 Nebenbefunden wurden 110 umgesetzt, 40 als „nicht geplant“ geschlossen, 21 sind offen. Von den entschiedenen Befunden waren damit rund 73 % relevant genug für eine Umsetzung.

Im Betrieb kommen die Agenten laut Dashboard auf etwa 24.000 Läufe, davon 37 fehlerhaft. Seit der eigenen Testumgebung, eingeführt am 21.10., enthalten alle 23 neuen Pull Requests den automatischen Prüfbericht.

Wirkung

Was sich durch das Testen verändert hat

Früher stand bei Frontend-Änderungen ehrlich „Not tested“ im Pull Request, und die ganze Prüfung lag beim Reviewer. Heute stellt der Agent einen gemeldeten Fehler zuerst nach, belegt danach den Fix Schritt für Schritt mit Screenshots und legt sich dafür bei Bedarf selbst Testdaten an. Gut ein Drittel seiner Pull Requests betrifft das Frontend.

Grenzen

Die Entscheidung bleibt beim Menschen

Jeder Pull Request durchläuft ein Review und die reguläre CI, bevor er gemergt wird. Issues mit offenen Designfragen klären wir vorher gemeinsam, so wie ich bei größeren Änderungen auch selbst erst den Plan Mode nutze.

Der Agent übernimmt klar umrissene Aufgaben.
Kritische Bereiche wie Zahlungen, Rechnungen, Mandantentrennung oder Datenbank-Trigger bleiben bewusst beim Menschen.
Produktentscheidungen trifft er nicht.
Echte Zahlungen, Mails und externe Dienste sind in seiner Umgebung abgeschaltet.

Weiter im Cluster

Andere Seiten zu Claude Code

Arbeitsweise

Zurück zum Überblick über mein Setup.

Die Übersichtsseite ordnet ein, wo dieses Thema in meinem Arbeitsalltag steht.

Zur Claude-Code-Übersicht Zur Softwareentwicklung