Das GSD-Framework: Wie KI-Agenten tatsächlich liefern
Der Agent, der tatsächlich liefert, läuft nicht mit dem besten Modell. Eine Studie von Morphllm aus März 2026, die 15 KI-Coding-Agenten getestet hat, zeigt: Dasselbe Basismodell erreicht je nach Agent-Framework 17 Benchmark-Probleme mehr oder weniger. Das Scaffolding ist die entscheidende Variable. Das Modell spielt eine fast untergeordnete Rolle.
Das GSD-Framework (Get Shit Done) für KI-Agenten ist die deutlichste Formulierung dieser Idee, die wir bisher gesehen haben. Entwickelt von Lex Christopherson und durch das AI-Labs-Video "GSD Is the Missing Piece For Claude Code" bekannt geworden, ist GSD kein weiteres KI-Coding-Tool mit Meinung. Es ist eine Scaffolding-Philosophie, die auf einer simplen Erkenntnis beruht: Agenten scheitern auf der Workflow-Ebene, nicht auf der Intelligenz-Ebene.
Dieser Beitrag erklärt das GSD-Framework, warum es funktioniert, was Produktions-Agent-Pipelines wirklich brauchen — und was wir beim Betrieb von über 25 autonomen Cron-Agenten täglich bei Context Studios gelernt haben.
Warum die meisten Agent-Pipelines scheitern
Die Morphllm-Daten sind es wert, verinnerlicht zu werden. Claude Code erreicht 80,9% auf SWE-bench Verified, wenn es mit dem richtigen Scaffolding und der richtigen Orchestrierung kombiniert wird. Dasselbe Basismodell in einer schlecht strukturierten Agent-Pipeline kann 17 Punkte weniger auf denselben Benchmark-Aufgaben erzielen. Diese Lücke ist keine Modell-Lücke. Es ist eine Architektur-Lücke.
Die meisten Agent-Pipelines scheitern an denselben Problemen:
Kontextfenster-Chaos. Ohne explizites Zustandsmanagement sammelt der Agent über mehrere Durchläufe Rauschen an. Bis er den kritischen Schritt erreicht — das File-Edit, den API-Aufruf, die Datenbankmigrierung — hat er die ursprüngliche Spezifikation in einem Meer von Zwischenüberlegungen verloren.
Unklare Erfolgskriterien. Ein Agent mit vagen Anweisungen wird den Buchstaben der Aufgabe erfüllen, aber nicht den Geist. "Aktualisiere den Authentifizierungsfluss" führt zu unvorhersehbarem Verhalten. "Füge eine Prüfung für abgelaufene Tokens in auth/middleware.ts hinzu, gib 401 zurück wenn abgelaufen, führe die Auth-Test-Suite aus, bestätige alle 47 Tests als bestanden" nicht.
Fehlende Fail-Fast-Schleifen. Menschliche Entwickler überprüfen ihre Arbeit ständig. Agenten ohne explizite Verifikationsschritte halluzinieren einen Erfolg und machen weiter. Der Bug wird ausgeliefert.
Fehlende Wiederherstellungspfade. Wenn ein Agent an eine Wand stößt — Timeout, Tool-Fehler, unerwartete Ausgabe — gibt es keinen Plan. Die Pipeline hängt entweder still oder bricht ab, ohne Zwischenergebnisse zu speichern.
Das GSD-Framework adressiert alle vier Probleme.
Was das GSD-Framework ist
GSD ist ein spezifikationsgesteuertes Entwicklungssystem, das vollständig auf den nativen Funktionen von Claude Code aufbaut. Es hat mehr als 23.000 GitHub-Stars. Das gesamte System läuft auf etwa 50 Markdown-Dateien, einem Node.js-CLI-Helfer und zwei Hooks. Kein proprietäres Runtime. Kein Framework-Lock-in.
Das System ist um sechs Slash-Befehle herum organisiert, die einem linearen Workflow entsprechen:
/gsd:new-project— erfasst die Idee und generiert Spezifikationen/gsd:discuss-phase— klärt Anforderungen, bevor Code geschrieben wird/gsd:plan-phase— unterteilt die Arbeit in atomare, ausführbare Aufgaben/gsd:execute-phase— führt diese Aufgaben aus, mit Parallelität wo möglich/gsd:verify-work— validiert die Ausgabe anhand expliziter Erfolgskriterien/gsd:complete-milestone— archiviert den Zustand und veröffentlicht
Hinter diesen Befehlen stehen 29 Skills, 12 benutzerdefinierte Agenten und 2 Hooks. Jeder Befehl ist eine Markdown-Datei mit YAML-Frontmatter und XML-getaggten Abschnitten. Das XML-Tagging ist kein Dekorationselement: Claude behandelt XML-Grenzen als strukturelle Signale, was das Modell messbar zuverlässiger beim Befolgen mehrstufiger Anweisungen macht.
Das GSD-Framework funktioniert für Claude Code, OpenCode und Gemini CLI gleichermaßen. Die Scaffolding-Philosophie überträgt sich auf alle Agenten.
Die vier GSD-Prinzipien
Der Produktionswert des Frameworks ergibt sich aus vier Architekturentscheidungen, die jedes Agent-System übernehmen kann.
1. Spezifikation vor Ausführung. Jeder GSD-Workflow beginnt mit einer maschinenlesbaren Spezifikation — kein natürlichsprachliches Ziel, sondern ein strukturiertes Dokument mit Einschränkungen, Erfolgskriterien und Tool-Berechtigungen. Der /gsd:discuss-phase-Befehl existiert, um Unklarheiten aufzudecken, bevor eine einzige Codezeile ausgeführt wird.
2. Parallele Forschung, sequentielle Synthese. Während der Recherchephase laufen vier Agenten gleichzeitig — jeder untersucht eine andere Dimension des Problems: Tech-Stack, Features, Architektur, Edge Cases. Jeder schreibt Ergebnisse in eine eigene Datei. Ein Synthese-Agent verarbeitet diese Ergebnisse dann sequenziell, und ein Roadmapper erstellt den endgültigen Plan. Dieses Fan-out/Fan-in-Muster begrenzt die Kontextfensterlast für jeden einzelnen Agenten.
3. Persistenter Zustand über Kontext-Resets hinweg. GSD schreibt alles in ein .planning/-Verzeichnis: Projektdefinition, Anforderungen, Roadmap und aktueller Zustand. Git-Commits passieren nach jedem Schritt. Ein /gsd:resume-work-Befehl liest diesen Zustand nach einem Reset zurück. Der Agent fängt nie von vorne an. Dies ähnelt dem Ansatz von Claude Code /loop für autonome Sessions — persistenter Zustand über Kontextfenster hinweg.
4. Deterministische Schritte durch Scripts. Bash-Scripts übernehmen Aufgaben, bei denen exakte Zuverlässigkeit wichtig ist: Dateizugänglichkeit prüfen, Phasennummern berechnen, Testzahlen validieren. LLM für Urteilsvermögen, Script für Determinismus — diese Grenze ist eine der wichtigsten Designentscheidungen in einem Produktions-Agent-System.
Produktionsrealität: Was wir aus 25+ täglichen Agenten gelernt haben
Context Studios betreibt täglich über 25 autonome Agenten auf Cron-Zeitplänen. Intel-Sammlung, SEO-Audits, Content-Pipelines, Social-Engagement-Runden. Wir haben das lange genug gemacht, um Fehlermuster zu erkennen, die die GSD-Dokumentation noch nicht abdeckt — weil sie nur in der Produktion auftauchen.
Timeout-Management ist eine Disziplin. Wir haben diese Woche fünf separate Cron-Jobs angepasst, weil Agenten konsistent an Ausführungsgrenzen stießen. Eine gut konzipierte Agent-Pipeline braucht explizite Timeout-Budgets in jeder Phase: Recherchephase bekommt N Sekunden, Ausführungsphase M Sekunden, Verifikationsphase P Sekunden. Ohne phasenspezifische Budgets verbrennt der Agent das gesamte Zeitfenster im ersten Schritt und schlägt im schlechtesten Moment fehl.
Das Edit-auf-großen-Dateien-Antimuster. Wir hatten zwei aufeinanderfolgende Pipeline-Fehler, die auf dieselbe Ursache zurückzuführen waren: Ein Agent verwendete File-Edit-Tools auf großen Dateien, ohne sie zuerst zu lesen. Der Agent übernahm die Dateistruktur aus dem Kontext, wendete ein gezieltes Edit an und beschädigte die Datei. Jetzt enthalten unsere Pipelines eine explizite Read-before-Edit-Einschränkung im Scaffolding.
Browser-Vorabprüfungen sind nicht optional. Mehrere unserer Automatisierungsagenten sind von einer Browser-Session abhängig. Ein toter Browser ist ein stiller Fehler — der Agent läuft 20 Minuten, meldet Erfolg und hat tatsächlich nichts getan. Eine Browser-Gesundheitsprüfung als ersten Schritt jeder browserbezogenen Pipeline hinzuzufügen, eliminiert diese gesamte Fehlerklasse.
Selbstheilung statt manueller Wiederherstellung. Wir bauen Wiederherstellungspfade direkt in unser Agent-Scaffolding ein. Wenn der primäre Pfad scheitert, gibt es einen Fallback. Wenn der Fallback scheitert, wird das Teilergebnis gespeichert und zur Überprüfung markiert, anstatt verworfen zu werden. Dies ist nicht komplex zu implementieren — es geht hauptsächlich darum, das Scaffolding explizit zu machen: Was ist Erfolg in jedem Schritt? Was passiert, wenn er nicht eintritt?
Die Multi-Agenten-PR-Analyse von Claude Code folgt einem ähnlichen Ansatz, Paralleles parallel erledigen, kritische Verifikation sequentiell. Die 3 Tools, die unsere KI-Agenten-Entwicklung verändert haben, deckt die Tool-Seite ab — dieser Beitrag geht um die Disziplin-Seite.
Eigenes GSD-ähnliches Scaffolding aufbauen
Das GSD-Framework muss nicht vollständig übernommen werden. Die Prinzipien sind trennbar.
Beginne mit expliziten Erfolgskriterien für jede Agent-Aufgabe. Nicht "Schreibe Tests für das Auth-Modul", sondern "Schreibe Tests für das Auth-Modul mit ≥ 90% Coverage auf auth/middleware.ts, alle bestehenden Tests noch bestanden." Diese einzelne Änderung eliminiert die größte Klasse von Agent-Fehlern.
Dann füge Verifikations-Gates hinzu. Nach jedem wichtigen Schritt sollte der Agent prüfen, ob die erwartete Ausgabe existiert und der Spezifikation entspricht. Das ist, was GSD's /gsd:verify-work-Befehl automatisiert.
Dann füge Zustandspersistenz hinzu. Nach jedem verifizierten Schritt schreibe den aktuellen Zustand auf die Festplatte. Verwende Git-Commits als Checkpoints.
Schließlich ziehe die LLM/Script-Grenze explizit. Alles, was exakt richtig sein muss, kommt in ein Script. Alles, was Urteilsvermögen erfordert, geht an das Modell.
Die Morphllm-Daten bestätigen, was diese Architektur vorhersagt: Das Agent-System, das diese Entscheidungen richtig strukturiert, wird das übertreffen, das ein nominell stärkeres Modell betreibt, aber mit schwachem Scaffolding.
FAQ
Was ist das GSD-Framework für KI-Agenten? GSD (Get Shit Done) ist ein spezifikationsgesteuertes Entwicklungssystem für Claude Code. Es nutzt 50 Markdown-Dateien, 6 Slash-Befehle und 2 Hooks, um einen vollständigen Entwicklungs-Workflow zu orchestrieren — von der Idee bis zum ausgelieferten Code. Kein Custom-Runtime erforderlich.
Warum ist Scaffolding wichtiger als das KI-Modell? Die Morphllm-Studie zeigte, dass dasselbe Modell 17 Benchmark-Probleme je nach Scaffolding mehr oder weniger löst. Scaffolding bestimmt, wie das Modell Aufgaben erhält, Kontext verwaltet, Ausgaben verifiziert und bei Fehlern recovert.
Was sind die häufigsten Ursachen für Ausfälle von KI-Agent-Pipelines? Die vier Hauptursachen: (1) Kontextfenster-Erschöpfung durch schlechtes Zustandsmanagement, (2) vage Erfolgskriterien, (3) fehlende Verifikationsschritte, (4) keine Recovery-Pfade bei Fehlern oder Timeouts.
Wie geht GSD mit Kontext-Resets um?
GSD schreibt den Projektstatus in ein .planning/-Verzeichnis und committet nach jedem Schritt. Ein /gsd:resume-work-Befehl liest diesen Status nach einem Reset zurück.
Funktioniert das GSD-Framework mit anderen Modellen als Claude? Ja. Die GSD-Architektur unterstützt Claude Code, OpenCode und Gemini CLI gleichwertig. Die Scaffolding-Prinzipien übertragen sich auf jedes Agent-System.
Wie viele parallele Agenten kann eine GSD-Pipeline betreiben? GSD's Recherchephase nutzt standardmäßig vier parallele Agenten. Das Fan-out/Fan-in-Muster ist skalierbar. Unsere eigenen Cron-basierten Pipelines betreiben über 25 Agenten täglich mit unabhängigen Zeitplänen und isolierten Kontexten.
Der Produktionsstandard hat sich verschoben
Die Morphllm-Benchmark-Streuung — 17 Probleme, gleiches Modell, verschiedenes Scaffolding — ist der deutlichste verfügbare Beweis, dass die Qualitätsanforderung für Agent-Arbeit nicht mehr davon abhängt, welches Modell verwendet wird. Es geht darum, wie gut die Arbeit definiert, die Ausführung eingeschränkt, die Ausgabe verifiziert und bei Fehlern recovert wird.
GSD ist eine Implementierung dieser Erkenntnis. Die dahinterliegenden Prinzipien stehen jedem Entwickler zur Verfügung, der bereit ist, explizite Spezifikationen zu schreiben, Verifikations-Gates hinzuzufügen und den Zustand über Resets hinweg zu persistieren.
Die Agenten, die zuverlässig liefern, sind die mit klaren Erfolgskriterien. Das gilt auch für menschliche Entwickler.