Was unterscheidet jemanden, der das Maximum aus einem Programmierassistenten herausholt, von jemandem, der schon beim ersten Problem stecken bleibt? Anthropic untersuchte rund 400.000 Sitzungen mit dem Tool Claude Code – und die Antwort überraschte. Es ist nicht die Fähigkeit, Code zu schreiben. Es ist das Fachwissen in dem Bereich, in dem die Person arbeitet.
Die Forschenden untersuchten Sitzungen von rund 235.000 Menschen zwischen Oktober 2025 und April 2026. Dazu verwendeten sie ein Tool, das die Privatsphäre schützt, sodass niemand einzelne Transkripte las. Sie interessierten sich für drei Dinge: Welche Arbeit mit dem Assistenten erledigt wird, wer sie erledigt und ob sie erfolgreich ist.
Sie entscheiden, was zu tun ist, der Assistent klärt, wie
Beginnen wir damit, wie eine solche Zusammenarbeit eigentlich abläuft. Die Forschenden teilten jede Entscheidung in einer Sitzung in zwei Arten ein. Bei der Planung geht es darum, was getan werden soll, welcher Ansatz gewählt wird und wann die Arbeit abgeschlossen ist. Bei der Ausführung geht es um die Details: welche Dateien geändert, welcher Code geschrieben und welche Befehle ausgeführt werden sollen. Dabei zeigte sich eine klare Arbeitsteilung. Menschen treffen im Durchschnitt rund 70 Prozent der Planungsentscheidungen, aber nur etwa 20 Prozent der Ausführungsentscheidungen. Der Mensch sagt, was er bauen möchte, und der Assistent findet heraus, wie es geht.
Wie viel erledigt Claude zwischen zwei Anweisungen? Eine typische Sitzung umfasst etwa vier Interaktionen. Jede Anweisung eines Menschen löst im Durchschnitt rund zehn Aktionen des Assistenten aus, manchmal sogar mehr als hundert. Bei jeder davon liest Claude Dateien, bearbeitet Code, führt Befehle aus und erzeugt im Durchschnitt 2.400 Wörter Ausgabe. Je mehr Kontrolle der Mensch über die Ausführung behält, desto weniger erledigt der Assistent selbst. Und umgekehrt: Überlässt der Mensch ihm auch die Planung, steigt die Zahl der Aktionen sprunghaft an.
Ein Buchhalter, der noch nie Python programmiert hat, kann ein Experte sein
Die Forschenden beurteilten die Expertise weder anhand der Berufsbezeichnung noch anhand der allgemeinen Fähigkeiten einer Person. Sie betrachteten die Expertise in Bezug auf die konkrete Aufgabe. Was bedeutet das in der Praxis? Ein erfahrener Ingenieur, der zum ersten Mal eine Frage zu Rust stellt, ist in Rust ein Anfänger. Ein Buchhalter hingegen, der noch nie mit Python gearbeitet hat, Claude aber genau erklärt, welche Regeln ein Abstimmungsskript einhalten muss, und einen Fall zeigt, an dem es beim Monatsabschluss scheitern würde, ist bei dieser Aufgabe ein Experte.
Ein Klassifikator erkannte die Expertise anhand von drei Signalen. Wie präzise eine Person ihre Anweisungen formuliert. Was sie vom Assistenten überprüfen lässt. Und ob eher der Mensch die KI korrigiert oder die KI den Menschen.
Der Hauptunterschied zwischen Anfängern und Experten zeigte sich bei der Ausgabe. In Sitzungen von Anfängern löst eine Anweisung etwa fünf Aktionen und rund 600 Wörter aus. Bei Experten sind es mehr als doppelt so viele Aktionen und fünfmal so viel Ausgabe, also etwa 3.200 Wörter. Je mehr ein Mensch über das Fachgebiet weiß, desto mehr hochwertige Arbeit erhält er vom Assistenten.
Die Arbeit hat sich innerhalb von sieben Monaten verändert
Die Zusammensetzung der Aufgaben, für die Menschen Claude Code verwenden, hat sich im untersuchten Zeitraum deutlich verschoben. Die stärkste Veränderung verzeichneten die Forschenden bei der Reparatur fehlerhaften Codes. Ihr Anteil sank von 33 auf 19 Prozent. Stattdessen nahm die Arbeit rund um den Code zu. Der Softwarebetrieb, also Bereitstellung, Konfiguration und Ausführung, stieg von 14 auf 21 Prozent. Das Verfassen von Dokumenten und die Datenanalyse verdoppelten sich ungefähr, von rund 10 auf 20 Prozent der Sitzungen.
Und es ging nicht nur um das Volumen. Auch die Aufgaben selbst gewannen an Wert. Die Forschenden schätzten ihn durch einen Vergleich mit Auftragsangeboten auf dem Markt für unabhängige Fachkräfte. Nach diesem Maßstab stieg der Wert einer durchschnittlichen Sitzung zwischen Oktober und April um 27 Prozent. Entwicklung, Betrieb und Fehlerbehebung verteuerten sich jeweils um etwa ein Drittel oder mehr. Die Autoren räumen ein, dass diese Schätzungen grob sind und daher eher dem Vergleich der Aufgaben untereinander dienen als der Ermittlung genauer Beträge.
Anfänger geben auf, Experten finden zurück in die Spur
Erfolgreicher sind diejenigen, die Fachwissen mitbringen. Das gilt über alle von den Forschenden verwendeten Erfolgsmaßstäbe hinweg. Sitzungen, die als von Anfängern stammend eingestuft wurden, erreichten in 15 Prozent der Fälle die strengste Schwelle, den sogenannten verifizierten Erfolg. Zumindest teilweise erfolgreich waren 77 Prozent. Sitzungen von Fortgeschrittenen und Experten erreichten in 28 bis 33 Prozent der Fälle einen verifizierten Erfolg und in 91 bis 92 Prozent einen Teilerfolg.
Interessant ist, wo dieser Sprung stattfindet. Der größte Zugewinn entsteht beim Übergang vom Anfänger zum Fortgeschrittenen. Zwischen Fortgeschrittenen und Experten ist der Unterschied nur noch gering. Es genügt also, ein solides Verständnis des Fachgebiets zu haben; eine perfekte Spezialisierung bringt nur noch einen kleinen zusätzlichen Vorteil.
Am deutlichsten zeigt sich das, wenn etwas schiefgeht. Bei Sitzungen, in denen ein Problem auftrat, stieg der Anteil verifizierter Erfolge von 4 Prozent bei Anfängern auf 15 Prozent bei Experten. Dann gibt es noch die Kehrseite. Wenn jemand ein Projekt aufgab, ohne eine einzige Zeile Code zu schreiben, sprechen die Forschenden von einer abgebrochenen Sitzung. Bei Anfängern endeten 19 Prozent der problematischen Sitzungen auf diese Weise. Bei allen anderen waren es nur 5 bis 7 Prozent. Weniger erfahrene Menschen geben schlicht auf, wenn sie nicht weiterkommen. Erfahrene Menschen können den Assistenten wieder in die richtige Richtung lenken.
Der Beruf spielt eine geringere Rolle, als man erwarten würde
Doch was, wenn der Erfolg einfach darauf beruht, dass Programmierer eben Programmierer sind? Die Daten stützen diese Vermutung kaum.
Menschen aus softwarebezogenen Berufen erzielten in rund 30 Prozent der Sitzungen einen verifizierten Erfolg. Bei Menschen aus anderen Berufen waren es 26 Prozent. In Sitzungen, in denen mindestens eine Zeile Code entstand, lagen die Werte bei 34 beziehungsweise 29 Prozent. Ein Unterschied von fünf Prozentpunkten ist gering und wurde im Laufe der sieben Monate weder größer noch kleiner, obwohl die Erfolgsquote in beiden Gruppen stieg.
Und jetzt kommt das Beste. Bei Sitzungen, in denen Code erzeugt wurde, lag jede der zehn am stärksten vertretenen Berufsgruppen in den Daten höchstens sieben Prozentpunkte von den Softwareingenieuren entfernt. Beim verifizierten Erfolg schnitten Menschen in Führungspositionen am besten ab, knapp vor den Ingenieuren. Möglicherweise liegt das an Managementfähigkeiten, die sich auf die Steuerung eines Assistenten übertragen lassen. Die Fähigkeit, eine Aufgabe klar zu formulieren und zu sagen, welches Ergebnis man erwartet, ist eben nützlich – egal, ob man mit einem Menschen oder einem Programm spricht.
Was die Studie noch nicht messen kann
Die Autoren gehen vorsichtig mit den Schlussfolgerungen um. Sie schreiben selbst, dass es sich um vorläufige Ergebnisse handelt. Sie können nicht erkennen, ob der in einer Sitzung geschriebene Code letztlich verwendet wurde oder im Papierkorb landete. Außerdem wurde sämtliche nicht interaktive Arbeit von der Analyse ausgeschlossen, also ein großer Teil der automatisierten Abläufe, bei denen Claude ohne einen Menschen an der Tastatur arbeitet. Und alle Bewertungen beruhen darauf, wie ein Modell das Transkript einer Sitzung interpretiert, was sich in großem Maßstab nur schwer überprüfen lässt.
Die Studie wurde verfasst von Zoe Hitzig, Maxim Massenkoff, Eva Lyubich, Shaoyi Zhang, Ryan Heller und Peter McCrory aus dem Forschungsteam von Anthropic.
