Data Engineering hat ein Skalierungsproblem. Eine Pipeline nach der anderen bauen, monitoren, debuggen — das ist wertvolle Ingenieurszeit, die in repetitiven Aufgaben steckt. In diesem Artikel zeige ich, wie ein KI-Agent wie Claude diese Aufgaben vollständig übernehmen kann: von der Erstellung einer neuen Pipeline bis hin zum selbstständigen Debugging eines Datenfehlers.
Die Grundlage dafür ist unsere DAG-Engine Reveal — und das Prinzip dahinter lässt sich auch auf andere Pipeline-Frameworks anwenden, solange man die richtigen Voraussetzungen schafft.
Was der Agent wissen muss
Bevor ein KI-Agent sinnvoll mit einer Data Pipeline arbeiten kann, braucht er Zugang zu allen relevanten Informationen. Das klingt offensichtlich — aber in der Praxis fehlt dieser Kontext fast immer.
Was “alle relevanten Informationen” konkret bedeutet:
Pipeline-Implementierung Der Agent muss den Code der Pipeline kennen. Das heißt: Zugang zum Repository, idealerweise als direkter Clone. Ein LLM ist in der Lage, Quellcode zu lesen, DAG-Strukturen zu verstehen und Transformationslogik zu interpretieren. Keine Zusammenfassung, kein Dokument — der echte Code.
Daten-Orte Wo liegen die Eingangsdaten? Wo landen die Ausgaben? Connection Strings, Bucket-Namen, Datenbankschemas — alles, was der Agent braucht, um Daten direkt zu inspizieren.
Helm Chart Ein LLM kann Helm Charts lesen und verstehen. Man muss ihm nur den Clone zeigen. Damit kennt der Agent das Deployment-Setup: welche Images laufen, welche Environment-Variablen gesetzt sind, welche Kubernetes-Ressourcen existieren.
Querverbindungen zwischen Artefakten Das ist der entscheidende Punkt. Code, Helm Chart, Kubernetes-Cluster und Daten-Orte müssen miteinander verbunden sein — nicht in einem separaten Wiki, sondern als navigierbare Verweise direkt im Kontext des Agenten. Wenn der Agent in Node A einen Fehler vermutet, muss er von dort direkt zum Helm Chart und von dort zum laufenden Kubernetes-Pod navigieren können, ohne dass ein Mensch den nächsten Schritt einleitet.
Ein konkretes Beispiel: “Die Daten im Report passen nicht”
Der Klassiker im Data-Engineering-Alltag. Kunde schreibt: “Die Zahlen im Report von gestern stimmen nicht.” Kein Stack-Trace, kein Kontext — nur das Symptom.
So geht ein KI-Agent mit dem richtigen Setup damit um:
Schritt 1 — DAG analysieren, relevanten Knoten identifizieren
Der Agent liest zunächst den DAG der Pipeline. In Reveal passiert das direkt aus dem Code — jede Node-Klasse ist selbstbeschreibend, und der Mermaid-Code der Pipeline gibt die Struktur wieder. Der Agent entscheidet anhand von Node-Typ (Transform, Match, Report) und Position im DAG, welcher Knoten für den gemeldeten Fehler in Frage kommt.
> Hey Claude, die Auswertung für gestern zeigt falsche Umsatzzahlen. Welcher Teil der Pipeline ist betroffen?
→ Ich sehe im DAG drei mögliche Kandidaten: CashFlowNormalize, VerheirateMatch und ReportNode.
Da der Fehler im finalen Report liegt, schaue ich zunächst auf ReportNode — dessen Input kommt
von VerheirateMatch. Ich prüfe jetzt die Eingangsdaten dieses Knotens.
Schritt 2 — Eingangsdaten inspizieren
Der Agent greift direkt auf die Eingangsdaten des verdächtigen Knotens zu. Er liest die tatsächlichen Rohdaten aus der Datenquelle — nicht Logs, sondern die Datensätze selbst.
→ Ich sehe 47 Transaktionen vom gestrigen Tag. Davon haben 12 Einträge kein gültiges
Gegenkonto. Das entspricht genau der Differenz im Report.
Schritt 3 — Fehlerursache im Code suchen
Jetzt geht der Agent zurück in den Code — konkret in die Klasse, die für den Matching-Schritt zuständig ist. Er sucht nach der Logik, die bestimmt, welche Transaktionen durchkommen und welche herausgefiltert werden.
→ In VerheirateMatchNode.cs, Zeile 84, finde ich eine Filterbedingung:
where t.CounterAccountId != null && t.CounterAccountId != ""
Problem: Transaktionen mit CounterAccountId = "0" (als String) werden nicht gefiltert,
aber später schlägt der Join fehl. Ich schlage vor, die Bedingung auf
int.TryParse zu ändern und auf > 0 zu prüfen.
Schritt 4 — Fix einspielen und Pipeline neu starten
Der Agent passt den Code an. Über die CI/CD-Pipeline wird automatisch ein neues Docker-Image gebaut. Jetzt braucht der Agent zwei Dinge: das Helm Chart (um das neue Image-Tag zu kennen) und Zugang zum Kubernetes-Cluster.
> Hey Claude, das neue Image ist gebaut (Tag: 2026-05-15-fix-counter-account).
Kannst du einen manuellen Pipeline-Run mit dem neuen Image starten?
→ Ich aktualisiere das Image-Tag im Helm Chart auf 2026-05-15-fix-counter-account
und triggere einen manuellen Run des betroffenen CronJobs im Namespace reveal-prod.
kubectl create job --from=cronjob/verheiraते-match verheiraте-match-manual-20260515
Run gestartet. Ich beobachte die Logs.
Was Reveal hier ermöglicht
Der Ablauf oben ist kein Zukunftsszenario — er funktioniert heute, weil Reveal-Pipelines so gebaut sind, dass ein LLM direkt damit arbeiten kann:
- Selbstbeschreibende Node-Klassen: Jede Node enthält Metadaten über Input-Typ, Output-Typ und Transformationslogik. Ein Agent kann die gesamte Pipeline aus dem Codebase lesen, ohne Dokumentation.
- Mermaid-DAG im Code: Die Abhängigkeitsstruktur ist maschinenlesbar direkt im Repository — kein manuell gepflegtes Diagramm.
- Audit Trail: Jeder Pipeline-Run wird protokolliert. Der Agent kann Runs vergleichen und Regressionen erkennen.
- Kubernetes-nativ: Reveal läuft auf Kubernetes. Der Agent kann über
kubectldirekt eingreifen — Jobs triggern, Logs lesen, Image-Tags aktualisieren.
Für wen das relevant ist
Data Engineers und Berater, die Pipeline auf Pipeline implementieren: Das Setup-Investment (Repository-Struktur, Helm-Chart-Konventionen, Querverbindungen zwischen Artefakten) zahlt sich bereits ab der zweiten Pipeline aus. Debugging, das früher Stunden gedauert hat, dauert Minuten.
Software-Vendor-Teams, die Reporting- und Analytics-Features in ihr Produkt einbauen wollen: Wenn eure Kunden ihre Pipelines selbst erweitern und debuggen können — mit einem KI-Agenten als Interface — dann wird euer Produkt mit jedem Kundenwunsch besser, ohne dass ihr jede Anpassung selbst implementieren müsst.
Der entscheidende Schritt ist nicht das LLM — das gibt es. Der entscheidende Schritt ist, die Pipeline-Infrastruktur so zu bauen, dass ein Agent überhaupt navigieren kann. Wer das einmal richtig aufsetzt, bekommt einen Mitarbeiter, der rund um die Uhr verfügbar ist, keinen Kontext verliert und sich über Routine-Debugging nicht beschwert.