Thema: Teil 16. Teamarbeit und Code-Review
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 4-6 Stunden (Theorie: 2 Stunden, Praxis: 2-4 Stunden)
Voraussetzungen: Teile 1-15 des SDD-Kurses (Verständnis der Spezifikation: requirements.md, plan.md, validation.md)
Grundkenntnisse in Git und der Arbeit mit Branches
Erfahrung mit Pull Requests in GitHub/GitLab
Verständnis der Rolle von Qwen Code als Entwicklungsagent
Lernziele: Vierstufige Reviews zusammenstellen und verwenden (Anforderungen → Plan → Fakten → Code) zur Überprüfung von Merge-Requests in SDD-Projekten
PR-Vorlage anwenden, um den Zusammenhang zwischen Spezifikation und Code-Änderungen zu demonstrieren
Bestimmen, wann die Spezifikation im Feature-Branch korrigiert werden darf und wann ein separater Replanning-Branch erforderlich ist
Qwen Code als zweiten Leser beim Review nutzen, ohne automatische Code-Korrekturen durch den Agenten zuzulassen
Änderungen identifizieren, die nicht dem Agenten im Autopilot-Modus überlassen werden dürfen, und menschliche Kontrolle über kritische Entscheidungen sicherstellen
Überblick: Dieser Kursabschnitt wechselt von der individuellen Entwicklung zur Teamarbeit im Rahmen des Specification-Driven Development (SDD). Die zentrale Erkenntnis: Im Team wird die Spezifikation nicht nur zum Hinweis für den Agenten, sondern zu einem Vertrag zwischen Menschen. Wenn dieser Vertrag nicht reviewed wird, kann der Agent sauberen Code basierend auf einer schwachen oder unvollständigen Beschreibung implementieren – und das wird wie ein Erfolg aussehen, bis verborgene Probleme auftreten. Die Hauptregel: Im Pull-Request wird nicht nur der Code, sondern das Bündel „Anforderungen → Plan → Prüffakten → Änderungen“ reviewed. Der Abschnitt deckt den vollständigen Arbeitsfluss vom Feature-Branch bis zum Merge ab, die Rollen von Autor und Reviewer, PR-Vorlagen, Konfliktmanagement in der roadmap.md und die Grenzen der Automatisierung mit Qwen Code.
Schlüsselkonzepte: Hauptregel des Team-SDD: Im Pull-Request wird nicht nur der Code reviewed. Das Bündel wird reviewed: Anforderungen → Plan → Prüffakten → Änderungen. Dies verhindert Situationen, in denen sauberer Code eine falsche Spezifikation implementiert.
Arbeitsfluss (Workflow): Feature-Branch → Spezifikation (requirements.md, plan.md, validation.md) → erstes Review der Grenzen und Fakten → Entscheidung „darf implementiert werden?“ → Implementierung → Prüfung nach validation.md → Pull Request → Code- und Spezifikations-Review → Merge und Replanning. Das erste Review in einem kleinen Team kann mündlich sein, in einem großen Team ein kurzer Kommentar im PR.
Vier Fragen des Autors vor dem Öffnen eines PR: 1) Gibt es für das Feature einen eigenen Ordner in specs/? 2) Hat der Agent Dateien außerhalb der Feature-Grenzen geändert? 3) Sind alle obligatorischen Fakten aus validation.md geprüft? 4) Wenn sich Fakten im Laufe der Arbeit geändert haben, ist erkennbar, warum sie sich geändert haben? Die letzte Frage ist kritisch: Ein schlechtes Zeichen – der Agent ändert validation.md nach einem Testfehler, damit die Prüfung einfacher wird; ein gutes Zeichen – der Autor erklärt die Ursache der Faktenänderung explizit.
Vier Review-Ebenen des Reviewers: Anforderungen (sind die Grenzen verständlich, für wen ist das Feature, was ist nicht enthalten), Plan (entsprechen die Aufgabengruppen den Anforderungen, gibt es verstecktes Refactoring), Fakten (prüfen sie das tatsächliche Verhalten, nicht die Absicht; gibt es maschinell prüfbare Fakten), Code (entspricht die Implementierung dem Plan und den Fakten, gibt es „nebenbei“ vorgenommene Änderungen). Wenn der Reviewer nur den Code betrachtet, degeneriert SDD zu einem gewöhnlichen Review mit überflüssigen Markdown-Dateien.
Pull-Request-Vorlage: Die minimale Vorlage ist in appendix-c-checklists.md ausgelagert und wird in .github/pull_request_template.md kopiert. Der Sinn – den Autor zwingen, den Zusammenhang von Spezifikation und Änderungen zu zeigen: Spezifikationsordner, durchgeführte Fakten, zurückgestellte Fakten mit Begründungen, Dateien außerhalb des erwarteten Bereichs, besonders aufmerksam zu prüfende Stellen für den Reviewer. Für die meisten Features genügen 6–8 Punkte.
Spezifikationskorrektur im Feature-Branch: Zulässig bei Klärungen, die mit dem aktuellen Feature zusammenhängen und die Projektstrategie nicht ändern: HTTP-Status präzisieren, manuellen Prüffakt für die Benutzeroberfläche hinzufügen, Routenbezeichnung korrigieren, Fakt als zurückgestellt markieren, bei der Implementierung getroffene Entscheidung hinzufügen. Eine schlechte Korrektur: Feature-Grenzen umschreiben, damit sie mit dem bereits zufällig geschriebenen Code übereinstimmen.
Replanning-Branch: Erforderlich bei Änderungen, die die Projektverfassung betreffen: Stack-Wechsel, Phasenreihenfolge, neue architektonische Grenze, MVP-Änderung, Regel für mehrere zukünftige Features, Neuschreibung von QWEN.md oder Team-Skill. Trennt Feature-Implementierung von Prozess-/Roadmap-Änderung.
Konflikte in roadmap.md: Engpass: Zwei Personen können gleichzeitig die Status verschiedener Phasen ändern. Regel: Im Feature-Branch kann gelesen und referenziert werden, Statusänderungen besser vor dem Merge oder in einem kurzen Replanning-Branch. In großen Teams – Regel des Roadmap-Besitzers.
Qwen Code im Review: Nützlich als zweiter Leser, nicht als Ersatz für den Reviewer. Gute Anfrage: QWEN.md lesen, Branch-Spezifikation, git diff; Implementierung mit den drei Spezifikationsdateien vergleichen; Abweichungsliste erstellen; Dateien nicht ändern. Schlechte Anfrage: „prüfe PR und korrigiere alles“ – der Agent vermischt Review, Korrektur und Entscheidungsfindung, was in der Teamarbeit gefährlich ist.
Verbote für den Agenten-Autopilot: Ohne menschliche Entscheidung dürfen nicht übergeben werden: Feature-Grenzen erweitern, Stack wechseln, Fakten aus validation.md löschen, Sicherheitsrichtlinie ändern, roadmap.md mehrerer Phasen aktualisieren, PR mergen, Git-Historie korrigieren, irreversible Migrationen/Datenlöschung. Der Agent kann vorschlagen, der Mensch entscheidet.
Praxisübungen: Titel: Übung 1: Bereitschafts-Audit für PR anhand der vier Fragen
Problem: Ihnen liegt der Feature-Branch „Hinzufügen der Patientenfilterung nach Diagnose“ im AgentClinic-Projekt vor. Der Autor hat einen PR eröffnet. Bei der Prüfung stellen Sie fest: Der Ordner specs/patient-filter/ existiert; im git diff sind Änderungen in specs/patient-filter/requirements.md, specs/patient-filter/plan.md, specs/patient-filter/validation.md, src/services/patient_service.py, tests/test_patient_filter.py sichtbar; aber auch die Datei src/models/base_model.py wurde geändert (Feld is_archived hinzugefügt). In validation.md wurde der letzte Fakt von „Filter gibt nur aktive Patienten zurück“ auf „Filter gibt Patienten zurück, bei denen is_archived = false“ geändert, wobei im Commit-Verlauf ersichtlich ist, dass diese Änderung nach dem Fehlschlagen des Tests test_active_patients_only erfolgte. Schreiben Sie, bei welchen der vier Fragen der Autor keine zufriedenstellende Antwort geben konnte, und formulieren Sie einen Reviewer-Kommentar.
Lösung: Schritt 1: Frage 1 prüfen – Ordner specs/patient-filter/ vorhanden, Antwort „ja“. Schritt 2: Frage 2 prüfen – src/models/base_model.py außerhalb der Feature-Grenzen geändert, Antwort „nein, wurde geändert“. Schritt 3: Frage 3 prüfen – nicht eindeutig prüfbar, aber wir gehen davon aus, dass Fakten geprüft wurden. Schritt 4: Frage 4 prüfen – Fakt nach Testfehler geändert, Ursache nicht explizit erklärt, scheint wie eine Abschwächung der Prüfung. Reviewer-Kommentar: „Frage 2: Die Änderung von base_model.py überschreitet die Feature-Grenzen. Erfordert entweder Auslagerung in ein separates Feature oder Begründung im PR, warum dies für die Filterung notwendig ist. Frage 4: Der Fakt zu aktiven Patienten wurde nach Testfehler ohne Erklärung der Ursache geändert. Dies sieht wie Anpassung der Spezifikation an den Code aus, nicht wie Präzisierung der Anforderung. Bitte ursprünglichen Fakt wiederherstellen oder Geschäftsgrund für die Änderung explizit erklären und neuen Fakt hinzufügen, der die Korrektheit des neuen Verhaltens bestätigt."
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 2: Trennung von Korrekturen in Feature-Branch und Replanning-Branch
Problem: Im AgentClinic-Projekt möchte ein Entwickler im Feature-Branch „PDF-Berichtsexport“ folgende Änderungen vornehmen. Bestimmen Sie, welche im Feature-Branch vorgenommen werden können und welche einen separaten Replanning-Branch erfordern: (A) manuellen Prüffakt „PDF öffnet sich in Acrobat Reader ohne Validierungsfehler“ in validation.md hinzufügen; (B) PDF-Generierungsbibliothek von WeasyPrint auf Playwright + Chromium umstellen; (C) in requirements.md präzisieren, dass Export nur Lateinisch und Kyrillisch unterstützt; (D) Berichtsgenerierung aus Modul services/ in neues Modul reporting/ verschieben; (E) roadmap.md aktualisieren, Phase „Berichte“ als abgeschlossen markieren und Phase „Berichtsanalytik“ hinzufügen; (F) QWEN.md ändern, Regel hinzufügen „alle neuen Module werden mit Präfix agentclinic_ erstellt“.
Lösung: Schritt 1: Jede Änderung nach dem Kriterium analysieren – betrifft sie die Projektverfassung oder nur das aktuelle Feature? (A) Manueller Fakt in validation.md – Präzisierung des aktuellen Features, Feature-Branch. (B) Bibliothekswechsel – ändert Technologieentscheidung, beeinflusst andere Features und Projekt-Zukunft, separater Replanning-Branch. (C) Präzisierung unterstützter Zeichen – Grenze des aktuellen Features, Feature-Branch. (D) Neue architektonische Grenze Modul reporting/ – betrifft Projektstruktur und zukünftige Features, separater Replanning-Branch. (E) Aktualisierung von roadmap.md mit neuer Phase – ändert Roadmap mehrerer Phasen, separater Replanning-Branch (oder kurzer Replanning-Branch). (F) Änderung von QWEN.md – ändert Team-Skill, separater Replanning-Branch. Ergebnis: Feature-Branch – A, C; separater Replanning-Branch – B, D, E, F.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 3: Erstellung einer PR-Vorlage für ein konkretes Feature
Problem: Ein Entwickler hat das Feature „Arztbenachrichtigung bei kritischer Änderung von Patientenwerten“ in AgentClinic abgeschlossen. Die Spezifikation befindet sich in specs/critical-alerts/. Von validation.md sind 4 von 5 Fakten geprüft: Der Fakt „Benachrichtigung in < 30 Sekunden zugestellt“ ist zurückgestellt, da er Lasttests erfordert, die für die nächste Iteration geplant sind. Im git diff geändert: specs/critical-alerts/validation.md (Markierung zurückgestellter Fakt), src/services/alert_service.py, src/notifications/push_sender.py, tests/test_critical_alerts.py. Unerwartet: auch src/config/settings.py geändert – Umgebungsvariable ALERT_TIMEOUT_MS hinzugefügt. Erstellen Sie eine PR-Beschreibung nach der Vorlage aus Anhang C, 6–8 Punkte.
Lösung: Schritt 1: Spezifikationsordner angeben. Schritt 2: Geprüfte Fakten aufzählen. Schritt 3: Zurückgestellten Fakt mit Begründung vermerken. Schritt 4: Änderung außerhalb des erwarteten Bereichs erklären. Schritt 5: Besonders aufmerksam zu prüfende Stellen für den Reviewer angeben. Schritt 6: Gesamteinschätzung der Bereitschaft geben. Beispielergebnis: 1. Spezifikation: specs/critical-alerts/ (requirements.md, plan.md, validation.md). 2. Geprüfte Fakten: Benachrichtigung wird bei kritischer Änderung erstellt; enthält Patienten-ID und Wert; wird zuständigem Arzt zugesandt; wird in Audit-Trail protokolliert. 3. Zurückgestellt: Fakt „Zustellung < 30 Sek“ – erfordert Lasttest, geplant für Sprint 14. 4. Änderung außerhalb der Grenzen: src/config/settings.py – ALERT_TIMEOUT_MS hinzugefügt für einheitliches Timeout-Management der Benachrichtigungen. Begründung: Hartkodierung in alert_service.py vermeiden. 5. Besonders prüfen: Korrektheit der Verbindung zwischen alert_service.py und push_sender.py; erzeugt ALERT_TIMEOUT_MS keine Konflikte mit anderen Timeouts in settings.py. 6. Bereitschaft: Feature funktionsfähig, zurückgestellter Fakt blockiert nicht MVP.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 4: Formulierung einer Anfrage an Qwen Code für das Review
Problem: Sie sind Reviewer in einem SDD-Projekt. Der PR-Autor bittet: „Lassen Sie Qwen prüfen und den Code korrigieren, dann schauen Sie sich das an.“ Erklären Sie, warum dies eine schlechte Praxis ist, und formulieren Sie eine korrekte Anfrage an Qwen Code, die Sie als Reviewer dem Agenten für Review-Unterstützung geben, ohne automatische Korrektur zuzulassen.
Lösung: Schritt 1: Problem erklären: Die Anfrage „prüfe und korrigiere“ vermischt drei Rollen – Review (Abweichungen identifizieren), Korrektur (Code ändern) und Entscheidungsfindung (was korrigiert wird und was nicht). In der Teamarbeit ist dies gefährlich: Der Agent kann Entscheidungen treffen, die der Mensch treffen muss (z. B. Fakt abschwächen oder Grenzen erweitern). Das Review muss zuerst eine klare Abweichungsliste erstellen, und der Autor entscheidet, was korrigiert wird. Schritt 2: Korrekte Anfrage formulieren. Ergebnis: „/clear. Lies @QWEN.md, die Branch-Spezifikation specs/critical-alerts/ (requirements.md, plan.md, validation.md) und den git diff dieses Branches relativ zu main. Vergleiche die Implementierung mit jeder der drei Spezifikationsdateien. Erstelle eine Abweichungsliste: wo der Code nicht den Anforderungen entspricht, wo die Implementierung vom Plan abweicht, wo Fakten der validation.md nicht oder fehlerhaft geprüft werden. Ändere keine Dateien. Formuliere das Ergebnis als nummerierte Liste mit Angabe von Datei und Zeile."
Schwierigkeitsgrad: Mittelstufe
Fallstudien: Titel: Fallstudie: Degeneration von SDD zu „Markdown-Review“ im Startup MedFlow
Szenario: MedFlow – ein Startup mit 4 Entwicklern, das SDD nach dem Kurs eingeführt hat. Die ersten zwei Monate arbeiteten sie nach der Regel „Review des Bündels Anforderungen-Plan-Fakten-Code“. Mit wachsender Belastung schlug der leitende Entwickler vor, „schneller zu werden“: Der Reviewer betrachtete nur noch git diff und validation.md und übersprang requirements.md und plan.md. PR-Autoren begannen, die Spezifikation zu minimieren, und Qwen Code wurde zur Auto-Ausfüllung von PR-Vorlagen verwendet.
Herausforderung: Nach 6 Wochen stellte das Team fest, dass das Feature „Laborintegration“ implementiert war, das tatsächlich nicht das tat, was das Geschäft erforderte: Der Code übermittelte akkurat Daten an die Labor-API, aber in requirements.md waren die Grenzen vage („Integration“ ohne Präzisierung der Richtung). Der Plan ging von bidirektionalem Austausch aus, die Implementierung ermöglichte nur Bestellungsversand ohne Ergebnisempfang. validation.md prüfte die Korrektheit von HTTP-Statuscodes, aber nicht die Existenz eines Callback-Endpoints. Das Feature bestand das Review, da der Code der schwachen Spezifikation entsprach. Das Geschäft verlor 3 Wochen für die Nacharbeit.
Lösung: Das Team führte eine strenge Regel ein: PR ohne explizite Referenz auf requirements.md und plan.md werden automatisch zurückgewiesen. Der Reviewer ist verpflichtet, mindestens eine Frage zu jeder der vier Ebenen zu stellen. Qwen Code wurde in den Modus „nur Abweichungsliste“ mit Verbot der Auto-Korrektur versetzt. Für roadmap.md wurde ein wöchentlicher Wechsel des Besitzers eingeführt. Die PR-Vorlage wurde auf 6 Pflichtpunkte gekürzt, diese jedoch streng gestaltet.
Ergebnis: Die durchschnittliche Review-Zeit stieg von 15 auf 40 Minuten, die Anzahl der Nacharbeiten sank um 70%. Das nächste Integrationsfeature (mit Zahlungsgateway) bestand mit einer Review-Iteration statt der bisherigen vier. Der CTO stellte fest, dass die „Verlangsamung“ beim Review sich durch Beschleunigung in der Geschäftsabnahme amortisierte.
Gelernte Lektionen: Das Überspringen von Review-Ebenen (besonders Anforderungen und Plan) macht SDD zur Formalität und schützt nicht vor Implementierung falscher Spezifikationen
Auto-Ausfüllung von Vorlagen durch den Agenten zerstört deren Sinn – die Vorlage muss den Autor zum Denken zwingen, nicht Zeit beim Kopieren sparen
Kürze der Vorlage ist wichtiger als Vollständigkeit: 6 strenge Punkte funktionieren besser als 15 optionale
Verwandte Konzepte: Hauptregel des Team-SDD
Vier Review-Ebenen des Reviewers
Pull-Request-Vorlage
Qwen Code im Review
Titel: Fallstudie: Konflikt in roadmap.md und Einführung des Roadmap-Besitzers
Szenario: AgentClinic – ein Projekt mit 8 Entwicklern, die nach SDD arbeiten. Die Roadmap in roadmap.md enthielt 5 Phasen. Zwei Entwickler, Alexej und Maria, arbeiteten parallel an den Phasen 3 („Sensorintegration“) und 4 („Werteanalytik“). Beide änderten den Status ihrer Phasen in roadmap.md in ihren Feature-Branches.
Herausforderung: Beim Merge des ersten PR änderte sich der Status von Phase 3 auf „abgeschlossen“ und von Phase 4 auf „in Entwicklung“. Beim Merge des zweiten PR entstand ein Konflikt: Maria hatte den Status von Phase 4 auf „in Entwicklung“ in ihrem Branch geändert, aber zu diesem Zeitpunkt hatte Alexej bereits Phase 5 „Prädiktive Analytik“ in main hinzugefügt. Git konnte die Änderungen in roadmap.md nicht automatisch zusammenführen. Die Konfliktlösung dauerte 2 Stunden, wobei versehentlich der Status von Phase 2 („Patientenregistrierung“) verloren ging, den jemand zuvor korrigiert hatte.
Lösung: Das Team führte eine Regel ein: Im Feature-Branch kann roadmap.md gelesen und auf Phasen referenziert werden, Statusänderungen jedoch nur in einem kurzen Replanning-Branch oder unmittelbar vor dem Merge mit expliziter Zustimmung. Ein Roadmap-Besitzer wurde bestimmt – die Rolle wechselt wöchentlich, Verantwortung: Prüfen, dass Phasenstatus der Realität entsprechen, und alleiniger Commit von roadmap.md-Änderungen in main.
Ergebnis: Konflikte in roadmap.md verschwanden. Die Sprint-Planungszeit sank von 4 Stunden auf 45 Minuten. Der Roadmap-Besitzer wurde zur natürlichen Synchronisationsstelle zwischen Entwicklern, was unerwartet die Teamkommunikation verbesserte.
Gelernte Lektionen: roadmap.md – Engpass bei paralleler Arbeit, erfordert explizite Besitzregel
Rotation der Roadmap-Besitzer-Rolle verhindert Bus-Faktor und bindet alle in das Strategieverständnis ein
Trennung von Statusänderungen von Feature-Branches verringert Konflikte und macht die Historie nachvollziehbar
Verwandte Konzepte: Konflikte in roadmap.md
Replanning-Branch
Arbeitsfluss (Workflow)
Lerntipps: Bearbeiten Sie das Material parallel zu einem realen oder Übungsprojekt: Versuchen Sie, einen beliebigen abgeschlossenen PR als „mentales Review“ nach den vier Ebenen zu betrachten – dies verwandelt abstrakte Regeln in Fähigkeiten
Drucken Sie den Checkliste der vier Autorenfragen und vier Review-Ebenen aus oder halten Sie sie griffbereit – verwenden Sie sie buchstäblich für die ersten 5 PR, bis es automatisch wird
Üben Sie die Formulierung „guter“ und „schlechter“ Anfragen an Qwen Code: Schreiben Sie 3 gute und 3 schlechte, erklären Sie den Unterschied einem Kollegen oder im Übungschat – Lernen durch Lehren festigt das Verständnis
Erstellen Sie ein Übungs-Repository mit mehreren Feature-Branches und bringen Sie in einen davon typische Fehler ein (Änderung außerhalb der Grenzen, Faktenabschwächung nach Testfehler, fehlender specs-Ordner) – üben Sie deren Erkennung anhand der Checkliste
Studieren Sie die verwandten Teile 17, 18, 20 nicht sequentiell, sondern parallel: Automatisierung von Prüfungen (17), Review-Sicherheit (18) und Antipatterns (20) – dies sind drei Facetten desselben Prozesses, und ihr Zusammenhang ist tiefergreifender als isoliertes Studium
Führen Sie ein „Reviewer-Tagebuch“: Notieren Sie, welche Fragen Sie bei realen PR stellen, welche Probleme finden, welche sich als Fehlalarme erweisen – nach einem Monat haben Sie eine personalisierte Checkliste
Für visuellen Lernstil: Zeichnen Sie den Arbeitsfluss vom Feature-Branch bis zum Merge auf Papier, markieren Sie, wo genau jede Prüfung stattfindet und wer dafür verantwortlich ist
Zusätzliche Ressourcen: Appendix-c-checklists.md: Originale Pull-Request-Vorlage aus dem Kurs – Grundlage für .github/pull_request_template.md
Teil 17. Automatisierung von Review-Prüfungen: Welche Hooks helfen, Teile des Reviews automatisch durchzuführen – Fortsetzung des Themas Teamarbeit
Teil 18. Sicherheit beim Review: Was im Diff zu suchen ist: Geheimnis-Lecks, neue MCP-Server, Hook-Änderungen – kritisch für reale Projekte
Teil 20. Antipatterns: Situationen für sofortige PR-Ablehnung: Spezifikation ohne Fakten, im Laufe der Arbeit abgeschwächte Fakten, Implementierung einer zukünftigen Phase
GitHub Docs: About pull request templates: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository – Technische Anleitung zur Vorlagen-Einführung
„Code Review Best Practices“ von Palantir: https://blog.palantir.com/code-review-best-practices-19e02770015f – Klassischer Artikel, der den SDD-spezifischen Ansatz durch allgemeine Review-Prinzipien ergänzt
Buch „Working Effectively with Legacy Code“ von Michael Feathers: Kapitel über „Seams“ und Änderungsgrenzen – nützlich zum Verständnis, warum das Überschreiten von Feature-Grenzen wichtig ist
Zusammenfassung: Teamarbeit in SDD erfordert eine Neuüberlegung der Spezifikationsrolle: Sie wird zum Vertrag zwischen Menschen, nicht nur zum Hinweis für den Agenten. Die Hauptregel – das Bündel „Anforderungen → Plan → Fakten → Code“ reviewen, nicht isoliert den Code. Erfolgreiche Anwendung erfordert Disziplin des Autors (vier Fragen vor dem PR), Systematik des Reviewers (vier Prüfebenen), Klarheit bei Änderungsgrenzen (Feature-Branch vs. Replanning-Branch), Management von Engpässen (Roadmap-Besitzer) und bewussten Einsatz der Automatisierung (Qwen Code als zweiter Leser, nicht Ersatz für den Reviewer). Die PR-Vorlage ist ein Verbindungsinstrument, keine Bürokratie. Verbote für den Agenten-Autopilot schützen kritische Entscheidungen vor unüberlegter Automatisierung. Die Einhaltung dieser Prinzipien verhindert die Degeneration von SDD zu einem formalen Review mit überflüssigen Markdown-Dateien und gewährleistet Vorhersehbarkeit der Team-Entwicklung.