ki-praxis/manuskript/kapitel-03-kontext-ist-koenig.md

3. Kontext ist König

Wenn Coding-Agents enttäuschen, liegt die Ursache erstaunlich oft nicht an „zu wenig Intelligenz“, sondern an zu schlechtem oder zu vollem Context. Das Modell generiert aus dem, was im Fenster liegt — plus Training und Tools. Prompt-Feinschliff allein ändert wenig, solange das Fenster voller gestern verworfener Designs steckt.

These 2: LLMs können nur so gute Antworten generieren, wie der Kontext es ermöglicht. Context is King.

These 3: Bei Coding-Agents beobachten wir in der Praxis oft ein U-ähnliches Muster über den Füllgrad: relativ brauchbare Performance bei niedriger bis moderater, signalstarker Füllung, spürbarer Abfall bei ungünstig wachsendem, rauschigem Context (Dumb Zone), und bei sehr hoher Füllung gelegentlich eine unzuverlässige leichte Erholung — bei deutlich höheren Inferenzkosten. Das ist eine Heuristik, keine gemessene Naturkonstante. Mehr Context ist deshalb häufig schlechter, aber nicht in jedem Setup gleich stark.

Die Füllgrad-U (Sweet Spot, Dumb Zone, Zone C) ist Praxisheuristik, kein Gesetz — was gemessen ist und was nicht: 3.12. Operativ: Füllgrad und Signal-Rausch-Verhältnis steuern, nicht pauschal mehr anhängen. Parallel verschlechtern oft drei andere Mechanismen die Nutzbarkeit: Länge, Context Rot (Session-Qualitätsverfall) und Lost-in-the-Middle (Positionsprofil).

3.1 Was „Context“ konkret ist

„Context“ klingt abstrakt, bis der Agent den dritten Fix-Versuch fährt und das Fenster voller alter Stacktraces steckt. Konkret: System- und Developer-Instructions, Skills und AGENTS.md; User- und Assistant-Turns; Tool-Calls und vor allem Tool-Results (oft die größten Brocken); Dateien, Diffs, Logs; Memory, RAG, Repo-Maps.

Was in der UI nicht sichtbar ist, kann trotzdem im Context landen — Summaries, implizite Rules, serverseitige Prefills. Was sichtbar ist, ist manchmal schon verdichtet. „Nur drei Dateien angehängt“ ist kein Beweis für ein schlankes Fenster.

Context ist Arbeitsgedächtnis, kein Archiv

Menschen lagern Wissen in Wiki, Git und Kopf aus. Das Modell hat pro Schritt ein Fenster. Was nicht im Fenster, in einem Tool-erreichbaren Zustand oder im Training liegt, existiert für die nächste Token-Entscheidung nicht.

Deshalb scheitern „gestern hast du doch …“-Erwartungen ohne Handoff oder Memory so zuverlässig. Der Chat ist Arbeitsgedächtnis, kein Wiki — und verrottet, wenn man ihn als Archiv missbraucht.

3.2 Beobachtete Muster: U-Form, Abfall, Position

y-Achse: Aufgaben-Performance (Korrektheit, Fokustreue, sinnvolle Tool-Wahl). x-Achse: relative Context-Auslastung. Das häufig beschriebene Muster ist weder glatter Abfall noch „je voller, desto schlauer“ — eher eine U-ähnliche Form, modell-, task- und sessionabhängig.

Achtung: Die U-Form ist Community-Heuristik, nicht gemessenes Gesetz. Länge, Position und Multi-Turn sind andere Mechanismen — gemessen in 3.12, nicht dieselbe Kurve.

{width=90%}

Bereich A (Zone A) — oft „Sweet Spot“ (hohes Signal, geringes Rauschen)

Viele Praktiker beschreiben hier die angenehmsten Sessions: Ziel und DoD bleiben greifbar, relevante Dateien werden eher gefunden, Änderungen wirken surgicaler, veraltete und aktuelle Fakten vermischen sich seltener. Genug Signal — Spec, Schlüsseldateien, kurze History — und vergleichsweise wenig Rauschen. Das ist der Zustand, den Teams anstreben: weder unterinformiert noch im Matsch. Was bei einem Modell und einer Retrieval-lastigen Task gut läuft, kann bei starkem Reasoning oder einem anderen Harness anders aussehen.

Bereich B (Zone B) — oft berichteter Abfall: Dumb Zone

Ab einer — je nach Setup sehr unterschiedlichen — Füllung und vor allem bei schlechtem Signal-Rausch-Verhältnis berichten viele Teams spürbare Qualitätseinbußen. Anweisungen vom Anfang wirken „vergessen“. Die DoD rutscht aus dem Fokus. Turns widersprechen sich. Der Agent greift zu falschen Dateiversionen, alten APIs oder bereits verworfenen Ansätzen. Er liest dieselben Files erneut ohne Fortschritt. „Fix“-Kaskaden blähen den Diff auf. Scope-Drift und wiederholtes Auspacken alter Entscheidungen sind typische Begleiter.

Für diesen Füllgrad- und Rausch-Abfall hat sich in der Praxis der Begriff Dumb Zone eingebürgert (manchmal salopp Dump-Zone — als würde man den Context „vollmüllen“). Die genauen Grenzen — ob eher absolute Token-Zahlen oder relative Prozente, und wann der Abfall spürbar wird — scheinen stark zu variieren zwischen Modellen, Task-Typen (Retrieval vs. Reasoning vs. Code) und sogar zwischen Sessions.

Parallel zur Füllgrad-Heuristik wirken drei gemessene Mechanismen (Messwerte: 3.12) — sie erklären Abfall, sind aber nicht die U-Kurve:

Länge kann schaden, auch ohne Müll; der Chroma-Report (2025) nennt das „Context Rot“. Context Rot meint in diesem Buch etwas anderes: den Verfall der Kontextqualität über die Sessionzeit, nicht die Token-Zählung. Gescheiterte Patches bleiben als irreführende Spuren. Zwischenstände widersprechen dem Endziel. Debug-Logs dominieren über Spec. Mehrere Teilziele vermischen sich. Ein Context kann moderat gefüllt und trotzdem verrottet sein — wenn der Inhalt Müll ist. Das ist kein Labormaß, sondern das, was Teams in langen Threads sehen. Compact aus verrottetem Material ist riskant — der saubere Exit bleibt Handoff plus neue Session (Kap. 4).

{width=90%}

Lost-in-the-Middle ist das Positions-Phänomen langer Contexts (Liu et al., TACL 2024): Information am Anfang und am Ende wird in vielen Settings besser genutzt als Information in der Mitte — ein Positionsprofil (Ränder oft stärker, Mitte schwächer), nicht dieselbe Sache wie die Füllgrad-Heuristik aus These 3. Stärke und Form hängen von Modell, Positionierung der Fakten und Task ab. Lange Sessions schieben DoD und Architekturentscheidungen gerne genau in die Mitte — während der Schwanz aus Tool-Logs prall gefüllt ist.

{width=90%}

Deshalb wichtige Fakten erneut an den Rand legen (aktueller Turn, Handoff, Compact-Erhalt, Datei im Repo), statt darauf zu vertrauen, dass „irgendwo in Turn 17“ reicht.

Multi-Turn / „sich verlaufen“: Modelle treffen früh eine Annahme und erholen sich oft nicht (3.12). Das ist Session-Dynamik, kein Token-Balken und keine Füllgrad-U.

Bereich C (Zone C) — sehr hohe Füllung (gelegentlich beschrieben, selten Ziel)

Zone C ist die schwächste und teuerste Stelle der Heuristik: gelegentlich berichtet, durch keine der Arbeiten in 3.12 gestützt, operativ kein Ziel. Hier berichten Praktiker manchmal eine leichte Erholung der Nutzbarkeit: extreme Füllung kann Harness und Modell zu anderen Mustern drängen — stärkere Nutzung der Ränder, aggressivere interne Priorisierung. Das klingt verlockend und entpuppt sich in vielen Berichten als teure Falle: unzuverlässig, task-abhängig, Kosten und Latenz steigen (siehe 3.4), und es bleibt kaum Puffer für die nächste große Observation. Viele Teams behandeln diesen Bereich deshalb eher als Notbetrieb denn als angestrebten Arbeitsmodus — ohne zu behaupten, dass jedes Setup dort gleich „scheitert“.

Orientierung, keine Schwellen-Gesetze: Manche Teams arbeiten mit einer Daumenregel für einen niedrigen bis mittleren Füllstand — kein Optimum-Gesetz. Ab mittlerer bis hoher Füllung mit Rauschen sinkt die Qualität oft (Dumb Zone). Bei sehr hoher Auslastung berichten Praktiker unzuverlässige leichte Erholung — teuer, wenig Puffer, kein Ziel. Entscheidender als der Prozentsatz: hohes Signal, geringes Rauschen, DoD an den Rändern, Compact/Handoff bevor die Session unbrauchbar wirkt.

Warum oft „U“ und nicht nur „runter“: Unterfüllung lässt das Modell aus Training raten; im Mittelbereich kippt das Signal-Rausch-Verhältnis (Dumb Zone). Länge, Position und Multi-Turn können denselben Abfall parallel erzeugen — eigene Hebel, nicht Teile der U (3.12).

Grenzen der Heuristiken

Schwellen entstehen am eigenen Stack anhand von Symptomen (3.3), nicht anhand einer heiligen Prozentzahl. Absolute Token-Zahlen variieren mit Modell, Harness-Definition von „Context“, Caching, Task und Signal-Rausch-Verhältnis. Ein halbvoller Context mit klarer DoD schlägt einen dünnen voller Debug-Müll. Was greift, gehört in Team-Notizen, nicht in Cargo-Cult — was gemessen ist: 3.12.

3.3 Symptome in der Praxis

Der Agent „spinnt“ selten ohne Vorwarnung. Meist meldet sich der Context vorher — und die Signale werden als Modell-Versagen gelesen. Typische Szene: DoD stand im ersten Prompt klar drin, und nach zwei Stunden Debug-Logs prüft niemand mehr den Exit-Code. Oder der Diff rührt plötzlich CSS an, obwohl der Task Auth hieß.

Symptom	Typische Ursache
Agent löst gestern verworfenes Design wieder aus	Alte Turns + Lost-in-the-Middle
DoD wird nicht geprüft, obwohl im ersten Prompt	DoD in der Mitte begraben
Wiederholtes Lesen derselben Datei ohne Fortschritt	Fokusverlust / Rauschen
Unrelated Files im Diff	Scope-Drift im vollen Context
„Ich habe X geändert“, aber Diff zeigt Y	Inkonsistente Selbstbeschreibung
Endloses Fixen desselben Tests mit neuen Nebenfehlern	Rot + fehlende Slice-Grenze
Plötzlich anderer Code-Stil / andere Library	Regeln überdeckt von Beispieldumps

Sobald zwei bis drei dieser Symptome zusammenkommen, lohnt Context-Reparatur (Compact, Handoff, neue Session, Repo-Hygiene) oft mehr als der nächste Clever-Prompt. Symptome schlagen den Prozentbalken. Probe: Ziel, DoD und eine harte Invariante wiederholen lassen (Kap. 4.2; Teach-back in Kap. 11).

3.4 Kosten: Warum „mehr Context“ teuer und oft dumm ist

Context kostet zweimal: auf der Rechnung und in der Qualität. Direkt skalieren Input-Tokens mit der Context-Größe — bei jedem Schritt. Lange Histories machen jeden Turn teurer. Große Tool-Results (Test-Logs, node_modules, minifiziertes JSON) sind still die Budget-Killer.

Indirekt steigt die Latenz, Supervision wird schlechter, Sessions in der Dumb Zone produzieren Nacharbeit. Das Team lernt leicht den falschen Satz: „Agent ist unzuverlässig“ — statt „wir managen Context nicht“.

Caching und trügerische Sparsamkeit

Prompt-Caching verbilligt wiederholte Prefixe. Neue Tool-Dumps kosten trotzdem; schlechte Qualität wird durch Cache nicht besser; beim rotierenden Schwanz (stetig neue Results) landet der teure Teil oft nicht im Cache. Zuerst weniger und besseren Context steuern, Caching danach als Multiplikator — inklusive dem Risiko, schlechte Prefixe zu multiplizieren.

Grobmodell, bewusst vereinfacht: eine schlanke Session (~15k Tokens pro Turn) bleibt über 20 Turns ein Bruchteil einer ungesteuert gewachsenen (~80k). Der wachsende Schwanz ist oft uncached. Ein gescheiterter 40-Turn-Thread im Abfall-Bereich kostet Geld und Nacharbeit; Handoff plus acht schlanke Turns ist häufig billiger und besser.

3.5 Mehr Dateien ≠ mehr Verständnis

Ein häufiger Reflex: „Ich hänge das ganze Modul an — zur Sicherheit.“ Irrelevante Hilfsfunktionen verdrängen die Spec; alte und neue Patterns widersprechen sich im selben Dump; die entscheidende Signatur in Zeile 800 fällt dem Lost-in-the-Middle zum Opfer; der Agent behandelt den Anhang als Wahrheit, auch wenn HEAD schon anders ist.

Was trägt: gezielte Reads im aktuellen Repo-Stand, plus kurze Spec. Was teuer wird: riesige, veraltete Snippets „zur Sicherheit“.

3.6 Context-Budget aktiv steuern

Zwei Sessions, gleicher Task, gleiches Modell. Links: DoD und drei Dateien oben, gefilterte Tests. Rechts: 40 Turns History, ungeschnittenes CI-JSON, DoD in der Mitte. Beide „fast voll“ — eine liefert, die andere halluziniert Scope. Die Figur steuert Allokation, nicht nur Füllgrad.

{width=90%}

Eine brauchbare Denkfigur ist das Budget — nicht der unbegrenzte Chat. Jeder Posten hat eine Strategie; ungesteuerte Posten füllen das Fenster trotzdem:

Budget-Posten	Häufige Strategie
Regeln / Skills	Schlank, aktuell (Kap. 12, 13)
Task-Spec	Kurz, DoD hart (Kap. 14)
History	Compact / neue Session (Kap. 4)
Tool-Results	Filtern, --quiet, relevante Ausschnitte
Repo-Wissen	Suchen statt Alles-Lesen; Maps nur wenn nützlich
Debug	Repro minimal; Logs kürzen

Die Kurve misst nicht nur Menge — Signal pro Token entscheidet.

• Guter Füllgrad: DoD, zwei bis drei Schlüsseldateien, letzter Testfehler, Entscheidungsliste.
• Schlechter Füllgrad: leere Höflichkeit, irrelevante README, halbes CI-Log ohne Spec.

Derselbe relative Füllstand, völlig andere Arbeitsfähigkeit.

3.7 Gegenstrategien (Überblick → Details in Kap. 4 und 5)

Wenn der Abfall-Bereich droht: Compact mit Hint oder Handoff + neue Session (Kap. 4); Tool-Output filtern (Kap. 5); Slice verkleinern (Kap. 8); Repo-Müll weg (Kap. 12). DoD und Verbote bei langer Session an den aktuellen Turn legen. Ops in Kap. 4, Lifecycle in Kap. 5 — hier reicht der Kompass.

3.8 Praxisbeispiel

Derselbe Agent, dieselbe DoD — zwei Context-Starts.

Task: Rate-Limit für POST /login.

Schlechter Context-Start

• ganze Auth-Monorepo-Docs
• drei alte Incident-Reports
• kompletter Nginx-Dump
• 20-Turn-Chat über JWT-Refactor von letzter Woche

Nach einer Stunde bastelt er an JWT-Claims, die gestern schon verworfen waren.

Besserer Context-Start

• Ziel und DoD klar: 5 Requests/min/IP; Tests auth/rate_limit_test.* grün; bestehende JWT-API unverändert
• Dateien gezielt: Handler, Middleware-Registry, bestehende Rate-Limit-Util falls vorhanden
• Harte Nebenbedingung: keine neue Infra, in-memory ok für Slice 1

Derselbe Agent: der zweite Start landet eher im Sweet Spot (Bereich A), der erste driftet in den Abfall (Bereich B). Der Unterschied war Budget und Signal, nicht „Intelligenz“.

3.9 Muster, die teuer werden

Sechs teure Muster kehren im Alltag wieder; jedes davon ist ein Auslöser für eine der vier Fragen aus Kap. 4.

Beobachtung	Typische Folge
Context als Dumpster für „könnte helfen“	Rot und Kosten
Session monatelang am Leben halten	begünstigt Positionsverlust (Lost-in-the-Middle)
Compact ohne Hint	Modell rät, was wichtig war
Compact erst im Notbetrieb	Zu spät; Qualität schon weg
Wichtige Regeln nur im ersten Prompt	Werden in der Mitte begraben
Dogmatische Prozent-Zielzonen	Cargo-Cult; Signal und Symptome zählen

3.10 Context-Audit in 10 Minuten

Wenn „der Agent spinnt“, liegt der Hebel selten im Modell-Wechsel — eher in rund zehn Minuten Audit:

1. Füllgrad notieren (UI oder Schätzung)
2. Top-3 Token-Fresser benennen (welches Log? welche Datei? welche History?)
3. DoD aus dem aktuellen Fenster rekonstruieren — gelingt das ohne Scrollen zu Turn 1?
4. Widersprüche suchen (alte vs. neue Entscheidung)
5. Eine Aktion wählen: Compact mit Hint, Handoff plus Reset, Slice verkleinern oder Repo-Müll entfernen

Ohne Audit endet die Runde leicht im Model-Blame-Reflex (Kap. 19).

3.11 Häufige Einwände

„Aber das Modell hat 200k Context!“
Kapazität ≠ optimale Arbeitsmenge. Ein Schreibtisch von 20 m² macht nicht produktiver, wenn er unter Papierbergen begraben ist.

„Compact verliert wichtige Details.“
Deshalb Hints und Handoff-Dateien. Details, die überleben müssen, gehören ins Repo, nicht nur in Turn 12.

3.12 Empirische Einordnung und Grenzen

Die operative Lehre bleibt: signalstark und schlank, DoD an den Rand, Compact und Handoff bevor die Session unbrauchbar wirkt. Was sich ändert, ist die Ehrlichkeit darüber, was belegt ist.

Mechanismus	Was gemessen wurde	Was das nicht ist
Position (Lost-in-the-Middle)	Liu et al., TACL 2024 — U-förmiges Positionsprofil	keine Füllgrad-Kurve, keine Agent-Session
Länge (Forschungs-„Context Rot“)	Chroma 2025 (18 Modelle); Levy et al. 2024 (0,92→0,68 bei ~3k); Du et al. 2025 (13,9–85 % trotz perfektem Retrieval)	kein Session-Müll, kein Coding-Agent-Loop
Multi-Turn / „sich verlaufen“	Laban et al., ICLR 2026 — Ø −39 % vs. Single-Turn; frühe Annahme, keine Erholung	kein Token-Balken, keine U-Kurve
Füllgrad-U, Dumb Zone, Zone C	Praxis- und Community-Muster in Agent-Workflows	keine Peer-Review-Messung dieses Buchs

Zwei Grenzen: Labor-Tasks (Needle-in-a-Haystack, gepaddete QA, simulierte Dialoge) sind nicht dein Montag-Auth-Slice — die Richtung überträgt sich, die Prozentzahlen nicht 1:1. Chroma ist ein Technical Report; Levy, Liu, Du und Laban sind peer-reviewed (Laban et al., ICLR 2026) — die Richtung (frühe Annahme, keine Erholung) trägt, die 39 % nicht als Naturkonstante. Die U-Form ist Community-Heuristik, nicht gemessenes Gesetz: die genannten Arbeiten messen Position, Länge bzw. Multi-Turn, nicht Sweet Spot, Dumb Zone oder Zone C über den Füllgrad. Zone C bleibt die schwächste und teuerste Stelle der Heuristik: gelegentlich berichtet, kein Ziel — durch keine der genannten Arbeiten gestützt.

---

Key Takeaways

• Context is King: Generationqualität ist an das Fenster gebunden.
• Die Füllgrad-U ist Heuristik. Belegt daneben: Länge, Position, Multi-Turn. Context Rot meint hier Session-Müll, nicht Tokenzahl (3.12).
• Symptome und Signal/Rauschen schlagen starre Prozentziele.
• Budget steuern; Session-Ops in Kap. 4, Lifecycle in Kap. 5.

Praktische nächste Schritte

1. Context-Auslastung im Tool eine Weile als Rohsignal mitlaufen lassen — keine heilige Zielzone.
2. Wenn der Agent „dumm wirkt“: Füllgrad, Top-Tokenfresser und Symptome aus 3.3 notieren.
3. Compaction-Hints aus Anhang A ins Repo; Compact, sobald Rauschen spürbar wird.
4. Weiter: Kapitel 4 (Session/Compact/Handoff).