Wie viel passiert wirklich, wenn LLM-Agenten eine Woche lang Backend-Entwicklung übernehmen? Ein Entwickler hat das gemessen, fünf Tage lang, in einer großen Rails-Codebasis. Er protokollierte jede Session, jeden Prompt und jeden Tool-Aufruf – und ließ anschließend weitere Agenten die Transkripte analysieren. Das Ergebnis zeigt, was autonome KI-Assistenten leisten können, wo sie scheitern und welche Rolle der Mensch dabei spielt.
Die Datenmenge ist groß: 2.200 Session-Dateien über vier verschiedene Tools, dazu 350 manuell getippte Prompts und 54 Stunden aktive Sessions. Aber die Zahlen erzählen nur einen Teil der Geschichte. Entscheidend ist, was in diesen Sessions tatsächlich passiert – und was die Agenten am Ende wirklich gefunden haben.
Die Messung einer ungewöhnlichen Arbeitswoche
Der Entwickler nutzte vier verschiedene Werkzeuge: Claude Code als Hauptagenten und Orchestrator, dazu Codex, Cursor und Amp für spezielle Aufgaben. Um die Wochenleistung zu erfassen, schrieb er ein Ruby-Skript, das alle Session-Protokolle durchging und für jede Session den Arbeitsordner, den Git-Branch, Start- und Endzeit, jeden eingegebenen Prompt, jeden Tool-Aufruf, Token-Zählungen und die auslösenden Skills extrahierte. Sechs weitere Agenten analysierten im Anschluss die Transkripte in der Tiefe.
Die Zahlen zeigen ein klares Ungleichgewicht: Von den 730 Claude-Code-Session-Dateien liefen nur 80 mit dem Entwickler an der Tastatur. Die restlichen 650 wurden von anderen Agenten gestartet – eine Kettenreaktion, die sich durch alle Tools zieht. Codex verzeichnete 2.100 Sessions, wovon 1.200 einem einzigen Workflow zuzuordnen sind: der automatisierten Überprüfung einzelner Diff-Blöcke, den sogenannten Hunks. Ein Hunk ist ein zusammenhängender Block geänderter Zeilen in einem Diff – und genau darauf war dieser Reviewer spezialisiert.
Auch die Token-Bilanz fällt auf: Für jedes getippte Token erzeugte das System durchschnittlich 1.500 Token Output. Der Median-Prompt war nur 83 Zeichen lang, fast die Hälfte aller Prompts unter 80 Zeichen. Statt langer Anweisungen verließ sich der Entwickler auf ein eingespieltes Setup aus Projektinstruktionen, Skills, MCPs und Kontextdateien – und gab dann kurze Befehle wie „retry“, „apply“ oder „push with lease“. Der Aufwand pro Prompt blieb über die Woche konstant, aber die Wirkung wuchs: Am Montag startete ein Prompt 7 Prozent der Machine-Outputs, am Donnerstag bereits 44 Prozent.
Vier Werkzeuge, vier Arbeitsweisen
Jedes Tool entwickelte eine eigene Persönlichkeit. Claude Code diente als Orchesterdirigent: Es startete Sub-Agenten, koordinierte Panels und führte die Fäden zusammen. Codex übernahm die Rolle des akribischen Prüfers – 946 seiner Sessions begannen mit der Anweisung, als adversärer, hunk-fokussierter Reviewer zu arbeiten. Cursor wiederum war überwiegend mit Lesen beschäftigt: 1.014 Datei-Lesevorgänge und 951 Suchvorgänge stehen nur 149 Edits gegenüber. Das entsprach seiner Funktion als einer der schnellsten Panel-Reviewer – mit einer Medianlaufzeit von 283 Sekunden gegenüber 739 Sekunden bei Claude. Amp blieb weitgehend unsichtbar, da seine Sub-Agenten nicht einsehbar waren.
Diese Unterschiede sind kein Zufall. Der Entwickler setzte Claude Code als Orchestrator ein, weil es die umfassendste Kontrolle über Sub-Agenten bietet. Codex wurde hauptsächlich als automatischer Reviewer für einzelne Diff-Änderungen eingesetzt, Cursor als schneller Zweitmeinung-Geber, und Amp ergänzte das Feld, ohne dass eine direkte Interaktion nötig war. Die Verteilung zeigt, wie LLM-Agenten nicht als monolithische Einheit arbeiten, sondern als spezialisierte Werkzeuge, die unterschiedliche Aufgaben übernehmen.
Wo die Agenten wirklich fanden – echte Defekte
Die eigentliche Frage ist: Was haben die Agenten entdeckt? Der Entwickler besprach 19 Merge-Requests – eigene und fremde. In 16 Panel-Durchläufen, bei denen vier Tools unabhängig dieselbe Änderung prüften, entstanden 17 Berichte. Elf Mal lautete das Urteil „Request changes“, fünf Mal „Approve with nits“. Insgesamt wurden 44 Kommentare an 10 Merge-Requests platziert, davon 56 Befunde mit Übereinstimmung von mindestens zwei Tools und 116 Einzelbefunde, die einzeln durchgesehen werden mussten.
Unter den echten Funden waren einige schwerwiegende Fehler. Ein Betragsverlust von einem Cent entstand, weil eine Steuerberechnung auf ganze Pence abrundete – was ein schriftliches Akzeptanzkriterium verletzte. Zwei Tools fanden das Kriterienproblem, ein drittes entdeckte die zugrunde liegende Floating-Point-Ungenauigkeit und reproduzierte sie. Eine Datenbank-Migration verzichtete auf einen Statement-Timeout-Schutz, obwohl dieselbe Migration in der Produktion bereits drei Wochen zuvor gescheitert war – der Fix war auf einem Pre-Production-Zweig gemerged, aber nie in den Hauptzweig übernommen worden. Genau dieser Befund enthüllte, dass 54 Commits auf dem Pre-Production-Zweig fehlten, darunter drei echte Produktions-Fixes.
Ein weiterer Fund betraf eine versteckte Änderung: Ein One-Time-Passwort-Bypass-Wert wurde in einem Commit zu einem anderen Thema manipuliert – das hatte die Pipeline rot gemacht. Alle vier Tools fanden diesen Fehler. Dazu kam ein Lookup-Problem: Wenn der erste übereinstimmende Datensatz ungültig war, gab der Dienst diesen zurück und ignorierte spätere gültige Datensätze. Der Entwickler maß die betroffene Population – einige hundert Fälle, bei einem Drittel mit gültigem Folge-Datensatz – bevor er entschied, das zu beheben.
Besonders spannend war ein Test, der nicht fehlschlagen konnte: Ein Regressionstest sollte ein bestimmtes Verhalten absichern, aber seine Fixture schrieb denselben Wert in beide verglichenen Felder. Eine Implementierung, die einfach nur den Eingabewert zurückgab, würde alle positiven Beispiele bestehen. Eine Test-Quality-Linse fand das bei einer Kollegen-Änderung; die Lösung war, die Fixture so anzupassen, dass die beiden Werte unterschiedlich wurden. Solche Befunde zeigen, dass LLM-Agenten nicht nur Code, sondern auch Testqualität prüfen können – wenn sie darauf spezialisiert sind.
Das Rauschen: Wenn die Hälfte der Meldungen falsch ist
So nützlich die echten Funde sind, so ernüchternd ist die Fehlerquote. Der Per-Hunk-Reviewer produzierte in drei Läufen 59 Kandidaten-Befunde – aber nur 17 wurden bestätigt, 42 widerlegt. Das entspricht einer Fehlerrate von 71 Prozent. Der schlimmste Lauf verschlang 133 Agenten und etwa 50 Minuten, um nur vier Befunde mit niedriger Schwere aus 26 Kandidaten zu liefern. Diese Widerlegungen waren nicht oberflächlich: Jeder einzelne wurde von einem separaten Agenten durchgeführt, der den echten Quellcode las und versuchte, die Behauptung zu widerlegen. Ohne diesen Schritt wäre das Ergebnis unbrauchbar, aber er kostet Zeit und Aufwand.
Ein weiteres Problem: Die Übereinstimmung zweier Tools ist kein Beweis für Richtigkeit. Auf einem Merge-Request meldeten zwei verschiedene Tools unabhängig voneinander denselben schwerwiegenden Befund mit korrekten Zeilenangaben. Doch beide lasen einen Worktree, der acht Commits veraltet war. Die zitierte Konstante war bereits absichtlich gelöscht worden – eine Entscheidung, die dokumentiert und überprüft war. Hätte der Entwickler dem Befund vertraut, hätte er gelöschten Code wieder eingeführt und fünf geschlossene Review-Threads wieder geöffnet. Der Grund war offensichtlich: Der Entwickler hatte in nur 5 von 14 Läufen eine aktuelle Zusammenfassung des Ziel-Branch-Zustands geliefert.
Umgekehrt ist Schweigen kein Zeichen von Zustimmung. In einem Review meldeten zwei Tools nichts, während die anderen beiden echte Probleme fanden – alle mit dem Muster „Der Code tut nicht, was die Beschreibung sagt“. Ein Tool, das die Beschreibung nicht gelesen hat, kann solche Diskrepanzen nicht erkennen. Die Panel-Übereinstimmung war also nur eine scheinbare: Es waren zwei Tools, die unterschiedliche Fragen beantworteten.
Am schwerwiegendsten war ein Fall, den das gesamte Panel verpasste. Eine Änderung stützte sich auf Zeilen aus einer Tabelle, um eine historische Tatsache zu etablieren. Aber ein nächtlicher Scheduled Job löscht genau diese Zeilen permanent, sobald sie ablaufen. Für abgelaufene Datensätze war die Tatsache also nicht wiederherstellbar – und der Test zu diesem Fall lief grün, weil während des Tests nichts gelöscht wurde. Keiner der acht Reviewer oder Linsen fand das. Ein späterer separater Durchgang deckte es auf. Die Ursache lag in einer fehlenden Frage: Jeder Reviewer argumentierte vom Schema aus, aber keiner fragte „Was schreibt oder löscht sonst noch in diese Tabelle?“. Der Fall zeigt, dass LLM-Agenten systematische Denkmuster übersehen, die einem erfahrenen Menschen sofort auffallen.
Der Mensch als Filter: Entscheiden statt nur abnicken
Was bleibt also für den Menschen zu tun? Der Entwickler formuliert es klar: Die Tools produzieren Kandidaten, aber er entscheidet. Er las jeden einzelnen Kommentar, bevor er gepostet wurde – in elf von elf Fällen gab seine Standardinstruktion vor: „In einfachem technischem Englisch, sag mir die Kommentare, die du posten willst, pro Datei und pro Zeile.“ Er überstimmte auch Befunde: Er behielt einen Kommentar, den ein Reviewer löschen wollte, weil er die nächste Entwicklung vor einer bewusst ausgeschlossenen Datensammlung bewahrte. Er lehnte ein Refactoring ab, das der Reviewer bereits angewendet hatte, weil es eine lesbare Sequenz in zwei undurchsichtige Methoden komprimierte.
Diese Übersteuerungen sind kein Zeichen von Sturheit, sondern von Urteilsvermögen. Der Entwickler kannte den Codebase-Kontext, die Review-Historie und die fachlichen Anforderungen – Wissen, das die Agenten nicht haben. Seine Rolle war nicht die eines Tippgebers, sondern eines Qualitätsgatters. Das zeigt sich auch in seinen eigenen Beiträgen: Er schrieb kurze Prompts, aber er baute ein System aus Skills, Instruktionen und Kontext, das den Agenten die Arbeit ermöglichte. Am Donnerstag, als die Maschinen-Anteile am Output 44 Prozent erreichten, blieb seine Tipparbeit konstant – das System war eingespielt.
Was du daraus für deinen Workflow mitnehmen kannst
Die Erfahrung lässt sich in konkrete Handlungsempfehlungen übersetzen. Erstens: Kontext liefern, bevor du Agenten losschickst. Der veraltete Worktree-Vorfall zeigt, dass eine aktuelle Zusammenfassung des Ziel-Branch-Zustands essenziell ist. Zweitens: Plane Rauschen ein. Eine Fehlerrate von 71 Prozent bedeutet, dass du Zeit für die Sichtung von Befunden einplanen musst – und dass die Widerlegung durch separate Agenten ein notwendiger Schritt ist, auch wenn er teuer ist. Drittens: Überprüfe Tests mit Mutationsanalyse. Der Entwickler bestätigte vor jedem Commit, dass die wichtigen Tests scheitern würden, wenn der Code gebrochen wird – das beweist, dass sie den behaupteten Fehler tatsächlich erkennen können.
Viertens: Verlasse dich nie auf Übereinstimmung oder Schweigen der Werkzeuge. Zwei übereinstimmende Tools können beide falsch liegen, wenn sie den gleichen veralteten Kontext haben. Und zwei schweigende Tools können einfach nur eine andere Frage beantworten. Fünftens: Lies jeden Kommentar, den ein Agent generiert, bevor du ihn postest – und habe den Mut, Befunde zu verwerfen. Die eigene Erfahrung und das Verständnis der Codebase sind nicht durch Automatisierung ersetzbar, sie bleiben das Entscheidungswerkzeug.
LLM-Agenten sind wie ein hochmotivierter, aber ungestümer Praktikant: Sie liefern viele Ideen, aber die Hälfte davon ist Unsinn. Du brauchst einen klaren Filter, eine gute Einarbeitung und die Bereitschaft, Nein zu sagen. Die Woche des Entwicklers zeigt, dass die Automatisierung funktioniert – aber nur, wenn der Mensch im Kreislauf bleibt und die Verantwortung trägt. Die Werkzeuge sind da, um dir Arbeit abzunehmen, nicht um sie zu ersetzen. Und das ist vielleicht die wichtigste Erkenntnis: Die Zukunft des Codes gehört nicht den Agenten, sondern den Entwicklern, die wissen, wie man sie einsetzt.
Quelle: allaboutcoding.ghinda.com
