Bestehenden Code verstehen

Wer neu in ein Projekt kommt, steht vor Code, den andere geschrieben haben. Mit genau diesem Fall beginnt die Doku zu Arbeitsabläufen (externe Seite, code.claude.com) ihre Rezepte: Man ist gerade zu einem Projekt gestoßen und muss seinen Aufbau schnell verstehen. Claude Code liest dafür die Dateien selbst, durchsucht sie, folgt Aufrufen und beantwortet Fragen. Der Leitfaden mit bewährten Mustern (externe Seite, code.claude.com) rät, Claude beim Einstieg in eine neue Codebasis zum Lernen und Erkunden einzusetzen. Man soll ihm die Fragen stellen, die man einem erfahrenen Kollegen stellen würde.

Wie oft Leute das tun, lässt sich nur grob sagen. Eine Studie des Herstellers (externe Seite, anthropic.com) über rund 400.000 interaktive Sitzungen führt zwei verwandte Arbeitsweisen: verstehen, wie ein bestehendes System funktioniert, und eine Änderung planen, bevor man sie macht. Von Oktober 2025 bis April 2026 kamen sie zusammen auf 14 Prozent der Sitzungen, nach der ersten Abbildung der Studie je 7 Prozent. Welche Sitzung wohin gehört, hat ein Modell eingestuft, und der Hersteller hat sein eigenes Produkt ausgewertet. Was die Studie sonst über den Einsatz sagt, steht in Kapitel 07.

Der Weg in vier Schritten

Die Doku beschreibt den Einstieg als Folge von Prompts. Zusammengenommen ergeben sie vier Schritte, und die zweite Ebene zeigt die Prompts im Wortlaut.

seitlich verschiebbar

eigene Darstellung nach den Rezepten der Herstellerdokumentation Common workflows und Best practices for Claude Code, Stand 13.10.2026

1. Überblick. Man startet Claude Code im Wurzelordner des Projekts und fragt nach einem Überblick über die Codebasis. Danach geht es tiefer: welche Architekturmuster der Code benutzt, welche Datenmodelle zentral sind. Die Doku rät, mit breiten Fragen zu beginnen und dann auf einzelne Bereiche einzugrenzen.
2. Fragen und Begriffe. Man fragt nach den Konventionen und Mustern des Projekts und lässt ein Glossar der Begriffe anlegen, die nur dieses Projekt benutzt. Auch eine Frage zu einer einzelnen Zeile geht, etwa warum der Code dort eine Funktion statt einer anderen aufruft. Eine besondere Formulierung braucht es dafür laut Leitfaden nicht.
3. Code finden und Abläufe verfolgen. Man lässt die Dateien suchen, die eine Funktion umsetzen. Dann verfolgt Claude einen Ablauf, im Beispiel der Doku die Anmeldung von der Oberfläche bis zur Datenbank. Die Doku rät, genau zu sagen, was man sucht, und die Begriffe des Projekts zu benutzen.
4. Aufschreiben. Aus dem Verstandenen wird Dokumentation. Das Rezept dafür endet mit einer Prüfung, ob sie den Standards des Projekts folgt.

Was Anthropic aus den eigenen Teams berichtet

Einen Fall mit Zahlen liefert der Bericht über die eigenen Teams (externe Seite, claude.com) vom 24.07.2025. Danach nutzen Teams im ganzen Unternehmen Claude Code, damit neue und auch langjährige Mitarbeiter sich in den Codebasen zurechtfinden. Zum Einarbeiten passen Beispiele aus vier Teams:

• Infrastructure: Neue Data Scientists geben Claude Code die ganze Codebasis. Claude erklärt die Abhängigkeiten der Datenpipelines und zeigt, welche Quellen in welche Dashboards fließen. Laut Bericht ersetzt das die üblichen Datenkataloge.
• Product Engineering: Claude nennt die Dateien, die man sich für eine Fehlerbehebung, ein Feature oder eine Analyse ansehen muss.
• Security Engineering: Bei einer Störung bekommt Claude Code Stacktraces und Dokumentation und verfolgt damit den Kontrollfluss durch den Code. Probleme, für die man üblicherweise 10 bis 15 Minuten von Hand sucht, sind in einem Drittel der Zeit gelöst.
• Inference: Mitglieder ohne Hintergrund im maschinellen Lernen lassen sich modellspezifische Funktionen erklären. Was sonst eine Stunde Suche bei Google kostete, dauert 10 bis 20 Minuten. Der Bericht nennt das 80 Prozent weniger Zeit für die Recherche.

Alle diese Zahlen melden die Teams selbst. Der Bericht entstand aus Gesprächen mit Mitarbeitern, und eine Messung beschreibt er nicht.

Die 80 Prozent gelten für eine Gruppe und eine Art von Frage. Gerechnet ergibt die Spanne von 10 bis 20 Minuten gegen eine Stunde 67 bis 83 Prozent, die genannte Zahl liegt also am oberen Rand. Wie weit diese Angaben reichen, steht auf der dritten Ebene.

Die Werkzeuge dahinter

Die Werkzeuge hinter den vier Schritten erklären andere Kapitel.

• Projektanweisung: Fehlt die CLAUDE.md, legt /init eine an, mit Befehlen zum Bauen und Testen und den Konventionen, die Claude im Code erkennt (Gedächtnis-Doku (externe Seite, code.claude.com)). Mehr in Kapitel 14.
• Code Intelligence: Ein Plugin für die eigene Sprache lässt Claude Definitionen und Verweise genau finden. Mehr in Kapitel 04.
• Subagent: Die Doku rät, die Erkundung einer großen Codebasis abzugeben, damit nur die Befunde zurückkommen. Mehr in Kapitel 20.
• Plan-Modus: Ein Plan nützt laut Leitfaden am meisten, wenn der Weg unklar ist, die Änderung mehrere Dateien betrifft oder man den Code nicht kennt. Mehr in Kapitel 23.

Aus dem Verstandenen wird Dokumentation

Was Claude beim Einarbeiten herausfindet, hat zwei Leser. Der eine ist der Mensch, der nach einem kommt. Für ihn entstehen Kommentare im Code, eine Beschreibung der Architektur oder eine Anleitung zur Fehlersuche. Der andere ist die nächste Sitzung von Claude Code. Für sie rät die Prompt-Sammlung der Doku (externe Seite, code.claude.com), die gelernten Konventionen in der CLAUDE.md festzuhalten. Dann beginnt jede Sitzung mit diesem Wissen, und Claude muss es nicht neu erarbeiten.

Ein Archi­tek­tur­über­blick gehört dagegen in die Dokumentation für Menschen. Seit Version 2.1.206 vom 09.07.2026 schlägt die Prüfung /doctor Kürzungen für eine eingecheckte CLAUDE.md vor (Versionsliste (externe Seite, code.claude.com)). Der Vorschlag streicht Archi­tek­tur­über­blick, Verzeichnisaufbau und Abhängigkeiten, denn Claude kann all das aus dem Code ableiten (Gedächtnis-Doku (externe Seite, code.claude.com)). Behalten soll die Datei Fallstricke, Begründungen und Konventionen, die von den Voreinstellungen der Werkzeuge abweichen.

Das Security-Engineering-Team zeigt die andere Richtung. Claude liest dort mehrere Quellen der Dokumentation. Daraus entstehen Runbooks und Anleitungen zur Fehlersuche in Markdown. Bei einem echten Problem im Betrieb dienen diese Dokumente wieder als Kontext, und das ist laut Bericht oft effizienter als die Suche in den vollständigen Wissenssammlungen.

Dokumentation altert mit dem Code. Der Leitfaden für große Codebasen rät deshalb, Änderungen an einer CLAUDE.md im Pull Request zu prüfen wie jede andere Dokumentation. Ein Beispiel aus einem Datenteam steht in Kapitel 13. Was geschieht, wenn die Pflege fehlt, zeigt der Beitrag ADR und Spezifikation an einem eigenen Projekt: Ein Eintrag stand auf angenommen, und gebaut war etwas anderes. Ob etwas gebaut ist, beantwortet nach dem Beitrag ein Test oder eine Suche im Quelltext.

Liegt die Dokumentation als Ordner mit Markdown-Dateien neben dem Code, lässt sie sich mit Claude Code durchsuchen und umordnen. Wie das bei Notizen und Dateisammlungen geht, zeigt Kapitel 10.

Drei Grenzen

Das Kontextfenster. Der Leitfaden nennt die Erkundung ohne Grenzen als typischen Fehler: Claude liest Hunderte Dateien und füllt damit das Fenster. Abhilfe schafft eine eng gefasste Frage oder ein Subagent.

Die Erklärung selbst. Eine Antwort über fremden Code ist ein Text, den man nachprüfen kann und sollte. Der Leitfaden rät, Claude auf die Quelle zu lenken, die eine Frage beantworten kann, etwa die Git-Historie einer Klasse. Wer sich Datei und Zeile nennen lässt, kann jede Aussage dort nachlesen.

Das eigene Lernen. In einem kontrollierten Versuch hat Anthropic gemessen, wie gut Entwickler eine ihnen unbekannte Python-Bibliothek mit und ohne KI-Hilfe lernen. Veröffentlicht ist er seit dem 29.01.2026 (Studie (externe Seite, anthropic.com)). Teilgenommen haben 52 Entwickler, die meisten am Anfang ihrer Laufbahn. Im Test danach kam die Gruppe mit KI-Hilfe im Mittel auf 50 Prozent, die Gruppe ohne auf 67 Prozent. Besser schnitt ab, wer die KI auch zum Verstehen nutzte: mit Nachfragen, mit der Bitte um Erklärungen oder mit Fragen zu Konzepten beim eigenen Programmieren. Diese Gruppen waren klein, und einen ursächlichen Schluss zieht die Studie daraus nicht.

Der Assistent im Versuch saß in der Seitenleiste einer Online-Plattform zum Programmieren. Die Studie grenzt diesen Aufbau selbst von Werkzeugen wie Claude Code ab und erwartet dort eher stärkere Auswirkungen auf das Lernen. Gemessen hat sie das nicht. Die Einzelheiten stehen auf der dritten Ebene.

Die Vertiefung zeigt die Prompts aus der Doku im Wortlaut, die Einstellungen für große Repositorys, das Rezept für Dokumentation und den Befehl /team-onboarding.

Die erste Ebene hat den Weg in vier Schritten beschrieben. Hier stehen die Prompts dazu im Wortlaut, die Einstellungen für große Repositorys und das Rezept, mit dem aus den Antworten Dokumentation wird. Die Prompts stehen auf Englisch, so wie die Doku sie abdruckt.

Der Einstieg im Wortlaut

Das erste Rezept der Doku zu Arbeitsabläufen (externe Seite, code.claude.com) beginnt im Wurzelordner des Projekts:

cd /path/to/project
claude

Dann folgen eine Frage nach dem Überblick und drei, die tiefer gehen.

give me an overview of this codebase
explain the main architecture patterns used here
what are the key data models?
how is authentication handled?

Der Startordner legt fest, welche Dateien Claude ohne weitere Freigabe lesen und bearbeiten darf, welche CLAUDE.md lädt und welche Pro­jekt­ein­stel­lungen gelten (Leitfaden für große Codebasen (externe Seite, code.claude.com)). Aus einem Unterordner erreicht Claude ohne Freigabe nur diesen Teilbaum. Für einen ersten Überblick passt also der Wurzelordner. Den Rest erklärt Kapitel 14.

Der Leitfaden mit bewährten Mustern (externe Seite, code.claude.com) gibt Beispiele für Fragen, wie man sie einem Kollegen stellen würde.

How does logging work?
How do I make a new API endpoint?
What edge cases does CustomerOnboardingFlowImpl handle?
Why does this code call foo() instead of bar() on line 333?

So genutzt sei Claude Code ein wirksamer Weg zur Einarbeitung: Man komme schneller ins Projekt, und andere Entwickler würden entlastet. Eine Zahl dazu nennt die Seite nicht.

Für die Frage, warum etwas so gebaut ist, rät derselbe Leitfaden, Claude auf die Quelle zu lenken, die sie beantworten kann. Sein Beispiel ist die Git-Historie einer Klasse.

look through ExecutionFactory’s git history and
summarize how its api came to be

Eine Nebenfrage, die nicht im Verlauf bleiben muss, stellt man mit /btw. Die Antwort geht nicht in den Verlauf ein, und der Kontext wächst nicht. Wie /btw bedient wird, steht in Kapitel 03.

Code finden und Abläufe verfolgen

Das zweite Rezept sucht den Code zu einer Funktion und verfolgt dann einen Ablauf.

find the files that handle user authentication
how do these authentication files work together?
trace the login process from front-end to database

Dazu gibt die Doku drei Hinweise. Man soll genau sagen, was man sucht, und die Begriffe des Projekts benutzen. Und man soll ein Plugin für Code Intelligence in der eigenen Sprache installieren.

Der Grund steht im Leitfaden für große Codebasen. In einer großen Codebasis kann die Suche, wo ein Symbol definiert ist oder benutzt wird, viele Lesezugriffe und grep-Aufrufe kosten. Ein solches Plugin verbindet Claude mit einem Language Server. Claude springt dann zur Definition, findet Verweise und sieht Typfehler, ohne den Baum abzusuchen. Im Terminal installiert man es für TypeScript so:

/plugin install typescript-lsp@claude-plugins-official

Zwei Bedingungen nennt der Leitfaden. Das Programm des Language Servers muss auf jedem Rechner im Team installiert sein. Der offizielle Marktplatz braucht Zugang zu GitHub. In einem abgeschotteten Netz bindet man den Marktplatz stattdessen über einen internen Git-Server oder einen lokalen Pfad ein. Das Werkzeug LSP gibt es seit Version 2.0.74 vom 19.12.2025 (Versionsliste (externe Seite, code.claude.com)). Was es sonst kann und wo es ausbleibt, steht in Kapitel 04.

Weniger lesen lassen

Was in der .gitignore steht, etwa node_modules/ oder dist/, lassen die Suchen von Claude von selbst weg. Für eingecheckten Fremdcode und erzeugte Dateien rät der Leitfaden zu Leseverboten in permissions.deny. Sie gelten für die eingebauten Dateiwerkzeuge. In der Shell gelten sie für die Dateibefehle, die Claude Code erkennt, etwa cat oder grep, wenn der gesperrte Pfad als Argument dasteht. Eine Suche mit grep -r über einen ganzen Ordner zeigt die gesperrten Dateien trotzdem. Wie solche Regeln aufgebaut sind, erklärt Kapitel 16.

Betreibt eine Organisation schon eine Codesuche oder einen RAG-Index über das Repository, kann sie ihn als MCP-Werkzeug anbieten. Claude fragt dann dort, statt die Dateien selbst zu lesen. MCP-Server erklärt Kapitel 19.

Erkunden im Subagent

Eine einzige Erkundung einer Codebasis kann laut Leitfaden Zehntausende Token verbrauchen. Die Doku zu Arbeitsabläufen gibt die Erkundung deshalb an einen Subagent ab. Ihr Beispiel, hier von Hand umbrochen:

use a subagent to investigate how our auth system
handles token refresh

Der Subagent liest die Dateien in seinem eigenen Kontextfenster und meldet nur eine Zusammenfassung zurück. Für das reine Suchen bringt Claude Code den Subagent Explore mit, der nur liest (Doku zu Subagents (externe Seite, code.claude.com)). Welches Modell er nimmt und wie gründlich er sucht, steht in Kapitel 20.

Liegen die Konventionen eines großen Baums in Plugins, fehlt beim Start in einem unbekannten Teil eine Auskunft: welches Plugin die Besitzer dieses Bereichs pflegen. Der Leitfaden schlägt dafür einen Hook beim Sitzungsstart vor. Als Beispiel nennt er ein Skript, das den Startordner liest und in einer eingecheckten Zuordnung von Pfaden zu Plugins nachschlägt. Seine Empfehlung reicht Claude in der ersten Antwort weiter. Hooks erklärt Kapitel 18.

Dokumentation erzeugen

Das Rezept für Dokumentation hat vier Schritte: undokumentierte Funktionen finden, Kommentare erzeugen, sie mit Kontext und Beispielen anreichern und gegen die Standards des Projekts prüfen.

find functions without proper JSDoc comments in the auth module
add JSDoc comments to the undocumented functions in auth.js
improve the generated documentation with more context
and examples
check if the documentation follows our project standards

Die Doku rät, den Stil zu nennen, etwa JSDoc oder Docstrings, und Beispiele zu verlangen. Und man soll Dokumentation für öffentliche APIs, Schnittstellen und verwickelte Logik ausdrücklich anfordern.

Eine Erklärung muss nicht im Code landen. Die Prompt-Sammlung der Doku (externe Seite, code.claude.com) rät, die Form der Antwort zu nennen: Format, Länge oder Publikum. Ihr Beispiel bestellt eine HTML-Seite mit Diagramm.

explain how the payment retry logic works as an HTML
page with a diagram, then open it in my browser

Für ein Glossar der Begriffe eines Projekts lässt sich derselbe Gedanke auf Deutsch formulieren, etwa so:

lege ein Glossar der Begriffe an, die nur dieses
Projekt benutzt, mit Datei und Zeile je Begriff

Datei und Zeile machen jede Erklärung nachprüfbar. Wer beim Einarbeiten selbst mitlernen will, kann den Ausgabestil Explanatory oder Learning wählen. Was die beiden tun, steht in Kapitel 03. Warum das zählen kann, zeigt die dritte Ebene.

Was in die CLAUDE.md gehört

Die gelernten Konventionen gehören nach der ersten Ebene in die CLAUDE.md. Damit die Datei mit dem Code mitgeht, nennt der Leitfaden für große Codebasen unter anderem einen Stop-Hook: Ein Skript sieht die Sitzung durch und schlägt Änderungen vor, solange die Lücke frisch ist. Einrichten und Pflege stehen in Kapitel 14.

Eine Anleitung für Neue: /team-onboarding

Seit Version 2.1.101 vom 10.04.2026 erzeugt /team-onboarding eine Anleitung für neue Kollegen (Versionsliste (externe Seite, code.claude.com)). Laut Befehlsübersicht (externe Seite, code.claude.com) wertet Claude dafür die eigenen Sitzungen, Befehle und MCP-Server der letzten 30 Tage aus. Heraus kommt eine Anleitung in Markdown, die ein Kollege als erste Nachricht einfügt, um schnell eingerichtet zu sein. Abonnenten von claude.ai in Team und Enterprise bekommen zusätzlich einen Link, den Kollegen direkt in Claude Code öffnen. Gegenstand ist also die eigene Arbeitsweise mit Claude Code. Den Code selbst erschließen die Rezepte oben.

Zwei weitere Teams

Der Bericht über die eigenen Teams (externe Seite, claude.com) beschreibt, unter welchem Druck fremder Code bei einer Störung im Betrieb gelesen wird. Wer dann über unbekannten Code nachdenken muss, verliert dabei oft Zeit. Das Product-Engineering-Team traut sich nach dem Bericht mit Claude Code an Fehler in fremden Codebasen. Es prüft den Vorschlag selbst und braucht dafür keine Hilfe anderer Teams. Dass Claude für eine Aufgabe die nötigen Dateien nennt, erspart dem Team vor einem neuen Feature das mühsame Zusammentragen des Kontexts von Hand.

Beim Infrastructure-Team liest Claude zuerst die CLAUDE.md-Dateien der Codebasis und sucht die passenden heraus. Die Projektanweisung dient dort also auch den neuen Menschen als Einstieg, vermittelt über Claude. Zahlen nennt der Bericht für diese beiden Teams nicht.

Die Zahlen dieses Kapitels stammen aus drei Ver­öf­fent­li­chungen des Herstellers: einem Bericht über die eigenen Teams, einer Auswertung von Sitzungen und einem kontrollierten Versuch. Die Doku daneben gibt Empfehlungen und misst nichts. Diese Ebene zeigt, wie jede Zahl entstand, was sie hergibt und welche Fragen keine der Quellen beantwortet.

Die Zahlen aus den Teams, nachgerechnet

Der Bericht über die eigenen Teams (externe Seite, claude.com) erschien am 24.07.2025. Er beruht auf Gesprächen mit Mitarbeitern von Anthropic. Der Hersteller beschreibt also den Einsatz seines eigenen Produkts im eigenen Haus. Eine Zahl der Befragten, einen Zeitraum oder eine Vergleichsgruppe nennt er nicht.

Die 80 Prozent gehören zum Inference-Team, genauer zu dessen Mitgliedern ohne Hintergrund im maschinellen Lernen. Sie lassen sich modellspezifische Funktionen erklären. Verglichen wird mit einer Stunde Suche bei Google, und danach dauert es 10 bis 20 Minuten. Für die Einordnung heißt das:

• Die Rechnung: 10 Minuten statt 60 sind 83 Prozent weniger, 20 Minuten statt 60 sind 67 Prozent weniger. Die genannten 80 Prozent entsprechen 12 Minuten und liegen damit am oberen Rand der eigenen Spanne.
• Der Vergleich: Verglichen wird mit der Websuche. Wie lange ein Kollege oder das Lesen des Codes gebraucht hätte, sagt die Zahl nicht.
• Die Reichweite: Es geht um Erklärungen aus einem fremden Fachgebiet. Wie lange eine neue Person braucht, bis sie im Projekt selbst etwas beiträgt, misst der Bericht nicht.

Die zweite Zahl stammt vom Security-Engineering-Team. Probleme, für die man bei einer Störung üblicherweise 10 bis 15 Minuten von Hand sucht, sind dreimal so schnell gelöst. Gerechnet sind das 3 bis 5 Minuten statt 10 bis 15, also eine Ersparnis von etwa 7 bis 10 Minuten je Problem. Auch diese Zahl meldet das Team selbst.

Der Bericht ist über ein Jahr alt, und drei Werkzeuge aus diesem Kapitel kamen erst danach. Den Subagent Explore gibt es seit Version 2.0.17 vom 15.10.2025 (Versionsliste (externe Seite, code.claude.com)). Das Werkzeug LSP für Code Intelligence kam mit 2.0.74 am 19.12.2025, der Befehl /team-onboarding mit 2.1.101 am 10.04.2026. Welches Modell die Teams damals nutzten, nennt der Bericht nicht.

Die Sitzungsstudie: 7 Prozent für das Verstehen eines Systems

Die Studie über rund 400.000 interaktive Sitzungen (externe Seite, anthropic.com) führt das Verstehen eines bestehenden Systems und das Planen einer Änderung als zwei Arbeitsweisen. Ihr Text nennt für beide zusammen 14 Prozent der Sitzungen. Ihre erste Abbildung trennt die beiden: je 7 Prozent für das Verstehen eines Systems und für das Planen einer Änderung. Ob das System dabei fremd war oder das eigene, unterscheidet die Studie nicht. Wie viel auf das Einarbeiten in fremden Code entfällt, lässt sich daraus also nicht ablesen.

Jede Sitzung hat ein Modell anhand ihres Verlaufs eingestuft. Wie die Stichprobe zustande kam und wie die Einstufung geprüft wurde, steht in Kapitel 07.

Ein Befund der Studie berührt das Einarbeiten trotzdem. Sie schätzt, wie sachkundig jemand bei genau der Aufgabe einer Sitzung auftritt, und der Beruf zählt dabei nicht. Ein erfahrener Entwickler mit seiner ersten Frage zu Rust gilt dort als Anfänger in Rust. Sitzungen, die das Modell als Anfänger einstuft, erreichen einen belegten Erfolg in 15 Prozent der Fälle, Sitzungen ab mittlerer Sachkenntnis in 28 bis 33 Prozent. Als belegter Erfolg zählt eine Sitzung, die als erfolgreich eingestuft ist und mindestens ein hartes Signal zeigt, etwa einen Commit oder bestandene Tests.

Ob die Person den Code danach verstanden hat, misst die Studie nicht. Ob ein neues Repository ebenso als fremdes Gebiet zählt wie eine neue Sprache, prüft sie auch nicht.

Der Versuch zum Lernen mit KI-Hilfe

Am 29.01.2026 hat Anthropic einen kontrollierten Versuch (externe Seite, anthropic.com) mit Entwicklern veröffentlicht, bei dem der Zufall die Gruppen einteilte. Die 52 Teilnehmer, die meisten am Anfang ihrer Laufbahn, schrieben seit über einem Jahr mindestens einmal pro Woche Python. Die Bibliothek Trio, um die es ging, kannte keiner von ihnen. Sie bauten damit zwei Funktionen und machten danach einen Test. Die eine Gruppe hatte einen KI-Assistenten in der Seitenleiste einer Online-Plattform. Er sah ihren Code und konnte auf Nachfrage jederzeit die richtige Lösung schreiben.

Die Gruppe mit KI-Hilfe war im Mittel etwa zwei Minuten schneller, und dieser Unterschied ist statistisch nicht gesichert. Im Test kam sie auf 50 Prozent, die Gruppe ohne auf 67 Prozent. Der Text der Studie nennt das 17 Prozent weniger. Gemeint sind Prozentpunkte. Gemessen am Wert der Gruppe ohne Hilfe sind es 25 Prozent. Am größten war der Abstand bei Fragen zur Fehlersuche.

Die Studie hat außerdem nach Arbeitsweisen gruppiert. Vier Teilnehmer ließen die KI den ganzen Code schreiben. Die Muster mit viel Abgabe an die KI lagen im Test im Mittel unter 40 Prozent.

Sieben Teilnehmer stellten nur Fragen zu Konzepten und lösten die Aufgabe mit dem, was sie dabei verstanden hatten. Diese Gruppe zählt zu den Mustern, die im Mittel 65 Prozent oder mehr erreichten. Die Gruppen sind klein, und einen ursächlichen Zusammenhang zwischen Arbeitsweise und Lernerfolg zieht die Studie ausdrücklich nicht. Ihre Ergebnisse nennt sie vorläufig.

Die Stichprobe nennt die Studie selbst relativ klein, und der Test folgte kurz auf die Aufgabe. Ob er das Können auf längere Sicht vorhersagt, lässt sie offen.

Der Versuch lief ohne Claude Code und mit einer einzelnen Bibliothek statt eines ganzen Repositorys. In einer Fußnote grenzt die Studie ihren Aufbau selbst von agentischen Werkzeugen wie Claude Code ab. Für solche Werkzeuge erwartet sie eher stärkere Auswirkungen auf das Lernen. Gemessen hat sie das nicht. Die Lage gleicht der beim Einarbeiten: unbekannter Code und ein Assistent, der auf Nachfrage die Lösung liefert.

Die Studie verweist auf die Lernmodi großer Anbieter, die das Verstehen fördern sollen, darunter die Modi Learning und Explanatory von Claude Code. In Claude Code sind das Ausgabestile, beschrieben in Kapitel 03. Ob sie den Abstand im Test verkleinern, hat der Versuch nicht geprüft.

Drei offene Fragen

Die Quellen dieses Kapitels lassen drei Fragen offen:

• Wie oft eine Erklärung stimmt. Keine der Quellen prüft, wie oft Claude fremden Code richtig erklärt. Der Leitfaden mit bewährten Mustern (externe Seite, code.claude.com) nennt als typischen Fehler eine plausibel aussehende Umsetzung, die Grenzfälle übergeht. Ob Erklärungen denselben Fehler haben, untersucht er nicht.
• Wie schnell jemand produktiv wird. Der Leitfaden sagt, die Einarbeitung mit Claude Code verkürze die Anlaufzeit und entlaste die Kollegen. Eine Zahl dazu gibt er nicht an.
• Wie lange erzeugte Dokumentation stimmt. Dass Dokumentation veraltet, zeigt der Beitrag ADR und Spezifikation an zwei Befunden aus dem eigenen Betrieb. Wie schnell das bei Dokumentation geht, die Claude geschrieben hat, misst keine der Quellen.

Die Sitzungsstudie benennt eine verwandte Grenze für sich selbst. Ob Code aus einer Sitzung später benutzt oder verworfen wird, kann sie nicht messen. Für eine Dokumentation gilt dasselbe: Ob jemand sie später liest und ob sie dann noch stimmt, steht in keiner der hier benutzten Erhebungen.

Einarbeiten und Lernen

Für ein Team, das neue Leute mit Claude Code einarbeitet, ergeben die Belege zusammen ein vorsichtiges Bild. Die Suche nach einer Antwort geht nach den eigenen Angaben der Teams deutlich schneller. Im Versuch schnitten im Test die besser ab, die sich Konzepte erklären ließen. Wer den Code schreiben ließ, lag darunter. Ursächlich belegt ist das nicht, und die Gruppen waren klein.

Wer das Einarbeiten auch als Lernen versteht, hat damit einen Anhaltspunkt: erklären lassen, nach Konzepten fragen und den ersten eigenen Code selbst schreiben. Wie man prüft, was ein Agent behauptet, steht in Vibe-Coding / Agentic Engineering, Kapitel 07.