Studie von Anthropic: KI-unterstuetztes Lernen brachte Devs 17 Punkte weniger ein, Junioren sollten zuerst solo coden
In einem Experiment von Anthropic schnitten Entwickler, die mit KI lernten, im Schnitt 17 Punkte schlechter ab. Die Empfehlung: Gerade Junioren sollten Grundlagen zunaechst ohne KI-Assistenz erarbeiten, bevor sie Tools wie Claude Code nutzen.
Gibt man Entwicklern einen KI-Assistenten an die Hand, während sie eine neue Bibliothek lernen, werden sie ungefähr so schnell fertig wie jemand ohne einen. Wenn man sie anschließend zu dieser Bibliothek abfragt, erreicht die KI-Gruppe in Anthropics randomisierter Studie im Durchschnitt 50 Prozent. Die Gruppe, die von Hand programmierte, kam im Durchschnitt auf 67 Prozent.
Das ist eine Differenz von 17 Prozentpunkten, und der größte Teil davon entfiel auf Debugging-Fragen. Der Geschwindigkeitsunterschied lag bei etwa zwei Minuten und war statistisch nicht signifikant.
Meine Einschätzung: Wenn dein Team neuen Mitarbeitern am ersten Tag einen Coding-Agenten in die Hand gibt, überspringt ihr die Wochen, in denen sie lernen, Fehler zu finden. Junior-Entwickler sollten die erste Version unbekannten Codes selbst schreiben, den Agenten zum Erklären nutzen und sich das Delegieren später verdienen.
Die Studie trägt den Titel How AI Impacts Skill Formation und stammt von Judy Hanwen Shen und Alex Tamkin; sie wurde am 28. Januar 2026 auf arXiv veröffentlicht. Anthropics Begleittext beschreibt die 52 Teilnehmenden als überwiegend Junior-Softwareentwickler. Alle nutzten Python seit über einem Jahr wöchentlich, hatten bereits KI-Coding-Assistenten ausprobiert und noch nie Trio verwendet, eine Python-Bibliothek für asynchrone Nebenläufigkeit.
Jede Person erhielt eine kurze Aufwärmübung und dann 35 Minuten Zeit, zwei Trio-Features zu bauen: einen Timer, der jede Sekunde ausgibt, während andere Arbeit läuft, und einen Datensatz-Abrufer, der fehlende Datensätze behandelt. Die Hälfte durfte während der Trio-Aufgabe einen KI-Assistenten nutzen, die andere Hälfte nicht. Anschließend legte jeder einen Test ab: 14 Fragen, 27 Punkte, die sieben Trio-Konzepte anhand von Debugging-, Code-Lese- und konzeptuellen Fragen abdeckten (Studie, Version 2).
Die Ergebnisse, aus der Studie und Anthropics Beitrag:
Die Studie besagt, dass der größte Punktabstand bei den Debugging-Fragen lag und der kleinste beim Code-Lesen. Sie zählt auch Fehler. Die Median-Programmiererin von Hand traf während der Aufgabe auf 3 Fehler, die Median-KI-Nutzerin auf 1. Von den 12 Personen, die beide Aufgaben ohne Fehler abschlossen, programmierten nur zwei von Hand.
Genau dieser Teil beschäftigt mich immer wieder. Die KI-Gruppe hatte eine reibungslosere Stunde und lernte weniger daraus. Die Autorinnen und Autoren vermuten, dass die Fehler das Lehren übernahmen.
Die Von-Hand-Programmierer stießen auf Trio-spezifische Fehler, die die Studie benennt: eine RuntimeWarning für eine Coroutine, die nie awaited wurde, und einen TypeError, weil eine Coroutine übergeben wurde, wo Trio eine Funktion erwartete. Hier ist die erste Art, in der Form der Timer-Aufgabe der Studie:
import trio async def ticker (): for i in range ( 3 ): print ( " tick ", i ) trio. sleep ( 1 ) # Fehler: await fehlt async def main (): async with trio. open_nursery () as nursery: nursery. start_soon ( ticker ) trio. run ( main ) Ohne das await erzeugt trio.sleep(1) nur ein Coroutine-Objekt und führt es nie aus. Die Ticks werden hintereinander ausgegeben, und Python warnt, dass die Coroutine nie awaited wurde. Herauszufinden, warum, bringt dir bei, was eine Coroutine ist. Die Warnung in ein Chatfenster einzufügen, bringt dir bei, wie man einfügt.
Die Studie untermauert das mit ihren sechs Interaktionsmustern. Anthropics Beitrag nennt Näherungswerte für jedes davon:
Den niedrigsten Wert in der Tabelle haben diejenigen, die die KI zum Debuggen nutzten. Die Gruppe mit konzeptuellen Nachfragen war insgesamt das zweitschnellste Muster nach der KI-Delegation und behielt den größten Teil des Lernens. Zu fragen, was ein nursery macht, kostete sie fast keine Zeit.
Lass den Agenten Fragen beantworten. Lass den Menschen den Fehler finden.
Lies dies, bevor du die 17 Punkte in einem Planungstreffen zitierst.
Die Einschränkungen verengen die Aussage: Das Risiko ist am höchsten, wenn jemand neu in dem ist, was er baut, und ein Junior ist in fast allem neu.
Drei Phasen, jeweils pro Bereich der Codebasis, nicht pro Kalendermonat:
Wenn dein Team Claude Code nutzt, passt der integrierte Learning-Output-Stil gut zu Phase 2. Claude übernimmt Routinecode, erklärt seine Entscheidungen in Insight-Blöcken und lässt die Entwurfsentscheidungen dich an einer TODO(human)-Markierung schreiben, dann wartet es. Wechsle mit /output-style learning oder setze es in.claude/settings.local.json:
{ "outputStyle": "Learning" } Die Dokumentation besagt, dass der Wert case-sensitiv ist, daher fällt learning in der Datei auf den Standardstil zurück. Die Dokumentation sagt auch, dass Claude einen Output-Stil als Anweisung behandelt, der er nicht immer folgt, also erzwingt er Phase 1 nicht für dich.
Ich baue Hermes IDE, bewerte diesen Abschnitt also vor diesem Hintergrund. Hermes führt jeden Agenten in seinem eigenen echten Terminal aus, und einfache Shells öffnen sich auf dieselbe Weise. Ein Junior kann in demselben Fenster eine Shell für die eigenständige Version und eine Agentensitzung für Fragen behalten.
Hermes 2.3.4: die Leiste über einer Claude Code Sitzung, mit geöffneter Befehlsliste.
Seit 2.3.4 bündelt die Leiste über jeder Sitzung Model, Plan und Review an derselben Stelle für jeden Agenten, und die Befehlsliste enthält deine eigenen Befehle und Skills. Ein Claude Code Befehl wie /output-style gehört weiterhin zu Claude Code. Hermes führt nur die eigene Schnittstelle des Agenten aus.
Für Phase 3 zählt Review mehr als das Werkzeug. Hermes speichert jede Agentenrunde, und das Review Desk (⌘G, auf Windows und Linux Ctrl+Shift+G) zeigt die Änderungen nach Runden. Ein Mentor kann auf eine Runde zeigen und den Junior bitten, sie zu erklären, derselbe Nachfassschritt, den die Highscorer von selbst machten.
Hermes 2.3.4: das Review Desk nach Runden, mit dem Diff von Runde 1 und einer aus den Runden formulierten Commit-Message.
Hermes wird niemanden daran hindern, am ersten Tag zu delegieren. Diese Regel muss dein Team aufstellen. Es ist source-available unter BSL 1.1 und läuft auf macOS, Windows und Linux. Lade es hier herunter oder lies den Code auf GitHub. Hermes IDE ist weder mit Nous Research noch mit dessen Hermes Agent verbunden.
Anthropics Beitrag endet mit der unbequemen Zeile: Kognitive Anstrengung, und selbst schmerzhaft festzustecken, ist wahrscheinlich wichtig, um Meisterschaft zu fördern. Teams kaufen genau solche Agenten, um genau das zu beseitigen.
Lässt du neue Mitarbeiter vom ersten Tag an Agenten nutzen, oder schreiben sie die erste Version allein? Und wenn du zugeschaut hast, wie jemand mit einem Agenten an der Seite das Debuggen lernt, ist es hängen geblieben? Schreib es in die Kommentare.
Interviews bewerten nach wie vor genau die Fähigkeit, von der diese Studie sagt, dass KI sie untergraben kann: ein Problem selbst laut durchdenken, ohne ein Werkzeug als Rückfallebene. Mein System Design Pocket Guide: Interviews führt Schritt für Schritt durch 15 echte Designs. Nutze ihn so, wie die beste Gruppe der Studie die KI nutzte: skizziere zuerst dein eigenes Design, dann lies meins und streite mit ihm.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Give a developer an AI assistant while they learn a new library, and they finish about as fast as someone without one. Then quiz them on that library. In Anthropic's randomized trial, the AI group averaged 50%. The group that coded by hand averaged 67%.
That is a 17-percentage-point gap, and the biggest piece of it was on debugging questions. The speed difference was about two minutes and not statistically significant.
My take: if your team hands new hires a coding agent on day one, you are skipping the weeks where they learn to debug. Juniors should write the first version of unfamiliar code themselves, use the agent to explain things, and earn delegation later.
The paper is How AI Impacts Skill Formation by Judy Hanwen Shen and Alex Tamkin, posted to arXiv on January 28, 2026. Anthropic's write-up describes the 52 participants as "mostly junior" software engineers. Everyone had used Python weekly for over a year, had tried AI coding assistants, and had never used Trio, a Python library for async concurrency.
Each person got a short warm-up, then 35 minutes to build two Trio features: a timer that prints every second while other work runs, and a record fetcher that handles missing records. Half could use an AI assistant during the Trio task. Half could not. Then everyone took a quiz: 14 questions, 27 points, covering seven Trio concepts through debugging, code reading and conceptual questions ( paper, v2 ).
The results, from the paper and Anthropic's post:
The paper says the largest score gap was on debugging questions and the smallest on code reading. It also counts errors. The median hand coder hit 3 errors during the task, the median AI user hit 1. Of the 12 people who finished both tasks with zero errors, only two coded by hand.
That is the part I keep coming back to. The AI group had a smoother hour and learned less from it. The authors suspect the errors were doing the teaching.
The hand coders ran into Trio-specific mistakes the paper names: a RuntimeWarning for a coroutine that was never awaited, and a TypeError from passing a coroutine where Trio expected a function. Here is the first kind, in the shape of the study's timer task:
import trio async def ticker (): for i in range ( 3 ): print ( " tick ", i ) trio. sleep ( 1 ) # bug: missing await async def main (): async with trio. open_nursery () as nursery: nursery. start_soon ( ticker ) trio. run ( main ) Enter fullscreen mode Exit fullscreen mode Without the await, trio.sleep(1) only creates a coroutine object and never runs it. The ticks print back to back, and Python warns that the coroutine was never awaited. Figuring out why teaches you what a coroutine is. Pasting the warning into a chat window teaches you how to paste.
The paper backs that up with its six interaction patterns. Anthropic's post gives approximate averages for each:
The lowest score in the table belongs to the people who used the AI to debug. The conceptual-inquiry group was the second fastest pattern overall, after AI delegation, and kept most of the learning. Asking "what does a nursery do" cost them almost nothing in time.
Let the agent answer questions. Let the human find the bug.
Read this before you quote the 17 points in a planning meeting.
The caveats narrow the take: the risk is highest when someone is new to the thing they are building, and a junior is new to almost everything.
Three stages, per area of the codebase, not per calendar month:
If your team uses Claude Code, its built-in Learning output style is a decent fit for stage 2. Claude handles routine code, explains its choices in Insight blocks, and leaves the design-decision pieces for you to write at a TODO(human) marker, then waits. Switch with /output-style learning, or set it in.claude/settings.local.json:
{ "outputStyle": "Learning" } Enter fullscreen mode Exit fullscreen mode The docs say the value is case-sensitive, so learning in the file falls back to the default style. The docs also say Claude treats an output style as an instruction it may not always follow, so it won't enforce stage 1 for you.
I build Hermes IDE, so weigh this section with that in mind. Hermes runs each agent in its own real terminal, and plain shells open the same way. A junior can keep a shell for the solo version and an agent session for questions in the same window.
Hermes 2.3.4: the bar above a Claude Code session, with the Commands list open.
Since 2.3.4, the bar above each session puts Model, Plan and Review in the same place for every agent, and the Commands list includes your own commands and skills. A Claude Code command like /output-style still belongs to Claude Code. Hermes just runs the agent's own interface.
For stage 3, review matters more than the tool. Hermes saves every agent turn, and the Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) shows the changes by turn. A mentor can point at one turn and ask the junior to explain it, the same follow-up step the high scorers did on their own.
Hermes 2.3.4: the Review Desk by turn, with turn 1's diff and a commit message drafted from the turns.
Hermes won't stop anyone from delegating on day one. Your team has to make that rule. It is source-available under BSL 1.1 and runs on macOS, Windows and Linux. Download it here or read the code on GitHub. Hermes IDE is not affiliated with Nous Research or its Hermes Agent.
Anthropic's write-up ends on the uncomfortable line: "Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery." Teams are buying agents to remove exactly that.
Do you let new hires use agents from day one, or do they write the first version alone? And if you have watched someone learn to debug with an agent beside them, did it stick? Tell me in the comments.
Interviews still grade the skill this study says AI can erode: reasoning through a problem yourself, out loud, without a tool to fall back on. My System Design Pocket Guide: Interviews walks through 15 real designs step by step. Use it the way the study's best group used the AI: sketch your own design first, then read mine and argue with it.