Ein Programmieragent kann Code schreiben, Befehle ausführen und mehrere Schritte hintereinander erledigen, ohne jedes Mal auf eine Anweisung zu warten. Dadurch verlagert sich die Arbeit des Entwicklers: weniger Tippen, mehr Vorgaben und Überprüfung. Doch neben dem weniger sichtbaren Zeitgewinn bleibt eine Frage: Wie lassen sich die Fähigkeiten bewahren, die nötig sind, um einen Fehler zu erkennen oder wieder die Kontrolle zu übernehmen, wenn man bestimmte Aufgaben seltener selbst erledigt?
Dieses Risiko wird von Ingenieuren diskutiert, die solche Werkzeuge täglich nutzen. Es darf jedoch nicht mit einem nachgewiesenen dauerhaften Kompetenzverlust bei allen Entwicklern verwechselt werden. Die verfügbaren Erkenntnisse beschreiben vor allem Nutzungsweisen, Wahrnehmungen und Erfahrungen, die auf bestimmte Aufgaben begrenzt sind. Sie helfen dennoch zu verstehen, wo Delegation problematisch werden kann und wie sich die Kontrolle konkreter gestalten lässt.
Code zu delegieren bedeutet nicht, die Verantwortung abzugeben
In einem Text über den Einsatz von Programmieragenten unterscheidet Addy Osmani, Ingenieur bei Anthropic und Mitglied des Claude-Code-Teams, drei Stufen der Delegation. Auf der ersten erstellt der Agent einen Vorschlag, den die Person prüft. Auf der zweiten wird dieser Vorschlag zum Ausgangspunkt der Arbeit. Auf der dritten wird er ohne echte Kontrolle übernommen. Die Forscher von Wharton bezeichnen diese Haltung als „kognitive Kapitulation“.
Der Unterschied liegt weniger im Werkzeug als in der Rolle, die der Nutzer beibehält. Ein Entwickler kann einen Agenten eine Funktion schreiben lassen und dennoch dafür verantwortlich bleiben, zu verstehen, was sie tut, zu prüfen, ob sie den Anforderungen entspricht, und zu entscheiden, ob sie integriert werden kann. Umgekehrt kann eine technisch plausibel wirkende Antwort übernommen werden, weil sie gut präsentiert ist oder weil der erste Test besteht.
Ein erfolgreicher Test belegt jedoch nur, was er überprüft. Wenn der Test eine fehlerhafte Annahme der Funktion übernimmt, die er eigentlich kontrollieren soll, können beide gemeinsam daran scheitern, das Problem zu erkennen. Eine sinnvolle Überprüfung besteht daher auch darin, den Umfang des Tests zu untersuchen: Welche Fälle deckt er ab, welche lässt er aus, und welchen Annahmen muss man vertrauen, damit das Ergebnis zuverlässig ist?
Nutzungsgewinne messen nicht den Lernerfolg
Eine 2025 von Anthropic veröffentlichte Studie gibt Einblick in die im Unternehmen beobachteten Veränderungen. Sie stützt sich auf eine Befragung von 132 Ingenieuren und Forschern, 53 Interviews und die Analyse von 200 000 internen Claude-Code-Transkripten, die im Februar und August 2025 gesammelt wurden. In der Befragung schätzten die Beschäftigten, Claude bei 59 % ihrer Arbeit einzusetzen, und schrieben dem Tool einen durchschnittlichen Produktivitätsgewinn von 50 % zu. Diese Zahlen beruhen auf Selbstauskünften: Sie geben die Einschätzung der Befragten wieder und sind keine unabhängige Messung der tatsächlich eingesparten Zeit.
Die Analyse der Transkripte zeigt ihrerseits, wie sich die Verteilung der Nutzungsweisen verändert hat. Zwischen Februar und August stieg der Anteil der Transkripte, die als Arbeit an der Implementierung neuer Funktionen eingestuft wurden, von 14,3 % auf 36,9 %; der Anteil jener, die als Arbeit am Design oder an der Planung des Codes eingestuft wurden, stieg von 1 % auf 9,9 %. Das Tool führte auch mehr Aktionen aus, bevor ein Mensch erneut eingriff. Diese Ergebnisse deuten darauf hin, dass die Teams Claude Code komplexere oder autonomere Aufgaben anvertrauten. Für sich genommen messen sie weder einen Anstieg des gesamten Arbeitsvolumens noch das Kompetenzniveau der einzelnen Personen.
Die Interviews zeigen die mögliche Kehrseite dieser Entwicklung. Einige Teilnehmer berichten, in Bereichen sicherer zu werden, die sie zuvor weniger gut beherrschten, weil die KI das Erstellen einer ersten Version oder das Erkunden unbekannten Codes erleichtert. Andere befürchten, weniger zu lernen, wenn sie Probleme nicht selbst lösen: Dokumentation zu lesen, die Funktionsweise eines Werkzeugs zu untersuchen oder einem Fehler nachzugehen, kann Wissen vermitteln, das für die unmittelbare Korrektur nicht unbedingt erforderlich ist, später aber dabei hilft, das gesamte System zu verstehen.
Anthropic weist darauf hin, dass die Teilnehmer Beschäftigte eines Unternehmens sind, das diese Werkzeuge entwickelt, und sie in einem besonderen Kontext nutzen können. Die Antworten können zudem durch die Auswahl der befragten Personen und den Umstand beeinflusst sein, dass einige Messwerte auf Selbstauskünften beruhen. Diese Arbeit beleuchtet Zielkonflikte, die in dieser Organisation beobachtet wurden; sie erlaubt nicht den Schluss, dass Entwickler allgemein dauerhaft ihre Fähigkeiten verlieren, wenn sie KI nutzen.
Für die Überwachung muss man wissen, was man kontrolliert
Das ist das praktische Paradox der Überwachung: Um den Code eines Agenten beurteilen zu können, braucht man genügend Wissen, um zu erkennen, was gefährlich, unvollständig oder ungeeignet ist. Genau den Erhalt von Fähigkeiten, die sowohl beim Schreiben als auch beim kritischen Prüfen von Code gebraucht werden, sehen die von Anthropic befragten Teilnehmer jedoch mit Sorge. Einige berichten deshalb, sich Zeit zum Programmieren ohne KI freizuhalten, um dieses Können weiter zu trainieren.
Diese Entscheidung beantwortet nicht alle Fragen. Insbesondere muss noch geklärt werden, welche Fähigkeiten bei einer Arbeit unverzichtbar sind, in der die Werkzeuge die Aufgaben der Ingenieure verändern. Einige befragte Beschäftigte rechnen mit einer Verlagerung hin zu Konzeption, Code-Review oder der Koordination von Agenten. Andere bedauern, weniger direkt mit Code zu arbeiten, oder fragen sich, wie Einsteiger ausgebildet werden sollen. Die Studie gibt diese Sichtweisen wieder; sie entscheidet nicht über die Zukunft des Berufs.
Die Ergebnisse einer anderen Studie, die ihre Autoren im Wharton Magazine diskutieren, lenken die Aufmerksamkeit darauf, wie bereitwillig generierte Antworten übernommen werden. Teilnehmer konnten ChatGPT nutzen, um Logik- und Denkaufgaben zu lösen. Steven Shaw erklärt, dass die Personen, die das Tool in den Experimenten konsultierten, dessen Antwort häufig übernahmen – auch wenn sie falsch war. Diese Aufgaben beleuchten ein Verhalten in einer experimentellen Situation; sie messen weder die Arbeitsqualität eines Entwicklers in einem Unternehmen noch eine dauerhafte Abnahme seiner Fähigkeiten.
Die Kontrolle dem Risiko anpassen
Addy Osmani empfiehlt nicht, jede Aufgabe gleich gründlich zu überprüfen. Eine risikoarme und leicht rückgängig zu machende Delegation erfordert nicht unbedingt dieselbe Prüfung wie eine Änderung, die sich auf die Sicherheit, die Daten oder den Produktivbetrieb auswirken könnte. Vor einer wichtigen Aufgabe schlägt er vor, zunächst eine eigene Hypothese zu formulieren und dann zu überlegen, wodurch die Antwort des Agenten falsch sein könnte. Außerdem rät er dazu, den Agenten seine Entscheidungen und die verwendeten Standardwerte erläutern zu lassen.
Bei einer Softwareänderung lassen sich diese Schritte in konkrete Fragen übersetzen: Welches Verhalten soll sich ändern? Welche Teile des Systems sind betroffen? Welche Fälle deckt der Test tatsächlich ab? Hat der Agent eine Abhängigkeit oder Annahme eingeführt, die das Team nicht geprüft hat? Eine sinnvolle Prüfung besteht nicht nur darin, das Ergebnis noch einmal zu lesen; sie vergleicht es mit Kriterien, die vor der Annahme festgelegt wurden.
Es geht also nicht darum, sich zwischen dem selbstständigen Schreiben jeder Zeile und dem vollständigen Überlassen der Arbeit an einen Agenten zu entscheiden. Vielmehr gilt es festzulegen, welche Vorgänge delegiert werden können, genügend Verständnis zu bewahren, um wichtige Entscheidungen zu überwachen, und sicherzustellen, dass die Arbeitsgewohnheiten weiterhin die nötigen Fähigkeiten fördern. Die Ausführungsgeschwindigkeit ist sichtbar, sobald Code generiert wurde. Ob man ihn wieder übernehmen kann, zeigt sich erst, wenn man ihn erklären, korrigieren oder weiterentwickeln muss.
Quellen
- Anthropic, „How AI is transforming work at Anthropic“
- Wharton Magazine, „Is AI Hijacking Our Brains?“
- Clubic, Interview und Ratschläge von Addy Osmani zur Delegation an KI
Ein Videospiel-Entwicklungsstudio in Indien. Symbolfoto, nicht mit den von Anthropic untersuchten Teams verbunden.
Bildnachweis: Red Apple Learning — Wikimedia Commons — CC BY-SA 4.0.
