Startseite / Artikel / Context Engineering für KI-Coding-Agenten: Warum größere Fenster nicht reichen

context-engineering coding-agents rag graphrag llm

Context Engineering für KI-Coding-Agenten: Warum größere Fenster nicht reichen

Warum ein Fenster mit einer Million Tokens Coding-Agenten nicht repariert und wie Token-Budgets, Repository-Graphen und mehrschichtiges Gedächtnis ihnen den richtigen Kontext liefern statt einfach mehr davon.

1022 Wörter

Größere Kontextfenster haben Coding-Agenten nicht repariert

Was KI-Coding-Assistenten bremst, ist nicht mehr die Intelligenz. Die Schwachstelle ist, wie sie Informationen über eine ganze Codebasis hinweg speichern, abrufen und verknüpfen.

Als Fenster mit einer Million Tokens kamen, klang das Versprechen sauber: Das Modell kann endlich Ihr gesamtes Repository aufnehmen. Wer schon einmal ChatGPT (Codex), Cursor, Claude Code oder Gemini (Antigravity) auf ein echtes Projekt losgelassen hat, weiß, wie das ausgeht. Bitten Sie um einen Bugfix in AuthService.ts, und das Modell vergisst einen Helper, der zwanzig Dateien entfernt liegt. Fügen Sie eine neue API-Route hinzu, und es schreibt Code gegen eine veraltete Version des Interfaces. Das Fenster ist riesig, und die Antwort ist trotzdem falsch.

Das Modell ist nicht zu klein. Der Kontext wird schlecht verwaltet.

Das Token-Budget zählt mehr als das Token-Limit

Ein Kontextfenster ist eine Obergrenze und kein Speicher, den man beliebig füllen kann. Ein mittelgroßes Produktions-Repository enthält vieles gleichzeitig:

Quellcode, verteilt auf Hunderte Dateien
Git-Diffs von laufenden Änderungen
Stacktraces und Logs
API-Dokumentation
Konfigurationsdateien
READMEs und Architekturnotizen

All das in den Prompt zu stopfen ist teuer und meist sinnlos. Vergleichen Sie es mit dem RAM in einem Betriebssystem: Ein Laptop mit 32 GB lädt nicht die ganze Festplatte in den Speicher, nur weil er es könnte.

Coding-Agenten verhalten sich genauso und verwalten ein Token-Budget. Die Frage ist nicht mehr, was hineinpasst, sondern was die Tokens verdient.

Was Vorrang bekommt

Ganz oben auf der Liste steht die Datei, die bearbeitet wird, dazu die jüngsten Git-Änderungen, die Abhängigkeiten, die sie importiert, und die Funktionen, die mit dem Fehler zu tun haben. Ganz unten landen fremde Dokumentation, alte Logs, ungenutzte Module und entlegene Ecken des Repositorys.

Zu entscheiden, was beim Modell ankommt, statt einfach das Fenster zu vergrößern, nennt man inzwischen Context Engineering.

Warum große Projekte mehr Halluzinationen erzeugen

Halluzinationen beim Programmieren sind selten zufällig. Meist hat das Modell nur einen Ausschnitt des Bildes bekommen. Nehmen Sie diese Abfolge. Zuerst wird UserService.ts geladen:

`UserService.ts` is loaded.

Dann schafft es PermissionManager.ts nie in den Kontext:

`PermissionManager.ts` is not loaded.

Und schließlich füllt das Modell die Lücke mit selbst erfundener Berechtigungslogik:

The model invents permission logic.

Aus Sicht des Modells sieht fehlende Information genauso aus wie Information, die es nicht gibt. Die Forschung zu langem Kontext fügt ein zweites Problem hinzu: Modelle tun sich schwer damit, relevante Details zu nutzen, die mitten in einem sehr langen Prompt stecken, ein Effekt namens Lost in the Middle. Größere Fenster mildern also manche Fehler, beseitigen aber keine Retrieval-Fehler.

Ein Repository als Graph denken

Dieses Denkmodell verändert, wie man das Problem angeht. Ein Repository ist kein Haufen Dateien, sondern ein Graph. Knoten sind die bedeutsamen Dinge: Dateien, Klassen, Funktionen, APIs und Datenbankmodelle. Kanten sind Beziehungen wie Imports, Funktionsaufrufe, Vererbung und Datenfluss.

Geben Sie dem Agenten nun eine Aufgabe wie "Behebe das Authentifizierungs-Timeout." Er muss keine 400 Dateien lesen. Er läuft den Graphen entlang und sammelt die Nachbarschaft rund um die Authentifizierung ein, was weit weniger kostet, als alles zu laden.

Abhängigkeiten folgen, nicht nur Schlüsselwörtern

Klassische Retrieval-Augmented Generation sucht nach Chunks, die der Anfrage semantisch nahe sind. Das hilft, aber Code trägt eine Struktur, die Prosa nicht hat. Eine bessere Pipeline läuft so:

User query -> Semantic search finds relevant functions -> Graph traversal expands connected dependencies -> Context optimizer compresses everything into the token budget

Statt isolierter Chunks bekommt der Agent also verbundenen Kontext. Das ist die Kernidee graphbasierter Suche wie Microsofts GraphRAG. Bedenken Sie, dass GraphRAG eine Forschungsarchitektur ist und niemand bestätigt hat, dass sie in kommerziellen Coding-Assistenten läuft.

Ein Chatverlauf ist kein Gedächtnis

Ein verbreiteter Irrtum hält den Gesprächsverlauf für Gedächtnis. Tatsächlich arbeiten Coding-Agenten mit drei Schichten:

Arbeitskontext: der aktuelle Prompt und die aktiven Dateien
Gleitendes Fenster: jüngste Unterhaltung und Änderungen
Retrieval-Gedächtnis: Wissen über das Repository, das bei Bedarf geholt wird

Deshalb können Cursor oder ChatGPT (Codex) eine lange Programmiersitzung durchhalten, ohne jede frühere Nachricht im Prompt mitzuschleppen. Sie holen das Relevante dann, wenn es gebraucht wird, statt das ganze Gespräch erneut abzuspielen. Die Umsetzungen unterscheiden sich je nach Produkt, aber der mehrschichtige Aufbau ist ein gängiges Muster moderner Agenten.

Wie eine Kontext-Pipeline aussieht

Die Zukunft liegt nicht in unendlichen Fenstern, sondern in besseren Pipelines. Eine Kontext-Engine könnte Folgendes tun:

Das Repository in einen AST verwandeln.
Daraus Abhängigkeits- und Aufrufgraphen bauen.
Embeddings erzeugen, damit semantische Suche funktioniert.
Bei passenden Knoten beginnen und entlang der Abhängigkeiten nach außen erweitern.
Das Ergebnis komprimieren, bevor es an das LLM geht.

Eine Breitensuche kann nahe Abhängigkeiten einsammeln, und Graph-Zentralität oder ein Ranking im Stil von PageRank kann die einflussreichsten Dateien nach oben bringen. Der Bau eines solchen Systems ist also mindestens so sehr gewöhnliches Software-Engineering wie Arbeit am Modell.

Die richtigen Tokens lesen

Das Rennen um größere Fenster ist wichtig, wird aber nicht die ganze Antwort sein. Ein Assistent wird nicht besser, weil er mehr Tokens liest, sondern weil er die richtigen im richtigen Moment liest. Das ist der Schritt vom Prompt Engineering zum Context Engineering. Und wenn Agenten Produktionssoftware bauen sollen, könnte es sich als eine der wichtigeren Architekturideen für die nächste Generation von Assistenten erweisen, Repositories als Graphen statt als riesige Textdateien zu behandeln.