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
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.
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.“
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.
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“.
Ich verstehe nicht ganz, was Sie in Ihrem Kommentar sagen wollen. Mein Punkt war, dass man zum fairen Vergleich der beiden Methoden nicht die insgesamt verbrauchte Token-Anzahl vergleichen sollte? Verbraucht auch Refactoring nicht Tokens?
Außerdem scheint Ihre zusätzliche Antwort weder im Artikel zu stehen noch experimentell überprüft worden zu sein. Sie meinen offenbar nicht den Token-Vergleich pro einzelner Anfrage, sondern dass sich bei mehreren Anfragen der Refactoring-Overhead verringert und sich daraus durch die geringere erwartete Token-Anzahl pro Anfrage ein Vorteil bei der Gesamtzahl der Tokens ergibt. Das wäre aber nur dann zutreffend, wenn diese Kostenreduktion bei mehreren Anfragen tatsächlich so bestehen bleibt, wie Sie annehmen, und das wirkt auf mich wie eine sehr ideale Annahme. Es gibt keine Garantie dafür, dass die Kostensenkung durch Refactoring unabhängig von der Anzahl der folgenden Anfragen erhalten bleibt, und ohne Experiment kann man das auch nicht einfach voraussetzen. Wenn Sie genau diese Aussage vertreten wollen, müssten Sie die Kostensenkung über mehr als eine Anfrage hinweg experimentell zeigen. Aber haben Sie nicht nur ein einziges Experiment durchgeführt und darauf basierend verglichen?
Ergänzend: Das ist nur meine eigene Annahme, aber wenn man für dasselbe Ziel (ein ideales Endergebnis) die Anfragen unendlich oft wiederholt, dann sollte der Code im Idealfall unabhängig davon, ob Refactoring stattfindet oder nicht, gegen dieselbe Form konvergieren. (Das ideale Endergebnis ist eindeutig.)
Wenn diese Annahme vernünftig ist, dann dürfte mit zunehmender Zahl an Anfragen der Unterschied mit oder ohne Refactoring kleiner werden, sodass auch der Vorteil der Token-Kostenreduktion allmählich sinkt. Wenn man das also aus einer makroskopischen Perspektive betrachtet: Falls dieser Vorteil durch die Kostenreduktion nicht lange genug anhält, könnte der Unterschied in der insgesamt für die Anfragen verwendeten Token-Anzahl am Ende vielleicht gar nicht signifikant sein, oder?
Da dieser Text eher den Charakter einer Studie zum Thema „Experiment“ hat,
liegt der Fokus aller in diesem Text enthaltenen Zahlen darauf, dass alle, die diesen Text lesen, die Ergebnisse „reproduzieren“ können.
Daher wurden sowohl der verwendete Original-Source-Code als auch sämtliche im Test verwendeten Verfahren vollständig dokumentiert,
sodass der Inhalt darauf ausgerichtet ist, Informationen bereitzustellen, mit denen alle Versuchspersonen dieselben Ergebnisse erzielen können.
Wenn ich die Stimmung in den Kommentaren betrachte, habe ich das Gefühl,
ich sollte künftig vielleicht zwei getrennte Texte schreiben: einen mit der Tendenz zu einer Zusammenfassung in drei Zeilen
und einen weiteren für Menschen, die die Details wissen möchten.
Wenn Sie mir mitteilen, welcher Teil dieses Textes als übermäßig komplex oder zu ausführlich empfunden wurde,
würde mir das beim Verfassen künftiger Texte sehr helfen.
Es ist nötig, den Quellcode vor und nach der Vorverarbeitung zu vergleichen.
Der Untertitel passt nicht ganz zum Inhalt. Wenn man es neu ordnet, scheint „Es ist eine Analyse klarerer Faktoren nötig, die zur Token-Reduktion führen“ als Untertitel passender zu sein.
Diesem Inhalt stimme ich in vielen Punkten zu. Allerdings hat dieser Artikel auch den Charakter, den Menschen, die ihn lesen, realistische Anwendungsmethoden vorzuschlagen.
Schon an den Kommentaren unter diesem Artikel lässt sich die Stimmung erkennen; auch ich habe erst vor Kurzem erfahren, dass es unter den AI-Nutzern vermutlich viele Nicht-Entwickler gibt, die als Vibe-Coder unterwegs sind.
Wenn durch vom Autor direkt angepassten Code, also ohne den Einsatz von AI, ein herausragendes Ergebnis erzielt wird,
wirkt das leicht so, als wolle der Autor seine Entwicklungsfähigkeiten zur Schau stellen und die Fähigkeiten von AI herabsetzen.
Daher wurde als Element das „Prompt“ gewählt, das auch andere Vibe-Coder nutzen können, und es wurden Beispiele behandelt, bei denen jeder das Ergebnis nachvollziehen kann.
Ich fände es gut, wenn im Anschluss an diese Untersuchung weitere Studien folgen würden, die die Faktoren, welche den AI-Token-Verbrauch beeinflussen, differenzierter aufschlüsseln.
Vibe Coding führt nicht mit nur einem einzigen Prompt zu einem fertigen Ergebnis.
Wenn durch eine einmalige strukturelle Überarbeitung die Token-Nutzungsrate von n Prompts gesenkt wird, dann spiegelt sich diese Reduktion über alle n identisch ausgeführten Durchläufe hinweg wider.
Dabei ist n ein Wert, der durch Ziel und Funktionsumfang des Projekts sowie durch Menge und Komplexität des dafür nötigen Codes bestimmt wird.
Außerdem gab es zuletzt bei Cursor- und Claude-Code-Agenten Updates, die die Ausführungseinheiten kleiner halten, um Probleme wie Endlosschleifen oder den unkontrollierten Token-Verbrauch durch KI zu lösen.
Ich halte es daher für richtig, Studien zum n-Wert in Bezug auf die Projektkomplexität getrennt durchzuführen.
Um das Verständnis möglichst zu erleichtern, wurde als Beispiel eine Codeverbesserung ausgehend von von der KI geschriebenem Code mit strukturellen Problemen gezeigt, sofern keine gesonderten Vorgaben gemacht werden.
Was man an dieser Stelle nicht übersehen darf, ist, dass eine Verbesserung der Struktur niemals ein Vorgang ist, der absolut unabhängig von der eigentlichen Codeentwicklung stattfindet.
Sie kann bereits über den ersten Prompt oder über Einschränkungen wie ein KI-Regelwerk (.cursorrules) als Base Context Einfluss nehmen.
Und eine einzige strukturelle Verbesserung kann im Verlauf des Projektentwicklungszyklus nicht alle Probleme auf einmal lösen.
Mit anderen Worten: Statt Codeverbesserungen in festen Intervallen zu planen, ist es sinnvoller, als Base Context von Anfang an die richtige Struktur anzuleiten.
Außerdem erscheint es sinnvoll, die Untersuchung getrennt danach durchzuführen, ob es als Base Context Regeln zur strukturellen Anleitung gibt oder nicht.
Zur Zusammenfassung von Punkt 1:
Wenn es als Base Context Regeln zur strukturellen Anleitung gibt, kann der gesamte Token-Verbrauch möglicherweise sinken, und
da es die Variable gibt, dass das Endergebnis über n Prompt-Anweisungen erreicht wird,
ist die Behauptung irreführend, man müsse den Token-Verbrauch eines einzelnen Prompts zur strukturellen Verbesserung zusätzlich aufschlagen und so berechnen.
Das habe ich ähnlich empfunden.
Ich verstehe zwar die Absicht des Autors, aber im Verhältnis zu dem, was gemacht wurde, wirkt der Text übermäßig komplex.
Vermutlich wurde er so geschrieben, weil möglichst viele der im Experiment verwendeten Details in den Text einfließen sollten.
Wenn Sie aber nur die Kernaussagen knapp herausziehen, werden Leser, die sich für so ein Thema interessieren, es wahrscheinlich trotzdem verstehen.
Wenn Sie mutig Details weglassen und nur das Wesentliche zusammenfassen, wäre es meiner Meinung nach besser.
Ich fand die Absicht des Autors und auch das Ergebnis selbst interessant.
Die Hauptthese ist, dass besserer Sourcecode zu geringerem Token-Verbrauch führt,
und dazu scheint ein entsprechendes Experiment entworfen und durchgeführt worden zu sein.
Wenn ich nur das aufzähle, was ich vom Experiment verstanden habe:
Es wurden zwei Versionen vorbereitet: der Sourcecode, zu dem die KI befragt werden sollte, und derselbe Sourcecode, der per Prompt vorverarbeitet (?) wurde.
Auf GPT5 und Sonnet wurden beide Sourcecodes jeweils fünfmal ausgeführt und der Token-Verbrauch verglichen.
So scheint es zu sein.
Und wenn ich es richtig verstanden habe, lautet das Fazit, dass der per Prompt vorverarbeitete Sourcecode insgesamt weniger Tokens verbraucht.
Ein interessantes Fazit, aber meine Meinung zum Experiment ist wie folgt.
Kein fairer Vergleich
Zahlenmäßig scheint der Verbrauch zwar gesunken zu sein, aber eigentlich müsste man die gesamte Token-Zahl vergleichen, die für die Verarbeitung des Sourcecodes benötigt wurde.
Anders gesagt sollten auch die Tokens berücksichtigt werden, die für die Vorverarbeitung verbraucht wurden.
Wenn die dafür verwendete Token-Zahl übermäßig groß war, wurde in Wirklichkeit insgesamt mehr verbraucht und das Ganze wäre damit bedeutungslos. Und selbst wenn sie gering war, dürfte der tatsächliche Unterschied beim Token-Verbrauch deutlich kleiner sein, als es der Text vermuten lässt.
Ein Vergleich des Sourcecodes vor und nach der Vorverarbeitung ist nötig.
Wenn man die für die Vorverarbeitung verwendeten Tokens ausklammert, scheint der Token-Verbrauch bei der Anfrage tatsächlich signifikant gesunken zu sein.
Wenn man aber analysiert, welcher genaue Unterschied im Sourcecode zu diesem Effekt führt, würde der Beitrag deutlich an Aussagekraft gewinnen.
Denn das würde bedeuten, dass sich der Vorverarbeitungs-Prompt optimieren lässt, um genau diese Unterschiede zu maximieren.
Der Autor sagt, dass das Refactoring der Code-Struktur zu diesem Ergebnis geführt habe, aber ich stimme dem nicht zu und denke, dass man das noch nicht wissen kann.
Denn auch wenn man die KI nicht zum Refactoring, sondern zur Verbesserung anderer Aspekte einsetzt, könnte der Token-Verbrauch sinken.
Es braucht vielfältigere Experimente
Ich denke, derselbe Versuch sollte nicht nur mit dem aktuellen Code, sondern auch mit anderen Codebasen durchgeführt werden.
Denn man muss beurteilen können, ob das konsistent gute Ergebnisse liefert oder nicht.
Ich verstehe allerdings, dass das in der Praxis schwer zu testen sein kann, daher würde ich das nur als Hinweis betrachten.
Ich fasse ergänzend die Inhalte zu dem verwendeten Prompt zusammen.
Offenbar ist das besonders für Entwickler vorteilhaft, wenn sie Prompts zur Verbesserung der Struktur schreiben. Da jedes Programm unterschiedliche Eigenschaften hat, ist für hocheffiziente Optimierungen ein gewisses Maß an Entwicklungswissen erforderlich.
Das bedeutet jedoch nicht, dass Vibe-Coder ohne Entwicklerhintergrund diese Methode nicht nutzen können. Die Effizienz mag unterschiedlich ausfallen, aber selbst mit einfachen Anweisungen wie „Bitte räume den Projektcode etwas auf. Entferne ungenutzten Code.“ trennt und organisiert die AI Dateien und Klassen.
Allerdings kann der Unterschied im Detailgrad der Strukturverbesserung zu Effizienzunterschieden führen, daher ist beim Referenzmaterial Vorsicht geboten.
Vielen Dank für das große Interesse an diesem Beitrag. Da der Hauptzweck offenbar die Verbreitung im Ausland ist, wurde der Artikel auf Englisch verfasst, wodurch wohl verschiedene Probleme entstehen.
Daher teile ich hier einen auf Koreanisch zusammengefassten Beitrag.
Der Kern der Aussage ist, dass nach der Anweisung an die AI, die Codestruktur zu refaktorieren, der Tokenverbrauch gesunken ist.
Umgekehrt könnte man auch erklären, dass der Tokenverbrauch steigt, wenn man Befehle in einem Zustand mit strukturellen Mängeln im Code weiterführt.
Zusammengefasst geht es darum, dass die Struktur des Quellcodes verbessert werden muss; es bedeutet nicht, dass der Prompt nur die Kernaussagen logisch verdichtet enthalten sollte.
Man sollte im Prompt nur das Wesentliche logisch formulieren. Heißt das also, je mehr man diesem und jenem in den Prompt packt, desto mehr Rauschen entsteht und desto komplexer und rauschbehafteter wird auch der daraus resultierende Code?
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
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
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: Liestplan.mdund zugehörige Entwürfe, erstellt daraus eine ausführbare Task-Liste und bietet Kennzeichnung parallelisierbarer Tasks sowie sichere ParallelgruppierungThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]verhindert Mutmaßungen und fördert explizite Rückfragenimplementation-details/ausgelagert, um die Lesbarkeit zu erhaltenThe Constitutional Foundation
memory/constitution.mdwird eine Entwicklungsverfassung übernommen, die alle Implementierungen konsistent, einfach und hochwertig hältThe Transformation
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
.cursorrulesgrundlegende 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.
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“.
Ich verstehe nicht ganz, was Sie in Ihrem Kommentar sagen wollen. Mein Punkt war, dass man zum fairen Vergleich der beiden Methoden nicht die insgesamt verbrauchte Token-Anzahl vergleichen sollte? Verbraucht auch Refactoring nicht Tokens?
Außerdem scheint Ihre zusätzliche Antwort weder im Artikel zu stehen noch experimentell überprüft worden zu sein. Sie meinen offenbar nicht den Token-Vergleich pro einzelner Anfrage, sondern dass sich bei mehreren Anfragen der Refactoring-Overhead verringert und sich daraus durch die geringere erwartete Token-Anzahl pro Anfrage ein Vorteil bei der Gesamtzahl der Tokens ergibt. Das wäre aber nur dann zutreffend, wenn diese Kostenreduktion bei mehreren Anfragen tatsächlich so bestehen bleibt, wie Sie annehmen, und das wirkt auf mich wie eine sehr ideale Annahme. Es gibt keine Garantie dafür, dass die Kostensenkung durch Refactoring unabhängig von der Anzahl der folgenden Anfragen erhalten bleibt, und ohne Experiment kann man das auch nicht einfach voraussetzen. Wenn Sie genau diese Aussage vertreten wollen, müssten Sie die Kostensenkung über mehr als eine Anfrage hinweg experimentell zeigen. Aber haben Sie nicht nur ein einziges Experiment durchgeführt und darauf basierend verglichen?
Ergänzend: Das ist nur meine eigene Annahme, aber wenn man für dasselbe Ziel (ein ideales Endergebnis) die Anfragen unendlich oft wiederholt, dann sollte der Code im Idealfall unabhängig davon, ob Refactoring stattfindet oder nicht, gegen dieselbe Form konvergieren. (Das ideale Endergebnis ist eindeutig.)
Wenn diese Annahme vernünftig ist, dann dürfte mit zunehmender Zahl an Anfragen der Unterschied mit oder ohne Refactoring kleiner werden, sodass auch der Vorteil der Token-Kostenreduktion allmählich sinkt. Wenn man das also aus einer makroskopischen Perspektive betrachtet: Falls dieser Vorteil durch die Kostenreduktion nicht lange genug anhält, könnte der Unterschied in der insgesamt für die Anfragen verwendeten Token-Anzahl am Ende vielleicht gar nicht signifikant sein, oder?
Da dieser Text eher den Charakter einer Studie zum Thema „Experiment“ hat,
liegt der Fokus aller in diesem Text enthaltenen Zahlen darauf, dass alle, die diesen Text lesen, die Ergebnisse „reproduzieren“ können.
Daher wurden sowohl der verwendete Original-Source-Code als auch sämtliche im Test verwendeten Verfahren vollständig dokumentiert,
sodass der Inhalt darauf ausgerichtet ist, Informationen bereitzustellen, mit denen alle Versuchspersonen dieselben Ergebnisse erzielen können.
Wenn ich die Stimmung in den Kommentaren betrachte, habe ich das Gefühl,
ich sollte künftig vielleicht zwei getrennte Texte schreiben: einen mit der Tendenz zu einer Zusammenfassung in drei Zeilen
und einen weiteren für Menschen, die die Details wissen möchten.
Wenn Sie mir mitteilen, welcher Teil dieses Textes als übermäßig komplex oder zu ausführlich empfunden wurde,
würde mir das beim Verfassen künftiger Texte sehr helfen.
Dem stimme ich voll und ganz zu. Solche Formen der Kritik begrüße ich sehr.
Man lebt nicht allein auf der Welt, und die Fähigkeiten oder Umstände jedes Einzelnen sind unterschiedlich.
Auch ich bin letztlich nur ein Entwickler und kann nicht alle Tests auf eigene Kosten durchführen.
Ich hoffe, dass dieser Beitrag als Samen dient, viele Menschen positiv beeinflusst und zum Ausgangspunkt für viele weitere Forschungen wird.
Der Untertitel passt nicht ganz zum Inhalt. Wenn man es neu ordnet, scheint „Es ist eine Analyse klarerer Faktoren nötig, die zur Token-Reduktion führen“ als Untertitel passender zu sein.
Diesem Inhalt stimme ich in vielen Punkten zu. Allerdings hat dieser Artikel auch den Charakter, den Menschen, die ihn lesen, realistische Anwendungsmethoden vorzuschlagen.
Schon an den Kommentaren unter diesem Artikel lässt sich die Stimmung erkennen; auch ich habe erst vor Kurzem erfahren, dass es unter den AI-Nutzern vermutlich viele Nicht-Entwickler gibt, die als Vibe-Coder unterwegs sind.
Wenn durch vom Autor direkt angepassten Code, also ohne den Einsatz von AI, ein herausragendes Ergebnis erzielt wird,
wirkt das leicht so, als wolle der Autor seine Entwicklungsfähigkeiten zur Schau stellen und die Fähigkeiten von AI herabsetzen.
Daher wurde als Element das „Prompt“ gewählt, das auch andere Vibe-Coder nutzen können, und es wurden Beispiele behandelt, bei denen jeder das Ergebnis nachvollziehen kann.
Ich fände es gut, wenn im Anschluss an diese Untersuchung weitere Studien folgen würden, die die Faktoren, welche den AI-Token-Verbrauch beeinflussen, differenzierter aufschlüsseln.
Wenn durch eine einmalige strukturelle Überarbeitung die Token-Nutzungsrate von n Prompts gesenkt wird, dann spiegelt sich diese Reduktion über alle n identisch ausgeführten Durchläufe hinweg wider.
Dabei ist n ein Wert, der durch Ziel und Funktionsumfang des Projekts sowie durch Menge und Komplexität des dafür nötigen Codes bestimmt wird.
Außerdem gab es zuletzt bei Cursor- und Claude-Code-Agenten Updates, die die Ausführungseinheiten kleiner halten, um Probleme wie Endlosschleifen oder den unkontrollierten Token-Verbrauch durch KI zu lösen.
Ich halte es daher für richtig, Studien zum n-Wert in Bezug auf die Projektkomplexität getrennt durchzuführen.
Was man an dieser Stelle nicht übersehen darf, ist, dass eine Verbesserung der Struktur niemals ein Vorgang ist, der absolut unabhängig von der eigentlichen Codeentwicklung stattfindet.
Sie kann bereits über den ersten Prompt oder über Einschränkungen wie ein KI-Regelwerk (
.cursorrules) als Base Context Einfluss nehmen.Und eine einzige strukturelle Verbesserung kann im Verlauf des Projektentwicklungszyklus nicht alle Probleme auf einmal lösen.
Mit anderen Worten: Statt Codeverbesserungen in festen Intervallen zu planen, ist es sinnvoller, als Base Context von Anfang an die richtige Struktur anzuleiten.
Außerdem erscheint es sinnvoll, die Untersuchung getrennt danach durchzuführen, ob es als Base Context Regeln zur strukturellen Anleitung gibt oder nicht.
Zur Zusammenfassung von Punkt 1:
ist die Behauptung irreführend, man müsse den Token-Verbrauch eines einzelnen Prompts zur strukturellen Verbesserung zusätzlich aufschlagen und so berechnen.
Das habe ich ähnlich empfunden.
Ich verstehe zwar die Absicht des Autors, aber im Verhältnis zu dem, was gemacht wurde, wirkt der Text übermäßig komplex.
Vermutlich wurde er so geschrieben, weil möglichst viele der im Experiment verwendeten Details in den Text einfließen sollten.
Wenn Sie aber nur die Kernaussagen knapp herausziehen, werden Leser, die sich für so ein Thema interessieren, es wahrscheinlich trotzdem verstehen.
Wenn Sie mutig Details weglassen und nur das Wesentliche zusammenfassen, wäre es meiner Meinung nach besser.
Ich fand die Absicht des Autors und auch das Ergebnis selbst interessant.
Die Hauptthese ist, dass besserer Sourcecode zu geringerem Token-Verbrauch führt,
und dazu scheint ein entsprechendes Experiment entworfen und durchgeführt worden zu sein.
Wenn ich nur das aufzähle, was ich vom Experiment verstanden habe:
So scheint es zu sein.
Und wenn ich es richtig verstanden habe, lautet das Fazit, dass der per Prompt vorverarbeitete Sourcecode insgesamt weniger Tokens verbraucht.
Ein interessantes Fazit, aber meine Meinung zum Experiment ist wie folgt.
Kein fairer Vergleich
Zahlenmäßig scheint der Verbrauch zwar gesunken zu sein, aber eigentlich müsste man die gesamte Token-Zahl vergleichen, die für die Verarbeitung des Sourcecodes benötigt wurde.
Anders gesagt sollten auch die Tokens berücksichtigt werden, die für die Vorverarbeitung verbraucht wurden.
Wenn die dafür verwendete Token-Zahl übermäßig groß war, wurde in Wirklichkeit insgesamt mehr verbraucht und das Ganze wäre damit bedeutungslos. Und selbst wenn sie gering war, dürfte der tatsächliche Unterschied beim Token-Verbrauch deutlich kleiner sein, als es der Text vermuten lässt.
Ein Vergleich des Sourcecodes vor und nach der Vorverarbeitung ist nötig.
Wenn man die für die Vorverarbeitung verwendeten Tokens ausklammert, scheint der Token-Verbrauch bei der Anfrage tatsächlich signifikant gesunken zu sein.
Wenn man aber analysiert, welcher genaue Unterschied im Sourcecode zu diesem Effekt führt, würde der Beitrag deutlich an Aussagekraft gewinnen.
Denn das würde bedeuten, dass sich der Vorverarbeitungs-Prompt optimieren lässt, um genau diese Unterschiede zu maximieren.
Der Autor sagt, dass das Refactoring der Code-Struktur zu diesem Ergebnis geführt habe, aber ich stimme dem nicht zu und denke, dass man das noch nicht wissen kann.
Denn auch wenn man die KI nicht zum Refactoring, sondern zur Verbesserung anderer Aspekte einsetzt, könnte der Token-Verbrauch sinken.
Es braucht vielfältigere Experimente
Ich denke, derselbe Versuch sollte nicht nur mit dem aktuellen Code, sondern auch mit anderen Codebasen durchgeführt werden.
Denn man muss beurteilen können, ob das konsistent gute Ergebnisse liefert oder nicht.
Ich verstehe allerdings, dass das in der Praxis schwer zu testen sein kann, daher würde ich das nur als Hinweis betrachten.
Nutzlose Geschenke zu machen scheint gerade beliebt zu sein … um neue nutzlose Geschenke aufzuspüren, ist das wohl ganz gut.
Ich fasse ergänzend die Inhalte zu dem verwendeten Prompt zusammen.
Offenbar ist das besonders für Entwickler vorteilhaft, wenn sie Prompts zur Verbesserung der Struktur schreiben. Da jedes Programm unterschiedliche Eigenschaften hat, ist für hocheffiziente Optimierungen ein gewisses Maß an Entwicklungswissen erforderlich.
Das bedeutet jedoch nicht, dass Vibe-Coder ohne Entwicklerhintergrund diese Methode nicht nutzen können. Die Effizienz mag unterschiedlich ausfallen, aber selbst mit einfachen Anweisungen wie „Bitte räume den Projektcode etwas auf. Entferne ungenutzten Code.“ trennt und organisiert die AI Dateien und Klassen.
Allerdings kann der Unterschied im Detailgrad der Strukturverbesserung zu Effizienzunterschieden führen, daher ist beim Referenzmaterial Vorsicht geboten.
Wenn Sie mit Geodaten arbeiten müssen, ist das eine gute Wahl.
Vielen Dank für das große Interesse an diesem Beitrag. Da der Hauptzweck offenbar die Verbreitung im Ausland ist, wurde der Artikel auf Englisch verfasst, wodurch wohl verschiedene Probleme entstehen.
Daher teile ich hier einen auf Koreanisch zusammengefassten Beitrag.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Der Kern der Aussage ist, dass nach der Anweisung an die AI, die Codestruktur zu refaktorieren, der Tokenverbrauch gesunken ist.
Umgekehrt könnte man auch erklären, dass der Tokenverbrauch steigt, wenn man Befehle in einem Zustand mit strukturellen Mängeln im Code weiterführt.
Zusammengefasst geht es darum, dass die Struktur des Quellcodes verbessert werden muss; es bedeutet nicht, dass der Prompt nur die Kernaussagen logisch verdichtet enthalten sollte.
Man sollte im Prompt nur das Wesentliche logisch formulieren. Heißt das also, je mehr man diesem und jenem in den Prompt packt, desto mehr Rauschen entsteht und desto komplexer und rauschbehafteter wird auch der daraus resultierende Code?
Doppelt gemoppelt
Ich bin der Autor. Vielen Dank für das Feedback. Ich werde es beim Verfassen des nächsten Artikels berücksichtigen.