Thema: Teil 2. Warum Entwicklung nach Spezifikationen
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden (Theorie + Praxis)
Voraussetzungen: Grundlegendes Verständnis der Arbeit mit KI-Assistenten (Qwen, ChatGPT, Claude u. a.)
Erfahrung mit Versionskontrollsystemen (Git)
Grundkenntnisse der Webentwicklung (HTML, CSS, JavaScript/TypeScript)
Verständnis grundlegender Konzepte der Softwarearchitektur
Erfahrung mit der Kommandozeile und npm-Skripten
Lernziele: Fünf typische Vibe-Coding-Fehler erklären und deren Beseitigungsmechanismen durch SDD (Specification-Driven Development) darlegen
Antworten auf sieben Kontrollfragen zur Prüfung der Bereitschaft einer Feature-Spezifikation zur Implementierung formulieren
Eine vollwertige Mini-Spezifikation eines Features im Format requirements/plan/validation für ein Qwen Code-Projekt erstellen
Den Unterschied zwischen SDD auf Feature-Ebene und dem klassischen Wasserfallmodell herausarbeiten
Die praktische Regel zur Bestimmung der Notwendigkeit einer Spezifikation für eine konkrete Code-Änderung anwenden
Überblick: Dieses Modul widmet sich dem Übergang vom chaotischen Vibe-Coding zur disziplinierten Entwicklung nach Spezifikationen (SDD) bei der Arbeit mit KI-Agenten, insbesondere mit Qwen Code. Vibe-Coding ist ein Ansatz, bei dem der Entwickler sequenzielle impulsive Befehle an die KI gibt, dabei architektonischen Kontext verliert und technische Schulden ansammelt. SDD löst dieses Problem durch die Erstellung versionierbarer, prüfbarer und agentenlesbarer Dokumente, die Absichten, Grenzen, getroffene Entscheidungen und Akzeptanzkriterien festhalten. Das Modul deckt typische Pathologien des Vibe-Codings, die Struktur eines stabilen Arbeitszyklus mit Qwen Code, sieben Fragen zur Qualität einer Spezifikation, Kriterien für SDD-Redundanz und die Praxis des Verfassens von Mini-Spezifikationen ab.
Schlüsselkonzepte: Vibe-Coding: Ein Ansatz zur Entwicklung mit KI-Assistenten, der auf kontinuierlicher Improvisation basiert: Der Entwickler gibt kurze Befehle im Chat, der Agent führt sie sofort aus, der Kontext existiert nur innerhalb einer flüchtigen Sitzung. Nützlich für Prototyping und Erkundung, verursacht aber fünf kritische Fehler: Absichtsverschiebung, Kontextzerfall, unprüfbares Ergebnis, verborgene Entscheidungen, Reviewer-Ermüdung.
SDD (Specification-Driven Development): Eine Entwicklungsmethodik, bei der der KI-Agent nicht nur den Befehl „mach“ erhält, sondern strukturierten Kontext in Form versionierbarer Dateien: Projektmission, Technologie-Stack, Roadmap, Spezifikationen einzelner Features. Verlagert Wissen aus flüchtiger Korrespondenz in das Repository, macht Fehler früh, klein und prüfbar.
Absichtsverschiebung: Ein typischer Vibe-Coding-Fehler: Der Agent interpretiert „einfaches Formular“ als Anlass, komplexes Zustandsmanagement, eine neue Bibliothek, eine alternative Oberflächengestaltung hinzuzufügen – alles, was der Entwickler nicht angefordert, aber der Agent für sinnvoll gehalten hat.
Kontextzerfall: Verlust architektonischer Entscheidungen zwischen Sitzungen mit dem Agenten. Nach einigen Iterationen vergisst der Agent, warum das Projekt kein ORM verwendet, warum die API HTML serverseitig rendert, warum ein bestimmter Stack gewählt wurde – und trifft widersprüchliche Entscheidungen erneut.
Stabiler Arbeitszyklus mit Qwen Code: Eine Alternative zur langen improvisatorischen Sitzung: drei getrennte Phasen mit erzwungenem Kontextlöschen (/clear). Phase 1 – Lesen der Basisspezifikationen und Erstellen eines Feature-Plans mit präzisierenden Fragen. Phase 2 – Implementierung einer streng begrenzten Teilmenge von Aufgaben nach konkretem Plan. Phase 3 – Validierung des Ergebnisses nach vorab festgelegten Kriterien mit Auflistung von Abweichungen vor Korrekturen.
Mini-Spezifikation eines Features: Ein kompaktes Dokument (keine 80 Seiten Wasserfall), ausgerichtet auf eine Phase, einen Branch, einen Merge. Besteht aus drei Dateien: requirements.md (Anforderungen und Grenzen), plan.md (Implementierungsplan), validation.md (Prüfkriterien). Eigenschaften: klein, prüfbar, mit der Roadmap verknüpft, für einen neuen Agenten ohne vorherigen Chat verständlich, streng genug, um Raten auszuschließen.
Sieben Fragen der Spezifikation: Eine Checkliste zur inhaltlichen Bereitschaft: (1) Geschäftsabsicht hinter dem Feature, (2) Benutzer und Szenario, (3) Arbeitsgrenzen, (4) getroffene und offene Entscheidungen, (5) unverzichtbare Einschränkungen, (6) was nicht kaputtgehen darf, (7) wie die Korrektheit des Ergebnisses nachgewiesen wird. Das Fehlen einer Antwort auf eine beliebige Frage bedeutet Unbereitschaft zur Implementierung.
Negative Anforderungen: Festhaltung bestehenden Verhaltens, das ein Feature nicht beeinträchtigen darf. Kritisch wichtig zur Verhinderung von Regressionen bei der Arbeit mit Agenten, die zu weitreichenden Änderungen neigen. Werden in Teil 7 des Kurses ausführlicher behandelt.
Praktische Redundanzregel: Eine Heuristik zur Bestimmung der Notwendigkeit einer Spezifikation: Wenn eine Änderung verständlich und in 5 Minuten prüfbar ist – reicht eine gewöhnliche Anfrage; wenn sie Architektur, Daten, Sicherheit, öffentliches Verhalten oder mehrere Dateien berührt – ist eine Spezifikation erforderlich; wenn ein Agent autonom länger als einige Minuten arbeitet – amortisiert sich eine Spezifikation fast immer.
Grenzen und jenseits der Grenzen: Explizit aufgeführte Ein- und Ausschlüsse in der Feature-Spezifikation. Schützen vor Umfangsaufblähung (scope creep) und verhindern, dass der Agent „nachdenkt“ über Funktionalität, die der Entwickler nicht bestellt hat.
Übungsaufgaben: Titel: Diagnose eines Vibe-Coding-Fehlers
Problem: Lesen Sie das folgende Szenario und bestimmen Sie, welcher der fünf typischen Vibe-Coding-Fehler aufgetreten ist: Ein Entwickler bittet den Agenten, „Bewertungen zu Produkten hinzuzufügen“. Der Agent erstellt ein vollwertiges Bewertungssystem mit Moderation, Benachrichtigungen, Analytik und Integration mit einem externen Dienst. Der Entwickler wollte nur die Anzeige von Textbewertungen unter der Produktkarte. In der nächsten Sitzung schlägt der Agent vor, die bestehende SQLite durch PostgreSQL für „Skalierbarkeit“ zu ersetzen. Der Entwickler verbringt 2 Stunden mit dem Zurückrollen von Änderungen.
Lösung: Schritt 1: Wir identifizieren den ersten Fehler – der Agent hat unverbundene Funktionalität (Bewertungen, Moderation, Benachrichtigungen, Analytik, externer Dienst) anstelle des angeforderten Minimums hinzugefügt. Dies ist eine klassische Absichtsverschiebung: die Interpretation von „Bewertungen“ als Anlass für ein Ökosystem. Schritt 2: Wir identifizieren den zweiten Fehler – in der neuen Sitzung erinnert sich der Agent nicht an/berücksichtigt nicht die Entscheidung über SQLite und schlägt PostgreSQL vor. Dies ist Kontextzerfall: die architektonische Entscheidung über den Speicher-Stack ist verloren gegangen. Schritt 3: Wir identifizieren den dritten Fehler – das Ergebnis erfordert 2 Stunden zum Zurückrollen, was bedeutet, dass die Änderungen nach Umfang unprüfbar und nach Auswirkungen unvorhersehbar waren (unprüfbares Ergebnis + Reviewer-Ermüdung). Schritt 4: Wir schlagen eine SDD-Lösung vor: Erstellen von specs/2026-05-08-reviews-display/requirements.md mit expliziten Grenzen („nur Anzeige“, „ohne Bewertungen“, „ohne Moderation in dieser Phase“), Festhalten der SQLite-Entscheidung in tech-stack.md, Erstellen von validation.md mit Prüfung auf Abwesenheit neuer Abhängigkeiten.
Schwierigkeitsgrad: mittel
Titel: Erstellung einer Mini-Spezifikation für Admin-Login
Problem: Nehmen Sie das Feature „Füge Login hinzu“ aus dem Kursbeispiel. Transformieren Sie die impulsive Anfrage in eine vollwertige Mini-Spezifikation mit drei Dateien: requirements.md, plan.md, validation.md. Verwenden Sie die sieben Fragen als Inhaltsprüfung. Formulieren Sie dann drei präzisierende Fragen, die Sie dem Agenten vor Beginn der Implementierung stellen würden.
Lösung: Schritt 1: requirements.md – Struktur: # Anforderungen – Admin-Login; ## Grenzen (eine Login-Seite, Cookie-Sitzung, ohne Selbstregistrierung, ohne Passwort-Reset in dieser Phase); ## Jenseits der Grenzen (OAuth, JWT, Benutzerregistrierung, Passwort-Reset, Multi-Faktor-Authentifizierung); ## Entscheidungen (ein Administrator in SQLite, httpOnly-Cookie, Schutz nur für /dashboard); ## Prüfung (Testszenarien). Schritt 2: plan.md – Dekomposition in Aufgabengruppen: (1) Datenschema und Benutzermodell, (2) Routen /login und /dashboard mit Middleware, (3) Formular und Validierung, (4) Tests. Schritt 3: validation.md – Konkrete Prüfungen: Nicht authentifizierter GET /dashboard → 302 zu /login; falsches Passwort → allgemeine Fehlermeldung ohne Leak der Benutzerexistenz; korrektes Passwort → httpOnly-Cookie + 302 zu /dashboard; npm test und npm run typecheck bestehen; keine neuen Abhängigkeiten außer bcrypt und cookie-parser. Schritt 4: Prüfung anhand der sieben Fragen: (1) Absicht – eingeschränkter Zugang zum Admin-Panel, (2) Benutzer – einzelner Administrator, (3) Grenzen – explizit aufgeführt, (4) Entscheidungen – SQLite, Cookie, bcrypt festgehalten, (5) Einschränkungen – httpOnly, Schutz nur für /dashboard, (6) negative Anforderungen – wir brechen öffentliche Seiten nicht, (7) Nachweis – 4 Testszenarien + CI-Prüfungen. Schritt 5: Präzisierende Fragen an den Agenten: „Bestätige, dass du verstehst: Kein Passwort-Reset in dieser Phase bedeutet Abwesenheit der Route /forgot-password und Abwesenheit einer Integration mit E-Mail-Dienst“; „Schlage eine Alternative zu bcrypt mit Begründung vor, falls du sie für SQLite als unoptimal erachtest“; „Wie prüfst du, dass das Cookie tatsächlich httpOnly ist und nicht über document.cookie zugänglich?"
Schwierigkeitsgrad: mittel
Titel: Entwurf eines stabilen Zyklus für ein Feature
Problem: Sie haben ein Next.js-Blogprojekt mit einer Roadmap: Phase 1 – Basis-Posts, Phase 2 – Kommentare, Phase 3 – Tags und Suche. Sie möchten Phase 2 (Kommentare) implementieren. Entwerfen Sie drei Qwen Code-Sitzungen mit Verwendung von /clear, geben Sie an, welche Spezifikationsdateien der Agent in jeder Sitzung liest, und welche konkreten Anweisungen er erhält. Begründen Sie die Aufteilung in drei Sitzungen.
Lösung: Schritt 1: Sitzung „Erkundung und Planung“ – /clear; Lesen von @specs/mission.md (Projektziel: minimalistischer Blog mit Fokus auf Lesbarkeit), @specs/tech-stack.md (Next.js 14 App Router, Prisma + PostgreSQL, Tailwind, React Server Components standardmäßig), @specs/roadmap.md (Phase 1 abgeschlossen, Phase 2 – Kommentare, Phase 3 – Tags). Anweisung: „Erstelle eine Feature-Spezifikation für Phase 2 der Roadmap. Stelle mir zuerst Fragen zu Unklarheiten. Schreibe keinen Code.“ Begründung: Der Agent muss den Projektkontext verstehen, ohne ihn mit vorherigen Sitzungen zu vermischen, und Unklarheiten vor der Implementierung formulieren. Schritt 2: Sitzung „Implementierung“ – /clear; Lesen von @specs/mission.md, @specs/tech-stack.md, @specs/2026-05-15-comments/plan.md (in Sitzung 1 erstellt). Anweisung: „Implementiere nur Aufgabengruppen 1 und 2 des Plans: Prisma-Schema für Kommentare und API-Route POST /api/posts/[id]/comments. Ändere keine unverbundenen Dateien. Füge in dieser Sitzung kein UI hinzu.“ Begründung: Die Begrenzung des Arbeitsumfangs verhindert Absichtsverschiebung, klare Grenzen schützen vor Umfangsaufblähung. Schritt 3: Sitzung „Validierung“ – /clear; Lesen von @specs/2026-05-15-comments/validation.md. Anweisung: „Vergleiche die aktuelle Implementierung mit validation.md. Liste Abweichungen vor Korrekturen auf. Schlage dann minimale Korrekturen vor.“ Begründung: Eine separate Prüfsitzung verhindert impulsive Korrekturen, erzwingt explizite Problemerkennung, schützt vor Reviewer-Ermüdung durch strukturiertes Protokoll.
Schwierigkeitsgrad: fortgeschritten
Titel: Anwendung der praktischen Redundanzregel
Problem: Bewerten Sie nach der praktischen Regel, ob eine vollwertige Spezifikation (requirements/plan/validation) für jede der folgenden Änderungen erforderlich ist: (A) Korrektur eines Tippfehlers in der Überschrift der Startseite; (B) Hinzufügen eines Feldes „Biografie“ im Benutzerprofil mit Validierung auf 500 Zeichen; (C) Umstieg von SQLite auf PostgreSQL für Unterstützung konkurrierender Schreibzugriffe; (D) Erstellung eines Einweg-Datenmigrationsskripts für internen Gebrauch; (E) Implementierung einer Stripe-Zahlungsintegration für Abonnements.
Lösung: Schritt 1: (A) Tippfehlerkorrektur – Änderung einer Datei, in 30 Sekunden verständlich, visuell prüfbar. Praktische Regel: < 5 Minuten, einmalig, berührt keine Architektur. Entscheidung: gewöhnliche Anfrage, ohne Spezifikation. Schritt 2: (B) Biografie-Feld – berührt Datenschema, Validierung, Formular, API, möglicherweise Tests. Aber Änderung ist lokalisiert, schematisch, Agent arbeitet < 5 Minuten. Grenzen sind offensichtlich. Entscheidung: Leichte Anfrage mit Kontext im Chat kann ausreichen, aber minimale Fixierung in requirements.md erhöht Zuverlässigkeit. Grenzfall – kann ohne vollständigen Zyklus auskommen. Schritt 3: (C) Umstieg SQLite → PostgreSQL – architektonische Entscheidung, berührt Daten, Konfiguration, möglicherweise ORM-Abfragen, Tests, CI/CD. Agent wird lange arbeiten, Fehler sind teuer. Entscheidung: Vollständige Spezifikation mit expliziten Entscheidungen, negativen Anforderungen (was wir nicht brechen), Migrationsplan, Validierung. Schritt 4: (D) Einweg-Migrationsskript – intern, einmalig, prüfbar nach Ergebnis. Aber wenn Agent autonom arbeitet und Produktionsdaten berührt, ist das Risiko hoch. Entscheidung: Wenn Skript einfach und Daten nicht kritisch – leichte Anfrage; wenn komplexe Logik oder Produktion – minimale Spezifikation mit Prüfung auf Datenkopie. Schritt 5: (E) Stripe-Zahlungsintegration – Sicherheit, öffentliches Verhalten, externer Dienst, Benutzergelder, rechtliche Folgen von Fehlern. Entscheidung: Obligatorische vollständige Spezifikation mit expliziten Grenzen (welche Zahlungen, welche Währungen, welche Webhooks), festgehaltenen Entscheidungen (Stripe SDK vs. API, Fehlerbehandlung), unverzichtbaren Einschränkungen (PCI-Compliance, Idempotency-Keys), negativen Anforderungen (keine CVV-Speicherung, keine synchrone Zahlungsverarbeitung), detaillierter Validierung.
Schwierigkeitsgrad: mittel
Fallstudien: Titel: Migration eines Startups vom Vibe-Coding zu SDD: Projektrettung durch Spezifikationen
Szenario: Ein EdTech-Startup entwickelte eine Plattform für Online-Kurse mit Claude und GitHub Copilot im Vibe-Coding-Modus. In 4 Monaten schuf ein Team aus 2 Entwicklern ein funktionierendes MVP: Autorisierung, Videoplayer, Lernfortschritt, Zahlungen. Das Projekt wuchs impulsiv: Jedes Feature wurde auf Anfrage „mach X“ hinzugefügt, architektonische Entscheidungen wurden vom Agenten ad hoc ohne Dokumentation getroffen.
Herausforderung: Im 5. Monat stieß das Team auf kritische Probleme: (1) Absichtsverschiebung – das Zahlungssystem enthielt 3 verschiedene Ansätze (Stripe Checkout, Stripe Elements, selbstgeschriebenes Formular), weil in verschiedenen Sitzungen Agenten unterschiedliche Entscheidungen trafen; (2) Kontextzerfall – ein neuer Entwickler konnte nicht verstehen, warum der Videoplayer ein benutzerdefiniertes Fortschrittsspeicherformat anstelle des Standardformats verwendete; (3) Unprüfbares Ergebnis – ein Release enthielt 47 geänderte Dateien, Review dauerte 6 Stunden, Fehler schlichen sich in die Produktion; (4) Verborgene Entscheidungen – eine kritische Entscheidung über Datenbank-Sharding blieb nur im Chatverlauf eines ausgeschiedenen Entwicklers; (5) Reviewer-Ermüdung – die CTO stellte Nachtreleases ein, weil Qualitätsgarantie unmöglich war.
Lösung: Das Team führte SDD in 3 Wochen ein: (1) Retrospektive – Extraktion verborgener Entscheidungen aus Chatverläufen, Fixierung in specs/mission.md, specs/tech-stack.md, specs/architecture-decisions/; (2) Roadmap – Dekomposition verbleibender Features in Phasen mit expliziten Grenzen; (3) Mini-Spezifikationen – jedes Feature erhielt requirements/plan/validation, geprüft anhand der sieben Fragen; (4) Stabiler Zyklus – Einführung von /clear zwischen Sitzungen, Trennung in Planung/Implementierung/Validierung; (5) Prüfautomatisierung – npm-Skripte und GitHub Actions für obligatorisches Bestehen von validation.md vor dem Merge.
Ergebnis: Nach 2 Monaten: Review-Zeit sank von 6 Stunden auf 45 Minuten; Anzahl Release-Bugs fiel um 70%; neuer Entwickler war in 3 Tagen statt 3 Wochen eingearbeitet; 2 von 3 Zahlungssystemen konnten dank negativer Anforderungen ohne Regressionen entfernt werden. CTO nahm Nachtreleases mit Zuversicht wieder auf. Das Projekt zog eine Serie-A-Finanzierung an.
Gelernte Lektionen: Vibe-Coding hat versteckte Kosten: Jede gesparte Minute an Spezifikation verwandelt sich in Stunden Review und Zurückrollen im Horizont von 3-6 Monaten
Die sieben Fragen der Spezifikation fungieren als früher Detektor für Unklarheit: Wenn der Agent bei Prüfung von requirements.md unerwartete Fragen stellt, ist die Spezifikation noch nicht bereit
Die Trennung von Sitzungen mit /clear ist kritisch wichtig zur Vermeidung von Kontextvermischung: Selbst ein „schlauer“ Agent verwechselt Prioritäten, wenn in einer Sitzung Planung, Implementierung und Bugfixing kombiniert sind
Negative Anforderungen sind die am meisten unterschätzte Komponente: Die explizite Angabe „was wir nicht tun“ schützt besser vor Umfangsaufblähung als die Aufzählung „was wir tun"
SDD amortisiert sich nicht sofort, sondern durch Ansammlung versionierbaren Kontexts: Der Nutzen wächst exponentiell mit Teamgröße und Projektalter
Verwandte Konzepte: Vibe-Coding
Sieben Fragen der Spezifikation
Stabiler Arbeitszyklus mit Qwen Code
Negative Anforderungen
Praktische Redundanzregel
Titel: Scheitern einer OAuth-Integration: Wenn „Füge Login hinzu“ teurer ist als eine Spezifikation
Szenario: Ein Indie-Entwickler baute ein SaaS für Freelancer – Zeiterfassung mit Rechnungsstellung. Zur Vorbereitung des öffentlichen Launches wurde Autorisierung benötigt. Der Entwickler gab Claude eine impulsive Anfrage: „Füge Login über Google hinzu".
Herausforderung: Der Agent implementierte eine vollwertige OAuth 2.0-Integration mit Google, einschließlich: Registrierung neuer Benutzer über Google, Verknüpfung bestehender Konten, Token-Aktualisierung, Zugriff auf Google Calendar für Import von Ereignissen, Profil mit Avatar aus Google. Probleme: (1) Der Entwickler wollte nur Authentifizierung, keine Calendar-Datenautorisierung; (2) Die Kontenverknüpfung erzeugte eine Schwachstelle: Benutzer A konnte die E-Mail von Benutzer B verknüpfen, falls dieser zuvor per Passwort eingeloggt war; (3) Die Token-Aktualisierung erforderte eine Cron-Aufgabe, nicht in der Infrastruktur dokumentiert; (4) Die Registrierung über Google umging das Pflichtfeld „Zeitzone“, kritisch für die Rechnungsstellung; (5) Das Zurückrollen dauerte 8 Stunden, einschließlich Datenbankwiederherstellung aus Backup.
Lösung: Nach dem Vorfall wandte der Entwickler den SDD-Ansatz an: Erstellte specs/auth/requirements.md mit Grenzen (nur Authentifizierung, kein Zugriff auf Google-Daten, keine Selbstregistrierung in dieser Phase), fixierte die Entscheidung über E-Mail-Passwort-Priorität vor OAuth im ersten Release, beschrieb negative Anforderungen (wir brechen bestehende Benutzer nicht, wir fordern Zeitzone bei OAuth-Login nicht). Der Plan enthielt 2 Aufgabengruppen statt 8, die Validierung – 5 konkrete Prüfungen einschließlich Prüfung auf Abwesenheit neuer Scopes in der Google Console.
Ergebnis: Die wiederholte Implementierung dauerte 2 Stunden statt 8 Stunden Zurückrollen + unbestimmter Zeit für Korrektur. Die Spezifikation verhinderte 3 von 5 Problemen vor Code-Schreibung (Zugriff auf Calendar, Kontenverknüpfung, Zeitzone-Anforderung). Die 2 verbleibenden Probleme wurden in der Validierungsphase in 15 Minuten erkannt. Der Entwickler schätzte, dass das Verfassen der Spezifikation 25 Minuten dauerte – eine Einsparung um Faktor 12 gegenüber dem Zurückrollen.
Gelernte Lektionen: Die impulsive Anfrage „Füge X hinzu" ist nur im Moment billig: Die vollständigen Kosten umfassen Zurückrollen, Korrektur, Datenwiederherstellung und Reputationsschäden
Agenten neigen zu „nützlichen“ Erweiterungen, die der Entwickler nicht bestellt hat: OAuth zieht naturgemäß Profile, Integrationen, Synchronisationen nach sich
25 Minuten für eine Spezifikation sind eine Investition mit ROI > 1000% beim ersten ernsthaften Fehler
Negative Anforderungen in der Form „kein Zugriff auf Google-Daten" sind konkreter und prüfbarer als „nur Authentifizierung"
Validierung durch Vergleich der Implementierung mit vorab festgelegter Liste schützt vor „scheint okay" bei Reviewer-Ermüdung
Verwandte Konzepte: Absichtsverschiebung
Grenzen und jenseits der Grenzen
Praktische Redundanzregel
Sieben Fragen der Spezifikation
Mini-Spezifikation eines Features
Studientipps: Bearbeiten Sie das Material sequentiell: Erst erfassen Sie Vibe-Coding-Probleme durch eigene Erfahrung oder Fälle, dann studieren Sie SDD als systematische Lösung, nicht als Bürokratie
Führen Sie ein „Vibe-Coding-Tagebuch“ – halten Sie Ihre impulsiven KI-Anfragen über eine Woche fest, analysieren Sie dann: Welche führten zum Zurückrollen? Welche hätten in 10 Minuten formalisiert werden können?
Üben Sie die sieben Fragen an realen oder erdachten Features: Nehmen Sie ein beliebiges Feature aus Ihrem aktuellen Projekt und prüfen Sie, ob Sie alle sieben Fragen in 5 Minuten beantworten können. Wenn nicht – ist eine Spezifikation nötig
Verwenden Sie die „Rote-Team“-Technik: Nach dem Verfassen einer Spezifikation bitten Sie einen Agenten oder Kollegen, Unklarheiten zu finden, durch die die Implementierung abweichen könnte. Dies trainiert kritisches Denken
Erstellen Sie Vorlagen für die drei Spezifikationsdateien in Ihrem Editor oder Snippets: requirements.md, plan.md, validation.md. Die Automatisierung der Erstellung senkt die Einstiegshürde für SDD
Üben Sie die Sitzungstrennung buchstäblich: Schließen Sie den Chat, öffnen Sie einen neuen mit /clear, auch wenn „Fortsetzung" effizienter erscheint. Messen Sie den Unterschied in der Ergebnisqualität
Studieren Sie negative Anforderungen separat: Dies ist der kontraintuitivste Teil, der die Gewohnheit erfordert, „was ich NICHT will" statt „was ich will" zu denken
Vergleichen Sie SDD aktiv mit dem Wasserfall: Wasserfall versucht die Zukunft vorherzusagen, SDD fixiert ausreichend Kontext für den nächsten Schritt. Das sind unterschiedliche Logiken, nicht unterschiedliche Skalen
Messen Sie Metriken: Review-Zeit, Anzahl Bugs im Release, Onboarding-Zeit neuer Entwickler. SDD rechtfertigt sich durch Metriken, nicht Intuition
Beginnen Sie mit einem Feature: Versuchen Sie nicht, das gesamte Projekt sofort mit Spezifikationen abzudecken. Wählen Sie das nächste nichttriviale Feature, durchlaufen Sie den vollständigen Zyklus, messen Sie das Ergebnis, skalieren Sie dann
Zusätzliche Ressourcen: Originalkurs zu SDD: Kursmaterialien, aus denen dieser Teil extrahiert wurde – Grundlage für das Eintauchen in kontextabhängige Entwicklung mit KI-Agenten
Qwen Code-Dokumentation: Offizielle Materialien zur Arbeit mit Kontext, /clear-Befehlen, @-Verweisen auf Dateien – technische Grundlage des stabilen Zyklus
„Writing Great Specifications" von Kamil Nicieja: Buch über Spezifikationen im klassischen Sinn, anwendbar auf KI-Agenten mit Skalenanpassung
ADR (Architecture Decision Records): Format zur Fixierung architektonischer Entscheidungen – ergänzt SDD auf Projektebene, schützt vor Kontextzerfall zwischen Features
„The Checklist Manifesto" von Atul Gawande: Buch über die Kraft von Checklisten in komplexen Systemen – die sieben Fragen der Spezifikation als Qualitätscheckliste
Beispiele für Spezifikationen von Open-Source-Projekten: Studium, wie Teams Feature-Grenzen in RFCs (Request for Comments) festhalten – Parallele zu SDD-Mini-Spezifikationen
Kurs zu API-Design-Patterns (API Design Patterns): Hilft bei der Formulierung unverzichtbarer Einschränkungen in Spezifikationen, besonders für Features mit externen Schnittstellen
Zusammenfassung: Entwicklung nach Spezifikationen (SDD) ist die Antwort auf die fundamentale Einschränkung des Vibe-Codings: die Flüchtigkeit des Kontexts. KI-Agenten schreiben schnell Code, aber ohne beständige Erinnerung an Absichten, Grenzen und getroffene Entscheidungen. SDD verlagert diesen Kontext in versionierbare Dateien und schafft eine „Projektkarte" für den Agenten. Schlüsselpraktiken: Stabiler Zyklus mit /clear und getrennten Sitzungen für Planung/Implementierung/Validierung; Mini-Spezifikationen von Features statt monolithischer Planung; sieben Fragen als Bereitschaftsprüfung; explizite Grenzen und negative Anforderungen zum Schutz vor Umfangsaufblähung; praktische Redundanzregel zur Aufwandsoptimierung. SDD macht den Agenten nicht fehlerfrei – es macht Fehler früh, klein und prüfbar. Die Einführung erfordert Disziplin, amortisiert sich aber exponentiell mit Projekt- und Teamwachstum.