Compound Context: Warum KI-Projekte besser werden, je länger Sie dranbleiben

Vor sechs Monaten nahm eine Programmieraufgabe in meinem ResumeGeni-Projekt eine ganze Sitzung voller Erklärungen in Anspruch. Der Agent musste das Datenbankschema, die Routing-Konventionen, die Template-Vererbung, die Cache-Schicht, die Deployment-Pipeline und die Testmuster verstehen, bevor er auch nur eine einzige Codezeile anfassen konnte. Jede Sitzung begann bei null.

Letzte Woche sagte ich „fix the market page performance”, und der Agent las ein Übergabedokument aus einer früheren Sitzung, identifizierte den Engpass in market_hub(), implementierte eine paginierte Datenbankabfrage mit einem aggregierten RPC, schrieb Tests und deployte. Austin ging von 14 Sekunden auf 108 Millisekunden herunter. Der Agent wurde nicht intelligenter. Das Projekt wurde reichhaltiger.

Der Unterschied liegt nicht im Modell. Der Unterschied liegt im angesammelten Kontext rund um das Projekt: die CLAUDE.md, die Konventionen beschreibt, die Memory-Dateien, die Entscheidungen festhalten, die Übergabedokumente, die Diagnosen über Sitzungsgrenzen hinweg bewahren, die Hooks, die Einschränkungen durchsetzen, die Skills, die Workflows kodifizieren, die Testsuiten, die Korrektheit verifizieren, die Captain’s Logs, die festhalten, was ausgeliefert wurde und warum. Jedes Artefakt wurde erstellt, um ein bestimmtes Problem zu lösen. Zusammen machen sie jedes nachfolgende Problem günstiger lösbar.

Das ist Context Compounding.

TL;DR

• Context Compounding ist das Phänomen, bei dem KI-gestützte Projekte sich schneller verbessern, je länger Sie daran arbeiten – denn gelöste Probleme hinterlassen wiederverwendbaren Kontext, der die Kosten für die Lösung des nächsten Problems senkt.
• Das Modell verbessert sich zwischen den Sitzungen nicht. Die Projektinfrastruktur schon: CLAUDE.md-Dateien, Memory-Systeme, Hooks, Skills, Übergabedokumente, Testabdeckung, Namenskonventionen und operative Protokolle.
• Context Compounding erklärt, warum der Start eines neuen Projekts mit einem KI-Agenten sich langsam anfühlt, die 500. Sitzung am selben Projekt dagegen schnell. Die erste Sitzung baut Kontext auf. Die 500. gibt ihn aus.
• Der Effekt tritt nicht automatisch ein. Er erfordert gezielte Investition in Kontextartefakte: Dokumente, die Entscheidungen festhalten, Hooks, die Einschränkungen kodieren, Tests, die Annahmen verifizieren, und Protokolle, die operative Geschichte bewahren.
• Organisationen, die Context Compounding verstehen, werden aufhören, Ingenieure vierteljährlich zwischen Projekten zu rotieren, und stattdessen angesammelten Projektkontext als Kapitalanlage behandeln.

Was sich kumuliert

Context Compounding wirkt über sechs Kategorien angesammelten Projektwissens. Jede Kategorie erzeugt eine andere Art von Rendite.

Konventionsdokumente (CLAUDE.md). Eine CLAUDE.md-Datei teilt jeder Agentensitzung mit, wie das Projekt funktioniert: Dateistruktur, Namenskonventionen, Import-Muster, Testansatz, Deployment-Prozess. Die erste Sitzung ohne CLAUDE.md verbringt einen Großteil ihrer Zeit damit, Konventionen zu entdecken. Die hundertste Sitzung mit einer ausgereiften CLAUDE.md verbringt damit null Zeit. Das Dokument kumuliert, weil jede einmal festgehaltene Konvention nie wieder erklärt werden muss.

Entscheidungsspeicher. Memory-Dateien halten fest, warum Entscheidungen getroffen wurden – nicht nur, was entschieden wurde. Wenn eine zukünftige Sitzung auf denselben Trade-off stößt, liest sie die Memory-Datei, anstatt die Antwort neu herzuleiten. Mein Memory-System speichert Projektentscheidungen, Benutzerpräferenzen, Feedback-Korrekturen und Referenzverweise. Jede einzelne Erinnerung ist klein. Die Sammlung insgesamt bildet einen Entscheidungs-Cache, der das Projekt daran hindert, bereits geklärte Fragen erneut zu verhandeln.

Übergabedokumente. Ein Übergabedokument bewahrt eine Diagnose über Sitzungsgrenzen hinweg. Das Übergabedokument zur Marktseiten-Performance überstand drei Code-Review-Korrekturen, zwei Prioritätsumstellungen und leitete schließlich vier Tage später die Implementierung. Ohne die Übergabe hätte die nächste Sitzung die Untersuchung von vorne begonnen – und wahrscheinlich den falschen Codepfad ins Visier genommen (wie es der erste Entwurf tat). Die Übergabe kumulierte, indem sie Diagnosezeit in ein wiederverwendbares Artefakt umwandelte.

Hooks und Einschränkungen. Jeder Hook kodiert eine Lektion aus einem vergangenen Fehler. Mein Schutz gegen destruktive API-Befehle existiert, weil ein Agent einmal den gesamten Cloudflare-Cache geleert hat. Mein Sandbox-Hook existiert, weil ein Agent versucht hat, in ~/.ssh/ zu schreiben. Mein Drift-Detektor existiert, weil Agenten in sechzig Tagen zwölfmal den Überblick über ihre Aufgabe verloren. Jeder Hook verhindert, dass dieselbe Fehlerklasse in allen zukünftigen Sitzungen erneut auftritt. Hooks kumulieren, weil sie Incident Response in permanente Prävention umwandeln.

Skills und Workflows. Ein Skill ist ein kodifizierter Workflow, den ein Agent ausführen kann, ohne den Prozess neu zu erfinden. Mein /nightcheck-Skill führt über 50 Seitenprüfungen mit TTFB-Benchmarks, Cache-Verifizierung und umfassenden Sitemap-Crawls durch. Mein /scan-intel-Skill durchsucht sechs akademische Quellen über acht Forschungsthemen mit Deduplizierung und Bewertung. Mein /blog-translator-Skill übersetzt Beiträge in neun Sprachen mit Formatbeibehaltung. Jeden Skill einmal zu erstellen war aufwendig – ihn fortan auszuführen ist kostenlos. Skills kumulieren, weil sie Prozesswissen in ausführbare Automatisierung umwandeln.

Testsuiten. Tests verifizieren, dass das Projekt nach Änderungen noch funktioniert. Eine ausgereifte Testsuite ermöglicht es einem Agenten, aggressive Änderungen mit Zuversicht vorzunehmen, weil Fehler sofort erkannt werden. Ein Projekt ohne Tests erzwingt konservative, inkrementelle Änderungen, da der Agent seine Arbeit nicht verifizieren kann. Testabdeckung kumuliert, weil jeder Test zukünftige Änderungen günstiger und sicherer macht.

Die Kumulierungskurve

Context Compounding folgt einer charakteristischen Kurve.

Sitzungen 1–10: Investitionsphase. Der Großteil des Aufwands fließt in den Aufbau von Kontext statt in die Lieferung von Features. Sie schreiben die CLAUDE.md, etablieren Konventionen, erstellen die ersten Hooks, richten das Test-Framework ein. Der Output fühlt sich langsam an, weil Sie Infrastruktur aufbauen, nicht Produkt.

Sitzungen 10–50: Beschleunigungsphase. Kontext beginnt, Wert zurückzugeben. Der Agent hört auf, nach Konventionen zu fragen, und beginnt, sie zu befolgen. Hooks fangen Fehler ab, bevor sie deployt werden. Skills automatisieren repetitive Workflows. Jede Sitzung produziert mehr Output als die vorherige, weil die Kontextbasis wächst.

Sitzungen 50–200: Kumulierungsphase. Das Projekt hat genug angesammelten Kontext, dass schwierige Probleme einfach werden. Ein Agent, der eine ausgereifte CLAUDE.md, einen Satz Memory-Dateien und ein Übergabedokument liest, kann komplexe mehrstufige Implementierungen ohne zusätzliche Anleitung ausführen. Der Fix der Marktseite geschah in dieser Phase. Ein einziger Satz („fix the market page performance”) löste einen viertägigen Prozess aus, der mit einer 132-fachen Verbesserung endete – weil die Kontextinfrastruktur die Diagnose, die Einschränkungen und die Verifizierungskriterien trug.

Sitzungen 200+: Wartungsphase. Die Rate neuer Kontexterstellung verlangsamt sich, da die meisten Konventionen, Einschränkungen und Workflows bereits erfasst sind. Der Fokus verschiebt sich auf die Aktualisierung bestehenden Kontexts (Korrektur veralteter Erinnerungen, Erweiterung von Skills, Hinzufügen von Tests für neue Randfälle) statt auf Neuerstellung. Der Kumulierungseffekt erreicht ein Plateau, bleibt jedoch hoch.

Warum das nicht offensichtlich ist

Drei Faktoren verschleiern den Kumulierungseffekt.

Modellverbesserungen überdecken Kontextverbesserungen. Wenn sich Ihre KI-Sitzungen mit der Zeit verbessern, schreiben Sie die Verbesserung besseren Modellen zu. Claude Opus 4.6 ist besser als Claude 3.5 Sonnet. Allerdings übersteigt die Verbesserung, die Sie bei einem langlebigen Projekt erleben, die reine Modellverbesserung – weil sich Context Compounding auf die Modellverbesserung aufaddiert. Der Wechsel zu einem neuen Projekt mit demselben Modell offenbart den Unterschied: Das neue Projekt fühlt sich langsam an, weil es keinen kumulierten Kontext hat.

Kontext ist unsichtbar. Eine CLAUDE.md-Datei ist ein Textdokument. Memory-Dateien sind Markdown-Notizen. Hooks sind Shell-Skripte. Keines dieser Artefakte sieht einzeln betrachtet beeindruckend aus. Der Kumulierungseffekt zeigt sich nicht in einem einzelnen Artefakt. Er zeigt sich ausschließlich im Gesamtverhalten von Sitzungen, die gegen den vollständigen Kontext-Stack operieren. Sie können auf keine einzelne Datei zeigen und sagen „deshalb ist das Projekt schnell”. Sie können lediglich die 500. Sitzung mit der 1. vergleichen und den Unterschied bemerken.

Neue Projekte zu starten fühlt sich aufregend an. Ein neues Projekt hat frische Energie und keine angesammelten Altlasten. Doch es hat auch keinen angesammelten Kontext. Die erste Sitzung an einem neuen Projekt fühlt sich produktiv an, weil sie übergeordnete Entscheidungen trifft, die wirkungsvoll erscheinen. Die 20. Sitzung an einem bestehenden Projekt fühlt sich routiniert an, weil sie innerhalb etablierter Konventionen arbeitet. Das Routinegefühl ist der Kumulierungseffekt bei der Arbeit. Das Aufregungsgefühl ist seine Abwesenheit.

Was Kumulierung verhindert

Vier Fehlermodi brechen die Kumulierungskurve.

Kontextverfall. Veraltete Erinnerungen, überholte CLAUDE.md-Abschnitte und ausgemusterte Hooks erzeugen Verwirrung statt Klarheit. Ein Agent, der veralteten Konventionen folgt, produziert schlechtere Ergebnisse als ein Agent ganz ohne Konventionen. Kontext erfordert Pflege. Mein Memory-System enthält Zeitstempel der letzten Aktualisierung und explizite Prüfungen auf Veralterung. Toter Kontext ist schlimmer als kein Kontext.

Kontextwucherung. Zu viele Dateien, zu viele Hooks, zu viele Skills erzeugen ein Auffindungsproblem. Wenn der Agent den relevanten Kontext nicht finden kann, kumuliert dieser Kontext nicht. Organisation ist entscheidend: Meine Memory-Dateien verwenden Frontmatter mit Beschreibungen, damit zukünftige Sitzungen die Relevanz beurteilen können, ohne den gesamten Inhalt zu lesen. Meine Hooks sind in einem Dispatcher registriert, der sie nach Ereignistyp lädt. Auffindbarer Kontext kumuliert. Vergrabener Kontext verfällt.

Sitzungsisolation. Wenn Sitzungen keinen persistenten Kontext lesen oder schreiben, startet jede Sitzung bei null. Der Kumulierungseffekt erfordert bewusste Brücken: Übergabedokumente, die Diagnosen über Sitzungen hinweg tragen, Memory-Schreibvorgänge, die Entscheidungen festhalten, Captain’s Logs, die operative Geschichte aufzeichnen. Ohne diese Brücken hat ein Projekt mit 500 Sitzungen denselben effektiven Kontext wie ein Projekt mit einer einzigen.

Plattformwechsel. Der Wechsel zwischen KI-Tools setzt den Kontext-Stack zurück. Eine CLAUDE.md, die für eine Plattform geschrieben wurde, hilft nicht automatisch einer anderen. Hooks, die für das Ereignismodell einer Plattform geschrieben wurden, lösen auf einer anderen nicht aus. Context Compounding ist plattformspezifisch – was einen Lock-in erzeugt, der zugleich ein Wettbewerbsvorteil ist. Je tiefer Ihr Kontext-Stack auf einer Plattform reicht, desto höher die Wechselkosten – und desto schneller verbessert sich Ihr Projekt im Vergleich zu Wettbewerbern, die ständig wechseln.

Context Compounding als Kapital

In der Finanzwelt verwandelt Zinseszins kleine Einlagen über ausreichend Zeit in große Summen. Die zentrale Erkenntnis: Die Erträge selbst generieren weitere Erträge. Context Compounding funktioniert genauso.

Eine in CLAUDE.md festgehaltene Konvention reduziert Nachfragen in jeder zukünftigen Sitzung. Die eingesparte Zeit fließt in die Lösung neuer Probleme, die neue Konventionen generieren, die wiederum zukünftige Nachfragen weiter reduzieren. Ein Hook, der eine Fehlerklasse verhindert, eliminiert in jeder zukünftigen Sitzung die erneute Untersuchung dieses Fehlers. Die eingesparte Zeit fließt in den Bau neuer Hooks für neue Fehlerklassen. Jede Investition generiert Erträge, die weitere Investitionen ermöglichen.

Die Implikation für Organisationen: Projektkontext ist eine Kapitalanlage. Ingenieure vierteljährlich zwischen Projekten zu rotieren zerstört angesammelten Kontext – genauso wie das Schließen eines Sparkontos angesammelte Zinsen vernichtet. Ein Team, das zwei Jahre lang mit KI-Unterstützung am selben Projekt bleibt, wird ein Team übertreffen, das vierteljährlich rotiert – nicht weil die Einzelnen besser sind, sondern weil sich der Kontext kumuliert hat.

Die Implikation für einzelne Ingenieure: Ihre KI-Infrastruktur ist ein Investmentportfolio. Jeder CLAUDE.md-Abschnitt, jede Memory-Datei, jeder Hook, jeder Skill, jedes Übergabedokument ist eine Einlage. Das Portfolio wächst anfangs langsam. Nach Hunderten von Sitzungen generiert es Erträge, die schwierige Probleme für Außenstehende leicht aussehen lassen – Außenstehende, die den Kontext-Stack darunter nicht sehen.

Die Marktseite ging von 14 Sekunden auf 108 Millisekunden herunter. Ein Beobachter sieht einen Performance-Fix. Ich sehe ein Übergabedokument, das drei Überarbeitungen überstanden hat, ein Nightcheck-System, das die Regression gemessen hat, einen Schutz gegen destruktive Befehle, der eine Wiederholung des Cache-Purge verhinderte, einen Code-Review-Skill, der das falsche anfängliche Ziel erkannte, und fünfhundert Sitzungen angesammelten Kontexts, die das Ganze erst möglich gemacht haben.

Das ist Compound Context.

FAQ

Was ist Context Compounding?

Context Compounding ist das Phänomen, bei dem KI-gestützte Projekte sich mit der Zeit schneller verbessern, weil gelöste Probleme wiederverwendbaren Kontext (Dokumente, Hooks, Skills, Tests, Erinnerungen) hinterlassen, der die Kosten für die Lösung nachfolgender Probleme senkt. Der Begriff ist analog zum Zinseszins: Die Erträge selbst generieren weitere Erträge.

Funktioniert das mit jedem KI-Tool?

Das Prinzip gilt grundsätzlich, die Umsetzung hängt jedoch von der Unterstützung des Tools für persistenten Kontext ab. Claude Code unterstützt CLAUDE.md-Dateien, Hooks, Skills und Memory-Systeme nativ. Andere Tools erfordern möglicherweise externe Gerüste, um denselben Effekt zu erzielen. Die Kumulierungskurve ist steiler auf Plattformen, die mehr Mechanismen zur Kontextpersistenz bieten.

Wie beginne ich mit dem Aufbau von Compound Context?

Beginnen Sie mit einer CLAUDE.md, die Ihre Projektkonventionen beschreibt. Fügen Sie Memory-Dateien für wichtige Entscheidungen hinzu. Schreiben Sie Hooks für Fehlermuster, die Sie erlebt haben. Erstellen Sie Skills für Workflows, die Sie sitzungsübergreifend wiederholen. Die Investition fühlt sich anfangs langsam an. Die Erträge zeigen sich nach 10–20 Sitzungen.

Ist das nicht einfach Dokumentation?

Nein. Dokumentation ist eine Komponente, doch Context Compounding umfasst auch ausführbare Artefakte: Hooks, die Einschränkungen zur Laufzeit durchsetzen, Skills, die Workflows automatisieren, Testsuiten, die Korrektheit verifizieren, und Memory-Systeme, die Entscheidungsfindung unterstützen. Statische Dokumentation erklärt. Compound Context handelt.

Was ist mit Kontextfensterbeschränkungen?

Context Compounding erfordert nicht, dass der gesamte Kontext in jede Sitzung geladen wird. Es erfordert, dass der richtige Kontext bei Bedarf verfügbar ist. Eine CLAUDE.md wird automatisch geladen. Memory-Dateien werden nach Relevanz abgefragt. Übergabedokumente werden gelesen, wenn eine bestimmte Aufgabe fortgesetzt wird. Der Kontext-Stack ist größer als jedes einzelne Kontextfenster. Der Agent greift pro Sitzung auf den relevanten Ausschnitt zu.

Wie erkenne ich, ob mein Projekt Compound Context hat?

Vergleichen Sie den Aufwand für ähnliche Aufgaben am Anfang und später in der Projektgeschichte. Wenn eine Aufgabe, die im ersten Monat eine ganze Sitzung brauchte, im sechsten Monat mit einem einzigen Prompt erledigt ist, wirkt Compound Context. Ist der Aufwand gleich geblieben, wird Kontext entweder nicht angesammelt oder nicht zwischen Sitzungen persistiert.

Quellen

Dieser Artikel basiert auf Produktionserfahrung aus über 500 autonomen Coding-Sitzungen über sechs Projekte seit Mai 2025. Spezifisch referenzierte Beispiele:

• Marktseiten-Performance: Übergabedokument, Nightcheck-Verifizierung und Deployment beschrieben in Captain’s Logs vom 21.–25. März 2026
• Schutz gegen destruktive API-Befehle: erstellt nachdem ein Agent den gesamten Cloudflare-Cache geleert hatte, beschrieben im Beitrag deploy-and-defend
• Hook- und Skill-Infrastruktur: 84 Hooks, die 15 Ereignistypen abfangen, beschrieben im NIST-Kommentar
• Drift-Erkennung: Kosinus-Ähnlichkeitsverfolgung über mehr als 60 Sitzungen, beschrieben in The Invisible Agent
• Autoresearch-Schleifen: Budget-begrenzte Experimente auf Apple Silicon, validiert durch das Claudini-Paper
• Anthropic-Dokumentation zu Claude Code-Memory und Projektanweisungen: Manage Claude’s memory
• Andrej Karpathys Autoresearch-Repository: autoresearch