Schreiben Sie eine Spec, bevor Sie einem KI-Coding-Agenten Aufgaben geben

Eine Anfrage direkt in einen Coding-Agenten zu tippen, fühlt sich schneller an, als vorher etwas aufzuschreiben, und bei wirklich trivialen Aufgaben stimmt das oft auch. Schwierig wird es, sobald es mehr als eine vernünftige Deutung gibt: Der Agent wählt eine, baut darauf auf, und dass es die falsche war, sehen Sie erst, wenn Sie fertigen Code lesen. Jede weitere Runde kostet dann mehr als die paar Minuten, die eine Spec gekostet hätte.

Eine Spec dreht die Reihenfolge um. Bevor Code entsteht, schreiben Sie drei Dinge in einfacher Sprache auf: was das Ergebnis tun soll, für wen es ist und die Fertig-wenn-Prüfungen, die belegen, dass es funktioniert. Das ist kein technisches Dokument. Es ist eher die Notiz, die Sie einer fähigen Assistenz hinterlassen würden, die Sie noch nie getroffen hat: genug Details, damit sie bei den wichtigen Punkten nicht raten muss.

Der Grund, warum das funktioniert, ist einfach. Der Agent füllt Lücken in Ihrer Anfrage nicht mehr mit eigenen Annahmen, weil weniger Lücken übrig sind. Und Sie entdecken nicht erst im Nachhinein am Ergebnis des Agenten, was Sie eigentlich wollten, weil Sie es schon aufgeschrieben haben, bevor Sie überhaupt etwas angefragt haben.

Nichts davon ist an ein bestimmtes Werkzeug gebunden. Claude Code, Codex, Copilot, Cursor und jeder andere Coding-Agent arbeiten im Grundsatz gleich: Anweisungen in einfacher Sprache gehen hinein, Code und Befehle kommen heraus. Eine Spec verändert, was hineingeht, und damit, was zurückkommt, egal mit welchem Agenten Sie sprechen.

GitHubs Spec Kit ist ein Open-Source-Toolkit, das im eigenen Repository von GitHub unter der MIT-Lizenz gepflegt wird. Es soll KI-Coding-Agenten strukturierte Abläufe, wiederverwendbare Vorlagen und dokumentierte Ergebnisse geben, statt einzelner Gespräche. Es wird über ein eigenes Kommandozeilenwerkzeug installiert, und sein README beschreibt es als Toolkit für den Einstieg in Spec-Driven Development oder jeden anderen strukturierten Prozess, dem ein Agent folgen soll.

Der zentrale Spec-Driven-Workflow besteht laut Dokumentation des Projekts aus einer benannten Abfolge von sechs Befehlen: Einer legt die Leitprinzipien eines Projekts fest, einer schreibt die Spec selbst, einer macht aus der Spec einen technischen Plan, einer zerlegt den Plan in eine geordnete Aufgabenliste, einer führt die Aufgaben aus und schreibt den eigentlichen Code, und ein letzter prüft, wie genau das Ergebnis zur Spec konvergiert ist. Das Projekt empfiehlt, diese Befehle nacheinander auszuführen, jedes Ergebnis vor dem Weitermachen zu prüfen und die Schritte Umsetzung und Konvergenz so lange zu wiederholen, bis die Konvergenz die Arbeit als konvergiert meldet, statt dem Agenten die ganze Aufgabe in einem Zug zu übergeben.

Zusätzlich liefert das Toolkit getrennte Erweiterungen, die Sie auf den Kern-Workflow aufsetzen, ebenfalls laut eigener Dokumentation: einen Satz Befehle rund um die Bewertung und Behebung eines konkreten Fehlers und einen weiteren, der eine grobe Idee durch Recherche und Definition führt, bevor entschieden wird, ob überhaupt gebaut wird.

Zu den unterstützten Agenten nennt die Setup-Dokumentation von Spec Kit mehrere, jeweils mit einem Integrationsschlüssel, den Sie bei der Installation angeben, darunter Claude Code und GitHub Copilot, und verweist auf eine eigene Dokumentation für die Anbindung weiterer Agenten. Verstehen Sie jede Agentenliste, auch diese, als Momentaufnahme: Prüfen Sie die aktuelle Dokumentation von Spec Kit, bevor Sie annehmen, dass ein bestimmtes Werkzeug heute unterstützt wird oder nicht.

Für jemanden ohne Entwicklungshintergrund, der eine einzelne kleine Sache baut, kann der vollständige Spec-Kit-Workflow mehr Aufwand sein, als die Aufgabe verlangt. Die dreiteilige Spec allein, als allererste Nachricht an den Agenten Ihrer Wahl getippt, leistet schon den größten Teil der Arbeit, ganz ohne Installation.

Fügen Sie die Spec ein und lassen Sie den Agenten Rückfragen stellen, bevor er irgendetwas schreibt. Ein fähiger Agent fragt nach, wenn etwas unklar ist, und eine Spec gibt ihm etwas Konkretes, wonach er fragen kann, statt stillschweigend zu raten und mit großer Sicherheit das Falsche zu bauen.

Diese schlichte Form der Gewohnheit ist übertragbar. Dasselbe dreiteilige Briefing funktioniert mit Claude Code, Codex, Copilot, Cursor oder jedem anderen Coding-Agenten, weil nichts davon auf einer Funktion eines einzelnen Werkzeugs beruht. Es ist eine Gewohnheit, die Sie aufbauen, kein Plugin, das Sie installieren.

Für einen einzelnen kleinen Build genügt eine einfache dreiteilige Spec, direkt in den Chat getippt, und sie ist schneller, als irgendetwas zu installieren. Die meisten Beispiele in diesem Leitfaden sind genau für diesen Fall geschrieben.

Spec Kit rechtfertigt den Einrichtungsaufwand, sobald Sie dies im selben Projekt wiederholt tun, seine Prinzipien automatisch bei jeder neuen Funktion durchgesetzt haben wollen oder die Struktur der Erweiterungen für Fehlerbehebung und Ideenbewertung nutzen möchten, statt jedes Mal eine eigene Variante zu erfinden.

In jedem Fall bleibt die eigentliche Fähigkeit dieselbe: festhalten, was es tut, für wen es ist und woran Sie merken, dass es fertig ist, bevor die erste Zeile Code entsteht. Das Toolkit automatisiert lediglich, dies einheitlich aufzuschreiben, sobald die Gewohnheit so oft gebraucht wird, dass sich die Automatisierung lohnt.