Was vom Data Engineer in der KI-Ära übrigbleibt

KI verändert so gut wie alle Jobrollen innerhalb der IT. Auch der Data Engineer bleibt nicht verschont.DC Studio | shutterstock.com



In meinen fast 15 Jahren als Data Engineer und in meiner derzeitigen Rolle als Developer Advocate – einer Schnittstelle zwischen Data Engineering, Produkt und Technologie –, ist mir eines bewusst geworden: Kaum ein Beruf in der IT ist in den vergangenen Jahren so wichtig geworden und zugleich so unsichtbar geblieben wie der des Data Engineer.



Denn hinter jedem Dashboard, jeder Umsatzprognose und jedem KI-Feature steht eine unscheinbare Schicht Arbeit: Pipelines, die Daten aus Dutzenden Quellsystemen einsammeln, bereinigen, prüfen, verarbeiten und verlässlich dorthin liefern, wo Entscheidungen fallen. Diese werden von Data Engineers gebaut und betrieben. Sie sind es, die dafür sorgen, dass die Zahlen, auf die sich ein Unternehmen verlässt, auch korrekt, vollständig und aktuell sind.



Das zeigt sich gerade im Hinblick darauf, dass Unternehmen in den letzten Jahren zunehmend Wert darauflegen, datengetrieben zu arbeiten. Die teuerste Analytics-Software und das beste KI-Modell sind in diesem Zusammenhang wertlos, wenn die zugrundeliegenden Daten nicht stimmen. So wurde aus der stillen Hintergrundarbeit von Data Engineers spätestens mit dem KI-Boom eine strategische Funktion: Wenn ein KI-Projekt nicht über den Prototyp hinauskommt, liegt es selten am Modell und fast immer an der darunterliegenden Datenschicht. Also genau an der Stelle, an der Data Engineers arbeiten.



Der Fall Air Canada



Ein Beispiel dafür, warum diese Datenschicht insbesondere für KI-Projekte so entscheidend ist, lieferte im Jahr 2024 Air Canada. Ein Passagier fragte den Chatbot der Fluggesellschaft nach Vergünstigungen im Trauerfall. Der Bot versicherte ihm, er könne zum vollen Preis buchen und nachträglich innerhalb von 90 Tagen einen entsprechenden Rabatt beantragen. Das war schlicht falsch, denn „Trauertarife“ gelten bei Air Canada nicht für bereits angetretene Reisen.



Das erklärt die Fluggesellschaft auf der eigenen Website auch transparent. Der Passagier verklagte Air Canada daraufhin – und bekam recht. Die Fluggesellschaft wurde zu Schadensersatz in Höhe von 812 kanadischen Dollar verurteilt. Das Gericht wies dabei die (bemerkenswerte) Argumentation zurück, der Chatbot sei eine eigenständige juristische Einheit, die für ihre Aussagen selbst verantwortlich ist.



Der eigentliche Fehler lag auch in diesem Fall nicht beim Modell, sondern in der Datenschicht darunter: Die korrekte Antwort existierte längst in den Systemen. Der Agent griff jedoch auf veraltete und widersprüchliche Quellen zu – ohne, dass eine Überprüfung sichergestellt hätte, dass der Output mit den maßgeblichen Richtlinien übereinstimmt.



Genau solche Prüfungen, Validierungen und Bereinigungen sind ein Teil dessen, was Data Engineers leisten – schon lange bevor die Daten überhaupt bei einem KI-Modell oder -Agenten ankommen.



Der neue Data Engineer



Allerdings wird die Rolle des Data Engineers gerade neu vermessen. Denn inzwischen schreiben KI-Agenten den Code. Und das sieht wie folgt aus: Ein moderner Coding-Agent ist kein einzelnes Tool, sondern ein Zusammenspiel mehrerer Bausteine. Das Herzstück ist das KI-Modell: Dieses plant, schreibt Code und entscheidet, was als Nächstes passiert. Damit aus diesem Gehirn ein handelnder Agent wird, braucht es ein „Harness“. Dieses bildet die Laufzeitumgebung um das Modell herum, das es in einer Schleife aus Lesen, Handeln und Prüfen arbeiten lässt. Ohne dieses „Harness“ ist das Modell lediglich ein Chatfenster.



Innerhalb besagter Schleife greift der Agent auf Tools zurück – also konkrete Fähigkeiten, mit denen aus Text Handlung wird: Dateien lesen und schreiben, Shell-Befehle ausführen, Tests laufen lassen. Über das Model Context Protocol (MCP) lässt sich der Agent an externe Systeme anbinden, etwa Datenbanken, Warehouses oder Ticketsysteme.



Das quelloffene MCP bildet quasi die Steckdosenleiste für Kontext und kapselt wiederkehrende Aufgaben in Skills. Dabei handelt es sich sozusagen um wiederverwendbare Anleitungen, die der Agent bei Bedarf heranzieht, statt jedes Mal bei null anzufangen. Als deterministische Auslöser sorgen Hooks an festen Punkten im Ablauf für Leitplanken, die nicht vom Wohlwollen des Modells abhängen – zum Beispiel Linter und automatisierte Tests nach jeder Änderung.



Zusammengenommen ergibt das einen Agenten, der nicht mehr nur Vorschläge macht, sondern eigenständig im Repository arbeitet. Das ist mächtig. Und genau hier stellt sich auch die Frage: Was bedeutet das für die Rolle des Data Engineer?



Das Kontext-Problem



Neulich hat ein KI-Agent in wenigen Minuten eine Daten-Pipeline für mich gebaut. Sie lief beim ersten Versuch sauber durch, ohne jegliche Fehlermeldung. Beim zweiten Lauf für denselben Tag standen die Zahlen dann jedoch doppelt in der Zieltabelle.



Der Agent hatte exakt das getan, worum ich ihn gebeten hatte. Das Problem war das, worum ich ihn nicht gebeten hatte: Schließlich lautetet meine Anweisung lediglich “implementiere eine tägliche Aggregation” – und nicht “sorge dafür, dass ein erneuter Lauf desselben Tages keine Duplikate erzeugt”. Solche Lücken füllt ein KI-Agent mit den für ihn naheliegendsten Informationen. Die interessante Frage ist dabei, warum diese Pipeline falsch war – und was das über die Zukunft der Data-Engineer-Rolle verrät.



Das verbreitete Narrativ: Wenn der Agent den Code schreibt, wird Data Engineering überflüssig. Nach fast 15 Jahren in diesem Feld halte ich das für falsch. Die Arbeit verschwindet nicht – sie verschiebt sich vielmehr, und zwar grundlegend.



Shridhar Iyer, ehemals Director of Data Engineering bei Meta, hat es kürzlich auf den Punkt gebracht: Das Handwerk stecke nicht mehr im Code, sondern in der Qualität der Frage, der Strenge der Evaluation und der Integrität des Kontexts, den man dem System gibt. Das klingt zunächst abstrakt, wird jedoch sehr konkret, sobald man ernsthaft mit KI-Agenten arbeitet. Dann kommt es vor allem auf drei Dinge an: die Spezifikation, den Kontext und die Verifizierung.



Die Spezifikation als neues Handwerk



Die Spezifikation kann den Unterschied machen zwischen einem Prototyp und einem belastbaren Ergebnis. Eine Anweisung wie “Aggregiere den Umsatz pro Produkt” führt zu einem Ergebnis, jedoch eher auf Prototypen-Niveau.



Eine Spezifikation, die die Quelltabellen benennt, den Primärschlüssel beschreibt, bei einem erneuten Lauf ausdrücklich ein Zusammenführen der Ergebnisse verlangt, vorschreibt, was mit fehlenden Werten geschieht, Akzeptanzkriterien formuliert, und Leitplanken definiert, erzeugt ein Ergebnis, das auch verlässlich den Zweck erfüllt.



Daraus habe ich für mich vier konkrete Techniken entwickelt, die sich in meinem Arbeitsalltag bewährt haben:




Erst die Spezifikation, dann der Code. Viele Werkzeuge bieten einen Plan-Modus an: Der Agent analysiert, fragt nach und schlägt einen Plan vor, bevor er eine Zeile schreibt. Das fühlt sich langsamer an, ist langfristig jedoch schneller, weil die teuren Missverständnisse nicht erst später im Review ausgeräumt werden müssen.



Die Spezifikation wie ein Lastenheft strukturieren. Kein Fließtext-Prompt, sondern klare Abschnitte: Was soll entstehen, welche Konventionen gelten, was darf der Agent niemals anfassen. Hilfreich sind explizite Leitplanken in drei Stufen: „immer erlaubt“, „vorher fragen“ und „niemals“. Eine gute Spezifikation liest sich wie die eingefrorene Anleitung eines erfahrenen Kollegen.



Den Agenten ein Protokoll führen lassen. Ich lasse mir parallel zur Arbeit eine Datei implementation-notes.md schreiben. In dieser hält der Agent fest, wo er die Spezifikation interpretiert hat, wo er bewusst abgewichen ist, welche Alternativen er verworfen hat und welche Fragen offen sind. So prüfe ich nicht nur das Ergebnis, sondern die Begründung. Denn dort stecken die Annahmen, die später teuer werden können.



Spezifikationen klein halten. Je mehr Anforderungen man in einen einzigen Auftrag presst, desto unzuverlässiger wird das Ergebnis. Modulare, fokussierte Spezifikationen schlagen den „einen“, großen Prompt. Es gibt inzwischen auch quelloffene Werkzeuge, die diesen Ablauf formalisieren, etwa das SpecKit von GitHub.




Ein Agent weiß nur, was im Kontext steht, den man ihm gibt. Konventionen, Schema, Namensregeln, die Grenzen dessen, was er anfassen darf. Steht es nirgends, erfindet er es eben. In offenen Projekten hat sich dafür eine schlichte Konvention durchgesetzt: Neben dem Code gibt es eine zentrale Datei, oft AGENTS.md genannt, die diese Regeln als verbindliche Wahrheit enthält.



Der Reflex, möglichst viel hineinzuschreiben, ist ein Fehler. Kontextfenster sind endlich. Wird die Datei zu lang, schneidet das Modell oft lautlos ab. Ich habe erlebt, dass ein Agent eine klare Namenskonvention konsequent ignoriert hat, einfach weil sie hinter zu viel Beiwerk stand und nie in seinem „Sichtfeld“ ankam. Guter Kontext ist vor allem kuratiert, nicht vollständig. Er funktioniert wie eine gute Dokumentation: knapp, präzise und auf das Wesentliche reduziert.



Und hier wird aus einer technischen Frage eine fachliche: Der wertvollste Kontext ist nicht die Ordnerstruktur, sondern die Bedeutung der Daten. Was heißt “aktiver Nutzer” genau? Wie hängen die Entitäten zusammen? Das ist der Kern der neuen Data-Engineering-Arbeit: Verantwortung für Semantik übernehmen, statt für Skripte. Oder anders ausgedrückt: Datenmodellierung wird zur Bedeutungsarbeit. Genau dieses sauber formulierte und gepflegte Wissen macht KI-Projekte erst erfolgreich.



Evaluierung sticht Bauchgefühl



Agenten weisen drei Eigenschaften auf, die zusammengenommen tückisch sind:




Sie sind schneller, als ein Mensch ihren Output prüfen kann.



Sie sind nicht-deterministisch, derselbe Auftrag liefert beim nächsten Mal ein anderes Ergebnis.



Und genau diese Kombination verführt dazu, die Prüfung abzukürzen.




Ein KI-Agent ist darauf konzipiert, eine Antwort zu finden und findet entsprechend auch eine, wenn er keine finden sollte. Fällt im Hintergrund ein Dienst aus, sucht der Agent sich einen anderen Weg und liefert ein Ergebnis, das autoritativ klingt, aber eventuell falsch ist. Agenten nehmen Kontext für bare Münze, verwechseln ähnliche Begriffe, verdrahten Definitionen quer und antworten überzeugend falsch. Falsche Daten sind gefährlich. Falsche Daten, die mit Überzeugung korrekt dargestellt werden, noch viel gefährlicher. Deshalb ist es auch eine neue Kernaufgabe für den Data Engineer, Leitplanken zu bauen.



Die Antwort auf diese Herausforderung ist Evaluierung – oder kurz Eval. Hierbei geht es vor allem um die Frage, ob sich das System wie vorgesehen verhält. In der Praxis kommen dazu verhaltensbasierte und Regressionstests zum Einsatz. In diesem Rahmen wird etwa geprüft, ob ein Agent ein altes SQL-Skript in ein sauberes, optimiertes dbt-Modell überführt, ohne das Datenergebnis zu verändern. Oder, ob der Agent eine Pipeline-Anomalie korrekt auf die auslösende Schema-Änderung zurückführt.



Daraus folgt ein besseres Maß für Erfolg: Es geht nicht mehr darum, wie viele Code-Zeilen die KI generiert oder wie viel Zeit sie eingespart hat. Stattdessen geht es um Fragen wie: „Wie viele vollständige Arbeitsabläufe erledigt der Agent eigenständig, statt nur einzelne Schritte zu beschleunigen?“



Der Data Engineer ist nicht tot



Nimmt man diese Punkte zusammen, ergibt sich ein klares Bild davon, wohin sich die Data-Engineering-Arbeit verlagert: Wir schreiben keinen Code mehr, sondern erstellen Spezifikationen, pflegen Kontext, entwerfen Schleifen, evaluieren und – am wichtigsten – übernehmen diesbezüglich mehr Verantwortung.



Das sind allerdings keine neuen Fähigkeiten, sondern die, die einen erfahrenen Data Engineer schon immer ausgezeichnet haben. Er muss präzise denken können, die Domäne verstehen, wissen, wie “korrekt” aussieht – und ein Gespür für die Fälle haben, bei denen ein Fail wahrscheinlich ist.



Dazu kommt jedoch eine in diesem Bereich lange unterschätzte Fähigkeit: Das Verständnis fürs Business. Wenn das letzte Jahrzehnt jene belohnt hat, die exzellent mit Infrastruktur und Tools umgehen konnten, wird das nächste diejenigen belohnen, die die besten Fragen stellen. Man muss verstehen, wie das Geld durch ein Unternehmen fließt und was für die Kunden zählt. Nur so lässt sich auch zuverlässig erkennen, welche Antwort eines KI-Agenten wirklich brauchbar ist.



Sobald Agenten autonom in Schleifen arbeiten, hängt ihre Qualität an den Daten und an der Infrastruktur, die diese Daten verlässlich liefert. Observability, Lineage und saubere Abhängigkeiten – hier fühlen sich Data Engineers zuhause. Die Rolle des Data Engineer stirbt also nicht. Sie wird bedeutender für das Fundament – und übernimmt zugleich mehr Verantwortung. Wer heute als Data Engineer lediglich Tickets in Code übersetzt, sollte sich deshalb Gedanken machen. (fm)



Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!