Kontext ist alles

Vor zwei Jahren habe ich angefangen, ernsthaft mit Coding-Agenten zu arbeiten, als Hauptwerkzeug in der täglichen Arbeit und nicht bloß zum Ausprobieren oder für Demos. Seitdem habe ich jede Generation dieser Werkzeuge begleitet: von den frühen Copilot-Versionen über Cursor bis zu Claude Code, OpenAI Codex und dem GitHub Copilot Coding Agent. Dabei habe ich jedes neue Release, jedes neue Modell und jede neue Architektur mitgenommen.

Eine Erkenntnis hat mich dabei am meisten Zeit und Nerven gekostet, bis ich sie akzeptiert habe: Das Modell ist selten das Problem. Meistens ist es der Kontext.

Was „Kontext" wirklich bedeutet

In der Welt der Sprachmodelle wird „Kontext" oft mit „Context Window" gleichgesetzt, der Anzahl der Tokens, die ein Modell gleichzeitig verarbeiten kann. 128k, 200k, bald eine Million. Die Zahlen wachsen, aber das Problem bleibt.

Denn Kontext ist nicht nur das, was das Modell sehen kann, sondern vor allem das, was es beachten soll. Das sind zwei verschiedene Dinge.

Ein aktuelles Paper von Distyl AI („How Many Instructions Can LLMs Follow at Once?") hat genau das untersucht. Das Forschungsteam gab 20 verschiedenen Modellen Aufgaben mit steigender Anzahl gleichzeitiger Anweisungen: von 10 bis 500. Die Ergebnisse haben mir endlich eine Erklärung geliefert für etwas, das ich seit zwei Jahren beobachte, aber nie sauber benennen konnte:

Selbst das beste getestete Modell (Gemini 2.5 Pro) erreichte bei 500 Anweisungen nur 69% Genauigkeit. Die Anweisungen passen problemlos ins Context Window. Das Modell sieht sie alle, befolgt aber nicht alle.

Zugegeben, der Benchmark ist vereinfacht. Keywords in einen Text einbauen ist etwas anderes als Architekturregeln in einer Codebase zu beachten. Aber das Prinzip überträgt sich: Wer einem Agenten eine Anweisungsdatei (CLAUDE.md, AGENTS.md oder ein vergleichbares Format) mit 30 Projektregeln gibt, dazu 15 Dateien als Kontext und eine komplexe Aufgabenbeschreibung, schickt hunderte implizite Constraints in eine Interaktion. Lesen kann das Modell sie alle. Die Frage ist, ob es sie alle gleichzeitig beachtet.

Drei Arten zu vergessen

Das Paper identifiziert drei Muster, wie Modelle unter steigender Anweisungslast degradieren. Wer regelmäßig mit Agenten arbeitet, wird sie alle wiedererkennen.

Threshold-Decay: Das Modell funktioniert fast perfekt bis zu einer gewissen Schwelle, dann bricht die Leistung abrupt ein. Reasoning-Modelle wie o3 oder Gemini 2.5 Pro zeigen dieses Muster. In der Praxis war das für mich der frustrierendste Fall: Der Agent arbeitet hervorragend durch die ersten 15 Aufgaben. Bei Aufgabe 16 vergisst er plötzlich die Architekturvorgaben aus der Anweisungsdatei. Man hat das Gefühl, einen zuverlässigen Kollegen zu verlieren, der auf einmal Dinge tut, die man nicht besprochen hat.

Linear-Decay: Stetige, gleichmäßige Verschlechterung mit jeder zusätzlichen Anweisung. Claude 3.7 Sonnet und GPT-4.1 verhalten sich so. Für mich war das lange das tückischste, weil ich es nicht bemerkt habe. Die Qualität erodiert, wie ein Gespräch, das langsam das Thema verliert, ohne dass jemand den Moment benennen kann, an dem es passierte.

Exponential-Decay: Rapider Zusammenbruch schon bei moderater Anweisungsdichte. Betroffen sind kleinere Modelle wie Llama 4 Scout oder Claude 3.5 Haiku. Brauchbar für einfache, fokussierte Aufgaben, aber nicht für komplexe Projekte.

Was mich am meisten beschäftigt hat: Der dominante Fehlertyp bei hoher Anweisungsdichte ist Omission. Das Modell lässt Anweisungen einfach weg, wortlos und ohne Hinweis. Es halluziniert dabei nichts Falsches, es übergeht sie. Wer das kennt, weiß, wie es sich anfühlt: Man reviewt den Code, alles sieht sauber aus, und erst beim dritten Hinschauen fällt auf, dass die Fehlerbehandlung fehlt, die man explizit angewiesen hat.

Zwei Jahre Evolution

Warum die aktuelle Generation so viel besser ist, zeigt erst der Vergleich mit den Anfängen. Dann sieht man auch, welche Probleme gelöst sind und welche nur verschoben.

2024: Die Ära des manuellen Kontextmanagements

Vor zwei Jahren sah ein typischer Workflow so aus: Man öffnete einen Chat, fütterte das Modell mit Codeausschnitten, erklärte den Kontext in Prosa, formulierte die Aufgabe, hoffte auf das Beste. Bei jeder neuen Nachricht musste man den Kontext mitschleppen oder riskieren, dass das Modell ihn vergisst.

Cursor war ein früher Durchbruch, weil es den Editor-Kontext automatisch einbezog. Man musste dem Modell nicht mehr erklären, in welcher Datei man war. Aber die Architektur-Ebene musste man bei jeder Session neu etablieren: warum der Code so strukturiert ist, welche Patterns gelten, was die Projektkonventionen sind.

Das Ergebnis: Man wurde zum Kontext-Manager. Die Hälfte der Arbeitszeit ging dafür drauf, den Kontext aufrechtzuerhalten, und fehlte für die eigentliche Aufgabe. Prompt-Engineering war im Kern Kontextmanagement, und es war anstrengend.

2025–26: Kontext als Architektur-Feature

Die aktuelle Generation hat verstanden, dass Kontextmanagement ein Architekturproblem ist und kein Nutzerproblem. Jedes Tool löst es auf eigene Weise.

Allen aktuellen CLI-Agenten gemeinsam ist das Konzept einer persistenten Anweisungsdatei im Projekt-Root: CLAUDE.md bei Claude Code, AGENTS.md bei OpenAI Codex und Copilot CLI, bei Cursor .cursorrules. Der Agent lädt die Datei bei jeder Interaktion automatisch. Sie enthält Projektregeln, Konventionen, Patterns, technische Entscheidungen, alles, was der Agent über das Projekt wissen muss.

Claude Code geht noch einen Schritt weiter mit einem Memory-System: Der Agent kann sich Dinge merken, die über Sessions hinweg gelten. „Verwende immer bun statt npm." „Das Projekt nutzt Vitest, nicht Jest." „Die API-Authentifizierung läuft über JWT mit RS256." Was man einmal gesagt hat, bleibt dauerhaft gespeichert.

Dazu kommt bei Claude Code der Plan Mode. Bevor der Agent Code schreibt, erstellt er einen Plan, den der Mensch absegnen muss. In der Praxis hat das meinen Workflow verändert: Es zwingt den Agenten, seinen Kontext explizit zu machen. Man sieht, was er verstanden hat und was nicht, und kann korrigieren, bevor eine Zeile Code entsteht. Dieses „Moment mal, das habe ich anders gemeint" kommt so vor der Implementierung. Das spart Zeit und verhindert den Frust, fertigen Code wieder einreißen zu müssen.

Andere Tools experimentieren mit einem Ansatz, den ich für besonders vielversprechend halte: strukturierte Aufgabenverwaltung direkt im Agenten. Die Aufgaben wandern aus dem Fließtext des Chats in eine lokale Datenbank, mit Status, Abhängigkeiten und Fortschritt. Der Agent kann abfragen, was er schon erledigt hat, was noch offen ist, was blockiert ist. Aus dem Chat mit Gedächtnis wird ein Agent mit Backlog.

Unabhängig von der konkreten Implementierung löst dieser Ansatz ein Problem, das mich in der Praxis ständig beschäftigt hat: den Verlust des Arbeitsstands. In der Chat-basierten Welt war ein Kontextwechsel oft der Moment, in dem der Agent den eigentlichen Plan vergaß: ein Compilerfehler, ein Lint-Problem, ein fehlschlagender Test. Er fixte den Fehler, kam aber nicht mehr zuverlässig zum ursprünglichen Vorhaben zurück. Eine persistente Aufgabenverwaltung macht den Arbeitsstand unabhängig vom Gesprächsverlauf, egal ob sie auf SQLite, Markdown-Dateien oder einem anderen Format basiert.

Das eigentliche Problem: Große bestehende Anwendungen

Greenfield ist vergleichsweise einfach.

Man beginnt bei null, definiert die Architektur und baut Schritt für Schritt auf. Der Kontext ist überschaubar, weil es anfangs nicht viel Kontext gibt. Die Agenten glänzen hier. Deshalb sehen die meisten Demos auch so beeindruckend aus.

Die Realität der professionellen Softwareentwicklung sieht anders aus, und wer sie kennt, weiß es: Man arbeitet in bestehenden Systemen. Systeme mit 500.000 Zeilen Code, gewachsenen Strukturen und impliziten Konventionen, dazu historische Entscheidungen, die niemand mehr dokumentiert hat, die aber trotzdem Gründe hatten. Systeme, die in Produktion laufen und deren Verhalten man nicht brechen darf.

Hier wird Kontext zum Bottleneck, und das liegt nicht an der Intelligenz des Agenten: Der relevante Kontext ist so groß, dass selbst ein Mensch Tage braucht, um sich einzuarbeiten.

Ich hatte die Aufgabe, in einer bestehenden Enterprise-Anwendung ein neues Modul zu implementieren. Das Modul musste mit dem existierenden Authentifizierungssystem zusammenarbeiten und das bestehende Rollen- und Berechtigungsmodell nutzen. Außerdem musste es sich in den vorhandenen CI/CD-Prozess einfügen und die etablierten Patterns für Datenbankzugriff, Logging und Fehlerbehandlung verwenden.

Einfach gesagt: „Füge Feature X hinzu."

Tatsächlich: Ein Kontextproblem mit 47 impliziten Constraints, von denen der Agent keinen einzigen kennt, wenn man ihn nicht briefet.

Mein erster Versuch (Hand aufs Herz) war, dem Agenten den ganzen Ordner hinzuwerfen und die Aufgabe zu beschreiben. „Hier ist der Code, hier ist was ich will, mach mal." Das Ergebnis war funktionierender Code, der jede einzelne Projektkonvention ignorierte: ein eigenes Logging-Framework anstelle des bestehenden, eine eigene Fehlerbehandlung, eine eigene Datenbankabstraktion. Technisch korrekt und architektonisch eine Katastrophe. Wer das schon erlebt hat, kennt dieses Gefühl: Der Code tut das Richtige, aber er gehört nicht dazu.

Das ist das Omission-Problem aus dem Paper: Der Agent hatte alle Informationen im Context Window, hat aber nicht alle beachtet.

Mein Weg zurück zur Struktur

Ich habe in einem früheren Beitrag beschrieben, warum KI-gestützte Entwicklung mehr Planung braucht. Dort habe ich auch empfohlen, die initiale Architekturarbeit ohne den Agenten zu machen. Bei der Arbeit in großen bestehenden Codebases hat sich für mich seitdem das Gegenteil als besser erwiesen: Planung gemeinsam mit dem Agenten. Der Agent kann eine Codebase systematisch erkunden, die selbst ich nicht vollständig kenne. Er scannt Verzeichnisstrukturen, identifiziert Patterns über hunderte Dateien hinweg und deckt Abhängigkeiten auf, die mir entgangen wären.

Was ich dort als Prinzip formuliert habe, hat sich seitdem zu einem konkreten Workflow verdichtet, den ich bei jedem größeren Vorhaben einsetze.

Der Workflow wirkt altmodisch, folgt aber direkt aus dem, was wir über Kontextdegradation wissen. Er macht überraschend viel Spaß, wenn man sich darauf einlässt.

Phase 1: Die Planungssession

Vor der ersten Zeile Code führe ich eine ausführliche Planungssession mit dem Agenten, und zwar als Dialog. Das ist der Teil, der mir am meisten Freude macht.

Die Session beginnt damit, dass der Agent die bestehende Codebasis systematisch untersucht: Verzeichnisstruktur, Architekturpatterns, Datenmodelle, Abhängigkeiten, Teststruktur, CI-Konfiguration. Ich weise ihn an, Fragen zu stellen. Gute Agenten tun das von selbst, die besten stellen dabei die richtigen Fragen.

Dann diskutieren wir. Ich bringe mein Architekturwissen ein, der Agent sein Patternwissen. Wir vergleichen den bestehenden Code mit Best Practices und suchen die Stellen, an denen er von etablierten Patterns abweicht, samt der Frage, ob das bewusste Entscheidungen oder gewachsene Inkonsistenzen sind. Ideen probieren wir aus und verwerfen sie wieder oder schärfen sie nach.

Es fühlt sich an wie Pair Programming mit einem Kollegen, der die gesamte Dokumentation der Welt gelesen hat, aber noch nie in diesem konkreten Gebäude gearbeitet hat. Man selbst kennt das Gebäude. Zusammen ergibt das etwas, das keiner allein hätte.

Am Ende steht ein gemeinsamer, abgestimmter Plan, und er ist konkret: klare Architekturentscheidungen, definierte Schnittstellen, identifizierte Risiken.

Diese Phase dauert eine Stunde, manchmal zwei. Ich habe lange gebraucht, um diese Zeit nicht als Verzögerung zu empfinden. Inzwischen ist sie für mich die wertvollste im gesamten Prozess.

Phase 2: Epics und Tickets

Den größten Unterschied hat für mich dieser Schritt gemacht. Den abgestimmten Plan zerlege ich in Epics, wieder gemeinsam mit dem Agenten. Jedes Epic ist ein abgeschlossener, kohärenter Arbeitsblock: „Datenbankschema erweitern", „API-Endpunkte implementieren", „Frontend-Komponenten bauen", „Integrationstests schreiben."

Die Epics teile ich weiter in Tickets auf. Ein Ticket beschreibt eine einzelne, fokussierte Aufgabe mit:

• Kontext: Welche Dateien sind betroffen? Welche bestehenden Patterns gelten?
• Aufgabe: Was genau soll gemacht werden?
• Akzeptanzkriterien: Woran erkennt man, dass es fertig ist?
• Abhängigkeiten: Welche Tickets müssen vorher erledigt sein?

Diese Tickets speichere ich als Markdown-Dateien in einem lokalen Verzeichnis, strukturiert nach Epics. Agent und Mensch können sie lesen, sie sind der gemeinsame Vertrag.

Direkt nach dem Erstellen der Epics aktualisiere ich die Anweisungsdatei des Agenten (die CLAUDE.md, AGENTS.md oder das jeweilige Äquivalent). Alle Architekturentscheidungen, Konventionen und Patterns aus der Planungssession fließen jetzt in die Datei ein, vor der ersten Zeile Code. So startet der Agent die Implementierung nicht nur mit einem Plan, sondern auch mit einem aktualisierten Regelwerk, das seine Arbeit über alle Epics hinweg konsistent hält.

Ein Beispiel für ein Ticket:

# EPIC-02/TICKET-03: User-Service um Rollenprüfung erweitern

## Kontext
- Bestehender UserService in `src/services/user.service.ts`
- Rollen-Enum in `src/types/roles.ts`
- Bestehendes Pattern: Guards nutzen `@UseGuards(RoleGuard)`
- Bestehende Tests in `src/services/__tests__/user.service.spec.ts`

## Aufgabe
- Methode `hasPermission(userId, permission)` zum UserService hinzufügen
- Bestehende Rollen-Hierarchie aus `roles.ts` respektieren
- Caching der Berechtigungen pro Request (nicht global)

## Akzeptanzkriterien
- [ ] Methode existiert und ist typisiert
- [ ] Unit-Tests für alle Rollen-Kombinationen
- [ ] Bestehende Tests laufen weiterhin grün
- [ ] Kein neues Logging-Pattern eingeführt

## Abhängigkeiten
- EPIC-02/TICKET-01 (Rollen-Enum erweitert)
- EPIC-02/TICKET-02 (Datenbank-Migration)

Phase 3: Epic für Epic

Ich weise dem Agenten ein komplettes Epic zu, mit allen Tickets darin. Das Epic gibt ihm Ort und Struktur: welcher Teil des Systems betroffen ist, welche Dateien relevant sind, welches Ziel am Ende stehen soll. Die Tickets innerhalb des Epics geben ihm die einzelnen Aufgaben in dieser Struktur, in der richtigen Reihenfolge, mit klaren Abhängigkeiten.

Das Gefühl, wenn ein Agent ein sauber strukturiertes Epic Ticket für Ticket abarbeitet und am Ende alles grün durch die Pipeline kommt, ist fantastisch. Es ist wie Lego bauen, wo man sonst Spaghetti entwirrt.

Das funktioniert, weil das Epic den Kontext liefert und die Tickets die Anweisungsdichte pro Schritt niedrig halten. Der Agent muss nur dieses Epic verstehen, das gesamte Projekt braucht er dafür nicht im Kopf. Innerhalb des Epics hat jedes Ticket 5–10 klare Constraints und nicht 50 oder 500, eine Menge weit unter der Degradationsschwelle, die das Paper beschreibt.

Kontextwechsel durch Compilerfehler, Lint-Probleme oder fehlschlagende Tests bleiben innerhalb des Epics lokal. Der Agent fixt den Fehler und kommt zum nächsten Ticket zurück, weil die Ticketliste der Anker ist. Sie steht schwarz auf weiß da, unabhängig vom Gesprächsverlauf, deshalb driftet nichts weg und nichts gerät schleichend in Vergessenheit.

Wenn ein Ticket innerhalb des Epics nicht klappt, ist der Fehler eingegrenzt. Man debuggt eine einzelne, klar umrissene Aufgabe innerhalb eines bekannten Kontexts. Das ist ein anderes Arbeiten als „der Agent hat irgendwo in 2.000 Zeilen etwas kaputt gemacht und ich darf suchen."

Phase 4: Wissen laufend konsolidieren

Mit dem ersten Schreiben ist die Anweisungsdatei nicht erledigt. Während der Implementierung tauchen immer neue Erkenntnisse auf: Eigenheiten des Testframeworks, implizite API-Konventionen, Patterns, die erst beim Arbeiten im Code sichtbar werden.

Nach jedem abgeschlossenen Epic weise ich den Agenten an, die Anweisungsdatei und bei Claude Code auch die Memory zu aktualisieren, manchmal auch nach einzelnen Tickets, wenn etwas Überraschendes aufgetaucht ist.

In diesem Moment wird temporäres Wissen zu persistentem Wissen. Hat der Agent entdeckt, dass ein bestimmtes Testframework eine Eigenheit hat, gehört das in die Anweisungsdatei. Dasselbe gilt für eine undokumentierte API-Konvention, auf die er gestoßen ist, oder für ein Pattern, das der bestehende Code konsistent einhält, das aber nirgends festgehalten war.

Ohne diesen laufenden Schritt erodiert das Wissen mit jeder neuen Session. So aber baut sich über die Zeit ein immer reichhaltigeres Kontextfundament auf, das den Einstieg in jede neue Session spürbar beschleunigt.

Was sich verschiebt

In der klassischen Softwareentwicklung war der Mensch gleichzeitig für Architektur, Planung und Implementierung zuständig. Agile hat versucht, diese Rollen zu verschmelzen: alle planen, alle coden, alle testen. Das funktionierte, solange der Mensch alles selbst schrieb und dabei lernte.

Mit Coding-Agenten beobachte ich, dass sich diese Rollen wieder trennen, in eine neue Konstellation und nicht zurück zum alten Wasserfall:

Der Mensch verschiebt sich Richtung Architektur und Planung. Er versteht das System, trifft die Entscheidungen, definiert die Aufgaben, prüft die Ergebnisse. Er schreibt weniger Code im Sinne von Zeichen in einer Datei, denkt aber mehr Code als vorher, weil das Entwerfen des Plans tieferes Verständnis erfordert, als es das bloße Tippen je tat.

Der Agent übernimmt mehr von der Implementierung. Er schreibt den Code, debuggt die Fehler und iteriert gegen die Pipeline. Er ist schnell und präzise und wird nicht müde, solange sein Kontext stimmt.

Die Tickets werden zur Schnittstelle zwischen beiden. Diese Schnittstelle ist schriftlich und strukturiert, und sie bleibt bestehen, anders als ein mündlicher Zuruf, ein Chat-Verlauf oder der flüchtige Kontext eines Prompts.

Ich habe diesen Workflow mit Claude Code, mit OpenAI Codex und mit GitHub Copilot CLI eingesetzt, und bei jedem Tool funktioniert er. Die Tools sind sich nicht ähnlich, aber der Workflow zielt auf das Problem, das alle teilen: die begrenzte Fähigkeit von Sprachmodellen, viele Anweisungen gleichzeitig zuverlässig zu befolgen.

Was ich daraus mitnehme

Wenn ich meine zwei Jahre mit Coding-Agenten in bestehenden Codebases destilliere, komme ich auf fünf Dinge, die den Unterschied gemacht haben:

1. Anweisungsdichte pro Interaktion niedrig halten. Ein Ticket mit einer Aufgabe und klarem Kontext. Das Gegenteil davon wäre „implementiere das ganze Feature". Weniger ist zuverlässiger, und die Forschung zeigt das auch.

2. Kontext persistent machen. Anweisungsdateien (CLAUDE.md, AGENTS.md), Memory-Dateien, Projektdokumentation. Alles, was der Agent über Sessions hinweg wissen muss, gehört in Dateien, denn Chat-Verläufe sind flüchtig.

3. Vor der Implementierung planen, gemeinsam mit dem Agenten. Die Planungssession ist die Phase, in der Mensch und Maschine ein gemeinsames Verständnis aufbauen, und deshalb keine Zeitverschwendung. Ohne dieses Verständnis ist jede Implementierung ein Ratespiel.

4. Tickets als Vertrag nutzen. Schriftlich, strukturiert, mit Kontext und Akzeptanzkriterien. Das Ticket ist der Anker, zu dem der Agent zurückkehrt, wenn ein Kontextwechsel ihn ablenkt.

5. Wissen nach jedem Meilenstein konsolidieren. Was der Agent gelernt hat, muss in persistente Dateien fließen. Sonst ist jede neue Session ein Kaltstart.

Handwerk heißt den Kontext beherrschen

In meinem ersten Beitrag habe ich geschrieben, dass sich Software-Handwerk in den letzten 10% zeigt. Im zweiten habe ich gefragt, wer diese 10% noch erkennen kann, und im dritten argumentiert, dass KI-gestützte Entwicklung mehr Planung braucht.

Dieser Beitrag ist die praktische Konsequenz: Handwerk in der Ära der Coding-Agenten heißt, den Kontext zu beherrschen. Das Modell muss man dafür nicht beherrschen, es wird ohnehin alle paar Monate besser. Gemeint ist die Fähigkeit, das eigene Wissen so zu strukturieren, dass eine Maschine es zuverlässig umsetzen kann.

Das ist eine neue Kompetenz, die es vor drei Jahren nicht gab und die schwerer ist, als sie aussieht.

Lange habe ich gehofft, dass die nächste Modellgeneration das Kontextproblem löst. Inzwischen glaube ich: Das Warten lohnt sich nicht. Kontextmanagement ist ein Merkmal probabilistischer Systeme und kein Bug in den heutigen Modellen. Selbst wenn das Context Window auf zehn Millionen Tokens wächst und die Modelle noch einmal deutlich besser werden: Die Fähigkeit, eine beliebig lange Liste von Anweisungen gleichzeitig und fehlerfrei zu befolgen, ist nicht das, was Transformer-Architekturen leisten. Die Lösung liegt eher im Prozess als im Modell.

Das ist weniger glamourös als „10x Developer durch KI." Aber es ist das, was in der Praxis funktioniert. Zumindest in meiner.