Über 80 % der neuen Datenbanken auf Databricks werden inzwischen von KI-Agenten angelegt, nicht von menschlichen Engineers. Diese Zahl aus dem Databricks-Jahresbericht 2025 zeigt, wohin sich Data Engineering bewegt: Weg vom manuellen Pipeline-Bau, hin zu einer Disziplin, in der Agenten die operative Arbeit erledigen und Engineers sich auf Architektur, Governance und Geschäftslogik konzentrieren. Im März 2026 hat Databricks Genie Code vorgestellt, einen autonomen Agenten, der Pipelines baut, Fehler debuggt und Dashboards ausliefert. Auf realen Data-Science-Aufgaben hat Genie Code die Erfolgsrate führender Coding-Agenten mehr als verdoppelt.
Aber Genie Code ist nur ein Player in einem wachsenden Markt. Matillion hat Maia herausgebracht, ein agentisches Datenteam, das Pipelines autonom baut und wartet. TensorStax hat 5 Millionen Dollar eingesammelt, um autonome Agenten in bestehende dbt-, Airflow- und Spark-Stacks einzubetten. Und Airflow 3, veröffentlicht im April 2025, bringt speziell für KI-Workloads konzipierte Features mit, die Agent-gesteuerte Pipelines als erstklassige Orchestrierungsaufgabe behandeln.
Das ist keine Zukunftsmusik. Diese Tools laufen heute in Produktion. Die Frage für Datenteams lautet nicht mehr, ob KI-Agenten ihre Arbeit verändern, sondern welche Teile der Pipeline sie zuerst abgeben.
Was KI-Agenten in einer Datenpipeline tatsächlich tun
Der Begriff “KI-gestütztes ETL” wird inflationär verwendet. Manche Anbieter meinen damit einen Chatbot, der SQL generiert. Andere meinen ein System, das autonom Schema-Änderungen erkennt, Felder neu zuordnet und sich selbst repariert, wenn eine Quell-API nachts um drei ihr Antwortformat ändert. Der Unterschied ist erheblich.
Echtes agentisches ETL arbeitet auf drei Ebenen: Schema-Intelligenz, Laufzeit-Selbstheilung und Qualitätsüberwachung. Jede Ebene steht für ein anderes Autonomieniveau, und die meisten produktiven Deployments befinden sich heute irgendwo zwischen der ersten und zweiten.
Schema-Erkennung und adaptive Zuordnung
Klassisches ETL bricht, wenn ein Quellsystem einen Spaltennamen ändert, ein Feld hinzufügt oder einen Datentyp verschiebt. Eine Pipeline, die customer_name als String erwartet, scheitert, wenn das Upstream-Team es in client_name umbenennt oder in ein contact-Objekt verschachtelt. Die Reparatur war bisher Handarbeit: Ein Data Engineer wird alarmiert, liest Logs, aktualisiert das Mapping, testet und deployt neu.
KI-Agenten gehen das anders an. Natural Language Processing erkennt, dass customer_name und client_name auf dieselbe Entität verweisen. Machine-Learning-Modelle, trainiert auf historischen Schema-Änderungen, sagen wahrscheinliche Zuordnungen für neue Felder voraus. Informaticas KI-gestütztes Mapping und Airbytes agentische Konnektoren nutzen diesen Ansatz. Teams berichten von 30-40 % weniger Zeitaufwand für Schema-Pflege.
Das ist kein Zauberwerk. Der Agent braucht nach wie vor ein sauber definiertes Zielschema und klare Regeln für mehrdeutige Fälle. Aber er eliminiert die nächtlichen Alarme bei routinemäßigen Feldumbenennungen.
Selbstheilung bei Ausfällen
Schema-Mapping behandelt bekannte Unbekannte. Selbstheilung behandelt den Rest: API-Rate-Limits, Netzwerk-Timeouts, fehlerhafte Datensätze, Upstream-Ausfälle. Ein selbstheilender Agent überwacht die Pipeline-Gesundheit in Echtzeit, identifiziert Fehlermuster und wendet Korrekturen ohne menschliches Eingreifen an.
Wie sieht das in der Praxis aus? Ein Entwickler berichtete auf Medium, dass er eine Produktionspipeline durch ein agentengesteuertes System ersetzt hat, das sechs Wochen ohne Downtime lief. Der Agent übernahm Retry-Logik, Dead-Letter-Queue-Management und leitete Traffic sogar um, als ein Source-Endpunkt hinter eine neue Authentifizierungsschicht wanderte.
IOblends agentisches ETL-Framework geht noch weiter: Agenten wiederholen dort nicht einfach fehlgeschlagene Tasks, sondern analysieren Ursachen und passen die Transformationslogik im laufenden Betrieb an. Wenn eine Quelle plötzlich Datumsformate ändert, erkennt der Agent den Musterwechsel, aktualisiert den Parser und protokolliert die Änderung für Audit-Zwecke.
Die Grenze ist Vertrauen. Selbstheilung funktioniert gut bei deterministischen Fehlern (Retries, Formatänderungen, Verbindungsabbrüche). Bei allem, was Geschäftslogik betrifft, etwa ob ein Null-Wert gelöscht, ersetzt oder markiert werden soll, wollen die meisten Teams weiterhin einen Menschen im Loop.
Die Tools, die ETL autonom machen
Der Markt hat sich 2025-2026 in zwei Lager geteilt: Plattformen, die KI-Features zu bestehenden ETL-Tools hinzugefügt haben, und Startups, die Agent-first-Architekturen von Grund auf neu bauen.
Databricks Genie Code
Genie Code, gestartet im März 2026, ist Databricks’ Vorstoß für vollautonomes Data Engineering. Anders als Copilot-artige Tools, die Code-Schnipsel vorschlagen, führt Genie Code komplexe Mehrstufenaufgaben aus: Es baut Delta-Live-Tables-Pipelines, erstellt und plant Jobs, debuggt fehlerhafte Notebooks und liefert Dashboards aus.
Die Zahlen sind beeindruckend: Auf internen Benchmarks gegen führende Coding-Agenten hat Genie Code die Erfolgsrate bei realen Datenaufgaben mehr als verdoppelt. Es arbeitet innerhalb der Databricks-Notebook-Umgebung und hat vollen Zugriff auf Unity-Catalog-Metadaten. Das bedeutet: Der Agent versteht Tabellenschemas, Datenlineage und Zugriffskontrollen, bevor er eine einzige Zeile Code schreibt.
Für Teams, die bereits auf Databricks arbeiten, ist das aktuell das nützlichste Tool auf dieser Liste. Die Integrationstiefe ist mit einem Drittanbieter-Agenten, der nachträglich aufgesetzt wird, kaum zu erreichen.
Matillion Maia und TensorStax
Matillions Maia verfolgt einen anderen Ansatz: Statt einem Agenten, der alles macht, setzt es ein Team spezialisierter Agenten ein. Einer übernimmt Extraktion, ein anderer Transformation, ein dritter Scheduling. Sie koordinieren sich über geteilten Kontext, ähnlich wie ein menschliches Datenteam, nur ohne Slack-Threads und Context-Switching.
TensorStax, mit 5 Millionen Dollar frisch finanziert, richtet sich an Teams, die ihren bestehenden Stack nicht ersetzen wollen. Ihre Agenten docken direkt an dbt, Airflow, Spark und Databricks an, als “deterministic labor layer.” Für Unternehmen mit jahrelangen Investitionen in Airflow-DAGs und dbt-Modelle ist das ein überzeugendes Angebot. Gerade im DACH-Raum, wo viele Mittelständler auf gewachsene Dateninfrastrukturen setzen, trifft dieser Ansatz einen Nerv.
Airflow 3 und die Orchestrierungsschicht
Apache Airflow bleibt der Standard-Orchestrator für Datenpipelines. Mit 44 % Adoption ist es das am häufigsten mit dbt kombinierte Tool, zum zweiten Jahr in Folge. Airflow 3 (April 2025) ist hier relevant, weil es Features speziell für agentengesteuerte Workloads mitbringt: bessere Async-Task-Unterstützung, verbessertes Ressourcenmanagement und engere Integration mit ML-Pipelines.
Astronomers Open-Source-Paket Cosmos, das dbt und Airflow verbindet, hat 2025 die 200-Millionen-Download-Marke überschritten. Diese Integration ist die Grundlage, auf der die meisten Teams heute agentenorchestrierte Pipelines aufbauen: dbt übernimmt die Transformationslogik, Airflow das Scheduling und die Abhängigkeiten, und Agenten das Monitoring, die Selbstheilung und die Optimierung darüber.
Warum Data Engineers nicht verschwinden werden
Jede Automatisierungswelle im Data Engineering hat dieselbe Vorhersage ausgelöst: Data Engineers werden ersetzt. Erst sollte ELT das klassische ETL ablösen. Dann dbt den handgeschriebenen Transformationscode. Jetzt sollen Agenten die Engineers komplett ersetzen.
Die Vorhersage liegt jedes Mal daneben, und das Muster ist aufschlussreich. KI-Agenten sind hervorragend darin, die mechanischen Teile des Data Engineerings zu automatisieren: Boilerplate-SQL schreiben, Schemas mappen, Jobs planen, Fehler beheben. Sie versagen bei allem, was Geschäftskontext erfordert: entscheiden, welche Metriken wichtig sind, Datenmodelle entwerfen, die die tatsächlichen Geschäftsprozesse abbilden, Data Contracts mit Upstream-Teams aushandeln und Abwägungen bei der Datenqualität treffen.
Vom Pipeline-Bauer zum Plattform-Architekten
Was sich tatsächlich ändert, ist das Verhältnis. Ein Bericht von The New Stack bringt es auf den Punkt: Data Engineers werden von Bauarbeitern zu Strategen. Die mechanische Arbeit (Extraktionsskripte schreiben, Job-Fehler debuggen, Schedules verwalten) wird automatisiert. Die strategische Arbeit (Datenprodukte gestalten, Zugriffsrechte steuern, Plattformen bauen, auf denen Agenten operieren können) wächst.
Das spiegelt wider, was in DevOps passiert ist, als Infrastructure-as-Code-Tools die Serverprovisionierung automatisierten. Sysadmins sind nicht verschwunden. Sie wurden Platform Engineers. Data Engineers sind auf dem gleichen Weg. Der Titel bleibt, aber die Stellenbeschreibung verschiebt sich hin zu Architektur, Governance und der Geschäftslogik, die Agenten nicht allein aus den Daten ableiten können.
Unternehmen, die KI-ETL-Tools einsetzen, berichten von 355 % ROI über drei Jahre durch reduzierte Entwicklungskosten und schnellere Deployments. Aber dieser ROI setzt voraus, dass erfahrene Engineers die Agenten steuern, nicht dass die Agenten unbeaufsichtigt laufen.
Wo das Ganze an seine Grenzen stößt
Kein KI-Agent kann zuverlässig eine Geschäftsanforderung nehmen und daraus eine produktionsreife Pipeline bauen. Die Lücke zwischen “eine funktionierende Query generieren” und “eine Pipeline bauen, die Edge Cases behandelt, SLAs einhält, die Compliance-Prüfung besteht und sich in Downstream-Systeme integriert” ist enorm.
Konkrete Schwachstellen, auf die man achten sollte:
Domänenwissen. Ein Agent, der das Geschäft nicht versteht, mappt revenue auf die falsche Tabelle, joint auf den falschen Key oder aggregiert auf der falschen Granularität. Schema-Intelligenz hilft bei Feldnamen, nicht bei Geschäftssemantik.
Data Contracts. Wenn ein Upstream-Team seine API ändert, ist die Lösung oft organisatorischer Natur (ein Gespräch, ein Contract-Update), nicht technisch. Agenten können an diesem Meeting nicht teilnehmen.
Compliance. In regulierten Branchen braucht jede Transformation einen Audit Trail und jede Datenbewegung eine Autorisierung. Das gilt im DACH-Raum durch DSGVO und den EU AI Act besonders. Selbstheilende Agenten, die Daten stillschweigend über andere Pfade umleiten, können Compliance-Albträume verursachen. Genau hier werden Observability und Kontrollschichten unverzichtbar.
Testing. Agenten können Pipeline-Code generieren. Sinnvolle Tests zu generieren fällt ihnen schwer, weil gute Tests Geschäftsannahmen kodieren (“Umsatz darf nie negativ sein,” “jede Bestellung braucht einen Kunden”). Diese Annahmen existieren in den Köpfen der Mitarbeitenden, nicht in den Daten.
Die Teams, die am meisten von agentischem Data Engineering profitieren, behandeln Agenten wie Junior Engineers: in der Lage, klar spezifizierte Aufgaben schnell auszuführen, aber mit Supervision, Code Review und klaren Leitplanken.
Häufig gestellte Fragen
Können KI-Agenten Data Engineers 2026 vollständig ersetzen?
Nein. KI-Agenten automatisieren mechanische Aufgaben wie Schema-Mapping, Job-Scheduling und Fehlerbehebung, können aber keinen Geschäftskontext, Datenmodellierungsentscheidungen oder teamübergreifende Abstimmungen übernehmen. Data Engineers entwickeln sich von Pipeline-Bauern zu Plattform-Architekten, die Agenten steuern und überwachen.
Was ist eine selbstheilende ETL-Pipeline?
Eine selbstheilende ETL-Pipeline nutzt KI-Agenten, um Fehler (API-Timeouts, Schema-Änderungen, fehlerhafte Datensätze) zu erkennen, Ursachen zu analysieren und automatisch Korrekturen anzuwenden, ohne dass ein Mensch eingreifen muss. Das funktioniert gut bei deterministischen Fehlern, erfordert aber weiterhin menschliche Aufsicht bei Geschäftslogik-Entscheidungen.
Welche Tools unterstützen KI-agentisches Data Engineering?
Führende Tools 2026 sind Databricks Genie Code (autonomer Pipeline-Bau), Matillion Maia (Multi-Agent-Datenteams), TensorStax (Agenten für bestehende dbt/Airflow-Stacks), Informatica KI-Mapping und Airbyte agentische Konnektoren. Apache Airflow 3 bietet native Unterstützung für KI-Workloads.
Wie gehen KI-Agenten mit Schema-Änderungen in Datenpipelines um?
KI-Agenten nutzen Natural Language Processing, um zu erkennen, dass umbenannte Felder (wie customer_name und client_name) auf dieselbe Entität verweisen, und Machine Learning, um Zuordnungen für neue Felder auf Basis historischer Muster vorherzusagen. Das reduziert den Zeitaufwand für Schema-Pflege um 30-40 % im Vergleich zu manuellen Ansätzen.
Welchen ROI können Teams von KI-gestützten ETL-Tools erwarten?
Unternehmen, die kommerzielle KI-ETL-Lösungen einsetzen, berichten laut Integrate.io von 355 % ROI über drei Jahre durch reduzierte Entwicklungskosten und schnellere Deployment-Zyklen. Voraussetzung ist allerdings, dass erfahrene Engineers die Agenten steuern und nicht unbeaufsichtigt laufen lassen.