Blog

Wie viel Arbeit bleibt nach dem Coding-Agenten?

Ein schneller Patch spart erst dann Zeit, wenn der Code geprüft und freigabefähig ist. So messt ihr den Aufwand an echten Entwicklungstickets.

Kevin Köhler neben einem Code-Review-Fenster mit gelbem Haken

Ein Coding-Agent hat nach zwei Minuten einen Patch. Er ändert drei Dateien, ergänzt einen Test und meldet Erfolg. Die Entwicklerin braucht anschließend eine halbe Stunde, um eine Annahme über alte Datensätze zu korrigieren. Der erste Patch war schnell. Was hat sich für das Team über den gesamten Vorgang verändert?

Anthropic berichtet bei Claude Opus 5.5 über Fortschritte auf Coding-Benchmarks. In einer frühen Studie von METR benötigten erfahrene Open-Source-Entwickler mit den damals verfügbaren KI-Werkzeugen bei Aufgaben in ihren eigenen Repositories im Mittel 19 Prozent länger. Ein späterer Versuch lieferte Hinweise auf schnellere Bearbeitung, aber METR stuft die neuen Schätzungen wegen Problemen bei Auswahl und Messung als unsicher ein. Der jeweilige Befund gilt für sein Studiendesign, die eingesetzten Werkzeuge und die ausgewählten Aufgaben. Anthropic zu Opus 5.5 · METR zum Produktivitätsexperiment

Die Zielmarke ist ein freigabefähiger Pull Request

Nehmt echte Aufgaben aus dem Team. Ein guter Mix enthält einen gut beschriebenen Fehler, eine Änderung mit bestehendem Datenformat und eine Aufgabe mit unklaren Anforderungen. Definiert die Abnahme vor dem Start. Zum Beispiel muss eine neue Validierung sowohl beim Speichern im Browser als auch beim API-Import greifen und vorhandene Datensätze weiterhin laden.

Für den Vergleich könnt ihr ähnliche Tickets nach Aufwand und Risikoklasse gruppieren und innerhalb der Gruppen zufällig mit und ohne Agent bearbeiten. Gebt beiden Gruppen Zugriff auf dieselbe Dokumentation und dieselben Tests. Wenn möglich, sehen Prüfer bei der ersten Bewertung nicht, wie der Patch entstanden ist. Ein kleines Experiment zeigt Tendenzen für euer Team. Haltet Ergebnisse deshalb auch je Aufgabentyp fest.

Ein Entwicklungsticket durchläuft Tests und die fachliche Prüfung des Codes.

Welche Zeit in die Rechnung gehört

Erfasst die aktive Zeit der Entwicklerin und der Prüfer. Dazu gehören die Vorbereitung des Auftrags, Rückfragen, das Lesen der Änderungen, das Testen und alle Korrekturen bis zur Freigabe. Messt die verstrichene Zeit separat. Ein Agent kann während einer Besprechung arbeiten und anschließend viel Review verlangen. Beide Zeiten beantworten verschiedene Fragen.

Angenommen, in einem Beispiel dauert eine manuelle Änderung 90 Minuten inklusive Review. Mit Agent sind es 15 Minuten Vorbereitung, 25 Minuten Prüfung und 20 Minuten Korrektur. Das sind 60 Minuten aktive Arbeitszeit. Eine spätere Fehlerbehebung von 35 Minuten würde den Gesamtaufwand auf 95 Minuten erhöhen. Legt deshalb vor dem Vergleich auch ein Beobachtungsfenster für Folgetickets und Rücknahmen fest.

Was ihr aus den Ergebnissen lernen könnt

Notiert, wo die Arbeit hängen bleibt. Wenn Agenten beim ersten Entwurf regelmäßig Tests übersehen, helfen eindeutige Testbefehle und prüfbare Abnahmekriterien. Wenn vor allem fachliche Entscheidungen offen sind, verbessert zunächst die Aufgabenbeschreibung. Und wenn der Reviewaufwand bei bestimmten Änderungen hoch bleibt, ist das ein Grund, sie zunächst anders zu bearbeiten.

Das Ergebnis des Versuchs kann eine einfache Entscheidung für den Alltag sein, etwa den Agenten für klar umrissene Änderungen mit guten Regressionstests einzusetzen. Wiederholt den Vergleich bei wesentlichen Werkzeugwechseln mit ähnlichen Aufgaben. Für die finanzielle Einordnung hilft das Rechenbeispiel zum Nutzen pro Vorgang.

Quellen