KI-Agenten als Pipeline-Engineers (1/2): Pipeline Generation

 yaico        May 15, 2026

Eine neue Data Pipeline anlegen — Shopify-Bestellungen rein, Amazon-Bestellungen rein, kombiniertes Sales-Dashboard raus — war bis vor kurzem ein Mehrtages-Projekt. Connector schreiben, Spalten mappen, Tests dazu, Deployment vorbereiten. Mit dem richtigen Setup im Repo — wie es yaico Reveal out of the box mitbringt — reicht heute ein Prompt an Claude:

In Action: eine neue Data Pipeline als DAG per Claude

> Hey Claude, baue ein Sales-Dashboard, das Shopify- und Amazon-Bestellungen
  zusammenführt.

→ Ich schaue mir die Reference-DAGs und die API-Docs in der Library an.
  ShopifyOrderLineItemsNode und AmazonOrderLineItemsNode existieren bereits.

→ Lege SalesDashboardPipeline.cs an — zwei Source-Nodes, ein DashboardIndex,
  Abhängigkeiten verdrahtet, Run-Aufruf am Ende:

Das Ergebnis ist lauffähiger Source-Code, der sofort durch Claude getestet und optimiert wird, bis er das gewünschte Ergebnis produziert:

var ctx     = PipelineContext.Create("/pipelineroot").EnsureDirectories();
var shopify = new ShopifyOrderLineItemsNode(ShopifyConnectorConfig.FromEnv(), context: ctx);
var amazon  = new AmazonOrderLineItemsNode (AmazonSpApiConnectorConfig.FromEnv(), context: ctx);

var top = new DashboardIndexNode("Sales", ctx);
top.DependsOn(shopify);
top.DependsOn(amazon);

Helpers.RunSemDag(top, false, Console.WriteLine);

2 Stunden statt 2 Tage — und das Ergebnis ist nicht ein Entwurf, sondern eine produktionsfähige Pipeline. Claude generiert nicht nur den Code, sondern führt ihn lokal aus, prüft die Audit-Logs, korrigiert Spalten-Mappings und Edge-Cases im Loop, schreibt die Tests dazu und reicht erst einen PR ein, wenn der DAG sauber durchläuft. Was bei dir landet, geht in den nächsten Cron-Run.

Zwei Sätze an Claude, eine lauffähige Pipeline, Tests und Audit-Trail gleich mit dabei. Das geht nicht, weil das LLM heute besser ist — es geht, weil unsere DAG-Engine Reveal so gebaut ist, dass der Agent darin navigieren kann. Und genau darum geht’s in diesem Artikel.

Dies ist Teil 1 einer zweiteiligen Serie:

  • Generation (dieser Artikel) — neue Pipelines aus dem Prompt heraus
  • Operation — Monitoring, Debug, Extend, Run, alles agentengetrieben

Was der Agent zum Generieren liest

Damit das Beispiel oben funktioniert, braucht der Agent vier Artefakte direkt im Source-Repo:

README.md im Source-Repo — Der schnellste Einstieg. Was die Pipeline tut, welche Konventionen gelten, wo Beispiele liegen. Eine knappe README ist mehr wert als 50 Seiten Confluence.

Samples — Existierende Connectoren, Transformations-Nodes, Tests. Der Agent lernt euer Pattern by example. Wer Samples pflegt, generiert per Prompt — wer keine hat, schreibt jedes Mal von Hand.

API-Docs im Code — DocStrings, XML-Comments, Interface-Definitionen. Source-of-truth ist der Code, nicht eine externe Doku-Site. Der Agent referenziert sie direkt beim Schreiben.

Source-Code — Der Agent liest die gesamte Codebase. Klare Klassennamen, kurze Methoden, wenig Magic. Was für Code-Review gut ist, ist auch für LLM-Lesbarkeit gut.

Agent generiert einen Reveal-DAG aus User-Prompt, README, Library Source, Reference DAGs und API-Docs

Sind diese vier Säulen da, wird Generation eine Frage von Stunden statt Tagen. Fehlt eine, schreibt der Agent jedes Mal von Hand mit — oder rät, mit entsprechendem Risiko. Reveal liefert genau diese vier Säulen out of the box.

Das Ergebnis ist ein fertiges Programm, das als Docker-Image gebaut und in einen Kubernetes-Cluster deployt werden kann. Auch diese Schritte — Image-Build, Helm-Chart-Update, Rollout — übernimmt Claude. Mehr dazu in Teil 2: Pipeline Operation.

Im zweiten Teil zeige ich, was beim Operating der laufenden Pipeline mit dem gleichen Setup möglich ist — Monitoring, Debug, Extend, Run, alles agentengetrieben.

Weiter zu Pipeline Operation →
Reveal kennenlernen →