Nur 2 % KI: Wie Claude Code wirklich funktioniert

Wer Claude Code zum ersten Mal benutzt, sieht eine schlichte Eingabezeile im Terminal. Man tippt eine Anweisung – „finde den Bug im Login-Flow" – und ein paar Sekunden später passieren Dinge: Dateien werden gelesen, Tests laufen, Code ändert sich. Von außen sieht es aus wie Magie, ausgegossen aus einem großen Sprachmodell.

Tatsächlich ist das Sprachmodell der kleinste Teil der Geschichte.

Was unter der Motorhaube wirklich passiert

Im Frühjahr 2026 wurde der gesamte Quellcode von Anthropics CLI-Tool versehentlich öffentlich. Über eine halbe Million Zeilen Code, 1.900 Dateien, 40 Werkzeuge, Multi-Agent-Orchestrierung, ein eigenes Gedächtnissystem. Die spannendste Zahl, die seitdem durch Analyse-Threads geht: Ungefähr 2 % des Codes treffen tatsächlich KI-Entscheidungen. Die anderen 98 % sind klassische, deterministische Software – Routing, Berechtigungen, Fehlerbehandlung, Speicherverwaltung, Sicherheitsprüfungen.

Das ist die zentrale Lektion, und sie steht im Gegensatz zu dem, was viele Unternehmen aktuell tun, wenn sie „KI integrieren": Sie verlieben sich in das Modell und unterschätzen alles drumherum.

Der Kreislauf: Kontext, Aktion, Prüfung

Im Kern arbeitet Claude Code in einer Schleife mit drei Phasen:

1. Kontext sammeln. Welche Dateien sind relevant? Was steht im Git-Log? Welche Konventionen gelten in diesem Projekt? (In unserem Repo zum Beispiel: „Nutze die API, nicht die Datenbank, wenn der User einen Artikel anlegen will" – steht in einer Datei namens CLAUDE.md, die immer mitgeladen wird.)
2. Aktion ausführen. Das Modell schlägt eine konkrete Operation vor – „lies Datei X", „führe Befehl Y aus", „schreibe in Datei Z". Bevor diese Operation passiert, wird sie durch ein Berechtigungssystem gefiltert.
3. Ergebnis prüfen. Funktionierte es? Gibt es Fehler? Was sagen die Tests? Das Resultat fließt zurück in den Kontext, und der nächste Schritt wird daraus abgeleitet.

Diese Schleife ist banal in der Beschreibung und der eigentliche Knackpunkt in der Umsetzung. Sie muss robust laufen, ohne sich im Kreis zu drehen, ohne den Speicher zu sprengen, ohne den Nutzer mit Berechtigungsfragen zu bombardieren – und ohne stillschweigend Unsinn anzurichten.

Werkzeuge: der Unterschied zwischen Reden und Handeln

Ein reines Sprachmodell kann nur Text produzieren. Was Claude Code agentisch macht, sind seine Werkzeuge – etwa 40 davon, in fünf Kategorien:

• Datei-Operationen (lesen, schreiben, umbenennen)
• Suche (Pattern-Matching, Inhaltssuche)
• Ausführung (Shell-Befehle, Tests, Builds, Git)
• Web (Suche, Dokumentation abrufen)
• Code-Intelligenz (Typfehler, Definitionen finden)

Jedes Werkzeug hat eine Berechtigungsstufe – grob: harmlos, vorsichtig, gefährlich. Eine Datei lesen ist harmlos. Eine Datei schreiben löst eine Rückfrage aus. Ein rm -rf braucht eine sehr explizite Erlaubnis. Diese Schichten sind kein KI-Feature, sondern stinknormale Software-Architektur. Aber sie sind der Grund, warum man dem System überhaupt vertrauen kann.

Mehrere Agenten gleichzeitig

Für komplexere Aufgaben startet das Hauptsystem Sub-Agenten – kleine isolierte Claude-Instanzen mit eigenem Kontextfenster und enger Aufgabenstellung („durchsuche dieses Verzeichnis und finde alle Stellen, wo X passiert"). Sie laufen parallel, arbeiten unabhängig, geben am Ende eine Zusammenfassung zurück und verschwinden wieder. Der Hauptkontext bleibt aufgeräumt.

Das ist das Software-Äquivalent zu einer guten Projektleiterin: nicht alles selbst lesen, sondern delegieren – und nur die destillierten Erkenntnisse einsammeln.

Das Vergessen-Problem

Sprachmodelle haben ein begrenztes „Kurzzeitgedächtnis" (das Kontextfenster). Bei langen Sessions läuft es voll, und ältere Inhalte fallen heraus. Claude Code verwaltet das mit mehreren Schichten:

• Kompaktion – ältere Werkzeug-Ausgaben werden automatisch zusammengefasst.
• Persistente Notizen in Dateien wie CLAUDE.md oder MEMORY.md, die in jeder neuen Session wieder eingelesen werden.
• Skills, die nur dann in den Kontext geladen werden, wenn sie tatsächlich gebraucht werden.
• Sub-Agenten als Wegwerf-Kontextinseln (siehe oben).

All das sind Engineering-Entscheidungen, keine Modell-Fähigkeiten. Das Modell selbst „weiß" nichts über Kompaktion. Es bekommt nur jeweils das vorgesetzt, was die umgebende Maschinerie für relevant hält.

Die eigentliche Lehre

Wenn man die Architektur ehrlich anschaut, ist Claude Code im Grunde ein klassisches Software-Produkt mit einem sehr fähigen, aber austauschbaren Reasoning-Modul in der Mitte. Genau das ist die spannende Erkenntnis für alle, die KI in eigene Produkte einbauen wollen:

• Das Modell ist Commodity. Es wird besser, schneller, billiger – das ist gut, aber es ist nicht das Differenzierungsmerkmal.
• Der Wert liegt in der Hülle: Wie sammelt man relevanten Kontext? Wie verhindert man, dass das Modell Schaden anrichtet? Wie macht man Fehler nachvollziehbar? Wie bringt man Ergebnisse zurück in bestehende Prozesse? Wie speichert man Lernprozesse über Sessions hinweg?
• Berechtigungen, Audit-Trails, Rollback – die langweiligen Themen aus klassischer Software-Entwicklung – werden bei KI-Produkten plötzlich wieder zentral. Ein Agent, der Shell-Zugriff hat, ist kein Chatbot. Er ist ein Stück Infrastruktur.

Anders gesagt: Wer ein KI-Produkt baut, baut zu 90 % ein normales Software-Produkt. Die Modellanbindung ist eine Abhängigkeit wie eine Datenbank oder eine Payment-API – wichtig, aber austauschbar. Die Konkurrenzfähigkeit entsteht nicht im Prompt, sondern im System drumherum.

Was wir daraus für unsere Projekte mitnehmen

Drei Dinge, die wir uns selbst notiert haben:

1. Beim KI-Feature zuerst die Drumherum-Architektur entwerfen. Welche Aktionen darf das System auslösen? Welche braucht eine Bestätigung? Was ist im Zweifel revidierbar? Diese Fragen kommen vor der Frage, welches Modell man nimmt.
2. Kontext ist Engineering-Arbeit, kein Prompt-Trick. Welcher Code, welche Dokumente, welche Konventionen müssen mitgeliefert werden? Das ist eine Datenfrage, keine Modellfrage.
3. Beobachten, was rausgeht – nicht nur was reinkommt. Ein KI-Agent, der eigenständig handelt, braucht das gleiche Maß an Logging, Monitoring und Rollback wie jedes andere produktive System. Vielleicht mehr.

Das ist die unsexy Hälfte der KI-Integration. Aber sie macht den Unterschied zwischen einem beeindruckenden Demo und einem System, das man tatsächlich in den Alltag lassen kann.