Thema: Teil 21. Qwen Code-Prozess für DataLakeHouse
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 90-120 Minuten (Theorie: 45 Minuten, Praxis: 45-75 Minuten)
Voraussetzungen: Grundlegendes Verständnis der Data Lakehouse-Architektur
Vertrautheit mit dbt (data build tool) und seinen Modellen
Verständnis des Konzepts der Data Contracts (ODCS, ODPS)
Erfahrung im Umgang mit Versionskontrollsystemen (Git)
Allgemeine Vorstellung von KI-Agenten und LLM-Werkzeugen
Verständnis der Grundsätze der Aufgabentrennung (separation of duties) im Bankenumfeld
Lernziele: Erklären, warum der SDD-Prozess in einzelne Befehle mit menschlichen Bestätigungspunkten zerlegt werden muss, anstatt von einem einzigen Befehl ausgeführt zu werden
Zweck und Verantwortungsbereich der fünf Befehle beschreiben: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release
Zwischen Skills (Fähigkeiten) und Sub-Agents (Sub-Agenten) unterscheiden und erklären, warum Generator und Reviewer unterschiedliche Rollen sein müssen
Bestimmen, in welchen Fällen Hooks eingeführt werden sollten und welche Änderungsklassen sie blockieren müssen
Eine minimale Prozesskarte mit Artefakten für das DataLakeHouse-Team erstellen
Übersicht: Kapitel 21 führt die Materialien des gesamten Bandes zu einem funktionierenden Interaktionszyklus mit Qwen Code bei der Arbeit mit DataLakeHouse zusammen. Im Mittelpunkt steht der fünfstufige Prozess /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release, bei dem jeder Befehl eine enge Rolle und einen menschlichen Bestätigungspunkt hat. Die Hauptidee des Kapitels: Ein einzelner Befehl sollte niemals den gesamten Prozess ausführen, insbesondere nicht bei Bankdaten, wo Contract Drift zu spät erkannt werden kann. Behandelt werden Skills (data-profiler), Sub-Agenten (data-contract-review), das Konzept von Hooks als Disziplinarschicht sowie der typische Fehler – die Erstellung eines einzelnen Befehls /sdd:do-everything, der die menschlichen Bestätigungen auslöscht und SDD wieder in einen Autopiloten verwandelt. Das Kapitel schließt den Band ab und gibt dem Leser die Möglichkeit, bewusst zu entscheiden, welcher Befehl wofür verantwortlich ist und welches Artefakt die Entscheidung festhalten muss.
Schlüsselkonzepte: Sdd (specification-driven development): Ansatz, bei dem die Arbeit mit Daten mit einer formalen Spezifikation (einem Contract) der Quelle beginnt, nicht mit der direkten Änderung von Modellen. Im Kontext von Qwen Code bedeutet dies, dass die Aktionen des Agenten durch einen expliziten Contract zwischen Quelle und Konsument bestimmt werden und nicht durch Improvisation des LLM.
Fünfstufiger Prozess /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release: Aufteilung des gesamten Datenarbeitszyklus in fünf separate Befehle, von denen jeder eine enge Verantwortung und einen menschlichen Bestätigungspunkt hat. Diese Dekomposition verhindert, dass der Agent unbegrenzte Macht über die Daten erhält.
/sdd:profile: Befehl zur Beobachtung der Quelle. Liest Metadaten, Schemata, Volumina, Statistiken und erstellt ein Schema Manifest – ein Artefakt mit Fakten über die Daten, ohne Modelle zu schreiben. Hat keine Berechtigung, die Struktur von marts oder contracts zu ändern.
/sdd:contract: Befehl zur Formulierung oder Überprüfung des Versprechens. Arbeitet mit ODCS/ODPS-Dokumenten, die beschreiben, was die Quelle dem Konsumenten garantiert. Berührt keine Modelle – nur Spezifikationen.
/sdd:build: Befehl zur Einbringung von Änderungen in dbt-Modelle. Wird ausgelöst, nachdem der Contract von einem Menschen genehmigt wurde. Generiert SQL, sollte sich aber nicht selbst validieren.
/sdd:verify: Befehl zur Ausführung von Prüfungen und zur Suche nach Drift. Führt dbt build, Tests und den Vergleich der tatsächlichen Daten mit dem Contract durch. Sucht nach Abweichungen zwischen Versprechen und Realität.
/sdd:release: Befehl zur Erstellung eines Evidenzpakets. Erstellt Artefakte für Stakeholder: was sich geändert hat, welche Tests bestanden wurden, wer bestätigt hat.
Data-profiler (Skill): Enger Skill zum Lesen von Quellen und zur Erstellung eines Manifests. Gibt nur Fakten zurück, hat keine Berechtigung, Modelle zu schreiben. Beispiel für einen Skill, der die Rolle des Agenten einschränkt.
Data-contract-review (Sub-Agent): Sub-Agent im Nur-Lese-Modus, der eine Review-Checkliste auf vorgeschlagene Änderungen anwendet. Kann kein SQL bearbeiten – nur rezensieren.
Trennung der Rollen von Generator und Reviewer: Prinzip, demzufolge der Autor von Änderungen und der Prüfende unterschiedliche Entitäten sein müssen. Andernfalls prüft der Agent seine eigenen Vermutungen, was bei Bankdaten gefährlich ist.
Menschliche Bestätigungspunkte: Stellen im Prozess, an denen der Agent anhalten und die Entscheidung an einen lebenden Spezialisten übergeben muss. Ohne diese Punkte verkommt SDD zum Autopiloten.
Hooks: Mechanismus zur automatischen Blockierung gefährlicher Änderungsklassen: PII-Felder in models/marts/, Änderung des YAML-Contracts ohne Bestätigungsmarkierung, Änderung des Grain ohne Hinweis auf Auswirkungen. Hooks ersetzen nicht das Review, sondern verhindern, dass offensichtliche Fehler dieses überhaupt erreichen.
Artefakt: Materielles Ergebnis der Arbeit eines Befehls (Schema Manifest, aktualisierter ODCS, geändertes dbt-Modell, Reviewer-Bericht). Regel: Wenn ein Befehl kein Artefakt hinterlässt, ist er im ersten Durchlauf nicht nötig.
Prozesskarte: Minimaler visueller Output des Kapitels – eine Tabelle mit der Zuordnung von Befehlen und Artefakten. Ermöglicht es, dem Team schnell zu erklären, wer wofür verantwortlich ist.
Contract Drift: Abweichung zwischen dem, was die Quelle verspricht (Contract), und dem, was tatsächlich mit den Daten passiert. Besonders kritisch im Bankenumfeld, wo Drift zu spät entdeckt wird.
Pii (personally identifiable information): Personenbezogene Daten von Kunden. Das Hinzufügen von Feldern mit dem Präfix pii_ in marts-Modelle ist eine typische gefährliche Änderungsklasse, die durch einen Hook blockiert werden muss.
Grain (Modellkorn): Granularitätsstufe der Datensätze in einem dbt-Modell (z. B. „ein Kunde – eine Zeile“). Eine Änderung des Grain ohne expliziten Hinweis auf Downstream-Auswirkungen ist eine häufige Fehlerquelle.
Wichtige Termine: Einführung von SDD in den DataLakeHouse: Reifestufe des Prozesses, auf der wiederkehrende Verstöße sichtbar werden – ein Zeichen dafür, dass es Zeit ist, Hooks zu schreiben
Erster Praxistest: Zeitpunkt, ab dem das Team typische Verstöße bereits versteht und Regeln für Hooks formulieren kann
Nach /clear: Zeitpunkt, an dem ein Reviewer im Nur-Lese-Modus besonders wichtig ist: Wenn er die Änderung anhand der Dateien nicht verstehen kann, bedeutet dies, dass der Autor die Bedeutung im Chat gelassen hat – ein Signal für schlechte Disziplin
Übungsaufgaben: Name: Übung 1: Erstellung einer Prozesskarte für das eigene Projekt
Problem: Sie arbeiten in einem Banken-DataLakeHouse-Team, das mit SDD und Qwen Code beginnt. Beschreiben Sie die Prozesskarte: Welche fünf Befehle werden Sie verwenden, welches Artefakt hinterlässt jeder davon und wo liegt der menschliche Bestätigungspunkt? Verwenden Sie das Tabellenformat aus dem Kapitel.
Lösung: Schritt 1. Listen Sie die fünf Befehle in der richtigen Reihenfolge auf: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release. Schritt 2. Bestimmen Sie für jeden Befehl das Artefakt: profile → Schema Manifest; contract → ODCS/ODPS-Aktualisierung; build → dbt-Modelländerung; verify → dbt build + Verifikationsfakten; release → Evidenzpaket. Schritt 3. Fügen Sie eine sechste Zeile für data-contract-review → Reviewer-Bericht hinzu. Schritt 4. Markieren Sie mit Pfeilen, wo sich der menschliche Bestätigungspunkt befindet (zwischen contract und build, zwischen verify und release). Schritt 5. Überprüfen Sie sich: Hat jeder Befehl ein Artefakt? Wenn nicht – ist dieser Befehl im ersten Durchlauf überflüssig.
Komplexität: beginner
Name: Übung 2: Trennung der Rollen von Autor und Reviewer
Problem: Führen Sie dieselbe Anfrage zur Änderung eines dbt-Modells (z. B. das Hinzufügen eines Felds customer_segment zu einer marts-Tabelle) in zwei Modi aus: (a) ein Agent erledigt alles selbst – profiliert die Quelle, schlägt die Änderung vor, schreibt SQL und reviewt sie; (b) Rollentrennung: Ein Autor-Agent schlägt die Änderung vor, ein Reviewer-Agent im Nur-Lese-Modus prüft. Vergleichen Sie, welche Anmerkungen nur bei der Rollentrennung auftauchen.
Lösung: Schritt 1. Bereiten Sie den Kontext vor: Beschreibung der Quelle, aktueller Contract, bestehendes dbt-Modell. Schritt 2. Modus (a): Bitten Sie einen Agenten, den gesamten Zyklus auszuführen. Halten Sie fest, welche Risiken er sich selbst erlaubt hat. Schritt 3. Modus (b): Starten Sie den Autor – er schreibt die Änderung. Starten Sie den Reviewer im Nur-Lese-Modus (nur Dateien, ohne Chat) – er wendet die Checkliste an. Schritt 4. Vergleichen Sie die Ergebnisse. Typische Anmerkungen, die nur bei der Trennung auftauchen: „Auswirkung auf den Grain nicht beschrieben“, „ODCS nicht aktualisiert“, „Test auf NULL im neuen Feld fehlt“, „nicht geprüft, wer die Konsumenten dieser Spalte sind“, „nicht markiert, dass das Feld PII enthalten kann“. Schritt 5. Formulieren Sie das Fazit: Die Rollentrennung deckt Risiken auf, die der Autor übersieht, weil sie „außerhalb seines Optimismus“ liegen.
Komplexität: intermediate
Name: Übung 3: Entwurf des ersten Hooks
Problem: Das Team hat drei Sprints mit SDD durchgeführt. Die Analyse der Reviews zeigte, dass sich drei Verstöße am häufigsten wiederholen: (1) in models/marts/ tauchen Felder mit dem Präfix pii_ auf; (2) Änderung des YAML-Contracts ohne menschliche Bestätigungsmarkierung; (3) Änderung des Modell-Grain ohne Hinweis in der PR-Beschreibung. Entwerfen Sie einen Hook, der alle drei Änderungsklassen blockiert. Beschreiben Sie ihn konzeptionell (ohne Code).
Lösung: Schritt 1. Formulieren Sie die Blockierungsbedingung: Der Hook wird beim Versuch ausgelöst, Dateien in models/marts/ zu schreiben. Schritt 2. Regel 1: Wenn eine neue oder geänderte Datei ein Feld enthält, das mit pii_ beginnt – Commit mit der Meldung blockieren: „PII in marts erfordert separate Genehmigung“. Schritt 3. Regel 2: Wenn im PR eine beliebige Datei im Verzeichnis contracts/ oder .odcs.yaml geändert wurde und in der Commit-/PR-Nachricht die Markierung „contract-approved“ fehlt – blockieren. Schritt 4. Regel 3: Wenn in models/marts/ eine Datei geändert wurde und in ihr die Zeile {{ config(materialized=..., grain=...) }} oder eine gleichwertige geändert wurde – in der PR-Beschreibung die Zeile „grain-impact:“ erzwingen. Schritt 5. Entscheiden Sie, in welcher Reihenfolge der Hook Fehler ausgibt und welche nur Warnungen sind. Schritt 6. Halten Sie fest: Der Hook ersetzt nicht das Review, sondern verhindert, dass offensichtliche Fehler dieses überhaupt erreichen.
Komplexität: intermediate
Name: Übung 4: Diagnose des Fehlers „/sdd:do-everything“
Problem: Das Team hat einen einzelnen Befehl /sdd:do-everything erstellt, der die Quelle profiliert, den Contract aktualisiert, ein dbt-Modell generiert, Tests ausführt und einen Bericht veröffentlicht. Nach einem Monat ist ein PII-Feld in die Produktion gelangt, das im Contract nicht vorhanden war. Führen Sie eine Analyse durch: Welche menschlichen Bestätigungspunkte wurden gelöscht und welche Artefakte fehlten?
Lösung: Schritt 1. Listen Sie die Bestätigungspunkte auf, die der Befehl hätte haben müssen: (a) nach profile – Bestätigung, dass das Manifest korrekt ist; (b) nach contract – Bestätigung, dass das Versprechen mit den Quell-Stakeholdern abgestimmt ist; (c) nach build – Bestätigung, dass die Änderung korrekt ist; (d) nach verify – Bestätigung, dass das Evidenzpaket vollständig ist. Schritt 2. Im Befehl /sdd:do-everything sind all diese Punkte zu einer einzigen automatischen Ausführung verschmolzen. Der Mensch sieht nur den Abschlussbericht, nicht die Zwischenergebnisse. Schritt 3. Welche Artefakte fehlten: Das Schema Manifest wurde nicht vom Quell-Experten geprüft; die ODCS-Aktualisierung wurde nicht vom Datenverantwortlichen unterzeichnet; der Contract-Reviewer erhielt kein separates Ticket; in den Logs fehlt die menschliche Bestätigungsmarkierung. Schritt 4. Wo genau „riet“ das PII durch: Der Agent fügte das Feld in marts hinzu, weil er es in der Quelle sah, und der Contract für diese Quelle wurde entweder nicht aktualisiert oder automatisch generiert. Schritt 5. Fazit: Ein einzelner Befehl löscht die menschlichen Bestätigungen und verwandelt SDD in einen Autopiloten. Die Lösung besteht darin, ihn in fünf Befehle zu zerlegen und zwischen diesen ausdrücklich manuelle Bestätigungen zu verlangen.
Komplexität: advanced
Fallstudien: Name: Fallstudie 1: Einführung des fünfstufigen SDD im Banken-DataLakeHouse
Szenario: Eine mittelgroße Retailbank (5 Mio. Kunden) führt Qwen Code ein, um die Entwicklung von dbt-Modellen im unternehmensweiten DataLakeHouse zu beschleunigen. Vor der Einführung verbrachten die Analysten bis zu 40 % ihrer Zeit mit der Beschreibung von Quellen und der Abstimmung von Contracts, und Änderungen umgingen häufig die formalen Verfahren. Ein Pilotteam aus 6 Data Engineers beginnt mit der Erstellung von fünf separaten Befehlen: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release.
Aufgabe: Die größten Herausforderungen: (1) Wie kann man das Team davon überzeugen, den Prozess nicht aus „Unbequemlichkeit“ des Wechselns in einen einzigen Befehl zu falten? (2) Wie formalisiert man menschliche Bestätigungspunkte so, dass sie nicht zu formalen Häkchen verkommen? (3) Wie richtet man unterschiedliche Rollen für Generator und Reviewer ein, sodass letzterer nicht vom Chat-Kontext abhängt? (4) Wie wählt man die erste Änderungsklasse für die Hook-Blockierung aus, ohne den Prozess zu überkomplizieren?
Lösung: Das Team ging in mehreren Etappen vor. Etappe 1: Es erstellte die Dateien .qwen/commands/sdd/profile.md, contract.md, build.md, verify.md, release.md – jede mit einer eigenen engen Anweisung. Etappe 2: Es führte den Skill data-profiler ein, der nur das Schema Manifest zurückgibt, ohne Berechtigung, Modelle zu schreiben. Etappe 3: Es sonderte den Sub-Agenten data-contract-review ab, der nur mit den Repository-Dateien arbeitet (Nur-Lese-Modus) und eine Checkliste anwendet. Etappe 4: Nach dem ersten Monat wurden wiederkehrende Verstöße analysiert – es stellte sich heraus, dass in 4 von 11 Fällen PII-Felder ohne ODCS-Markierung in marts gelangten. Dies wurde zur Grundlage für den ersten Hook, der das Schreiben von Feldern mit dem Präfix pii_ in models/marts/ blockiert. Etappe 5: Die Prozesskarte wurde festgehalten und zum Pflichtbestandteil des Onboardings neuer Analysten gemacht.
Ergebnis: Nach drei Monaten: Die durchschnittliche Zeit von der Änderungsanfrage bis zum Release sank um 28 % (von 9 auf 6,5 Tage), die Anzahl der Regressionen durch nicht-kontraktliche Felder fiel auf null, die Zeit für die Beschreibung der Quelle sank um 35 %. Der wichtigste qualitative Effekt: Es gab einen klaren Eigentümer für jedes Artefakt und einen klaren Punkt, an dem die Entscheidung von einem Menschen getroffen wird, nicht vom LLM.
Gewonnene Erkenntnisse: Die Aufteilung in fünf Befehle ist keine Bürokratie, sondern ein Weg, Verantwortung sichtbar zu machen: Das Profil schreibt keine Modelle, der Reviewer bearbeitet kein SQL, der Generator bestätigt nicht seine eigene Sicherheit
Hooks sind erst dann nützlich, nachdem das Team selbst wiederkehrende Verstöße gesehen hat – sonst ist der Hook entweder zu schwach oder zu störend
Ein Reviewer im Nur-Lese-Modus ist besonders nach /clear wertvoll: Wenn er die Änderung anhand der Dateien nicht verstehen kann, bedeutet dies, dass der Autor die Bedeutung im Chat gelassen hat – ein Signal für schlechte Disziplin, das sich leicht mit einer formalen Prüfung abfangen lässt
Die Prozesskarte ist ein minimales, aber verbindliches Artefakt: Ohne sie verstehen neue Teammitglieder nicht, wo ihr Bestätigungspunkt liegt
Verwandte Konzepte: Fünfstufiger Prozess /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release
Skills und Sub-Agenten
Trennung der Rollen von Generator und Reviewer
Menschliche Bestätigungspunkte
Hooks
Name: Fallstudie 2: Fehler des einheitlichen Befehls /sdd:do-everything im Core-Banking-DataLake
Szenario: Eine große Bank (Top 10) hat im Versuch, „DataOps zu beschleunigen“, einen einheitlichen Befehl /sdd:do-everything erstellt, der selbst die Quelle profilierte, den Contract aktualisierte, ein dbt-Modell generierte, Tests ausführte und einen Bericht veröffentlichte. Die Idee war, dass eine einzige Anfrage eines Analysten in einem Zyklus zu einer fertigen Änderung werden sollte. Die ersten zwei Monate lief alles reibungslos.
Aufgabe: Im dritten Monat gelangte in die marts-Tabelle mart_customer_360 das Feld passport_series mit dem Präfix pii_, das nicht im ODCS-Contract der Quelle enthalten war. Das Feld floss in drei Downstream-Berichte, darunter in das regulatorische Dashboard der Zentralbank. Die Schwierigkeit: (1) Der Befehl hinterließ keine Zwischenergebnisse – es gab nur den Abschlussbericht; (2) das Schema Manifest wurde nicht von einem menschlichen Quell-Experten geprüft; (3) die ODCS-Aktualisierung wurde automatisch generiert, ohne Unterschrift des Datenverantwortlichen; (4) in den Logs gab es keine Markierung für manuelle Bestätigung. Die Ursachenanalyse dauerte über eine Woche.
Lösung: Die Bank verzichtete auf /sdd:do-everything und wechselte zu fünf Befehlen. Profil und Contract wurden einer separaten Rolle übertragen – dem Data Steward. Der Generator der dbt-Modelle erhielt einen eingeschränkten Bereich (nur build) und ein Verbot zur Aktualisierung von contracts/. Der Reviewer data-contract-review wurde als separater Sub-Agent im Nur-Lese-Modus gestartet, der nur den Git-Diff erhält, keinen Chat-Kontext. Der Hook wurde sofort geschrieben: Er blockiert jeden Schreibvorgang in models/marts/ mit einem Feld, das mit pii_ beginnt, und verlangt die Markierung contract-approved bei jeder Änderung an ODCS-Dateien. Die menschlichen Bestätigungspunkte wurden in der Sicherheitsrichtlinie verankert: Kein dbt-Modell gelangt ohne Unterschrift des Data Steward in der PR-Beschreibung in main.
Ergebnis: Im nächsten Quartal wiederholten sich solche Vorfälle nicht. Die Prüfer der Zentralbank hoben das Vorhandensein einer expliziten Prozesskarte mit Artefakten als positives Signal für die DataOps-Reife gesondert hervor. Die Entwicklungsgeschwindigkeit erholte sich 6 Wochen nach dem anfänglichen Rückgang – die Analysten erkannten, dass fünf kurze Schritte mit expliziten Bestätigungen schneller sind als ein einziger langer Befehl mit anschließender Vorfallsanalyse im Fehlerfall.
Gewonnene Erkenntnisse: Der einheitliche Befehl /sdd:do-everything ist in der Demonstration bequem, aber bei Bankdaten gefährlich: Die menschliche Bestätigung verschwindet, und Contract Drift wird zu spät entdeckt
Ein Artefakt ist kein Bericht, sondern ein Ankerpunkt für die Untersuchung: Wenn es kein Schema Manifest und keinen unterzeichneten ODCS gibt, kann man niemandem etwas vorwerfen und nichts beweisen, was versprochen wurde
Rollentrennung ist keine Formalität, sondern ein Weg herauszufinden, wer das Problem hätte bemerken müssen: Nach einem Fehler zeigt genau die Rolle, wo ein Schritt ausgelassen wurde
Hooks im Bankenumfeld sollten nicht „alles Verdächtige“ blockieren, sondern eine enge, bekannte gefährliche Klasse – sonst werden sie umgangen
Verwandte Konzepte: Typischer Fehler: /sdd:do-everything
Contract Drift
PII in marts
Artefakt als Ankerpunkt
Hooks als Disziplinarschicht
Name: Fallstudie 3: Evolution vom Skill zum Sub-Agenten im Risikomodellierungs-Team
Szenario: Das Risikomodellierungs-Team einer Investmentbank verwendet Qwen Code, um die Vorbereitung von Vitrinen für Kredit-Scoring-Modelle zu beschleunigen. In der ersten Phase beschrieben sie data-profiler als Skill und data-contract-review als einfache Anweisung im Chat. Nach zwei Monaten wurde klar, dass das „Review im Chat“ leicht ignoriert wird: Der Autor antwortet einfach mit „alles ok“ und macht weiter.
Aufgabe: Das Problem: Der Reviewer muss strukturell eine separate Rolle sein, nicht ein Verhaltensmodus desselben Agenten. Wenn das Review eine Chat-Anweisung ist, bleibt der Agent in derselben Sitzung und erbt den Kontext des Autors, einschließlich seiner Zuversicht in die Richtigkeit der Entscheidung. Darüber hinaus muss der Reviewer nur die Dateien sehen, nicht die Korrespondenz, sonst bewertet er nicht den Code, sondern die Absichten.
Lösung: Das Team verlagerte das Review in einen separaten Sub-Agenten data-contract-review mit eigenem Systemprompt und Nur-Lese-Modus zum Repository. Der einzige Input ist der Git-Diff, kein Chat-Kontext. Die Review-Checkliste wurde formalisiert und enthält nun folgende Punkte: „Feld mit Präfix pii_ – in marts verboten“, „Änderung des Grain – grain-impact in der Beschreibung erforderlich“, „ODCS-Aktualisierung – contract-approved im Commit erforderlich“, „neue Quellabhängigkeit – erneutes profile erforderlich“. Außerhalb der Sitzung /clear bleibt der Reviewer vollständig funktionsfähig, was auch gefordert war.
Ergebnis: Im Quartal stieg die durchschnittliche Anzahl der vom Reviewer gefundenen Anmerkungen von 0,4 auf 2,7 pro PR. Besonders wertvoll erwies sich die Anmerkung „anhand der Dateien nicht verständlich, was die Änderung bewirkt“ – sie tauchte bei Autoren auf, die es gewohnt waren, die Logik im Chat zu erklären, nicht in den Commits. Dies zwang das Team, die Praxis der Commit-Nachrichten und PR-Beschreibungen zu verschärfen, was die allgemeine Codequalität unabhängig vom KI-Werkzeug verbesserte.
Gewonnene Erkenntnisse: Skill und Sub-Agent sind unterschiedliche Isolationsstufen: Der Skill verengt die Rolle in derselben Sitzung, der Sub-Agent bietet einen separaten Kontext und Modus
Ein Reviewer im Nur-Lese-Modus funktioniert am besten nach /clear: Man kann ihn nicht überzeugen, weil er keinen Zugriff auf den Chat hat
Die Review-Checkliste muss explizit sein, sonst verkommt das Review zu „sieht alles normal aus“
Die Anmerkung „anhand der Dateien nicht verständlich“ ist kein Reviewer-Bug, sondern ein Feature: Sie fängt schlechte Änderungsdokumentation ab
Verwandte Konzepte: Skills und Sub-Agenten
data-contract-review
data-profiler
Nur-Lese-Modus
Review-Checkliste
Lerntipps: Zeichnen Sie zuerst die Prozesskarte auf Papier, bevor Sie die Befehlsdateien erstellen: fünf Befehle, fünf Artefakte, klare Bestätigungspunkte. Das dauert 20 Minuten, spart aber wochenlange Kämpfe mit /sdd:do-everything
Führen Sie eine Aufgabe in zwei Modi aus – mit einem Befehl und mit fünf – und halten Sie den Unterschied bei der Anzahl der gefundenen Risiken fest. Das ist anschaulicher als jede Theorie
Schreiben Sie keine Hooks, bevor Sie wiederkehrende Verstöße gesehen haben: Sammeln Sie die ersten zwei bis drei Sprints lang Statistiken und formulieren Sie dann die Regeln
Halten Sie den Reviewer immer im Nur-Lese-Modus und ohne Chat-Zugriff: Das ist der einzige Weg, den Autor dazu zu bringen, verständliche Commits und PR-Beschreibungen zu schreiben
Überprüfen Sie nach /clear, ob der Reviewer die Änderung anhand der Dateien verstehen kann. Wenn nicht – ist das ein Signal, dass der Autor die Bedeutung im Chat gelassen hat, und die Disziplin verlangt eine Korrektur
Das Prinzip „Wenn ein Befehl kein Artefakt hinterlässt, ist er im ersten Durchlauf nicht nötig“ ist ein guter Filter: Fünf Befehle liefern fünf Artefakte; ein Befehl ohne Artefakt ist entweder ein überflüssiger Schritt oder eine schlecht definierte Rolle
Verknüpfen Sie jede Regel mit einer Änderungsklasse: PII in marts, Änderung des Grain, ODCS-Aktualisierung ohne Markierung. Abstrakte Regeln wie „der Code sollte qualitativ hochwertig sein“ funktionieren weder im Review noch in Hooks
Verwenden Sie die Terminologie des Kapitels: „menschlicher Bestätigungspunkt“, „Artefakt“, „Contract Drift“, „Grain“. Das ist eine gemeinsame Sprache, die es dem Team ermöglicht, Änderungen schnell abzustimmen
Zusätzliche Ressourcen: Open data contract standard (odcs): Standard zur Beschreibung von Daten-Contracts, der im Kapitel verwendet wird. Hilft, das Versprechen der Quelle gegenüber dem Konsumenten zu formalisieren. https://bitol-io.github.io/open-data-contract-standard/
Dbt (data build tool): Daten-Transformationstool, das im Kontext der Befehle /sdd:build und /sdd:verify erwähnt wird. Dokumentation: https://docs.getdbt.com/
Pii in data lakehouse: Überblick über Praktiken im Umgang mit personenbezogenen Daten in Lakehouses. Nützlich, um zu verstehen, warum PII in marts eine typische gefährliche Klasse ist
Data contracts (Mark López-Restrepo u. a.): Konzeptionelle Grundlage zu Data Contracts als Mittel zur Festschreibung von Versprechen zwischen Datenproduzenten und -konsumenten
Qwen code und qwen3-coder: Dokumentation zum KI-Werkzeug Qwen Code, einschließlich der Arbeit mit Befehlen, Skills und Sub-Agenten. https://qwenlm.github.io/
Spec-driven development (sdd): Methodik, die dem Kapitel zugrunde liegt. Verwandt mit BDD und TDD, aber mit Fokus auf Datenspezifikationen und Contracts
Separation of duties (sod) im Bankenumfeld: Konzept aus der internen Bankenkontrolle, das erklärt, warum Generator und Reviewer unterschiedliche Rollen sein müssen
Zusammenfassung: Kapitel 21 fasst den gesamten Band zu einem funktionierenden Qwen Code-Prozesszyklus für DataLakeHouse zusammen: fünf Befehle (/sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release), jeder mit einer engen Rolle, einem expliziten Artefakt und einem menschlichen Bestätigungspunkt dazwischen. Die Hauptbotschaft: Ein einzelner Befehl sollte nicht den gesamten Prozess ausführen – sonst verschwinden die menschlichen Bestätigungen und Contract Drift wird zu spät entdeckt, was bei Bankdaten besonders kritisch ist. Skills (data-profiler) und Sub-Agenten (data-contract-review) sind nützlich, wenn sie die Rolle verengen: Der Profiler schreibt keine Modelle, der Reviewer bearbeitet kein SQL, der Generator bestätigt nicht seine eigene Sicherheit. Hooks sind die nächste Disziplin-Stufe, dürfen aber nicht vor dem Prozess geschrieben werden: Zuerst muss das Team wiederkehrende Verstöße sehen (PII in marts, ODCS-Änderung ohne Markierung, Grain-Änderung ohne Hinweis) und sie dann in Regeln formalisieren. Der minimale Output des Kapitels ist eine Prozesskarte mit fünf Befehlen, fünf Artefakten und einer Zeile für den Reviewer-Bericht. Nach der Lektüre sollte der Leser sicher drei Kontrollfragen beantworten können: Warum darf der Prozess nicht in einem einzigen Befehl ausgeführt werden, wie unterscheidet sich ein Skill von einem Sub-Agenten und wo muss die menschliche Bestätigung stehen.