Von Andrew Tan
Warum ich dies schreibe
Da KI momentan in aller Munde ist, fragen sich einige CTOs: "Sollte KI die Hälfte unseres Data-Engineering-Teams ersetzen?"
Das ist der aktuelle Stand der KI im Data Engineering. Jeder veröffentlicht atemlose Inhalte. Niemand wird konkret. Hier ist meine Meinung zu dem Thema:
Wobei KI wirklich hilft
Die SQL-Generierung ist der klarste Gewinn. Tools im Copilot-Stil verkürzen die Zeit, um einen ersten Entwurf einer analytischen Abfrage zu schreiben, um 50-70 % für Ingenieure mit soliden SQL-Grundlagen. Man muss sie immer noch überprüfen. Man muss immer noch wissen, wie die Antwort aussehen sollte. Aber das Problem der leeren Seite ist verschwunden.
Die Dokumentation von Schemata ist dramatisch schneller. Von "wir haben 400 Tabellen" zu "wir haben 400 Tabellen dokumentiert" zu gelangen, dauerte früher Monate Analystenzeit. Mit guten LLM-Tools können Teams dies in Wochen schaffen. Die Dokumentation ist nicht perfekt, aber sie ist nützlich genug, was sie oft vorher nicht war.
Ad-hoc-Analysen haben sich für Nicht-Ingenieure bedeutend verändert. Business-Analysten, die früher Tickets für "können Sie mir eine Abfrage schreiben, die…" einreichten, können jetzt selbst funktionierende Antworten auf einfache Fragen erhalten. Das ist echte Produktivität. Es ist auch eine bedeutende Reduzierung der unterbrechungsgetriebenen Arbeit für Data-Engineering-Teams.
Entwürfe für Code-Reviews. Kein Ersatz für eine Überprüfung, aber das Auffangen offensichtlicher Dinge — nicht indizierte Joins, fehlende Null-Prüfungen, Typinkongruenzen — bevor ein Mensch es sich ansieht, spart insgesamt Zeit.
Diese Dinge sind real und sie sind wichtig. Ich möchte sie nicht abtun.
Was KI nicht zuverlässig bewältigen kann
Hier öffnet sich die Lücke zwischen den Behauptungen der Anbieter und der Realität in der Produktion.
Schema-Evolution im großen Maßstab
Der schwierigste Teil der Wartung von Produktionspipelines ist nicht das Schreiben des Codes — es ist zu wissen, was zu tun ist, wenn ein Upstream-System einen Feldtyp ändert, eine Spalte veraltet oder Daten in einem anderen Format sendet. Dies erfordert das Verständnis der Geschäftslogik hinter den Daten, der Downstream-Verbraucher, des historischen Kontexts, warum das Feld existiert. Ein LLM, das nicht im Raum war, als diese Entscheidungen getroffen wurden, kann nicht zuverlässig über die richtige Reaktion nachdenken. Es wird Ihnen etwas geben, das richtig aussieht. Oft ist es das nicht.
Zustandsbehaftete Stream-Verarbeitung
Ein Team kann drei Monate damit verbringen, ein LLM dazu zu bringen, eine fensterbasierte Aggregation mit verspäteter Ankunftsverarbeitung für ihre Echtzeit-Betrugserkennungspipeline korrekt zu implementieren. Das LLM könnte den Code schreiben. Der Code läuft auch. Er liefert falsche Antworten in Randfällen, die nur in der Produktion auftreten, unter bestimmten Ordnungsbedingungen, an Tagen mit ungewöhnlichen Ereignisvolumen. Diese Bugs sind die schwierige Art — sie werfen keine Fehler, sie korrumpieren einfach stillschweigend Ihre Metriken. Das Modell hat keine Möglichkeit, seine eigene Ausgabe gegen die tatsächlichen Randfälle zu testen, denen es begegnen wird.
Wiederherstellung nach Produktionsausfällen
Wenn ein Kafka-Consumer 48 Stunden im Rückstand ist und Sie entscheiden müssen, ob Sie wiederholen, verwerfen oder deduplizieren — das ist kein Problem der Codegenerierung. Das ist eine Ermessensentscheidung, die das Wissen über Ihr Geschäft, Ihre SLAs und die Kosten jeder Option erfordert. Ich habe noch kein LLM gesehen, das diese Entscheidung korrekt trifft, ohne signifikante menschliche Unterstützung.
Ein leitender Ingenieur bei einem Cyber-Sicherheitsunternehmen sagte mir: "Wir haben etwa 70 % Automatisierung bei unseren Standard-ETL-Mustern erreicht. Die letzten 30 % sind die Dinge, die tatsächlich in der Produktion kaputtgehen." Er beschwerte sich nicht. Er verstand warum. Aber die 30 % sind das, was Data Engineers beschäftigt.
Das "80% Automatisierung"-Problem
Gartner veröffentlichte letztes Jahr eine Prognose, dass 80 % der Data-Engineering-Arbeit bis 2027 betroffen sein würden. Ich verstehe, warum sie das geschrieben haben.
Hier ist das Ding mit den 80 %: Die 80 %, von denen sie sprechen, sind Gerüst. Boilerplate. Erste Entwürfe. Der Teil, der wirklich zu 80 % automatisierbar ist, ist der Teil, der bereits relativ schnell war.
Was bleibt, sind die 20 %, die 80 % der Zeit in Anspruch nehmen — das Debuggen, warum die Daten falsch aussehen, das Aushandeln von Schemaänderungen mit Upstream-Teams, das Nachdenken über die Zuverlässigkeit der Pipeline unter Bedingungen, die niemand vorhergesehen hat. Diese 20 % sind auch die 20 %, bei denen eine falsche Antwort teuer ist.
Ich sage das nicht, um pessimistisch zu sein. Die 80 % sind wichtig. Ingenieurteams von Gerüsten zu befreien, ist wirklich wertvoll. Aber die Teams, die für eine Welt planen, in der diese Automatisierung weniger Ingenieure bedeutet, machen eine spezifische Wette, dass auch die teuren Probleme einfacher werden. Das könnten sie. Ich sehe noch keine Beweise dafür.
Was ich Teams sage, die über Personalabbau nachdenken
Machen Sie es noch nicht. Nicht, weil die Technologie nicht real ist, sondern weil Sie auf die falsche Variable setzen.
Die Teams, die am meisten von KI-Tools profitieren, sind nicht die, die Personal abbauen — es sind die, die die gleiche Anzahl an Mitarbeitern auf schwierigere Probleme ansetzen. Die Ingenieure, die früher ihre Tage mit routinemäßiger ETL-Arbeit verbracht haben, arbeiten jetzt an Datenqualitäts-Frameworks, Schema-Governance, Echtzeit-Pipeline-Zuverlässigkeit. Der Output pro Ingenieur ist höher. Die Qualität des Outputs ist höher. Das Team ist schwerer zu ersetzen, nicht leichter.
Das ist die Geschichte. KI ist ein Produktivitätsmultiplikator für Data Engineers. Es ist nicht DER Data Engineer.
Eine einfache Übersicht
Ich weiß, ich habe gesagt, ich würde das Vergleichstabellenformat vermeiden. Aber diese ist wirklich die klarste Art, es zu zeigen:
| Aufgabe | KI hilft | KI hat Schwierigkeiten |
|---|---|---|
| SQL-Generierung | Erste Entwürfe, 50-70 % schneller | Komplexe Logik mit subtilen Geschäftsregeln |
| Schema-Dokumentation | Erster Durchgang, Wochen statt Monate | Genaue Semantik ohne Geschäftskontext |
| Ad-hoc-Analyse | Einfache Fragen für Nicht-Ingenieure | Fragen, die kontextübergreifende Systeme erfordern |
| Pipeline-Code | Boilerplate, Standardmuster | Zustandsbehaftete Logik, Randfallbehandlung |
| Schema-Evolution | — | Fast vollständig menschliches Urteil |
| Fehlerbehebung | — | Erfordert Geschäfts- + Betriebserkenntnisse |
| Produktions-Debugging | — | LLMs kennen Ihre spezifische Geschichte nicht |
Die linke Spalte ist real. Die rechte Spalte ist der Grund, warum Data-Engineering-Teams immer noch existieren.
Wo layline.io passt
Ich werde direkt sein: Die oben beschriebenen KI-Produktivitätsgewinne sind leichter zu erfassen, wenn Ihre Pipelines eine explizite Struktur haben, die LLMs verstehen und erweitern können.
Bei layline.io bauen wir Pipelines mit deklarativer Konfiguration — die Logik befindet sich in strukturierten Operatoren, nicht eingebettet in benutzerdefiniertem Code (außer gelegentlich Javascript oder Python hier und da und nur, wo es wirklich notwendig ist). Das passt gut zu KI-unterstützter Entwicklung. Wenn ein Ingenieur ein LLM bittet, einen Verarbeitungsschritt hinzuzufügen, kann das LLM darüber klar nachdenken. Wenn etwas kaputtgeht, liegt der Fehler an einem bekannten Ort und nicht in maßgeschneidertem Code vergraben.
Das ist nicht der Grund, warum wir es so gebaut haben. Wir haben es so gebaut, weil deklarative Pipelines für Menschen leichter zu debuggen und zu warten sind. Die KI-Affinität stellte sich als Nebeneffekt heraus.
Aber es bedeutet, dass Teams, die auf einer strukturierten Grundlage aufbauen, mehr aus KI-Tools herausholen als Teams, die in benutzerdefiniertem Code arbeiten. Etwas, das es wert ist, in Betracht gezogen zu werden, wenn Sie architektonische Entscheidungen treffen, die in zwei Jahren wichtig sein werden.
Die Frage, die es wert ist, Ihrem Team gestellt zu werden
Versuchen Sie dies: Wählen Sie Ihre letzten fünf Datenvorfälle aus. Fragen Sie bei jedem, ob eine KI ihn hätte verhindern oder schneller diagnostizieren können.
Für die meisten Teams lautet die Antwort "vielleicht 1 von 5." Die anderen vier sind Probleme, über die ein LLM nicht zuverlässig nachdenken kann — falsche Geschäftslogik, die technisch korrekter Code ist, eine Schemaänderung von einem Upstream-Team, die niemand angekündigt hat, ein Randfall in der Stream-Verarbeitung, der nur bei bestimmten Ereignisvolumen auftritt.
Wenn Sie KI-Tools evaluieren, ist das Ihr Ausgangspunkt. Nicht "wird KI das Data Engineering verändern" — natürlich wird sie das. Sondern "wird KI die Probleme eliminieren, die uns tatsächlich schaden?" Diese Antwort lautet nein, noch nicht, und wahrscheinlich nicht, ohne dass sich etwas ändert, das sich noch nicht geändert hat.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab verarbeitet.
