Kontext ist alles

Vor zwei Jahren habe ich angefangen, ernsthaft mit Coding-Agenten zu arbeiten. Nicht als Spielerei, nicht für Demos, als Hauptwerkzeug in der täglichen Arbeit. 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. Jedes neue Release, jedes neue Modell, jede neue Architektur.

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

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. Das Problem bleibt.

Denn Kontext ist nicht nur, was das Modell sehen kann. Kontext ist, was es beachten soll. Und das sind zwei völlig verschiedene Dinge.

Ein aktuelles Paper von Distyl AI („How Many Instructions Can LLMs Follow at Once?") hat genau das untersucht. Die Forscher gaben 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. Es befolgt sie nur nicht alle.

Natürlich ist der Benchmark 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, der schickt effektiv hunderte implizite Constraints in eine Interaktion. Die Frage ist nicht, ob das Modell sie alle lesen kann. 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 plötzlich 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 zeigen dieses Muster. Für mich war das lange das tückischste, weil ich es nicht bemerkt habe. Die Qualität sinkt nicht abrupt. Sie 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. Kleinere Modelle wie Llama 4 Scout oder Claude 3.5 Haiku. Für einfache, fokussierte Aufgaben brauchbar. Für komplexe Projekte nicht.

Was mich am meisten beschäftigt hat: Der dominante Fehlertyp bei hoher Anweisungsdichte ist Omission. Das Modell lässt Anweisungen einfach weg. Es halluziniert sie nicht falsch, es ignoriert sie. Wortlos. Ohne Hinweis. 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

Um zu verstehen, warum die aktuelle Generation so viel besser ist, lohnt sich ein Blick zurück. Nicht als Geschichtsstunde, sondern weil man erst durch den Kontrast sieht, 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 (warum der Code so strukturiert ist, welche Patterns gelten, was die Projektkonventionen sind) musste man bei jeder Session neu etablieren.

Das Ergebnis: Man wurde zum Kontext-Manager. Die Hälfte der Arbeitszeit ging nicht in die eigentliche Aufgabe, sondern in das Aufrechterhalten des Kontexts. Prompt-Engineering war im Kern Kontextmanagement. Und es war anstrengend.

2025–26: Kontext als Architektur-Feature

Die aktuelle Generation hat verstanden, dass Kontextmanagement kein Nutzerproblem ist, sondern ein Architekturproblem. Und 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. Die Datei wird bei jeder Interaktion automatisch geladen und 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." Einmal gesagt, dauerhaft gespeichert.

Ebenfalls bei Claude Code verdient der Plan Mode besondere Erwähnung. Bevor der Agent Code schreibt, erstellt er einen Plan, den der Mensch absegnen muss. Das klingt trivial. In der Praxis hat es meinen Workflow verändert: Es zwingt den Agenten, seinen Kontext explizit zu machen. Man sieht, was er verstanden hat, und was nicht. Und man kann korrigieren, bevor eine Zeile Code entsteht. Dieses „Moment mal, das habe ich anders gemeint" vor der Implementierung statt danach, das spart nicht nur Zeit, es 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. Statt Aufgaben als Fließtext im Chat zu halten, werden sie in einer lokalen Datenbank gespeichert, mit Status, Abhängigkeiten und Fortschritt. Der Agent kann abfragen, was er schon erledigt hat, was noch offen ist, was blockiert ist. Das ist kein Chat mit Gedächtnis. Das ist ein Agent mit einem 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 (ein Compilerfehler, ein Lint-Problem, ein fehlschlagender Test) oft der Moment, in dem der Agent den eigentlichen Plan vergaß. 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, 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 jeder, der sie kennt, weiß es: Man arbeitet in bestehenden Systemen. Systeme mit 500.000 Zeilen Code, gewachsenen Strukturen, impliziten Konventionen, historischen Entscheidungen, die niemand mehr dokumentiert hat, aber die trotzdem Gründe hatten. Systeme, die in Produktion laufen und deren Verhalten man nicht brechen darf.

Hier wird Kontext zum Bottleneck. Nicht weil der Agent dumm wäre, sondern weil der relevante Kontext so groß ist, 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, das bestehende Rollen- und Berechtigungsmodell nutzen, 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. Eigenes Logging-Framework statt dem bestehenden. Eigene Fehlerbehandlung. Eigene Datenbankabstraktion. Technisch korrekt, architektonisch eine Katastrophe. Jeder, der das schon erlebt hat, kennt dieses Gefühl: Der Code tut das Richtige, aber er gehört nicht dazu.

Das ist genau das Omission-Problem aus dem Paper: Der Agent hatte alle Informationen im Context Window. Er hat sie nur 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, nicht weniger. 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, weil der Agent eine Codebase systematisch erkunden kann, die selbst ich nicht vollständig kenne. Er kann Verzeichnisstrukturen scannen, Patterns über hunderte Dateien hinweg identifizieren und Abhängigkeiten aufdecken, 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.

Auf den ersten Blick wirkt er altmodisch. Auf den zweiten Blick ist er eine direkte Konsequenz aus dem, was wir über Kontextdegradation wissen. Und er macht überraschend viel Spaß, wenn man sich darauf einlässt.

Phase 1: Die Planungssession

Bevor eine einzige Zeile Code geschrieben wird, führe ich eine ausführliche Planungssession mit dem Agenten. Nicht als Monolog, als Dialog. Und das ist der Teil, der mir am meisten Freude macht.

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

Dann diskutieren wir. Ich bringe mein Architekturwissen ein, der Agent bringt sein Patternwissen ein. Wir vergleichen den bestehenden Code mit Best Practices. Wir identifizieren, wo der Code von etablierten Patterns abweicht, und ob das bewusste Entscheidungen oder gewachsene Inkonsistenzen sind. Wir probieren Ideen aus, verwerfen sie, 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. Nicht vage. Konkret. Mit klaren Architekturentscheidungen, definierten Schnittstellen, identifizierten Risiken.

Diese Phase dauert manchmal 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

Hier kommt der Schritt, der für mich den größten Unterschied gemacht hat.

Den abgestimmten Plan zerlege ich (wieder gemeinsam mit dem Agenten) in Epics. Jedes Epic repräsentiert einen abgeschlossenen, kohärenten Arbeitsblock: „Datenbankschema erweitern", „API-Endpunkte implementieren", „Frontend-Komponenten bauen", „Integrationstests schreiben."

Jedes Epic wird weiter in Tickets aufgeteilt. Jedes 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 in einem lokalen Verzeichnis, als Markdown-Dateien, strukturiert nach Epics. Der Agent kann sie lesen, der Mensch kann 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, bevor die erste Zeile Code geschrieben wird. So startet der Agent die Implementierung nicht nur mit einem Plan, sondern 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 den Agenten ein komplettes Epic zu, nicht einzelne Tickets. 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, statt Spaghetti zu entwirren.

Warum funktioniert das? Weil das Epic den Kontext liefert und die Tickets die Anweisungsdichte pro Schritt niedrig halten. Der Agent muss nicht das gesamte Projekt im Kopf behalten, er muss nur dieses Epic verstehen. Und innerhalb des Epics hat jedes Ticket 5–10 klare Constraints. Nicht 50. Nicht 500. Eine Menge, die weit unter der Degradationsschwelle liegt, die das Paper beschreibt.

Kontextwechsel (Compilerfehler, Lint-Probleme, fehlschlagende Tests) bleiben innerhalb des Epics lokal. Der Agent fixst 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. Kein Drift, kein schleichendes Vergessen.

Und wenn ein Ticket innerhalb des Epics nicht klappt? Dann ist der Fehler eingegrenzt. Man debuggt nicht das ganze Feature, sondern 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

Die Anweisungsdatei wird nicht nur einmal geschrieben und dann vergessen. 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 (manchmal auch nach einzelnen Tickets, wenn etwas Überraschendes aufgetaucht ist) weise ich den Agenten an, die Anweisungsdatei und bei Claude Code auch die Memory zu aktualisieren.

Das ist der Moment, in dem temporäres Wissen zu persistentem Wissen wird. Der Agent hat entdeckt, dass ein bestimmtes Testframework eine Eigenheit hat? Das gehört in die Anweisungsdatei. Er ist auf eine undokumentierte API-Konvention gestoßen? Dokumentiert. Er hat ein Pattern gefunden, das im bestehenden Code konsistent eingehalten wird, aber nirgends festgehalten war? Jetzt schon.

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

Was sich verschiebt

In der klassischen Softwareentwicklung war der Mensch gleichzeitig Architekt, Planer und Implementierer. 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. Nicht zurück zum alten Wasserfall, aber in eine neue Konstellation:

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. Aber er denkt 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, iteriert gegen die Pipeline. Er ist schnell, präzise und unermüdlich, solange sein Kontext stimmt.

Die Tickets werden zur Schnittstelle zwischen beiden. Nicht mündlich, nicht im Chat-Verlauf, nicht im flüchtigen Kontext eines Prompts. Schriftlich, strukturiert, persistent.

Ich habe diesen Workflow mit Claude Code, mit OpenAI Codex und mit GitHub Copilot CLI eingesetzt. Bei jedem Tool funktioniert er. Nicht weil die Tools ähnlich wären (sie sind es nicht), sondern weil der Workflow das zugrundeliegende Problem adressiert, 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, eine Aufgabe, klarer Kontext. Nicht „implementiere das ganze Feature." Weniger ist zuverlässiger. Das ist keine Meinung, das zeigt die Forschung.

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

3. Vor der Implementierung planen, gemeinsam mit dem Agenten. Die Planungssession ist keine Zeitverschwendung. Sie ist die Phase, in der Mensch und Maschine ein gemeinsames Verständnis aufbauen. 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. In meinem zweiten habe ich gefragt, wer diese 10% noch erkennen kann. In meinem dritten habe ich argumentiert, dass KI-gestützte Entwicklung mehr Planung braucht, nicht weniger.

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

Das ist eine neue Kompetenz. Eine, die es vor drei Jahren nicht gab. Und eine, 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 kein Bug in den heutigen Modellen. Es ist ein Merkmal probabilistischer Systeme. 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.