Context Rot bei KI-Agenten: Warum die Qualität sinkt

Wer mit Claude Code, Cursor oder Copilot arbeitet, kennt das Muster. Das Problem hat einen Namen: Context Rot. Die ersten Ergebnisse sind brillant, der Code präzise und die Architektur sauber. Dann kippt die Qualität. Nach 20, 30 Minuten fangen die Antworten an, sich zu wiederholen. Der KI-Agent vergisst Kontext. Er erzeugt Code, der dem widerspricht, was er fünf Prompts vorher geschrieben hat.

Kein Nutzerfehler, sondern ein Architekturproblem. Die Lösung liegt im Context Engineering: dem gezielten Management von Kontextfenstern durch Multi-Agent Orchestrierung. Genau solche Praxisprobleme adressiere ich in meiner KI & Automatisierungs-Beratung.

Context Rot: Das 200.000-Token-Problem

Jedes große Sprachmodell hat ein Kontextfenster. Bei Claude sind es 200.000 Tokens. Das klingt nach viel. Aber in einer typischen Entwicklungssession passiert Folgendes: Der Agent liest Dateien, analysiert Code, schreibt Lösungen, bekommt Feedback, liest weitere Dateien. Nach einer halben Stunde ist das Kontextfenster zu 70–80 % gefüllt. Ab diesem Punkt sinkt die Qualität messbar.

Das ist vergleichbar mit einer überladenen Werkbank: Wenn jedes Werkzeug, jede Skizze und jede Anleitung gleichzeitig auf dem Tisch liegt, findet der Handwerker nichts mehr. Die Konzentration leidet, Fehler schleichen sich ein.

Context Rot beschreibt den Qualitätsverlust von KI-Agenten, wenn das Kontextfenster sich mit altem, irrelevantem Inhalt füllt. Die Ausgaben werden ungenauer, widersprüchlich, der Code wiederholt sich.

Die typische Reaktion: Neue Session starten, Kontext manuell neu aufbauen, hoffen, dass es diesmal länger hält. Das funktioniert bei kleinen Skripten. Bei einem Projekt mit 50+ Dateien und komplexen Abhängigkeiten ist es Zeitverschwendung.

GSD (Get Shit Done): Multi-Agent Orchestrierung statt Solo-Agent

GSD (Get Shit Done) löst dieses Problem mit einem Ansatz, den ich aus meiner Arbeit mit Multi-Agent Orchestrierung kenne: Statt einem einzelnen Agenten, der alles allein macht, setzt GSD auf spezialisierte Agenten mit getrennten Kontextfenstern.

Das Open-Source-Framework hat aktuell 45.700 GitHub Stars und steht unter MIT-Lizenz. Die Installation ist ein einzelner Befehl:

npx get-shit-done-cc@latest

GSD beschreibt sich selbst als “Meta-Prompting, Context Engineering and Spec-Driven Development System”. Primär für Claude Code gebaut, aber auch kompatibel mit OpenCode, Gemini CLI, Codex, Cursor und Windsurf.

Die Kernidee: Jeder Agent bekommt ein frisches 200k-Token-Kontextfenster. Statt stehendes Gewässer, in dem sich der Kontext trübt, fließt frisches Wasser durch jeden Arbeitsschritt. Ein Researcher liest und analysiert, ein Planner gliedert Aufgaben, ein Executor schreibt Code, ein Verifier prüft das Ergebnis. Jeder mit vollem Kontext für seine Aufgabe.

GSD vs. klassischer KI-Agent: Spec-Driven Development

Der entscheidende Unterschied liegt im zweiten Punkt der Tabelle: Spec-Driven Development. GSD erzeugt beim Projektstart strukturierte Dokumente (PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md), die als Bauplan für alle nachfolgenden Agenten dienen. Das funktioniert wie eine technische Zeichnung statt einer mündlichen Anweisung: Die Zeichnung bleibt präzise, egal wer sie liest.

GSD-Workflow: So läuft die Projekt-Orchestrierung ab

Der Workflow folgt sechs Phasen, die über Slash-Commands gesteuert werden:

/gsd:new-project     → Projekt initialisieren, Specs generieren
/gsd:discuss-phase   → Anforderungen klären, Scope definieren
/gsd:plan-phase      → Aufgaben ableiten, Abhängigkeiten erkennen
/gsd:execute-phase   → Code schreiben, parallel wo möglich
/gsd:verify-work     → Ergebnisse prüfen, Tests laufen lassen
/gsd:ship            → Finalisieren, dokumentieren

In der Execute-Phase zeigt sich die Stärke der Architektur: GSD erkennt Abhängigkeiten zwischen Aufgaben und führt unabhängige Tasks parallel aus, sogenannte Wave Execution. Zwei Features, die keine gemeinsamen Dateien berühren, entstehen gleichzeitig. Jeder Task endet mit einem atomaren Git-Commit. Kein riesiger “WIP”-Commit am Ende des Tages, sondern nachvollziehbare, einzelne Änderungen.

Wer GSD heute einsetzt

Laut den Projektdaten nutzen Engineers bei Amazon, Google, Shopify und Webflow das Framework in ihrer täglichen Arbeit. Die Community wächst schnell: 45.700 Stars auf GitHub sprechen für sich.

In meinen eigenen Projekten, etwa bei KI-Einsatz im Mittelstand, habe ich den Effekt bestätigt: Sobald ein Projekt mehr als ein Dutzend Dateien umfasst, macht der Multi-Agent-Ansatz einen spürbaren Unterschied. Die einzelne Antwort wird nicht besser, aber die Qualität bleibt über die gesamte Session stabil. Das deckt sich mit meiner Erfahrung bei der Multi-Agent Orchestrierung mit OpenClaw: Agenten, die sich gegenseitig prüfen, liefern konsistentere Ergebnisse als ein Agent, der alles allein macht.

Das Motto des Projekts passt dazu: “No enterprise roleplay. Just build cool stuff consistently.” Kein Overhead, keine Zeremonie. Specs rein, Code raus, verifiziert und committed.

Grenzen von GSD: Wann das Framework nicht hilft

Kein Tool ohne Einschränkungen. GSD setzt voraus, dass man mit CLI-basierten Workflows arbeitet. Wer ausschließlich in einer IDE mit grafischer Oberfläche entwickelt, muss sich umgewöhnen. Die Spec-Dateien (PROJECT.md, REQUIREMENTS.md) müssen initial befüllt werden. Bei einem bestehenden Projekt kostet das 15–30 Minuten, amortisiert sich aber schnell.

Außerdem: GSD orchestriert die Arbeit von KI-Agenten, es macht ein schlechtes Modell nicht besser. Wer mit einem schwachen Basis-Modell arbeitet, bekommt auch mit GSD schwache Ergebnisse, nur sauberer aufgeteilt. Die größte Wirkung zeigt sich mit leistungsstarken Modellen wie Claude Opus oder Sonnet.

Genau so setze ich KI-Tools auch in meinen Beratungsprojekten ein: als praktisches Werkzeug, nicht als Selbstzweck.

Für wen sich GSD lohnt

GSD ist kein Tool für jeden Anwendungsfall. Wer ein einzelnes Python-Skript schreiben will, braucht keine Multi-Agent-Orchestrierung. Die Stärke zeigt sich bei:

• Projekten mit mehr als 10 Dateien, bei denen der Kontext eines einzelnen Agenten nicht ausreicht
• Teams, die KI-Agenten systematisch einsetzen und reproduzierbare Ergebnisse brauchen
• Langlebigen Codebasen, bei denen konsistente Architekturentscheidungen über viele Sessions hinweg wichtig sind
• Entwicklern, die bereits mit Claude Code oder ähnlichen Tools arbeiten und an die Grenzen des Solo-Agent-Ansatzes stoßen

Wer sich generell für den Einsatz von KI in der Softwareentwicklung interessiert, findet in meinem Beitrag Website-Relaunch mit KI statt Agentur ein konkretes Praxisbeispiel dafür, was mit KI-gestützter Entwicklung heute möglich ist.

Häufige Fragen zu Context Rot und Context Engineering

Was ist Context Rot bei KI-Coding-Agenten?

Context Rot bezeichnet den Qualitätsverlust, der entsteht, wenn das Kontextfenster eines KI-Agenten sich mit altem, irrelevantem Inhalt füllt. Nach 20–30 Minuten intensiver Arbeit sinkt die Ausgabequalität messbar: Antworten werden ungenauer und widersprüchlich, Codeblöcke wiederholen sich. Das Problem betrifft alle LLM-basierten Coding-Tools, ob Claude Code, Cursor, Copilot oder andere.

Was bedeutet Context Engineering?

Context Engineering ist die gezielte Steuerung dessen, welche Informationen ein KI-Agent zu einem bestimmten Zeitpunkt in seinem Kontextfenster hat. Statt alle Informationen in ein einziges Kontextfenster zu packen, verteilt Context Engineering die Arbeit auf mehrere spezialisierte Agenten mit jeweils frischem Kontext. GSD ist ein Open-Source-Framework, das diesen Ansatz umsetzt.

Wie unterscheidet sich GSD von normalem Prompting?

Normales Prompting arbeitet innerhalb eines einzigen Kontextfensters. GSD setzt auf Spec-Driven Development: Strukturierte Dokumente (PROJECT.md, REQUIREMENTS.md, ROADMAP.md) ersetzen mündliche Prompts. Vier spezialisierte Agenten (Researcher, Planner, Executor, Verifier) arbeiten mit jeweils eigenem 200k-Token-Kontextfenster. Das Ergebnis: gleichbleibende Qualität auch bei komplexen Projekten.

Funktioniert GSD nur mit Claude Code?

Nein. GSD wurde primär für Claude Code entwickelt, ist aber auch kompatibel mit OpenCode, Gemini CLI, Codex, Cursor und Windsurf. Die besten Ergebnisse zeigen sich mit leistungsstarken Modellen wie Claude Opus oder Sonnet.

Nächster Schritt

Sie setzen KI-Agenten in der Entwicklung ein und stoßen an die Grenzen von Context Rot? Ich berate zu Multi-Agent-Architekturen, Context Engineering und dem produktiven Einsatz von KI-Tools in echten Projekten.

→ Erstgespräch vereinbaren — kostenfrei

→ Oder zuerst mehr lesen: KI-Workshop: Geschäftsprozesse

Tools: GSD (Get Shit Done) · Claude Code · OpenCode