Data Engineer
Sie bauen die Daten- und KI-Infrastruktur, auf der der Rest des Unternehmens läuft. Pipelines, Warehouses, Vektorspeicher, Model-Serving-Infrastruktur, Observability: das Fundament, das Agenten arbeiten und Analysten Erkenntnisse produzieren lässt. Der Agent schreibt einen Großteil des Codes, Sie entwerfen die Architektur und verantworten das Fundament.
Die Arbeit
Sie verantworten die Daten- und KI-Infrastruktur des Unternehmens. ETL-Pipelines, Data Warehouses, Streaming-Systeme, Vektorspeicher, Model-Serving-Infrastruktur, Lieferung von Agent-Kontext, Daten-Observability. Der Agent schreibt einen Großteil des Codes, Sie entwerfen die Architektur, validieren, dass die Infrastruktur unter Last hält, und verantworten das Fundament, von dem alles andere abhängt.
Das ist Engineering-Arbeit, die sich von Anwendungs-Engineering unterscheidet: das Material ist anders (Datenflüsse, nicht Nutzerinteraktionen), die Fehlermodi sind anders (stille Datenkorruption, nicht sichtbare Bugs), und die Konsumenten sind anders (Analysten, Agenten, interne Nutzer statt direkt externe Kunden).
Im Alltag tun Sie folgendes:
- Datenarchitektur entwerfen. Wo Daten leben, wie sie fließen, welche Modelle sie strukturieren, wie sie im großen Maßstab zugänglich sind. Architekturentscheidungen, die sich über Jahre verstärken.
- Pipelines und Infrastruktur spezifizieren. Der Agent setzt um, Sie entwerfen, was umgesetzt wird, und validieren, dass es zusammenhält.
- Die Agent-Kontextschicht bauen. Agenten in der Produktionsarbeit brauchen verlässlichen, aktuellen, gut strukturierten Kontext. Das Datensubstrat zu entwerfen, das dies unterstützt, ist ein erheblicher Teil der Rolle auf KI-nativem Maßstab.
- Datenqualität und Observability verantworten. Schlechte Daten korrumpieren jeden nachgelagerten Konsumenten still. Observability zu entwerfen, die Probleme abfängt, bevor sie sich ausbreiten, ist Kernarbeit.
- Die KI-Infrastruktur betreiben. Vektorspeicher, Embedding-Pipelines, Model-Serving, Evaluations-Infrastruktur: das sind erstklassige Produktivsysteme mit spezifischen Zuverlässigkeits- und Kostencharakteristika.
- An risikoabgestuften Gates validieren. Routinemäßige Pipeline-Änderungen und Standard-ETL laufen über reine Agentenprüfung. Schemaänderungen, Datenlöschungen, kostenrelevante Infrastrukturentscheidungen, datenschutzrelevante Änderungen und KI-Infrastrukturmodifikationen erfordern Ihre direkte Freigabe.
- Mit Data Analyst partnern. Der DA definiert die Fragen und interpretiert Ergebnisse, Sie sorgen dafür, dass das Datenfundament verlässlich antwortet. Definitionen, Instrumentierung, Attribution: das wird gemeinsam verantwortet.
- Mit Anwendungs-Engineers partnern. Ihre Features erzeugen Daten, diese Daten fließen durch Ihre Infrastruktur, Ihre Infrastruktur speist in ihre Features zurück. Die Naht zählt.
Wie Erfolg aussieht
Konkrete Ergebnisse auf dieser Ebene:
- Pipeline-Zuverlässigkeit. Datenpipelines laufen zuverlässig, Latenz ist begrenzt, Ausfälle werden gefangen und wiederhergestellt. Konsumenten werden nicht von fehlenden oder korrupten Daten überrascht.
- Datenqualität. Probleme mit Datenqualität, Instrumentierung oder Labeling werden an der Quelle gefangen, nicht beim nachgelagerten Konsumenten.
- Kostendisziplin. Compute-Kosten, Storage-Kosten und KI-Infrastrukturkosten sind sichtbar, aktuell und verbessern sich über die Zeit. Sie können Infrastrukturausgaben pro Ergebnis verteidigen.
- Gesundheit der Agent-Infrastruktur. Agenten haben verlässlichen Zugang zu frischem, gut strukturiertem Kontext. Vektorspeicher, Embedding-Pipelines und Model-Serving-Infrastruktur laufen mit vorhersagbarer Latenz und Kosten.
- Architekturkohärenz. Datenarchitekturentscheidungen halten über Jahre. Schemamigrationen sind handhabbar. Die Infrastruktur altert gut, statt unter ihrer eigenen Komplexität zu kollabieren.
Was nicht als Erfolg zählt: gebaute Pipelines, gelieferte Dashboards, eingesetzte Technologien isoliert von Ergebnissen.
Was diese Arbeit interessant macht
Der interessante Teil sind nicht die Pipelines selbst. Es ist, am Fundament zu sitzen, von dem der Rest des Unternehmens zunehmend abhängt.
Ihre Arbeit ist tatsächlich tragend. Analysten hängen von Ihnen ab. Agenten hängen von Ihnen ab. Anwendungs-Engineers hängen von Ihnen ab. Produkt hängt von Ihnen ab. Wenn Dateninfrastruktur gut entworfen ist, bewegt sich das ganze Unternehmen schneller; wenn nicht, kämpft alles andere darum zu kompensieren.
Sie entwerfen auf mehreren Zeitskalen. Manche Entscheidungen (Schema, Benennung, Partitionierung) verstärken sich über Jahre; manche (spezifisches Pipeline-Tuning) brauchen quartalsweise Anpassung. Data Engineers, die beide Zeitskalen halten können, produzieren starke Infrastruktur.
KI-native Operationen brauchen neues Datensubstrat. Vektorspeicher, Embedding-Pipelines, Model-Serving-Infrastruktur, Agent-Kontextlieferung: das sind tatsächlich neue Systeme, die in Echtzeit entworfen werden. Sie sind Teil davon, die Muster herauszufinden, die die Branche nutzen wird.
Die diagnostische Arbeit ist befriedigend. Wenn Datenqualitätsprobleme nachgelagert auftauchen, betrifft die Untersuchung oft den Workflow, die Spezifikation, die Instrumentierung und manchmal die Infrastruktur selbst. Die Detektivarbeit ist reich.
Cost Engineering ist interessant. Dateninfrastrukturkosten haben sehr andere Charakteristika als Anwendungs-Infrastrukturkosten. Storage gegen Compute, Batch gegen Streaming, frisch gegen veraltet, Vektordimensionalität, Wahl des Embedding-Modells: die Optimierungsfläche ist neu und bedeutsam.
Funktionsübergreifende Partnerschaft wird tief. Mit absorbierter Routine-ETL-Arbeit haben Sie Zeit für substanzielles Engagement mit Data Analysts, Anwendungs-Engineers, Produkt, Workflow-Architekt. Die Rolle lebt an produktiven Schnittstellen.
Ihre Wirkung verstärkt sich. Ein gut entworfenes Datensubstrat erspart dem Unternehmen Jahre Arbeit. Ein schlecht entworfenes erzeugt technische Schuld, die Entscheidungen jahrelang einschränkt.
Die Karrieremobilität ist real. Starke Data Engineers auf T3 werden stark rekrutiert. Die übertragbaren Fähigkeiten (Architektur, Systemdesign, Cost Engineering, KI-Infrastruktur) sind über Unternehmen und Branchen hinweg wertvoll.
Was unter Umständen nicht reizt. Ihre Arbeit ist unsichtbar, wenn sie funktioniert. Niemand bemerkt eine reibungslos laufende Pipeline, sie bemerken nur die, die kaputtgeht. Anerkennung ist strukturell und leise, nicht laut. Data Engineers, die direkte nutzergerichtete Wirkung brauchen, finden die Arbeit manchmal distanziert. Sie arbeiten zudem mit Konsumenten (Analysten, Agenten, interne Nutzer) statt direkt mit Kunden, was sich weniger konkret anfühlen kann als Anwendungs-Engineering. Und Data Engineering wurde historisch in vielen Unternehmen relativ zum Anwendungs-Engineering unterbewertet, obwohl KI-native Operationen das schnell ändern; die alte Unterbewertung kann in manchen Kulturen noch auftauchen.
Wer in dieser Rolle gedeiht
Die wichtigsten Eignungen sind systemisches Denken, architektonisches Urteil und Kostendisziplin, also andere als Stärken im Anwendungs-Engineering.
Sie denken in Systemen und Flüssen. Daten sind systemförmig. Engineers, die natürlich Flüsse, Abhängigkeiten und emergentes Verhalten sehen, produzieren starke Dateninfrastruktur.
Sie kümmern sich um Korrektheit vor Geschwindigkeit. Schlechte Daten korrumpieren alles Nachgelagerte still. Data Engineers, die sich um Korrektheit kümmern, produzieren vertrauenswürdige Infrastruktur; jene, die für Lieferungstempo optimieren, produzieren versteckte Probleme.
Sie kommen mit langen Rückkopplungsschleifen zurecht. Architekturentscheidungen zeigen ihre Konsequenzen über Monate und Jahre. Data Engineers, die schnelles Feedback brauchen, haben Mühe; jene, die mit Sorgfalt und Geduld entwerfen können, produzieren starke Fundamente.
Sie halten Kostendisziplin. Dateninfrastruktur kann schnell teuer werden. Engineers, die Kosten als erstklassiges Anliegen behandeln, produzieren nachhaltige Infrastruktur; jene, die das nicht tun, produzieren Überraschungsrechnungen.
Sie können über Konsumenten hinweg lesen. Analysten, Agenten, Anwendungs-Engineers, interne Nutzer: sie haben unterschiedliche Bedürfnisse an dieselben Daten. Engineers, die mehrere Konsumentenperspektiven halten können, produzieren nützliche Infrastruktur; jene, die nur für eine optimieren, scheitern an den anderen.
Sie schreiben klar. Datenarchitekturdokumente, Schemaspezifikationen, Runbooks. Klares Schreiben ist Kern der Rolle.
Sie sind misstrauisch gegenüber sauberen Geschichten. Wenn Daten zu sauber aussehen, untersuchen Sie. Gesunde Skepsis gegenüber den eigenen Pipelines ist essenziell.
Sie partnern gut mit benachbarten Spezialisten. Data Analyst, Anwendungs-Engineer, DevOps Engineer, Workflow-Architekt. Engineers, die über diese Grenzen hinweg übersetzen können, produzieren kohärente Infrastruktur.
Weniger essenziell als zuvor: Beherrschung eines bestimmten Data-Tools oder ETL-Frameworks, die Fähigkeit, komplexes SQL per Hand zu schreiben, Tiefe in einem bestimmten Datenspeicher. Der Agent absorbiert das. Die Rolle schätzt Architektur, Urteil und Design.
Fähigkeiten, die Sie entwickeln sollten
Die Eignungen beschreiben die Disposition. Die folgenden Fähigkeiten bauen Sie aktiv auf.
Spezifikation der Datenarchitektur. Schreiben, wie Daten fließen, wo sie leben, welche Modelle sie strukturieren, mit genug Strenge, dass der Agent bauen und das Team erweitern kann. Wie üben: Die Datenarchitektur für Ihren aktuellen Bereich entwerfen. Eine Kollegin oder einen Kollegen herausfordern lassen, verfeinern.
Pipeline-Reliability-Engineering. Pipelines entwerfen, die beobachtbar, wiederherstellbar und unter Last vorhersagbar sind. Wie üben: Für eine Pipeline Observability und Wiederherstellung vor dem Bauen entwerfen. Durch Simulation von Ausfällen testen.
Denken in Kosten pro Ergebnis. Dateninfrastrukturkosten als Engineering-Daten lesen, nicht als Finanzdaten. Wie üben: Monatlich Kostentreiber auditieren. Die drei größten Optimierungsgelegenheiten ohne Qualitätsverlust identifizieren. Eine umsetzen.
Pflege von Schema und Definition. Kohärente Datenmodelle pflegen, auf die Konsumenten sich verlassen können. Wie üben: Ein Kernschema nehmen. Die maßgebliche Spezifikation schreiben. Funktionsübergreifende Zustimmung einholen. Die Disziplin verstärkt sich.
Design der KI-Infrastruktur. Vektorspeicher, Embedding-Pipelines, Model-Serving, Agent-Kontextlieferung. Wie üben: Für einen KI-Workflow, den Ihr Unternehmen betreibt, die Infrastruktur dokumentieren, von der er abhängt. Fehlermodi identifizieren. Steuerungen entwerfen.
Spezifikation der Daten-Observability. Was gemessen wird, was Alarme auslöst, was die erwartete Reaktion ist. Wie üben: Für jede Pipeline die Observability-Spec vor der Pipeline schreiben. Wenn die Antwort auf „Wie würden wir wissen, dass das kaputt ist?" „Beschwerden nachgelagert" lautet, ist die Spec nicht fertig.
Funktionsübergreifende Kommunikation. Für Data Analysts, Anwendungs-Engineers, Produkt, DevOps und Führung schreiben. Wie üben: Einen Infrastrukturvorschlag entwerfen. Einer Person aus jeder Funktion zeigen. Wo sie verwirrt sind, muss das Schreiben besser werden.
Migrations-Handwerk. Schemaänderungen, Infrastrukturmigrationen, Datenlöschungen. Die hochriskanten Operationen. Wie üben: Nach jeder bedeutenden Migration eine einseitige Reflexion schreiben. Das Muster über Migrationen hinweg ist Ihr Training.
Wählen Sie die Fähigkeit, die zu Ihrer jüngsten Infrastrukturenttäuschung passt. Üben Sie sie einen Monat lang.
Wie sich das von der alten Data-Engineer-Rolle unterscheidet
| Alter Data Engineer (vor KI) | Data Engineer (KI-nativ) |
|---|---|
| Erhebliche Zeit für das Schreiben von Pipelines, ETL und Warehouse-Queries per Hand | Pipeline-Code weitgehend vom Agenten absorbiert; Zeit fließt in Architektur und Design |
| Dateninfrastruktur ist nur intern, für Analysten und Dashboards | Dateninfrastruktur bedient nun Agenten, Analysten, interne Nutzer und externe Produkte |
| Kostendisziplin ist gelegentliches Aufräumen | Kostendisziplin ist kontinuierlich; KI-Infrastruktur bringt neue Kostencharakteristika |
| Schemaentscheidungen sind meist lokal | Schemaentscheidungen berücksichtigen Agent-Konsumenten, Wahl des Embedding-Modells, Vektorindexierung |
| Observability ist Nachgedanke | Observability wird hineinentworfen; schlechte Daten an der Quelle gefangen, nicht beim Konsumenten |
| Die besten Engineers sind operativ am rigorosesten | Die besten Engineers sind schärfste Architekten mit Urteil über Kosten und Zuverlässigkeit |
| Karrierepfad: Data Engineer zu Senior zu Lead zu Director of Data | Karrierepfad: derselbe, plus lateral zu Workflow-Architekt, Agentenbetreuer (für KI-Infrastrukturfokus), Senior FSE mit Infrastrukturtiefe |
Die Rolle ist kein schnellerer Data Engineer. Sie ist architektonischer: Pipeline-Umsetzung wird absorbiert, Designurteil weitet sich.
Welche Rollenentwicklungsmuster wirken
- Elevation (primär). Der Schwerpunkt der Rolle steigt von Umsetzung zu Architektur, Kostendesign und Observability-Spezifikation.
- Konvergenz (sekundär). Grenzen zu DevOps (KI-Infrastruktur), Anwendungs-Engineer (datenbewusste Features) und Data Analyst (Definitionen, Instrumentierung) verschwimmen, da die Data-Engineering-Rolle Zeit für substanzielle funktionsübergreifende Partnerschaft hat.
- Emergenz (teilweise). KI-Infrastruktur (Vektorspeicher, Embedding-Pipelines, Agent-Kontextlieferung) ist tatsächlich neue Verantwortung im Umfang des Data Engineer.
Spezialisierung innerhalb des Engineerings wirkt (die Rolle bleibt vom Senior FSE unterschieden, weil das Material anders ist: Datenflüsse gegen Nutzerinteraktionen, stille Fehlermodi gegen sichtbare Bugs, Infrastruktur-Konsumenten gegen kundengerichtete Erlebnisse). Das Konvergenz-Muster auf T3 löst innerhalb der Anwendung Spezialitätsgrenzen (FE/BE) eher auf als die Grenze zwischen Anwendung und Dateninfrastruktur, die operativ unterscheidbar bleibt.
Verwandte Rollen im Katalog
das Anwendungs-Engineering-Äquivalent; beide liefern über Spezifikationen und Urteil aus, aber das Material unterscheidet sich
Partner für Infrastruktur, die Datensysteme unterstützt
primärer Konsument; Partner für Definitionen und Instrumentierung
Quellen und weiterführende Literatur
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- Aus diesem Rahmenwerk: Zuverlässigkeit entwickeln, KI-Ausführungsstandards und Die KI-native Organisation.
← Zurück zu Rollen · Die KI-native Organisation · Rollenentwicklungsmuster · Referenzrahmenwerk · Zuverlässigkeit entwickeln