Sicherheitsvorkehrungen für von KI erstellte dbt-Projekte mit dbt-bouncer

dbt 2.0 wurde letzte Woche veröffentlicht. Das Hauptaugenmerk lag dabei auf der Engine: Nach vielen Monaten der Entwicklung wird dbt 2.0 nun mit Fusion als allgemein verfügbar (GA) ausgeliefert, und in den Berichten ging es vor allem darum, um wie viel schneller das Parsen und Kompilieren nun erfolgt.

Im gleichen Zeitraum wurde ein wachsender Anteil der DBT-Modelle, die weltweit in Pull-Anfragen eingereicht werden, nicht mehr von Hand geschrieben. Sie werden von einem Programmieragenten entworfen und anschließend angepasst. Bei Xebia beobachten wir dies mittlerweile in einer Vielzahl von Kundenprojekten, und das Muster ist durchgängig: Die Kosten für die Erstellung eines dbt-Modells sind gesunken, während die Kosten für dessen Überprüfung unverändert geblieben sind oder sogar gestiegen sein könnten. Früher war die Erstellung der Engpass; heute ist es das Vertrauen.

Was Makler tatsächlich falsch machen

Agenten machen selten Fehler bei der SQL-Abfrage. Geben Sie einem Agenten eine Quelltabelle und eine Beschreibung dessen, was Sie wünschen, und Sie erhalten eine Abfrage zurück, die (irgendwann) ausgeführt wird und Zeilen zurückgibt.

Was es Ihnen jedoch nicht liefern kann, sind die Konventionen Ihres Teams, da diese Konventionen nie an einem Ort festgehalten wurden, auf den es Zugriff hat. Sie sind vor achtzehn Monaten im Rahmen einer Diskussion entstanden und existieren nur in den Köpfen der drei Personen, die damals anwesend waren, von denen eine inzwischen nicht mehr für das Unternehmen tätig ist:

Ein Entwickler, der mit einer solchen Lücke konfrontiert wird, hält nicht inne und fragt nach. Er wählt eine plausible Lösung aus und macht weiter. Einmal ist das bei der Überprüfung nur eine Kleinigkeit. Über vierzig Pull-Anfragen hinweg ist es jedoch eine Abweichung, und diese Abweichung lässt sich später nur mit hohem Aufwand rückgängig machen.

Es gibt ein Problem zweiter Ordnung, das noch besorgniserregender ist. Früher, als Kollegen Modelle noch von Hand schrieben, las der Prüfer das Modell sorgfältig durch. Wenn ein Agent es verfasst hat und der Diff übersichtlich aussieht, überfliegt der Prüfer den PR, wobei er manchmal nur den Kommentar der KI-Prüfung betrachtet und den eigentlichen Code gar nicht erst ansieht. Der Code, dem am wenigsten menschliche Aufmerksamkeit geschenkt wird, ist nun genau der Code, an dem von vornherein am wenigsten menschliches Engagement beteiligt war.

Die Lösung besteht darin, die Konventionen in einer Form festzuhalten, auf die der Makler zugreifen kann.

Warum legen Sie die Konventionen nicht einfach unter „ CLAUDE.md “ ab?

Ich bin ein Fan von „ CLAUDE.md “; ich habe sogar einen Blogbeitrag darüber verfasst, wie man ein dbt-Projekt darauf aufbaut. Tragen Sie dort Ihre Konventionen ein, und ein Agent wird sich in den meisten Fällen daran halten.

Meistens liegt das Problem darin. Eine „ CLAUDE.md “ ist eine Anweisung an ein Modell, und das Modell wägt diese gegen alle anderen Elemente in seinem Kontext ab. Je größer die Datei wird und je mehr sich der Kontext mit der eigentlichen Aufgabe füllt, desto weniger Beachtung finden einzelne Anweisungen. Es gibt keinen Hinweis darauf, wann eine Anweisung übersprungen oder außer Kraft gesetzt wird.

Eine „ dbt-bouncer “-Prüfung ist eine Assertion. Sie wird nach der Ausführung des Codes ausgeführt, liefert jedes Mal dasselbe Ergebnis, und wenn sie fehlschlägt, wird der Build als fehlerhaft markiert. Sie deckt zudem Code ab, den der Entwickler nicht selbst geschrieben hat: etwa von einem Kollegen in Eile, einem anderen Entwickler oder einem Mitwirkenden, dessen Editor Ihre Datei „ CLAUDE.md “ gar nicht geladen hat.

Als Faustregel gilt daher: Speichern Sie die Konventionen unter „ CLAUDE.md “, damit der Agent sie in den meisten Fällen korrekt anwendet. Speichern Sie sie unter „ dbt-bouncer “, damit keine Änderungen, die gegen diese Konventionen verstoßen, übernommen werden.

Schritt 1: Machen Sie die Konventionen umsetzbar

Das ist das Problem dbt-bouncer wofür es entwickelt wurde, und ich habe hier über die ursprüngliche Version geschrieben. Es führt Prüfungen an den Artefakten von dbt durch, benötigt daher keine Datenbankverbindung und funktioniert mit jedem Adapter. Es gibt 127 (und es werden immer mehr) Prüfungen, die Modelle, Quellen, Makros, Exposures, Seeds, Snapshots, Tests und Ausführungsergebnisse abdecken.

In Version 4 (die diese Woche veröffentlicht wurde!) benötigen Sie keine Konfigurationsdatei mehr, um herauszufinden, ob diese Funktionen für Sie von Nutzen sind. Das Paket enthält drei Voreinstellungen:

pip install dbt-bouncer
dbt-bouncer run --preset standard

Wenn man dies in unserem Testprojekt ausführt, ergibt sich Folgendes:

Running dbt-bouncer (4.0.0)...
Using the `standard` preset configuration.
Validating conf...
Assembled 91 checks, running...
Running checks... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
`dbt-bouncer` failed. Please see below for more details.
Failed checks
╭──────────────────────────────────────────────────────┬──────────╮
│ Check name                                           │ Severity │
├──────────────────────────────────────────────────────┼──────────┤
│ check_source_not_orphaned:12:sources_that_dont_real… │ ERROR    │
╰──────────────────────────────────────────────────────┴──────────╯
Done. SUCCESS=90 WARN=0 ERROR=1

minimal ist ein Ausgangspunkt für ein Projekt ohne jegliche Konventionen; „ standard “ würden wir für die meisten Projekte verwenden, und „ strict “ umfasst den vollständigen Satz. Wenn Ihnen eine Voreinstellung nicht mehr ausreicht, erstellt „ dbt-bouncer init “ eine Konfigurationsdatei, die Sie bearbeiten können.

Sobald Sie eine Konfiguration haben, mit der Sie zufrieden sind, gehört diese an zwei Stellen hin.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/godatadriven/dbt-bouncer
    rev: v4.0.0
    hooks:
      - id: dbt-bouncer
        args: ["--config-file", "dbt-bouncer.yml"]

Schritt 2: Stellen Sie sicher, dass die Konventionen für den Agenten lesbar sind

Ein fehlgeschlagener „ pre-commit “ oder CI zeigt Ihnen an, dass ein Agent gegen eine Konvention verstoßen hat. Dem Agenten selbst sagt dies nichts: Er schreibt ein Modell, der Hook oder CI schlägt fehl, und ein Entwickler leitet den Fehler zurück (oder Sie bitten den Agenten, die Fehlerprotokolle auszuwerten). Dieser Kreislauf funktioniert zwar, kostet jedoch jedes Mal einen Zyklus, und der Agent ist hinsichtlich des Grundes für den fehlgeschlagenen Check nicht schlauer als zuvor.

dbt-bouncer Mit v4 wird der Kreis geschlossen, indem der Agent die Prüfungen über einen MCP-Server selbst ausführt. Dies ist eine optionale Funktion, die vor allem dann von Nutzen ist, wenn „ dbt-bouncer “ zu einem bereits bestehenden dbt-Projekt hinzugefügt wird.

pip install 'dbt-bouncer[mcp]'

{
  "mcpServers": {
    "dbt-bouncer": {
      "command": "dbt-bouncer",
      "args": ["mcp"]
    }
  }
}

Dadurch wird ein MCP-Server registriert, der vier Tools bereitstellt: list_checks, explain_check, read_project_config und run_checks. Bevor der Agent etwas schreibt, kann er die Konfiguration des Projekts auslesen und feststellen, welche Konventionen gelten. Nach dem Schreiben kann er die Prüfungen durchführen und seine eigene Ausgabe korrigieren. Der Pull-Request, den Sie schließlich lesen, ist bereits erfolgreich.

Jeder Check-in in Version 4 verfügt über einen stabilen Regelcode, und Sie können diesen sowohl über die Befehlszeile als auch über das Tool „ explain_check “ abfragen:

dbt-bouncer explain MO020

╭─ check_model_description_contains_regexp_pattern (MO020) ──────────╮
│ Models must have a description that matches the provided pattern.  │
│                                                                    │
│ !!! info "Rationale"                                               │
│     A free-text description field is easy to fill with             │
│     placeholder or low-quality content. Requiring descriptions to  │
│     match a pattern ensures that documentation meets a baseline    │
│     standard of usefulness rather than just being non-empty.       │
╰────────────────────────────────────────────────────────── manifest ─╯

Die Begründung ist der Aspekt, der das Verhalten eines Mitarbeiters verändert. Erhält ein Mitarbeiter lediglich die Information, dass eine Überprüfung fehlgeschlagen ist, wird er das Nötigste tun, um die Meldung verschwinden zu lassen – oft ist dies jedoch der falsche Ansatz. Wird ihm hingegen erklärt, warum die Regel besteht, neigt er dazu, das zugrunde liegende Problem zu beheben.

Für Nutzer von Claude Code dient das Repository gleichzeitig als Plugin und enthält eine Funktion, die ein bestehendes dbt-Projekt auswertet und eine Konfiguration vorschlägt, die auf den darin bereits vorhandenen Konventionen basiert. Dies ist ein pragmatischer Einstieg: Übernehmen Sie zunächst Ihre bisherigen Vorgehensweisen und optimieren Sie diese anschließend.

Schritt 3: Sorgen Sie dafür, dass der Ausstiegscode glaubwürdig ist

In den ersten beiden Schritten gelangt der Agent in eine Schleife, in der er die Prüfungen selbst durchführt. Ein Agent liest den Exit-Code aus, markiert den Schritt als erledigt und fährt mit der nächsten Aufgabe fort.

In Version 4 geben Ihnen die Exit-Codes Aufschluss darüber, um welche Art von Fehler es sich handelt:

Eine Pipeline, die jeden Code ungleich Null als Fehler behandelt, funktioniert weiterhin unverändert. Eine Pipeline, die „ 1 “ als einzigen Fehler behandelt, muss aktualisiert werden, da sich nun ein falsch konfigurierter Lauf von einem solchen unterscheiden lässt, bei dem Probleme festgestellt wurden.

Diese Funktion aktivieren, wenn bereits Verstöße vorliegen

Wenn Sie „ --preset strict “ auf ein bereits ausgereiftes dbt-Projekt anwenden, werden Hunderte, möglicherweise sogar Tausende von Fehlern angezeigt. Da niemand einen Bereinigungssprint dafür einplant, wird das Tool in der Regel deaktiviert.

In Version 4 wird hierfür eine Basislinie eingeführt:

dbt-bouncer baseline --config-file dbt-bouncer.yml
git add .dbt-bouncer-baseline.json
dbt-bouncer run --baseline .dbt-bouncer-baseline.json

Der erste Befehl protokolliert die heutigen Fehler. Danach führen nur noch Fehler, die nicht in der Baseline enthalten sind, zum Fehlschlagen des Builds. Bestehende technische Schulden sind sichtbar, blockieren den Build jedoch nicht. Es gibt zudem das Flag „ --state “, das den Vergleich nicht anhand einer Datei, sondern anhand eines Verzeichnisses mit Artefakten aus einem früheren Durchlauf vornimmt.

Dies eignet sich für von Agenten geschriebenen Code: Das Modell, das Ihr Agent heute Morgen geschrieben hat, unterliegt den vollen Standards. Das Modell, das jemand im Jahr 2022 geschrieben hat, unterliegt diesen Standards erst dann, wenn sich jemand entscheidet, es zu bearbeiten.

Ausführung unter dbt 2.0

dbt-bouncer v4 läuft unter dbt 2.0 ohne Konfigurationsänderungen, da dbt 2.0 dieselben Artefaktschemata ausgibt wie dbt 1.x. Alle Prüfungen, die zuvor funktioniert haben, funktionieren weiterhin.

Was sich geändert hat, ist die Art und Weise, wie Sie catalog.json generieren:

Falls bei konfigurierten Katalogprüfungen ein Katalog fehlt, weist v4 Sie darauf hin und beendet den Befehl „ 3 “, anstatt die Prüfungen zu überspringen.

Was das für Sie bedeutet

Konventionen in einem dbt-Projekt waren schon immer Teil der Dokumentation, deren Einhaltung jedoch nicht erzwungen wurde. Durch den Einsatz von Agenten ist es schwieriger geworden, dies zu ignorieren, da ein Agent Ihre Confluence-Seite nicht lesen kann und Sie nicht fragen wird, was Sie damit gemeint haben.

Notieren Sie die Konventionen also in Form von Prüfungen, gewähren Sie dem Agenten Zugriff darauf und stellen Sie sicher, dass der Exit-Code angibt, was tatsächlich schiefgelaufen ist.

dbt-bouncer Version 4 ist nun verfügbar. Der Migrationsleitfaden behandelt die kompatibilitätsbrechenden Änderungen, und das Repository ist der ideale Ausgangspunkt.

Gehören Sie zu einer Organisation, die sich mit der Implementierung von Best Practices rund um dbt beschäftigt? Unsere Berater für Analytik-Ingenieure helfen Ihnen gerne weiter - kontaktieren Sie uns einfach und wir melden uns bei Ihnen. Oder sind Sie ein Analyst, Analytiker oder Datentechniker und möchten mehr über dbt erfahren? Schauen Sie sich unseren dbt Learn Kurs in der Xebia Academy an oder werfen Sie einen Blick auf unsere Stellenangebote.