Die Vorteile von GitHubs Spec Kit lassen sich auch mit GitHub Copilot nutzen.
Da es von GitHub entwickelt wurde, ist das vielleicht selbstverständlich? Viele andere Tools basierten jedoch auf Claude.

Ich habe plötzlich das Gefühl, dass das auf Koreanisch auch möglich sein könnte ... Ein Puzzle ließe sich daraus jedenfalls machen ...

Ich werde es nur gut für Screening-Zwecke verwenden.

Bei Handelsaufträgen könnten durch Prompt Injection und Ähnliches unbeabsichtigte Orders ausgeführt werden; zusätzliche Funktionen wie Einschränkungen für das Ziel der Order oder Betragslimits scheinen daher zwingend erforderlich zu sein.

Entschuldigung ;;

Das erinnert mich an die Kiro IDE.

Danke.

Ja, ich denke genauso. schluchz

Das Experiment fand ich sehr interessant.

Haben Sie eine Schlagzeilen-Akademie besucht …

Wenn soziale Medien Zeitverschwendung sind, passt das Gefühl von „Bedauern“ oder „Scham“ eher dazu als bei Glücksspiel oder Drogen.

Interessant. Ergibt auch irgendwie Sinn.

Unabhängig vom Inhalt wirkt es wohl noch stärker so, weil der Titel mit der „einzeiligen Prompt“ etwas anderes erwarten lässt als das, worum es im Text tatsächlich geht.

k9s – ein Tool zur Verwaltung von Kubernetes-Clustern mit einer Terminal-UI

Der Link zur ausführlichen Vorstellung von SDD mitten im Artikel ist wirklich lesenswert. Unten ist eine KI-Zusammenfassung davon.

Spezifikationsgetriebene Entwicklung (Specification-Driven Development, SDD)

The Power Inversion

• Der bisher codezentrierte Ablauf, in dem PRD- und Design-Dokumente nur unterstützend dienten, wird umgekehrt: Die Spezifikation ist das Original, und der Code ist ein Artefakt, das in einer bestimmten Sprache bzw. einem bestimmten Framework implementiert wird
  • Es wird die Diagnose gestellt, dass die dauerhafte Lücke zwischen Spezifikation und Implementierung weder durch bessere Dokumentation noch durch strengere Prozesse leicht zu schließen war
  • Wenn ausführbare Spezifikationen und Implementierungspläne den Code erzeugen, verschwindet diese Lücke, und es bleibt nur noch Transformation
• KI ermöglicht die Interpretation komplexer Spezifikationen und die Erstellung von Implementierungsplänen, doch unstrukturierte Generierung führt zu Chaos; SDD sichert daher Qualität durch präzise Struktur und Guardrails
• Wartung ist ein Vorgang der Weiterentwicklung der Spezifikation; Entwicklungsabsicht wird durch natürliche Sprache, Design-Artefakte und Kernprinzipien ausgedrückt, während Code die letzte Meile einnimmt
• Beim Debugging steht nicht die Korrektur fehlerhaften Codes im Vordergrund, sondern zuerst die Anpassung der Spezifikation und des Implementierungsplans; Refactoring wird neu definiert als Neustrukturierung für mehr Klarheit

The SDD Workflow in Practice

• Ideen werden durch konversationelle Interaktion mit KI zu einem PRD verfeinert; die KI konkretisiert dabei Fragen, Edge Cases und Akzeptanzkriterien
  • Anforderungen und Design werden zu einer kontinuierlichen Aktivität, wodurch teamweite branchbasierte Spezifikationsarbeit sowie Reviews und Versionierung unterstützt werden
• Ein Research Agent untersucht Bibliothekskompatibilität, Performance, Sicherheit und organisatorische Einschränkungen (DB-Standards, Authentifizierung, Deployment-Richtlinien) und übernimmt diese automatisch in die Spezifikation
• Aus dem PRD wird ein Implementierungsplan erzeugt, der Anforderungen und technische Entscheidungen nachvollziehbar aufeinander abbildet; die KI prüft fortlaufend Widersprüche, Unklarheiten und Lücken
• Sobald Spezifikation und Plan ausreichend stabil sind, beginnt die Codegenerierung; anfangs dient explorative Generierung dazu, die Machbarkeit zu validieren
  • Fachliche Konzepte werden in Datenmodelle, User Stories in API-Endpunkte und Akzeptanzszenarien in Tests überführt
• Metriken und Incidents aus dem Betrieb aktualisieren die Spezifikation und fließen in die nächste Regenerierung ein; Performance-Bottlenecks werden zu nichtfunktionalen Anforderungen, Schwachstellen zu globalen Constraints hochgestuft

Why SDD Matters Now

• Schwellenwert der KI-Fähigkeiten: Aus natürlichsprachlichen Spezifikationen lässt sich verlässlich lauffähiger Code erzeugen; die Automatisierung der mechanischen Teile der Implementierungsübersetzung unterstützt Exploration und Kreativität
• Explosion der Komplexität: Durch viele Services, Frameworks und Abhängigkeiten wird es schwierig, die Konsistenz zwischen Absicht und Implementierung zu wahren; deshalb ist die spezifikationsgetriebene Ausrichtung von SDD nötig
• Beschleunigter Wandel: In Situationen mit häufigen Pivots verarbeitet SDD Änderungen nicht durch manuelle Weitergabe an Dokumentation, Design und Code, sondern durch systematische Regenerierung
  • Beispielsweise werden What-if-Simulationen und parallele Implementierungen möglich und erhöhen so die Entscheidungsagilität

Core Principles

• Spezifikation = gemeinsame Sprache: Die Spezifikation ist ein Artefakt erster Klasse, Code ist deren Ausdruck in einem bestimmten Stack, und Wartung ist die Weiterentwicklung der Spezifikation
• Ausführbare Spezifikation: Mit einer Spezifikation auf dem Niveau von Präzision, Vollständigkeit und Eindeutigkeit wird ein funktionsfähiges System erzeugt
• Kontinuierliche Verfeinerung: Statt eines einmaligen Gates erfolgt eine ständige Konsistenzprüfung
• Research-basierter Kontext: Performance, Sicherheit und organisatorische Einschränkungen werden fortlaufend gesammelt und in die Spezifikation eingespeist
• Bidirektionales Feedback: Die Realität des Betriebs wird zum Input für Spezifikations-Updates
• Branching für Exploration: Von derselben Spezifikation aus wird die Erzeugung mehrerer Implementierungen für Optimierungsziele wie Performance, Wartbarkeit, UX oder Kosten unterstützt

Implementation Approaches

• In der heutigen Praxis sind die Kombination bestehender Tools und das Einhalten von Disziplin entscheidend; umsetzen lässt sich das mit folgenden Elementen
  • KI-Assistenten zur iterativen Verfeinerung der Spezifikation
  • Research Agents zur Sammlung technischen Kontexts
  • Codegenerierungs-Tools für die Umwandlung von Spezifikation in Implementierung
  • Versionsverwaltung, angepasst an einen spec-first Workflow
  • Prüfungen auf Basis von KI-Konsistenzanalysen der Spezifikationsdokumente
• Das gemeinsame Grundprinzip lautet, die Spezifikation als Single Source of Truth zu behandeln und Code als von der Spezifikation gefordertes Ergebnis zu sehen

Streamlining SDD with Commands

• /specify: Wandelt eine Funktionsbeschreibung in eine strukturierte Spezifikation um und automatisiert automatische Nummerierung, Branch-Erstellung und die Einrichtung einer templatebasierten Verzeichnisstruktur
• /plan: Erzeugt Spezifikationsanalyse → Prüfung der Verfassungskonformität → technische Übersetzung → Dokumentation von Datenmodell, API-Verträgen und Testszenarien → Quickstart-Validierung
• /tasks: Liest plan.md und zugehörige Entwürfe, erstellt daraus eine ausführbare Task-Liste und bietet Kennzeichnung parallelisierbarer Tasks sowie sichere Parallelgruppierung
• Beispiel: Chat-Funktion
  • Es wird ein Ablauf gezeigt, bei dem sich rund 12 Stunden Dokumentationsarbeit im traditionellen Ansatz durch die Automatisierung von Spezifikation, Plan und Tasks auf etwa 15 Minuten reduzieren lassen
  • Zu den Artefakten gehören Spezifikation, Implementierungsplan mit Begründung, API-Verträge und Datenmodell, Quickstart-Szenarien sowie tasks.md, alles versionsverwaltet im Branch

The Power of Structured Automation

• Verhindern fehlender Punkte: Templates decken auch nichtfunktionale Anforderungen und Fehlerbehandlung ab
• Nachvollziehbarkeit von Entscheidungen: Jede technische Wahl ist mit konkreten Anforderungen verknüpft
• Lebende Dokumente: Da die Spezifikation den Code erzeugt, lässt sich die Synchronisierung leicht aufrechterhalten
• Schnelle Iteration: Bei Anforderungsänderungen ist durch Neu-Generierung des Plans eine Reaktion in Minuten oder Stunden möglich

Template-Driven Quality

• Verhindern vorschnellen Einsickerns von Implementierungsdetails: Regeln mit Fokus auf WHAT/WHY unter Ausschluss von HOW helfen, das Abstraktionsniveau zu halten
• Erzwingen von Unsicherheitsmarkierungen: Der Marker [NEEDS CLARIFICATION] verhindert Mutmaßungen und fördert explizite Rückfragen
• Checklistenbasierte Selbstprüfung: Durch Prüfung von Vollständigkeit, Klarheit und messbaren Akzeptanzkriterien wird ein Quality Gate umgesetzt
• Verfassungs-Gate: Checks in der Vorstufe (-1), etwa Simplicity Gate (≤3 Projekte), Anti-Abstraction Gate (Framework direkt verwenden) und Integration-First Gate (Verträge und Vertragstests zuerst)
• Geschichtete Detailverwaltung: Übermäßiger Code und Details werden in implementation-details/ ausgelagert, um die Lesbarkeit zu erhalten
• Test-Priorität: Regeln für Dateierstellung und Test-First in der Reihenfolge Vertrag → Integration → E2E → Unit sichern die Prüfbarkeit
• Eindämmung von Annahmen und spekulativen Features: Verbot spekulativer Features und explizite Voraussetzungen je Phase stärken das Scope-Management

The Constitutional Foundation

• Mit den unveränderlichen Prinzipien in memory/constitution.md wird eine Entwicklungsverfassung übernommen, die alle Implementierungen konsistent, einfach und hochwertig hält
  • Article I: Library-First — Jede Funktion beginnt als eigenständige Bibliothek und sichert so Modularität
  • Article II: CLI Mandate — Jede Bibliothek exponiert eine CLI-Schnittstelle mit Text-I/O und JSON, um Beobachtbarkeit und leichte Testbarkeit zu gewährleisten
  • Article III: Test-First — Keine Implementierung vor Testfreigabe und bestätigtem Fehlschlag (red); das Prinzip Verhalten zuerst definieren gilt
  • Articles VII & VIII: Simplicity, Anti-Abstraction — Minimierung der Projektanzahl und direktes Vertrauen in Frameworks bremsen Overengineering
  • Article IX: Integration-First Testing — Tests nah an der realen Umgebung werden bevorzugt, und Vertragstests sind verpflichtend vor der Implementierung
• Über das Phase--1-Gate der Templates wird die Verfassungskonformität in Checklisten gegossen; Ausnahmen dokumentieren ihre explizite Begründung unter Complexity Tracking
• Durch ein Änderungsverfahren kann sich die Anwendungsweise der Prinzipien weiterentwickeln, während die Kernphilosophie erhalten bleibt

The Transformation

• Ziel ist nicht der Ersatz von Entwicklern, sondern die Automatisierung mechanischer Übersetzung, um menschliche Fähigkeiten zu verstärken und die Konsistenz zwischen Absicht und Implementierung zu bewahren
• SDD setzt auf kontinuierliche Transformation, bei der Spezifikationen den Code erzeugen und sich Spezifikation, Research und Code in einem engen Feedback-Loop gemeinsam weiterentwickeln

Big-Brother-Quellcode geleakt!

Und Sie hatten auch nach den Inhalten zum Experiment bezüglich der Anzahl der Prompt-Verkettungen gefragt.

Tatsächlich ist das umgekehrt ein Faktor, mit dem der Autor, salopp gesagt, leicht mogeln kann.

Schon die Entwicklung selbst bietet sehr viele mögliche Richtungen, und wenn man Prompts in eine Richtung aufhäuft, in der der Token-Verbrauch stärker auseinandergeht, dann wird diese Zahl wie ein Schneeball immer weiter anwachsen.

In der Forschung gibt es die Philosophie der „Cumulative Science“.

Zumindest nach meinem Kenntnisstand habe ich bislang noch nie Forschung zum Token-Verbrauch bei einem einzelnen Befehl gefunden,

also habe ich mich nicht sofort auf eine Untersuchung über N Durchläufe konzentriert, sondern darauf, klare Tests und Schlussfolgerungen für einen eindeutig bestimmten Einzeldurchlauf zu behandeln,

und die Forschung zu N Durchläufen kann ja im Anschluss an dieses Experiment weitergeführt werden.

Wenn man so etwas wie Tiefbau macht, wird es bereits auch im Universitätsunterricht verwendet.

Außerdem habe ich in einem anderen Beitrag schon einmal die Unterschiede im Verhalten von KI in Abhängigkeit von den Unterschieden in der Codebasis behandelt.
(Dieser wurde auch bereits hier auf GeekNews vorgestellt: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)

Kurz gesagt geht es um Tests und Ergebnisse dazu, dass sich die Qualität der Ausgaben je nach der Codebasis unterscheidet, die der KI als Eingabe gegeben wird.

Je nach Qualität und Ausrichtung der ursprünglichen Codebasis kann die Qualität des darauf folgenden Codes erhalten bleiben oder sich fortlaufend verschlechtern.

Das bedeutet, dass sich die Kosten für Refactoring in der frühen Projektphase stark von den Kosten für Refactoring in einem bereits weit fortgeschrittenen Projekt unterscheiden können.

Falls der Fragesteller Entwickler ist, hat er vielleicht schon einmal den Ausdruck „Flugzeugträger auf einem Segelboot“ gehört.

Refactoring ist ein tiefgehendes Thema, bei dem sich die Kosten enorm unterscheiden können – je nachdem, zu welchem Zeitpunkt es durchgeführt wird und welche Prinzipien und welches Design zu Beginn eines Projekts festgelegt werden.

Anstatt dieses Thema als Variable einzubeziehen und dadurch ein unsicheres Fazit zu erhalten,

wurde ein Test durchgeführt, mit dem sich zumindest sicher erklären lässt: „Ah, wenn die Qualität der Codebasis gut ist, sinkt auch der Tokenverbrauch.“

Ich werde es noch einmal erklären.

Die Personen, die Vibe Coding betreiben, reichen von Nicht-Entwicklern bis hin zu erfahrenen Entwicklern. Je nach ihrem Wissensstand kann die Qualität der Ergebnisse völlig unabhängig vom Inhalt dieses Artikels extrem unterschiedlich ausfallen.
Jemand kann ganz selbstverständlich unter der Voraussetzung der Nutzung von Cursor in .cursorrules grundlegende OOP-Konventionen und Regeln zur Trennung von Klassen/Methoden festhalten und so in einer Form arbeiten, die kaum Refactoring erfordert,
bei jemand anderem kann aufgrund eines fehlenden Verständnisses selbst sehr grundlegender Kerninhalte eine Flut von Low-Level-Code entstehen.

Es gibt sogar bereits viele Beiträge und Erfahrungen, die im Kern empfehlen, die Codequalität grundsätzlich durch das Festlegen von Projektregeln hochzuhalten.

• Halte die Dateigröße klein: https://medium.com/realworld-ai-use-cases/…
• So hältst du die Ausführungsgeschwindigkeit einer Codebase hoch: https://forum.cursor.com/t/…
• Windsurf Best Practices und Richtlinien: https://gist.github.com/muratkeremozcan/…

Das deutet auf die Möglichkeit hin, dass manche auch ohne explizites Refactoring bereits Vorteile beim Token-Verbrauch haben könnten.

Allerdings fassen die oben genannten Fälle keine klare Verringerung des Token-Verbrauchs pro Ausführungseinheit anhand dieser Regeldefinitionen zusammen. Deshalb habe ich in diesem Beitrag die Unterschiede beim Token-Verbrauch je nach Qualität der Codebase getestet und die Ergebnisse zusammengefasst.

Mit anderen Worten: Je nach Nutzer wird die Anzahl expliziter Refactorings selbst wieder zu einer Variablen von 0 bis n,

und die eigentliche Absicht dieses Artikels ist wohl am besten so zu verstehen, dass er erklärt, „warum es sinnvoll ist, auf eine hochwertige Codebase zu achten“.