Der Agent schreibt Code – wer prüft seine Arbeit?

Einem Agenten lässt sich eine Aufgabe übertragen; anschließend kann man auf Änderungen im Repository warten und einen Entwurf für einen Pull Request zur Prüfung erhalten. Doch mit dem Code stellt sich auch die Frage: Entspricht das Ergebnis der Aufgabe, und haben die Tests ein wichtiges Problem übersehen?

Am 4. Februar 2026 kündigte GitHub die öffentliche Vorschau von Claude und Codex als Coding-Agenten an. Das Unternehmen teilte mit, dass sich den Agenten Aufgaben aus Issues und Pull Requests zuweisen lassen und anschließend der von ihnen erstellte PR-Entwurf geprüft werden kann. Das bestätigt, dass ein solcher Ablauf in die Entwicklungsumgebung aufgenommen wurde, belegt aber weder eine Zeitersparnis noch eine höhere Codequalität.

Es geht also nicht nur darum, ob ein Agent Code schreiben kann. Entscheidend ist auch, welche Arbeit rund um die delegierte Aufgabe beim Menschen bleibt: Vorgaben machen, den Arbeitsfortschritt beobachten und das Ergebnis beurteilen.

Aufsicht bedeutet mehr als eine abschließende Prüfung

In einem am 21. September 2026 auf arXiv veröffentlichten Preprint schlagen Forschende vor, die Aufsicht über einen Coding-Agenten als fortlaufenden Prozess zu betrachten. Die Arbeit The Work Behind Delegation stützt sich auf Beobachtungen und Prozessdarstellungen von 19 erfahrenen Entwicklern. Die Autoren beschreiben sieben Phasen der Aufsicht und wenden diesen Rahmen auf öffentliche Diskussionen von Entwicklern auf Reddit an.

Zu den von den Autoren beschriebenen Ansätzen gehören, der Planung mehr Aufmerksamkeit zu widmen, einen Teil der Aufsichtsaufgaben an andere Agenten zu übertragen und wiederkehrende Anweisungen in wiederverwendbare Materialien umzuwandeln. Das ist ein analytischer Rahmen und keine Messung des Zeitaufwands: Die Arbeit ermittelt weder, wie viel Zeit Entwickler für die Kontrolle aufwenden, noch, ob dieser Prozess schneller ist als manuelle Arbeit. Auf der arXiv-Seite ist der Preprint als in Begutachtung gekennzeichnet; seine Schlussfolgerungen sind daher als vorläufig zu betrachten.

Für die Praxis ist es hilfreich, drei Tätigkeiten zu unterscheiden. Die Aufgabenstellung definiert Ziel und Einschränkungen. Die Beobachtung hilft zu erkennen, ob der Agent von der Absicht abweicht. Die Prüfung ermöglicht eine Beurteilung, ob sich das Ergebnis angesichts der Anforderungen, des Codes und der Tests übernehmen lässt. Erfolg in einer Phase garantiert keinen Erfolg in der nächsten: Ein Patch kann plausibel aussehen, aber die falsche Aufgabe lösen oder erhebliche Nacharbeit erfordern.

Erfahrungsberichte aus der Community sind keine Statistik

In einer Diskussion auf r/LocalLLaMA schrieb ein Teilnehmer, seine Erfahrungen mit lokalen Modellen und Agenten seien enttäuschend gewesen: Seinen Angaben zufolge musste er Ergebnisse korrigieren und die Agenten an Anweisungen erinnern. Andere Teilnehmer desselben Threads beschrieben einen für sie nützlicheren Ablauf: Aufgaben einzugrenzen, schrittweise vorzugehen und den Code sorgfältig zu prüfen. Das sind einzelne Nutzerbeobachtungen, kein vergleichender Modelltest und keine Messung der Teamproduktivität.

Diese unterschiedlichen Rückmeldungen zeigen, dass die Erfahrungen von der Aufgabe, dem Modell, der Umgebung und der Arbeitsweise abhängen können. Aus einer einzelnen Diskussion lässt sich jedoch nicht ableiten, welche Praktiken im Durchschnitt wirksamer sind oder wie häufig Probleme auftreten. Der Thread behandelt lokale Modelle; seine Beobachtungen sollten daher nicht automatisch auf alle Agentenwerkzeuge übertragen werden.

Dass ein Mensch beteiligt bleibt, bedeutet nicht automatisch, dass Delegieren nutzlos ist. Entwickler können eine Aufgabe in Teilaufgaben zerlegen, Änderungen prüfen und Anforderungen präzisieren – und dennoch für das Ergebnis verantwortlich bleiben. Ohne den Zeitaufwand für Aufgabenstellung, Korrekturen und Reviews zu berücksichtigen, lässt sich jedoch nicht sagen, ob der Gesamtaufwand gesunken ist.

Ein PR-Entwurf ist noch kein angenommener PR

Im von GitHub beschriebenen Szenario lässt sich einem Agenten ein Issue zuweisen und ein Entwurf für einen Pull Request erhalten. Zwischen seiner Erstellung und der Annahme bleiben verschiedene Fragen offen: Entspricht die Änderung den Anforderungen, sind Randfälle berücksichtigt, gibt es genügend Tests und passt die Lösung zur Architektur des Projekts?

Diese Kriterien lassen sich nicht auf eine einzelne Kennzahl reduzieren. Die Zahl der erstellten Änderungen entspricht nicht der Zahl der brauchbaren, und erfolgreiche Tests bestätigen nicht zwangsläufig alle wichtigen Eigenschaften eines Patches. Selbst ein qualitativ überzeugend wirkendes Ergebnis sagt für sich genommen nicht aus, wie viel Arbeit seine Erstellung und Prüfung erfordert hat.

Um die Gesamtwirkung zu beurteilen, muss der gesamte Zyklus berücksichtigt werden: Aufgabenstellung, Warten auf das Ergebnis, Review, Korrekturen und spätere Wartung des Codes. Die hier betrachteten Quellen liefern keinen solchen Gesamtvergleich.

Was sich daraus schließen lässt

Der Preprint bietet einen Rahmen, um über Aufsicht zu sprechen, und GitHub berichtete von einem Szenario, in dem einem Agenten eine Aufgabe zugewiesen und der vorbereitete PR geprüft wird. Die Diskussion auf Reddit zeigt, dass einzelne Nutzer sowohl Schwierigkeiten als auch hilfreiche Arbeitsweisen mit lokalen Modellen beschreiben. Zusammengenommen werfen diese Materialien die Frage auf, wie sich die Prüfung delegierten Codes organisieren lässt, beantworten aber nicht, ob die Produktivität unterm Strich steigt.

Aus ihnen lässt sich weder schließen, dass Entwickler insgesamt bereits vom Schreiben von Code zur Aufsicht übergegangen sind, noch, dass Agenten zwangsläufig zusätzliche Arbeit verursachen oder die Produktivität der Branche steigern. Für solche Aussagen braucht es vergleichbare Messungen von Zeitaufwand und Qualität bei unterschiedlichen Aufgaben und in verschiedenen Teams.

Die praktische Frage für ein Team ist konkreter: Welche Änderungen kann ein Agent selbstständig vorbereiten, was muss vor dem Merge geprüft werden und wer ist dafür verantwortlich, dass das Ergebnis die ursprüngliche Aufgabe löst? Delegation hebt diese Ingenieursarbeit nicht auf – sie verändert, wo sie beginnt und worauf sie sich konzentriert.