Der Agent wurde nicht schlauer — das Projekt schon

Vor sechs Monaten erforderte eine Coding-Aufgabe eine ganze Session voller Erklärungen. Letzte Woche brauchte dieselbe Art von Aufgabe nur einen Satz. Zwischen diesen beiden Sessions hat sich das Modell nicht verändert. Claude Opus 4.6 diente in beiden Fällen. Dieselben Gewichte, dieselbe Architektur, dasselbe Kontextfenster, dieselben Fähigkeiten.

Der KI-Agent ist zwischen Session 1 und Session 500 nicht schlauer geworden; die Projektinfrastruktur hat sich verändert. Das ist die zentrale These des Gebiets AI Engineering: Das Modell ist eine Konstante, und die Variable ist alles, was Sie darum herum aufbauen. Bei langlaufenden Projekten trägt das Modell rund 30 % zur Session-Qualität bei, während der akkumulierte Kontext die übrigen 70 % liefert: Konventionsdokumente, Entscheidungsmemorien, Übergabeartefakte, Hooks, Skills und Testabdeckung. Ein schwächeres Modell auf einem reichen Projekt schlägt oft ein besseres Modell auf einem kargen.

Das Projekt hat sich verändert.

Die falsche Diskussion

Die Diskussion über KI-Produktivität dreht sich fast ausschließlich um Modellfähigkeiten. Welches Modell ist am schnellsten. Welches Modell schreibt den besten Code. Welches Modell bewältigt den längsten Kontext. Die implizite Annahme lautet: Das Modell ist die Variable — Modell upgraden, Output verbessern.

Für langlaufende Projekte ist diese Annahme falsch. Auf einem Projekt, an dem ich seit sechs Monaten mit über 500 Agent-Sessions arbeite, trägt das Modell vielleicht 30 % zur Session-Qualität bei. Die übrigen 70 % stammen aus der akkumulierten Projektinfrastruktur: Konventionsdokumente, Entscheidungsmemorien, Übergabeartefakte, Verhaltens-Hooks, kodifizierte Skills und Testabdeckung.

Ein besseres Modell auf einem kargen Projekt liefert bessere Ergebnisse als ein schwächeres Modell auf einem kargen Projekt. Ein schwächeres Modell auf einem Projekt mit 500 Sessions akkumulierten Kontexts liefert oft bessere Ergebnisse als ein besseres Modell auf einem kargen Projekt. Die Infrastruktur dominiert das Modell. Genau deshalb ist Kontext Architektur — das akkumulierte Projektwissen ist keine ergänzende Information, sondern tragende Struktur.

Evidenz

Der Performance-Fix der Market-Seite illustriert den Punkt. Ein Satz: „fix the market page performance.” Der Agent:

Las ein Handoff-Dokument aus einer vorherigen Session, das den Engpass diagnostizierte
Identifizierte den korrekten Code-Pfad (market_hub(), nicht _fetch_market_data())
Implementierte eine paginierte Datenbankabfrage mit einer aggregierten RPC
Schrieb Tests
Deployte

Austin ging von 14 Sekunden auf 108 Millisekunden zurück. Eine 132-fache Verbesserung aus einem einzigen Prompt.¹

Das geschah nicht, weil das Modell schlau ist. Es geschah, weil das Handoff-Dokument existierte. Das Handoff hielt eine Diagnose fest, die drei Code-Review-Korrekturen und zwei Prioritätsumordnungen über vier Tage hinweg überlebte. Ohne das Handoff hätte der Agent bei Null angefangen. Er hätte den falschen Code-Pfad untersucht (wie es der erste Entwurf des Handoffs tat). Er hätte unnötige HTMX-Partials vorgeschlagen (wie es der ursprüngliche Plan tat). Das Handoff enthielt die bereits gemachten und korrigierten Fehler. Der Agent erbte das korrigierte Verständnis.

Der Beitrag des Modells bestand darin, das Handoff zu lesen und den Fix umzusetzen. Der Beitrag der Infrastruktur bestand darin, das richtige Handoff zum Lesen bereitzuhalten.

Was sich verändert und was nicht

Zwischen Session 1 und Session 500 im selben Projekt bleibt genau eine Sache konstant: das Modell. Alles andere verändert sich.

Was sich verändert:

Die CLAUDE.md wächst von leer zu vollständig. Fragen zu Konventionen verschwinden. Der Beitrag AGENTS.md Patterns beschreibt die konkreten Muster, die diese Dateien wirksam machen.
Memory-Dateien akkumulieren. Entscheidungen werden zwischengespeichert. Trade-offs werden festgehalten. Das Projekt hört auf, bereits geklärte Fragen neu zu verhandeln.
Hooks akkumulieren. Jeder einzelne verhindert eine Fehlerklasse, die in einer früheren Session auftrat. 84 Hooks, die 15 der 26 Lifecycle-Event-Typen abfangen, die Claude Code bereitstellt, jeder einzelne eine Narbe aus einem vergangenen Vorfall.
Skills akkumulieren. Repetitive Workflows werden zu Ein-Befehl-Operationen. Der Nightcheck, dessen Entwurf eine ganze Session verschlang, läuft heute in 2 Minuten.
Tests akkumulieren. Der Agent wagt mutigere Änderungen, weil er sie sofort verifizieren kann.
Handoff-Dokumente akkumulieren. Komplexe Untersuchungen bleiben über Session-Grenzen hinweg bestehen.

Was gleich bleibt:

Das Modell. Dieselben Gewichte. Dieselben Fähigkeiten. Dieselbe Neigung, vom Thema abzudriften, Testergebnisse phantom zu verifizieren (siehe The Evidence Gate) und unnötige Abstraktionen vorzuschlagen.

Die Fehlermuster des Modells sind konstant. Die Fähigkeit der Infrastruktur, diese Fehlermuster abzufangen, wächst mit jeder Session. Session 500 ist besser als Session 1 — nicht weil sich das Modell verbessert hat, sondern weil die Infrastruktur gelernt hat, die konstanten Schwächen des Modells zu kompensieren.

Das Investitionsbild

Wenn das Modell nicht die Variable ist, dann ist die Modellwahl nicht die primäre Investitionsentscheidung. Die primäre Investition gilt der Kontextinfrastruktur.

Ein Team, das 200 $/Monat für Claude Max (das standardmäßig Opus 4.7 ausführt) ausgibt und massiv in CLAUDE.md-Dateien, Memory-Systeme, Hooks, Skills und Testabdeckung investiert, wird ein Team übertreffen, das 200 $/Monat für denselben Plan ohne Infrastrukturinvestition ausgibt. Die Modellkosten sind identisch. Die Output-Qualität divergiert, weil die Infrastruktur divergiert.

Das formt die Produktivitätsfrage um. Die Frage lautet nicht mehr „welches Modell sollen wir verwenden?” Die Frage lautet: „Was haben wir um das Modell herum aufgebaut, das jede Session besser als die letzte macht?”

Die Organisationen, die ich mit KI-Produktivität ringen sehe, verwenden nicht das falsche Modell. Sie beginnen jede Session bei Null. Kein Konventionsdokument. Kein Memory-System. Keine Hooks. Keine Skills. Kein akkumulierter Kontext. Jede Session ist Session 1, unabhängig davon, wie viele Sessions vorausgingen.

Das Modell wird sich verbessern

Modelle werden sich weiter verbessern. Claude Opus 4.7 war besser als Claude Opus 4.6, Opus 5 wird noch besser sein. Die Verbesserung ist real und wertvoll. Aber sie ist additiv, nicht multiplikativ.

Ein Modell, das 20 % besser in der Code-Generierung ist, liefert 20 % bessere Ergebnisse auf einem kargen Projekt. Dasselbe Modell mit 500 Sessions akkumulierten Kontexts liefert Ergebnisse, die qualitativ anders sind, nicht nur quantitativ besser. Die Kontextinfrastruktur fügt den Fähigkeiten des Modells keine 20 % hinzu. Sie liefert die Diagnose, die Einschränkungen, die Verifikationskriterien und die Betriebsgeschichte, die das Modell aus sich selbst heraus nicht produzieren kann, egal wie leistungsfähig es ist.

Kein Modell, wie leistungsfähig auch immer, kann wissen, dass market_hub() sämtliche company_markets-Zeilen lädt und in Python paginiert, solange ihm das niemand sagt. Das Handoff-Dokument sagt es ihm. Das Modell liest und handelt. Die Intelligenz verteilt sich zwischen dem Modell (Lesen, Schlussfolgern, Implementieren) und der Infrastruktur (Wissen, Einschränken, Verifizieren).

Session 500

Session 500 sieht so aus: Ich formuliere in einem Satz, was ich möchte. Die Ralph Agent Architecture ist das System, das dies ermöglicht. Der Agent liest die CLAUDE.md und kennt die Konventionen. Er liest die Memory-Dateien und kennt die Entscheidungen. Er liest das Handoff und kennt die Diagnose. Er läuft in einen Hook, der denselben Fehler verhindert, den ein anderer Agent vor drei Monaten gemacht hat. Er prüft seine Arbeit gegen die Test-Suite. Er berichtet über die Fertigstellung mit Evidenz für jede Behauptung.

Session 1 sieht so aus: Ich erkläre das Datenbankschema, die Routing-Konventionen, die Template-Vererbung, die Cache-Schicht, die Deployment-Pipeline und die Testing-Patterns. Der Agent stellt klärende Rückfragen. Er schlägt einen Ansatz vor, der drei Konventionen verletzt. Ich korrigiere ihn. Er implementiert den Fix. Er meldet „tests pass”, ohne pytest ausgeführt zu haben.

Das Modell ist in beiden Sessions dasselbe. Das Projekt nicht.

FAQ

Spielt die Modellqualität nicht trotzdem eine Rolle?

Doch. Ein stärkeres Modell liest Kontext wirksamer, argumentiert genauer über Trade-offs und implementiert Lösungen sauberer. Die Modellqualität legt den Boden fest. Die Infrastruktur hebt die Decke. Auf einem reifen Projekt zählt die Decke mehr als der Boden.

Ist das spezifisch für Coding-Agenten?

Nein. Jeder KI-Workflow, in dem dieselbe Aufgabendomäne über Sessions hinweg wiederkehrt, profitiert von akkumuliertem Kontext. Schreiben, Recherche, Analyse, Kundensupport. Die konkrete Infrastruktur unterscheidet sich (Styleguides statt CLAUDE.md, Knowledge Bases statt Hooks), aber die Dynamik bleibt dieselbe: Das Projekt wird besser, weil der Kontext um das Modell herum akkumuliert.

Was ist mit multimodalen Modellen oder Reasoning-Modellen?

Dasselbe Prinzip. Ein Reasoning-Modell, das 10 Minuten über ein Problem nachdenken kann, muss trotzdem wissen, über welches Problem es nachdenken soll. Das Handoff-Dokument, die Konventionsdatei und das Memory-System liefern die Problemdefinition. Das Modell liefert das Reasoning. Besseres Reasoning über ein gut definiertes Problem liefert bessere Ergebnisse als schwächeres Reasoning, aber besseres Reasoning über ein undefiniertes Problem liefert besser klingende Verwirrung.

Wie fange ich an, wenn ich keinerlei Kontextinfrastruktur habe?

Schreiben Sie eine CLAUDE.md-Datei, die Ihre Projektkonventionen beschreibt. Diese eine Datei ist die Investition mit dem höchsten Hebel. Alles andere wächst von dort aus zusammen.²

Quellen

Blake Crosley, „Compound Context: Why AI Projects Get Better the Longer You Stay With Them,” blakecrosley.com, März 2026. ↩
Anthropic, „Manage Claude’s memory,” Anthropic Documentation, 2026. ↩