Warum die meisten Entwickler trotz Coding Agents nur wenig davon profitieren.

Zwei Forschungsprojekte aus dem Jahr 2026, eines von JetBrains und eines von Anthropic, liefern Zahlen darüber, wie Entwickler tatsächlich mit Programmier-Agenten arbeiten. Gemeinsam argumentieren sie, dass der Unterschied zwischen dem Erreichen von Nutzen durch einen Agenten und dem Erhalten von Unnötigem darin liegt, wie die Arbeit delegiert wird – und nicht darin, welches Modell gewählt wird.

Die zentrale These lautet, dass künstliche Intelligenz im Programmieren nicht mehr nur ein Experiment ist, und dass der entscheidende Unterschied heute darin besteht, einem Modell den Auftrag zu geben, Code zu schreiben, im Gegensatz zur tatsächlichen Delegation von Entwicklungsarbeiten an dieses Modell.

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Warum eine Handels-App eine gute Testgrundlage ist

Betrachten wir eine iOS-Handels-App, die für eine Wertpapierfirma entwickelt wurde. UIKit und SwiftUI koexistieren dort nebeneinander, ergänzt durch MVVM und Clean Architecture. In einer solchen Codebasis wird eine falsche Zahl auf dem Bestätigungsbildschirm nicht zu einem Fehlerbericht – stattdessen erfolgt ein Anruf aus der Compliance-Abteilung.

Für ein Team in dieser Situation geht es bei der Übertragung echter Aufgaben an Coding-Agenten nicht um Geschwindigkeit. Entscheidend ist der Moment, in dem der Agent heimlich etwas falsch macht und niemand es bemerkt. Die Analyse dieses Moments lehrt mehr über die Arbeitsabläufe der Agenten als jedes Training, und die Daten von 2026 erklären, warum.

Was die JetBrains-Umfrage ergeben hat

Zwischen Mai und Juli 2026 befragte JetBrains mehr als 15.000 berufstätige Entwickler. Neun von zehn gaben an, mindestens wöchentlich KI-basierte Coding-Agenten im Job einzusetzen, und 68 % täglich.

Claude Code führt weltweit mit 39 % und in den USA mit 47 %, was etwa doppelt so viel ist wie GitHub Copilot mit 21 % – ein Wert, der im Vergleich zum Vorjahr von 29 % gesunken ist. Codex stieg hingegen von 3 % auf 16 %.

Ein begleitender Bericht zeigt eine interessantere Zahl: Entwickler schätzen, dass etwa 47 % ihres Codes derzeit vollständig von KI-Tools erstellt werden, mehr als die Hälfte schreibt weniger als 20 % ihres Codes manuell und einer von fünf schreibt ohne KI-Hilfe überhaupt keinen Code.

Erfahrung hat die Adoption nicht gebremst, sondern gefördert. Etwa jeder vierte erfahrene Entwickler lässt KI-Tools mehr als 80 % seines Codes erstellen – ein höherer Anteil als bei Junior-Entwicklern, die lieber Zeile für Zeile unterstützt werden. Das widerlegt die Annahme, dass KI Junior-Entwickler überflüssig macht. Diejenigen mit der besten Urteilsfähigkeit übergeben am meisten Aufgaben an KI-Tools – und das ist keineswegs Zufall.

Was 400.000 Sitzungen zeigen

Die eigene Studie von Anthropic umfasste etwa 400.000 interaktive Claude Code-Sessions von rund 235.000 Nutzern, die vom Oktober 2025 bis April 2026 aufgezeichnet wurden. Die Aufschlüsselung sieht einfacher aus, als die Marketingkampagne vermuten lässt:

• Code-bezogene Arbeiten machten 56 % der Sessions aus, wovon 25 % auf das Schreiben, 26 % auf die Behebung von Fehlern und 5 % auf Tests oder Orchestrierung entfielen.
• Die Bedienung von Software nahm 17 % ein.
• Planung und Erkundung machten 14 % aus.
• Analyse und Prosa nahmen 13 % ein.

Die wichtigste Erkenntnis betrifft die Entscheidungsfindung: Die Menschen treffen etwa 70 % der Planungsentscheidungen, während Claude etwa 80 % der Ausführungsentscheidungen trifft. Die Menschen entscheiden über das Was, der Agent über das Wie.

Niemand hat diese Aufteilung entworfen. Es handelt sich um ein Gleichgewicht, das Hunderttausende von Ingenieuren unabhängig voneinander erreicht haben, weil es funktioniert. Viele Beschwerden über KI-Assistenten stammen von Menschen, die diese Aufteilung umgekehrt haben – sie legten zunächst das Was fest und stritten anschließend mit dem Assistenten über das Wie.

Expertise verändert das Ergebnis

Die Zahlen widerlegen jeden, der glaubt, „jeder könne heute etwas entwickeln“. Die Sitzungen wurden anhand von drei Kriterien hinsichtlich der scheinbaren fachlichen Expertise des Nutzers bewertet: Wie präzise die Anweisungen waren, was der Nutzer von Claude überprüfen ließ und wie Korrekturen vorgenommen wurden. Anschließend wurden die Ergebnisse nebeneinander dargestellt.

Begonnen wird mit den ersten beiden Zeilen. Experten tippen nicht mehr. Eine einzige Anweisung eines Experts erbringt mehr als das Doppelte an Arbeit im Vergleich zu einem Anfänger, der zwölf Aktionen ausführt, während ein Experte nur fünf benötigt – obwohl Modell, Tool und Preis identisch sind. Die Nachricht des Experts enthält genügend Kontext, sodass der Agent nie anhalten und raten muss.

Auch die letzte Zeile ist genauso wichtig. Nachdem eine Sitzung vom Kurs abgekommen war, gaben etwa 19 Prozent der Anfänger auf, ohne Code zu erstellen, im Vergleich zu 5 bis 7 Prozent der Experten. Die entscheidende Fähigkeit liegt nicht im Formulieren der Anfrage, sondern darin, eine abgeschweifte Sitzung wieder auf Kurs zu bringen.

Ein Satz aus der Studie fasst es zusammen: Bei Anfängern neigt Claude dazu, den Benutzer zu korrigieren, während der Benutzer bei Experten Claude korrigiert. Das ist die Grenze zwischen dem Einsatz eines Agents und der Steuerung durch einen Agenten.

Der dreistufige Prozess, der fehlschlägt

Eine gängige Vorgehensweise sieht so aus:

Bad:
Prompt → AI writes code → Accept

Zwei dieser drei Schritte gehören zum Agenten. Es gibt keine Anforderungen, keinen Kontext, keinen Plan und keine Überprüfung. Das ist keine Delegation von Ingenieurarbeiten – es handelt sich vielmehr um automatische Vervollständigung in gröberer Granularität mit der Hoffnung, dass das Ergebnis richtig aussieht.

Ein siebenschrittiger Prozess, der hält

Die Routine, die dem Kontakt mit einer Produktionshandels-App standgehalten hat, umfasst sieben Schritte:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

Der Ingenieur ist für die ersten drei Phasen sowie die letzten beiden verantwortlich, während der Agent für den dazwischenliegenden Bereich zuständig ist. Dieses Verhältnis spiegelt die Forschungsergebnisse wider, bei denen eine Planungsverteilung von 70/30 sowie eine Ausführungsverteilung von 80/20 in Form eines Pipelines dargestellt werden. Jede Phase hat ihre eigenen Kosten.

Anforderung

Eine Aussage wie „Fügen Sie ein Bestätigungsformular zum Bestellprozess hinzu“ zählt als Aufgabe. Ein Agent kann etwas erstellen, das technisch korrekt ist, aber funktional fehlerhaft. Eine wirklich wertvolle Anforderung enthält weitaus mehr Inhalt:

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

Die letzte Zeile dieser Spezifikation betrifft das Fachwissen im jeweiligen Bereich, und kein Modell verfügt darüber. Genau das unterscheidet einen funktionsfähigen Bildschirm von einem, der zu regulatorischen Problemen führt. Dies entspricht dem „Präzisionsgrad der Richtung“-Signal im Rahmen der Forschung und ist außerdem das günstigste Problem, das behoben werden kann.

Kontext

Wo UIKit und SwiftUI unter der Clean Architecture zusammenarbeiten, entwickelt ein Agent sein eigenes Muster, falls keines vorgegeben ist – jedes so entstandene Muster wird später zu einem Überprüfungscomment. Deshalb wird dem Agent zunächst auf echte Beispiele hingewiesen: das aktuelle Use-Case-Protokoll, eine Implementierung im Repository, der ViewModel, der die ähnlichste Aufgabe übernimmt, sowie das CLAUDE.md-Dokument des Moduls mit seinen Schichtregeln. Drei Dateien sowie ein Dokument zu den Konventionen sind jedes Mal effektiver als drei Absätze Erklärung. Fast jeder überspringt diese Phase, obwohl sie den größten Nutzen bringt.

Plan

Bitten Sie im Voraus um einen Plan, in dem aufgelistet wird, welche Dateien sich ändern, welche Schicht jeweils welche Änderung übernimmt, was der ViewModel bereitstellt und was getestet wird. Lesen Sie ihn wie eine PR-Beschreibung. Die Ablehnung eines Plans dauert etwa neunzig Sekunden. Die Ablehnung einer Implementierung hingegen dauert zwanzig Minuten und hinterlässt einen Diff, den man im Kopf ignorieren muss.

Etwa ein Drittel der Pläne wird geändert, meist wegen Fragen zur Strukturierung, wie zum Beispiel dass ein Agent eine Berechnung im ViewModel platziert, obwohl sie eigentlich in einem Use Case liegen sollte. Das Korrigieren per Text ist unkompliziert, während es in Swift schwieriger ist.

Implementierung

Sobald der Plan vereinbart ist, treten Sie zurück. Hier liegen die 80 % der Entscheidungen bezüglich der Umsetzung: Benennung, Ablaufsteuerung, wie ein Diff strukturiert werden soll und welcher kleine Hilfsprogramm extrahiert werden muss. Durch ständige Unterbrechungen, um an einem Variablennamen herumzukritisieren, verwandelt sich eine Sitzung mit zwölf Schritten in eine mit nur fünf. Zudem wird dadurch die Aufmerksamkeit erfahrener Entwickler für die Arbeit von Junior-Entwicklern aufgebraucht.

Überprüfung

Die Anweisung mit dem besten Ergebnis besagt, dass die Arbeit erst abgeschlossen ist, wenn der Code kompiliert werden kann und die Tests bestehen – wobei der Agent beides eigenständig ausführt. Die Forschung beschreibt dies als das, was der Benutzer von Claude verlangt, dass er überprüft, und es ist das Signal, das am längsten unterschätzt wird. Ein Agent, der xcodebuild sowie das Testziel ausführen kann, schließt seinen eigenen Kreislauf ab. Ein Agent ohne diese Fähigkeit übergibt lediglich einen Entwurf und bezeichnet ihn als Funktion.

Für das Bestätigungsblatt bedeuten erfolgreiche Tests konkrete zuvor aufgelistete Verhaltensweisen. Die Kaufkraft muss beim Vorlegen des Blatts neu berechnet werden, die Bestätigungs-Schaltfläche muss während dieser Neuberechnung deaktiviert bleiben, und die Gebührenberechnung muss mit den bereits im Repository vorhandenen Einstellungen übereinstimmen.

Überprüfung

Jede Zeile wird gelesen. Das liegt nicht daran, dass der Code in der Regel schlecht ist – was meistens auch nicht der Fall ist. Bei der Überprüfung muss weiterhin menschliches Fachwissen in das System einfließen. Dabei wird geprüft, was eine automatische Überwachung nicht erkennen kann: ob die Änderung die Schichtgrenzen einhält, ob die Abschlagsregel tatsächlich die von der Finanzabteilung verwendete ist und ob die Zustandsmaschine mit einem Verbindungsabbruch mitten in einer Bestätigung umgehen kann.

Diese Phase stellt zugleich die tatsächliche Obergrenze für die Durchsatzleistung dar. Ein Agent kann mehr Arbeit erzeugen, als irgendjemand verantwortungsvoll prüfen kann, und der Drang zur oberflächlichen Betrachtung stellt die eigentliche Gefahr des gesamten Workflows dar. Das Risiko liegt weniger in Halluzinationen als vielmehr in Ermüdung.

Wohin sich die Arbeit entwickelt

Der siebmonatige Trend innerhalb der 400.000 Sessions verdient Aufmerksamkeit:

• Der Anteil der Sessions, die zum Debuggen verwendet wurden, sank von einem Drittel (33 %) auf 19 %.
• Das Ausführen von Software in Betrieb stieg von 14 % auf 21 %.
• Schreiben sowie Datenanalyse verdoppelten sich ungefähr, indem sie von etwa einem Zehntel auf etwa ein Fünftel der Sessions anstiegen.

Das Beheben von Fehlern nimmt weniger Zeit in Anspruch, während das Betreiben und Verständnis laufender Systeme mehr Zeit erfordert. Im gleichen Zeitraum stieg der geschätzte Wert der Aufgaben um etwa 25 %, während die Aufwand für die Entwicklung um rund 43 % anstieg. Die Arbeit verschwindet nicht – sie verschiebt sich auf eine höhere Ebene, weg vom Eingeben von Implementierungen hin zur Spezifizierung, Koordination und Überprüfung derselben, was auch der übliche Arbeitsablauf eines erfahrenen Ingenieurs mit Team ist.

Das Engpassproblem ist der Zyklus

Neun von zehn Entwicklern verwenden diese Tools wöchentlich, doch nur 15 bis 33 % der Sitzungen enden mit einem bestätigten Erfolg. Das Modell war also nie die Beschränkung – die meisten Menschen wenden einfach einen dreistufigen Zyklus auf ein für sieben Schritte konzipiertes Tool an.

Das Feinschleifen des Prompts wird das Problem nicht lösen. Die Lösung besteht darin, das Urteilsvermögen dort anzuwenden, wo Probleme entstehen, was bedeutet, „richtig“ im Voraus zu definieren und am Ende zu überprüfen, ob diese Definition eingehalten wurde. Der Agent kümmert sich um den mittleren Bereich und erledigt seine Aufgabe gut – in dem Maße, wie klar die Grenzen festgelegt wurden.

Im Jahr 2026 sind es nicht diejenigen, die die klügsten Prompts schreiben, sondern diejenigen, die am meisten aus Coding-Agents herausholen. Sie bleiben weiterhin diejenigen, die entscheiden, was „erledigt“ bedeutet.