Codegenerierung für Datenpipelines & Analytics Engineering (ETL/ELT, dbt, Spark)

Datenteams verbringen den Großteil ihrer Zeit damit, Transformationscode, Tests, Dokumentation und Orchestrierung zu schreiben und zu pflegen sowie über Nacht ausgefallene Pipelines zu reparieren. KI-Assistenten, die Warehouse-Metadaten, Lineage und das bestehende Projekt kennen, können dbt-Modelle und PySpark-Jobs entwerfen, Tests und Dokumentation ergänzen und Korrekturen für fehlgeschlagene Läufe vorschlagen, während ein Data Engineer jede Änderung in einem Pull Request prüft. Typischer Nutzen: schnellere Lieferung routinemäßiger Modelle und eine deutlich bessere Test- und Dokumentationsabdeckung, nicht unbeaufsichtigte Änderungen in der Produktion.

Problem & Nutzen

• Heute: Ingenieure schreiben Staging-, Zwischen- und Mart-Modelle von Hand, kopieren YAML-Textbausteine für Tests und Spaltenbeschreibungen, bauen DAGs von Hand und analysieren Fehler anhand von Logs. Dokumentation und Tests hinken hinterher; das Wissen steckt in wenigen Köpfen.
• Warum KI hilft: Pipeline-Code ist stark strukturiert (SQL, YAML, Python), Konventionen sind explizit (dbt-Schichtung, Namensgebung), und die Plattform liefert reichen Kontext (Schemas, Lineage, Laufhistorie). Das Erzeugen von Textbausteinen, das Verfassen von Tests und Dokumentation sowie die erste Fehlersuche sind die am besten geeigneten Aufgaben.
• Belege: Anbieter dokumentieren die Erzeugung von Dokumentation, Tests, semantischen Modellen, Metriken und SQL aus Prompts in natürlicher Sprache in der dbt-Studio-IDE [1]. Unabhängige, geprüfte Produktivitätszahlen speziell für Data Engineering sind selten; messen Sie am eigenen Repository, statt sich auf Herstellerangaben zu verlassen.
• Abgrenzung zu: DATA-001 (Fachanwender fragen Daten in natürlicher Sprache ab), DATA-003/008 (Bereinigung und Qualitätsüberwachung), CODE-013 (Schema-Design und Abfrageoptimierung). Dieser Anwendungsfall ist Pipeline-Engineering als Softwaredisziplin.

Varianten

• Analytics Engineering (dbt/SQL): Generierung von Modellen, Tests, Dokumentation und Semantic Layer auf Snowflake, BigQuery, Databricks, Redshift, DuckDB oder EU-Warehouses.
• Lakehouse / Spark: Erstellung von PySpark- und deklarativen Pipelines (Lakeflow Spark Declarative Pipelines), inkrementelle und Streaming-Jobs [2].
• Orchestrierung: DAG-Erzeugung und -Reparatur für Airflow, Dagster, Prefect, einschließlich Backfill- und Retry-Logik.
• Agent zur Pipeline-Fehlersuche: liest Logs fehlgeschlagener Tasks, Abfragehistorie und letzte Commits und schlägt einen Korrektur-PR vor (überschneidet sich mit CODE-010/011).
• Migration: Umstellung von Alt-ETL (Stored Procedures, SSIS, Informatica, Talend) auf dbt/Spark (siehe CODE-005, CODE-021).
• KMU: ein einzelner Analyst mit IDE-Assistent sowie dbt Core und DuckDB/Postgres; kein Plattformteam.

So funktioniert es

1. ticket / requirement + catalog, lineage & schema context (MCP / metadata API)
2. plan (sources, layers, grain, keys, tests)
3. generate code (dbt SQL + YAML, PySpark, DAG)
4. compile & dry-run in a dev/sandbox schema (limited sample, no production write)
5. run generated tests + data-diff vs. current output + SQL lint (sqlfluff)
6. pull request with lineage impact and cost estimate
7. human review & CI (state-aware slim CI)
8. merge
9. scheduled run
10. failure agent: logs + query history
11. hypothesis
12. fix PR

• Kontext ist der Schlüssel: Die Qualität hängt davon ab, dem Modell Schemas, Spaltenbeschreibungen, vorhandene Projektkonventionen und Lineage zugänglich zu machen, meist über einen MCP-Server oder eine Metadaten-API (dbt stellt einen MCP-Server bereit; Databricks Assistant nutzt Unity-Catalog-Metadaten) [1][7].
• Fundierte Ausführung: Der Agent kompiliert und führt in einer Sandbox aus und nutzt Test- und Data-Diff-Ergebnisse als Rückmeldung, statt generiertem SQL zu vertrauen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Jede Änderung landet als geprüfter Pull Request; Produktionszugangsdaten und Schreibrechte erhält der Agent nie; schemabrechende Änderungen und Modelle mit personenbezogenen Daten brauchen eine ausdrückliche Freigabe.

Datenaufbereitung

Die KI braucht Kontext, keine Rohdatensätze: Tabellen- und Spaltendefinitionen, dbt-Projekte, vorhandenen SQL- und Orchestrierungscode, Datenwörterbücher und Geschäftsregeln. Im Mittelstand liegen diese in den ERP-/CRM-Datenbanken, in einem Warehouse (oder nur einer Postgres-/SQL-Server-Datenbank), in Excel-Dateien auf Dateiservern und in den Köpfen von ein bis zwei Personen.

Typische Lücken: undokumentierte Tabellen mit kryptischen Spaltennamen, keine Tests oder Datenverträge, doppelte „Wahrheit“ in mehreren Tabellenkalkulationen, uneinheitliche Kennzahlendefinitionen, keine Staging-Umgebung und Produktionsdaten mit personenbezogenen Feldern, die dem Assistenten zugänglich sind.

Vorbereitungsschritte: 1. Schemas exportieren und Spaltenbeschreibungen ergänzen, zunächst mit KI-Hilfe und Prüfung durch Fachleute (PREP-012, PREP-011). 2. Ein Kennzahlenglossar und einige Referenzabfragen (Gold Standard) schreiben (PREP-016). 3. Pipelines in Git ablegen und grundlegende dbt-Tests ergänzen. 4. Dem Assistenten eine Dev-/Staging-Kopie mit pseudonymisierten oder synthetischen Daten bereitstellen (PREP-022). 5. Zugangsdaten auf Lesezugriff auf Metadaten beschränken.

Werkzeuge: dbt docs, DataHub oder OpenMetadata, Great Expectations. Aufwandsanteil: mittel, etwa 30 bis 40 Prozent, weil die Qualität generierter Pipelines direkt von dokumentierten Schemas abhängt. Siehe DATA-003, DATA-008 und GUIDE-003 für Reifegradprüfungen.

Umsetzungswege

Welcher Weg für wen

• smb (A): Copilot, Cursor oder Warehouse-eigene Assistenten (dbt, Snowflake, Databricks) funktionieren für ein kleines Datenteam auf einem Standard-Stack sofort.
• enterprise (B): Pipelines laufen gegen gesteuerte Warehouses und interne Standards, daher passt ein eigener Agent über API mit Metadaten, Lineage und Leitplanken am besten.
• developer (C): Ein Open-Weight-Codemodell mit Continue/Aider hält Schemas und Abfragen lokal und kostet nur Hardware.

Weg A — Kaufen (Standardsoftware) (für die meisten Teams empfohlen)

• dbt-Plattform: dbt Copilot (Dokumentation, Tests, semantische Modelle, Metriken, SQL) und die agentische Vorschau dbt Wizard [1]. dbt Labs sitzt in den USA; EU-Regionen prüfen.
• Lakehouse-Anbieter: Databricks Assistant und Genie Code mit Lakeflow-Pipelines, Snowflake Cortex Code / Copilot, Data-Engineering-Agenten von Google BigQuery Gemini, Microsoft Fabric Copilot [7].
• Spezialisiert: Paradime (dbt-orientierte IDE), Keboola (Tschechien, EU), Datafold (Data-Diff für KI-generierte Änderungen), Coalesce.
• Allgemeine Coding-Agenten: Claude Code, Cursor, GitHub Copilot, JetBrains AI mit dbt-/Spark-Skills oder MCP-Servern (siehe CODE-001/002).
• A wählen, wenn: Sie bereits eine dieser Plattformen betreiben; der Assistent ist dann ein Lizenz-Upgrade, kein Projekt.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende Codemodelle (Claude, GPT, Gemini) oder Mistral (Codestral, EU-Anbieter) in EU-Regionen (Bedrock Frankfurt, Azure OpenAI EU, Vertex EU, Mistral La Plateforme).
• Orchestrierung: ein Coding-Agent (Claude Agent SDK, LangGraph) mit Werkzeugen für dbt compile/run/test, Warehouse-Dry-Run, Katalogabfrage (OpenMetadata, DataHub, Unity Catalog) und Git-/PR-APIs; ausgelöst durch ein Ticket oder einen fehlgeschlagenen Airflow-/Dagster-Lauf.
• Leitplanken: Sandbox-Zugangsdaten nur mit Lesezugriff, Zeilenlimit und Kostenobergrenzen, Maskierung von Spalten mit personenbezogenen Daten, bevor Stichproben das Modell erreichen.
• B wählen, wenn: Sie Agenten zur Fehlersuche oder Ticket-zu-PR-Abläufe wünschen, die auf Ihr Repository zugeschnitten sind.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Codemodelle: Qwen3-Coder, DeepSeek-V3-Klasse, Codestral/Devstral (Mistral, EU), gpt-oss; betrieben mit vLLM oder Ollama, gesteuert über Continue, Aider, OpenHands oder Cline.
• Offener Datenstack: dbt Core oder SQLMesh, Apache Spark, Airflow/Dagster, DuckDB, OpenMetadata/DataHub als Lineage-Kontext, sqlfluff und dbt-expectations/Great Expectations für Prüfungen.
• Hardware: HW2 für ~30B-Codemodelle bei Aufgaben in einzelnen Dateien; HW3 für agentische Arbeit auf Repository-Ebene mit größeren Modellen.
• C wählen, wenn: die Quelldaten reguliert sind (Gesundheit, Finanzen, öffentlicher Sektor) und Metadaten oder Stichproben Ihr Netz nicht verlassen dürfen.

Weg D — Eigenes Training

Selten gerechtfertigt. Feintuning auf die eigenen dbt-Konventionen einer Organisation und die Historie gemergter PRs kann die Stiltreue verbessern, doch das Abrufen von Projektkonventionen plus Regeldateien bringt meist den Großteil des Gewinns. Erfordert tausende geprüfte, gemergte Beispiele.

Stand der Technik (2026)

• Assistenten entwickeln sich von der Autovervollständigung zu Agenten, die planen, Befehle ausführen und bei Testfehlern nachbessern; dbt, Databricks und Snowflake liefern jeweils agentische Modi auf ihrer Metadatenschicht aus [5][7].
• Stark: Staging-Modelle, Umbenennungen und Typumwandlungen, Standardtests, Spaltendokumentation, einfache Joins und Aggregationen, Übersetzung von Spark nach SQL, DAG-Gerüste.
• Schwach: Korrektheit der Geschäftslogik (Granularität, Fan-out-Joins, langsam veränderliche Dimensionen, verspätet eintreffende Daten), stille semantische Fehler, die dennoch kompilieren und oberflächliche Tests bestehen, Idempotenz und Sonderfälle inkrementeller Modelle sowie kostenineffiziente Abfragen.
• Wirksame Gegenmaßnahmen: Data-Diff gegen die vorherige Ausgabe, Eindeutigkeits-/Not-null-/Beziehungstests für jeden Schlüssel, Modelle mit erzwungenem Vertrag und Definitionen im Semantic Layer als gesteuerte Quelle der Kennzahlenwahrheit.
• Veröffentlichte Grenzen: dbt weist darauf hin, dass Copilot die neueste semantische YAML-Spezifikation noch nicht abdeckt und menschliche Prüfung erfordert [1].
• Benchmarks für Data-Engineering-Agenten sind noch unausgereift; behandeln Sie öffentliche Werte vorsichtig und bauen Sie aus Ihren eigenen Tickets ein internes Evaluierungsset auf (siehe CODE-018).

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie CODE-001/002 (IDE- und PR-Agenten), CODE-004 (Testgenerierung), CODE-006 (Dokumentation), CODE-013 (SQL-Optimierung), CODE-021 (Refactoring im großen Maßstab).
• Metadatenschicht (Katalog + Lineage, z. B. OpenLineage, OpenMetadata) wird mit DATA-001 (NL-zu-SQL), DATA-003 und DATA-008 (Qualitätsüberwachung) geteilt und ist für alle die wertvollste Investition.
• Nachgelagert: CODE-010/011 (Störungserkennung und Log-Analyse) speisen den Reparatur-Agenten; CODE-009 für die Infrastruktur der Datenplattform.
• Evaluierung und Tracing: CODE-018.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preise pro Nutzer oder nach Verbrauch zusätzlich zur Plattform.
• Weg B: 1-3 Monate für einen Ticket-zu-PR-Agenten mit Sandbox, CI und Katalogintegration; die Tokenkosten sind im Verhältnis zur Arbeitszeit der Ingenieure gering, versteckter Kostentreiber ist die Warehouse-Rechenleistung für Testläufe des Agenten.
• Weg C: 2-4 Monate plus GPU-Betrieb.
• Kennzahlen: Durchlaufzeit von Ticket bis Merge, Anteil der Modelle mit Tests und Dokumentation, PR-Ablehnungs-/Nacharbeitsquote bei KI-generierten Änderungen, durchgerutschte Datenvorfälle, mittlere Zeit bis zur Reparatur fehlgeschlagener Läufe, Warehouse-Kosten pro Änderung.

Menschen & Veränderung

Einbinden: Geschäftsleitung und Leitung Daten/IT entscheiden über Umfang und Budget. Die Datenverantwortlichen von ERP-, CRM- und Finanzquellen müssen freigeben, welche Schemas und Beispieldaten der Assistent sehen darf. Die IT stellt Umgebungen und Zugangsdaten bereit; die bzw. der Datenschutzbeauftragte ist nötig, wenn Staging-Daten personenbezogene Daten enthalten (Kunden, Beschäftigte), einschließlich AVV mit dem Tool-Anbieter und, bei umfangreichen personenbezogenen Daten, einer DSFA-Prüfung (GUIDE-005).

Betriebsrat: kommt darauf an. Assistenten protokollieren Prompts und Aktivität je Entwickler, wodurch das Werkzeug objektiv zur Überwachung geeignet ist (§87(1) Nr. 6 BetrVG, BAG). Analysen auf Mandantenebene je Person sollten deaktiviert oder in einer Betriebsvereinbarung geregelt werden; §90(1) Nr. 3 BetrVG verlangt rechtzeitige Information. Nach §80(3) kann ein Sachverständiger hinzugezogen werden. Öffentlicher Sektor: Personalrat.

KI-Kompetenz: Unterstützen Sie das Datenteam (Art. 4 KI-Verordnung) mit Schulungen dazu, generiertes SQL zu überprüfen, stille Logikfehler zu erkennen und keine personenbezogenen Produktionsdaten in Prompts einzufügen (GUIDE-006, GUIDE-007).

Pilot und Kommunikation: Wählen Sie einen Analytics Engineer und eine unkritische Pipeline; vergleichen Sie vier Wochen lang Prüfzeit und Fehler. Sorgen: „Meine Stelle wird automatisiert“ und „falsche Zahlen erreichen die Geschäftsleitung“. Antwort: Die KI entwirft, Menschen prüfen und verantworten jeden Merge, Tests steuern das Deployment (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko (Entwicklerwerkzeug, keine Verwendung nach Anhang III); die Pflicht zur KI-Kompetenz (Art. 4) gilt für das Team [3]. Speisen die generierten Pipelines ein Hochrisikosystem (Kreditwürdigkeitsprüfung, Personalwesen), gelten die Daten-Governance-Pflichten (Art. 10) für dieses System, nicht für das Coding-Werkzeug.
• DSGVO: Schema-Metadaten sind meist nicht personenbezogen, aber Stichproben, Abfrageergebnisse und Logs, die an Modellanbieter gehen, können personenbezogene Daten enthalten. Stichproben maskieren oder synthetisieren, EU-Regionen mit Auftragsverarbeitungsvertrag nutzen und Datenminimierung anwenden (Art. 5, 25, 28 DSGVO) [4]. Generierte Pipelines müssen Aufbewahrungs-, Lösch- und Zugriffskontrolllogik erhalten.
• Sicherheit: Prompt-Injection über Spaltenkommentare, Tabelleninhalte oder Ticket-Texte; überprivilegierte Zugangsdaten; Secrets in Logs. Rollen mit minimalen Rechten verwenden und keinen Schreibzugriff auf die Produktion gewähren.
• Qualität und Lineage: Stille Logikfehler sind das größte Geschäftsrisiko; Tests, Data-Diff und Prüfung verlangen. Einen Prüfpfad der von KI verfassten Commits führen.
• Lizenzen: Lizenz des Codemodells und Herstellerbedingungen für generierten Code prüfen; Data Act der EU und Cloud-Portabilität sprechen dafür, Pipelines in offenen Formaten zu halten (dbt, SQL, Iceberg/Delta).

Erste Schritte

1. Einen abgegrenzten Bereich (ein Quellsystem, ein Mart) mit bestehendem dbt-Projekt oder Spark-Repository und klaren Konventionen wählen; die Konventionen in eine Regeldatei schreiben.
2. Katalog-, Schema- und Lineage-Metadaten dem Assistenten bereitstellen (MCP oder plattformeigen), nur mit maskierten Stichproben.
3. Mit der Erzeugung von Dokumentation und Tests beginnen, dann Staging-Modelle, dann Marts; immer in einem Dev-Schema mit CI.
4. Data-Diff- und Vertragstests in die CI aufnehmen, damit KI-generierte Änderungen automatisch geprüft werden.
5. Kennzahlen 4-6 Wochen verfolgen, dann einen Agenten zur Fehlersuche für rein lesende Diagnose ergänzen, bevor Korrektur-PRs erlaubt werden.

Quellen

1. dbt Labs — Use dbt Copilot (docs, tests, semantic models, SQL) — https://docs.getdbt.com/docs/platform/use-dbt-copilot
2. dbt Labs — Develop with AI in the Studio IDE — https://docs.getdbt.com/docs/platform/studio-ide/develop-copilot
3. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. dbt Labs — About dbt Wizard — https://docs.getdbt.com/docs/cloud/dbt-copilot
6. dbt Labs — Introducing dbt Copilot — https://www.getdbt.com/blog/introducing-dbt-copilot
7. Databricks documentation — Lakeflow Spark Declarative Pipelines — https://docs.databricks.com/aws/en/dlt/
8. OpenLineage project — https://openlineage.io/