Coding-Agenten sind in vielen Entwicklungsteams längst Alltag. Sie legen Dateien an, refaktorieren, schreiben Tests und arbeiten inzwischen auch über längere Aufgabenketten hinweg selbstständig. Eine neue Untersuchung zu Claude Code und Codex weist nun auf eine Schwäche hin, die genau bei dieser Autonomie relevant wird: Die Agenten haben kein belastbares Zeitgefühl – und sie wissen das nicht.

Zwei Befunde: Dauer und Selbstbewertung

Der erste Befund betrifft die Einschätzung von Aufwänden. Laut der Untersuchung verschätzen sich beide Systeme systematisch, wenn sie angeben sollen, wie lange eine Aufgabe dauert. Für Codex wird eine Abweichung um teils das Zehnfache berichtet. Wie stark und in welche Richtung die Fehleinschätzung ausfällt, wird je nach Darstellung unterschiedlich betont – die Kernaussage bleibt in jedem Fall dieselbe: Zeitangaben von Coding-Agenten sind keine Planungsgrundlage.

Der zweite Befund wiegt in der Praxis schwerer. Beide Assistenten bewerten die Qualität ihrer eigenen Arbeit rund 20 Prozentpunkte zu positiv. Ein Agent, der eine Aufgabe für erledigt erklärt, liefert damit nicht nur ein Ergebnis, sondern auch ein systematisch zu optimistisches Urteil darüber. Wer diesem Urteil folgt, übernimmt eine Verzerrung, die im Code selbst nicht sichtbar ist.

Beides zusammen ergibt ein Kontrollproblem, das mit der Länge der Aufgabe wächst. Bei einem kurzen Auftrag – eine Funktion ergänzen, ein Formular validieren – prüft die Entwicklerin das Ergebnis ohnehin direkt. Läuft ein Agent dagegen über eine Stunde oder länger an einer verketteten Aufgabe, entscheidet er unterwegs immer wieder selbst, ob ein Teilschritt fertig ist und ob er weitergehen kann. Genau diese Entscheidungen basieren auf der zu positiven Selbsteinschätzung. Fehler pflanzen sich fort, statt am nächsten Prüfpunkt aufzufallen.

Warum das die Rolle der Teams verschiebt

Parallel zu diesem Befund wird in der Branche eine zweite Beobachtung diskutiert, die gut dazu passt: Je mehr Aufgaben KI übernimmt, desto wichtiger werden gute Teams. KI kann Code erzeugen, Code prüfen und Arbeitsschritte übernehmen. Was ihr fehlt, ist das Wissen, um Ergebnisse über mehrere Disziplinen hinweg einzuordnen – also zu beurteilen, ob eine technisch plausible Lösung auch fachlich, sicherheitstechnisch und betrieblich trägt. Und sie kann keine Verantwortung übernehmen.

Damit verändern sich vor allem die Anforderungen an DevSecOps – jene Arbeitsweise, die Entwicklung, Sicherheit und Betrieb in einem gemeinsamen Prozess zusammenführt. Wenn ein erheblicher Teil des Codes von Agenten stammt, verschiebt sich der Engpass von der Erstellung zur Bewertung. Die Frage ist weniger, wie schnell etwas entsteht, sondern wer beurteilt, ob es so in den Betrieb darf.

Was das für die Projektpraxis bedeutet

Aus den beiden Befunden lassen sich einige nüchterne Konsequenzen ableiten, die sich in laufenden Projekten umsetzen lassen:

  • Keine Zeitschätzungen von Agenten übernehmen. Aufwandsangaben eines Assistenten sind allenfalls ein Gesprächsanlass, keine Grundlage für Sprint-Planung, Angebote oder Terminzusagen gegenüber Kunden.
  • Selbstauskünfte nicht als Abnahme werten. Ein „fertig“ oder „Tests laufen durch“ aus dem Agenten ersetzt kein Review. Die berichteten rund 20 Prozentpunkte Abweichung bei der Selbstbewertung sind hier der eigentliche Merksatz.
  • Lange autonome Läufe zerlegen. Statt einer großen Aufgabe über Stunden lieber mehrere klar abgegrenzte Schritte mit festen Prüfpunkten. Je kürzer die Kette, desto geringer die Chance, dass sich eine falsche Selbsteinschätzung fortschreibt.
  • Objektive Prüfinstanzen zwischenschalten. Automatisierte Tests, statische Analyse, Linting und Security-Scans urteilen unabhängig vom Agenten. Sie ersetzen kein menschliches Review, verringern aber die Abhängigkeit von der Selbstauskunft.
  • Verantwortlichkeiten benennen. Für jedes Artefakt, das in den Betrieb geht, braucht es eine Person, die es fachlich verantwortet – unabhängig davon, wer oder was es geschrieben hat.

Erfahrung wird nicht überflüssig, sondern anders eingesetzt

Die naheliegende Sorge, Coding-Agenten würden erfahrene Entwicklerinnen und Entwickler ersetzen, greift vor diesem Hintergrund zu kurz. Der Befund deutet in eine andere Richtung: Gerade weil Agenten viel produzieren und ihre Ergebnisse zu gut bewerten, braucht es Menschen, die den fachlichen Kontext kennen. Wer eine Domäne versteht, erkennt eine Lösung, die technisch sauber aussieht und fachlich am Ziel vorbeigeht. Wer den Betrieb kennt, erkennt Entscheidungen, die im Testsystem funktionieren und unter Last oder in der Wartung teuer werden.

Für die Zusammenarbeit in Projekten heißt das auch: Reviews sollten nicht als Formalität behandelt werden, die man bei Zeitdruck als Erstes streicht. Sie sind die Stelle, an der die systematische Verzerrung der Agenten korrigiert wird. Und sie sind der Ort, an dem Wissen im Team bleibt – auch bei Code, den niemand im Team von Hand geschrieben hat.

Einordnung

Coding-Agenten bleiben ein sinnvolles Werkzeug, aber sie sind kein verlässlicher Berichterstatter über die eigene Arbeit. Für Web- und Softwareprojekte bedeutet das vor allem, Prüfschritte, Testabdeckung und klare Zuständigkeiten dort auszubauen, wo Agenten Tempo bringen. Wer Agenten einsetzt und gleichzeitig in Review-Kultur und Erfahrung im Team investiert, gewinnt Geschwindigkeit ohne Kontrollverlust – wer nur auf das Tempo setzt, verschiebt den Aufwand lediglich nach hinten in Wartung und Fehlerbehebung.

Quellen