Machine-Learning-Ingenieure bauen die Systeme, die die Arbeit anderer Menschen automatisieren. Die Rekursionsfrage — „ersetzt KI die ML-Ingenieure, die KI trainieren?“ — ist die Frage, die jedem ML-Ingenieur beim Abendessen gestellt wird. Sie ist meistens die falsche Frage. Der eigentliche Exposure-Befund für ML-Engineering ist interessanter: Die Rolle landet im KI-augmentierten Bereich, die operative KI-Kostenlinie für ML-Engineering-Aufgaben ist außergewöhnlich hoch, und die Human-critical-Arbeit konzentriert sich in einem schmaleren Band als bei Softwareingenieuren.
Die sechs ML-Engineering-Aufgaben, die wir modelliert haben
ML-Engineering ist eine Hybridrolle — teils Softwareingenieur, teils angewandter Wissenschaftler, teils Plattformingenieur. Unser v1-Korpus modelliert repräsentative Aufgaben über die Rolle hinweg: das Training eines Modells auf einem gelabelten Datensatz, die Bewertung der Modellleistung, das Produktivsetzen eines trainierten Modells, das Debuggen von Modellregressionen in der Produktion, das Design der Trainingspipeline (Daten → Features → Training → Eval → Deploy) und das Vorschlagen neuer Modellierungsansätze.
Der Befund auf Zellebene
Das Training eines Modells auf einem gelabelten Datensatz ist in unserem v1-Seed KI-augmentiert — der mechanische Teil (Fit-Jobs ausführen, Hyperparameter tracken, eine Lernrate austauschen) ist hochgradig automatisierbar, und AutoML-Tools fressen diese Arbeitsschicht seit drei Jahren auf. Was die Aufgabe im KI-augmentierten Bereich hält und nicht als Replaceable klassifiziert, sind die Entscheidungen, die ML-Ingenieure weiterhin besitzen: welche Datensatzversion trainiert wird, welches Holdout-Regime für den Deployment-Fall ehrlich ist, ob eine Regression auf einem Slice überhaupt ins Gewicht fällt. Diese Entscheidungen sind nicht automatisierbar, und sie sitzen in unserer Matrix auf derselben Aufgabe.
Die Bewertung der Modellleistung und das Schreiben des Eval-Reports ist KI-augmentiert. Die Metriktabelle zu produzieren ist mechanisch. Zu entscheiden, welche Metrik für die Deployment-Entscheidung zählt, ist Urteilsvermögen. KI ist exzellent bei der Tabelle, mittelmäßig bei der Schlussfolgerung.
Das Produktivsetzen eines trainierten Modells hinter einer API ist KI-augmentiert. Der Boilerplate-Code (FastAPI-Handler, Batching, Monitoring) ist hochgradig automatisierbar. Die Nicht-Boilerplate-Entscheidungen — Latenzbudget, Retry-Policy, Version-Rollback-Strategie — sitzen auf der menschlichen Seite. Die Zelle liegt solide im mittleren Band.
Das Debuggen von Modellregressionen in der Produktion fällt auf Human-led + AI-assisted, und hier schnellen die operativen KI-Kosten der Rolle in die Höhe. Die Zuverlässigkeitsachse ist hier schwach: KI stellt Regressionen selbstbewusst falsch, und eine Fehldiagnose führt gleichzeitig zu Aufsichtskosten und zu Folgekosten durch nachgelagerte Fehler. Die Aufsichtsminuten pro Debug-Session sind hoch. Die Aufgabenstunden sind wenige, aber das Dollargewicht pro Stunde ist groß.
Das Design der Trainingspipeline landet am tiefen Ende bei Human-led + AI-assisted. KI kann einen Pipeline-DAG entwerfen; KI kann nicht entscheiden, dass der Data-Refresh vor Mitternacht UTC landen muss, weil der europäische Stakeholder das Dashboard um 7 Uhr MEZ liest, das Upstream-Warehouse-SLA bei 2 Uhr UTC liegt und die Pufferlogik deshalb drei Stunden braucht, nicht die Lehrbuch-30-Minuten. Kontextachse hoch. Ambiguität hoch.
Das Vorschlagen neuer Modellierungsansätze ist die Human-critical-Aufgabe der Rolle. Die Fähigkeit der KI ist mittel — KI kann plausible Architekturen vorschlagen. Die Zuverlässigkeit ist schwach — die Vorschläge sind Rekombinationen von Mustern aus dem Trainingskorpus, die möglicherweise nicht zum tatsächlichen Problem passen. Die Ambiguitätsachse erreicht die Spitze der Skala des irreduziblen Werts: zu entscheiden, welches Problem angegangen wird, ist das, was die Seniorität des ML-Ingenieurs definiert. KI hat keinen Anteil an der Forschungsrichtung des Unternehmens.
Grob über eine typische Woche
Für einen ML-Ingenieur mittlerer bis hoher Seniorität in einem modell-deployenden Unternehmen (kein Foundation-Model-Lab — das ist eine andere Zelle) ist die v1-Baseline-Verteilung über die modellierten Aufgaben: null Replaceable, etwa die Hälfte KI-augmentiert (Training, Eval-Reports, Produktions-API-Deployment), der Rest aufgeteilt zwischen Human-led + AI-assisted (Regressions-Debugging, Pipeline-Design) und Human-critical (Entscheidungen zum Modellierungsansatz). Die Headline-Pill ist KI-augmentierter Bereich.
Das sieht dem Software-Engineering-Befund ähnlich — und ist es an der Oberfläche auch. Der Unterschied zeigt sich auf der Achse der operativen KI-Kosten, wo ML-Engineering-Aufgaben die höchsten Aufsichtsminuten-pro-Output-Werte in unserem gesamten Korpus haben. Das Debuggen einer Regression kostet Stunden menschlicher Aufmerksamkeit pro KI-vorgeschlagener Diagnose. Die operative Kostenlinie wird deshalb nicht von der Inferenz dominiert — sie wird von der Reviewer-Zeit zum Vollkostensatz eines Senior- ML-Ingenieurs dominiert. Das Klarna-Muster gilt hier anders: ein hochgradig fähiger KI-Assistent, der ML-Ingenieur-Aufsicht braucht, betreibt Lohnarbitrage gegen den teuersten Reviewer-Pool im Team.
Die Rekursionsfrage
Die Abendessen-Version: „Wird KI die ML-Ingenieure ersetzen, die KI trainieren?“ Die ehrliche Antwort aus dem v1-Befund lautet: nicht bis 2027. Die beiden Zellen, die am automatisierbarsten aussehen — Training und Eval-Tabellen-Produktion — sind bereits weitgehend automatisiert, und das seit AutoML. Die verbleibende Arbeit des ML-Ingenieurs konzentriert sich auf Pipeline-Design, Regressions-Debugging und Modellierungsentscheidungen — drei Zellen, in denen die Lücke zwischen Fähigkeit und Zuverlässigkeit am größten und die operativen KI-Kosten am höchsten sind.
Der strukturelle Befund ist, dass ML-Engineering eine der wenigen Rollen ist, in denen steigende Fähigkeit die Lohnnachfrage für die verbleibende Human-critical-Arbeit tatsächlich erhöht, weil höhere Fähigkeit bei den Aufgaben der unteren Hälfte ML-Ingenieur-Stunden für die hebelstarke Forschungsrichtungsarbeit freisetzt, die sich gegen die verteidigungsfähigen Modell-Assets des Unternehmens aufsummiert. Navals Framework der permissionless leverage gilt: ML-Ingenieure, die KI-Assistenz nutzen, um die mechanische Schicht abzudecken, holen mehr aus denselben Stunden heraus, nicht weniger.
Was wir nicht modellieren — die Foundation-Model-Lab-Zelle
Unser v1-Korpus modelliert den typischen angewandten ML-Ingenieur in einem modell-deployenden Unternehmen. Wir modellieren nicht den Foundation-Model-Lab-ML-Ingenieur (Anthropic, OpenAI, DeepMind, Mistral usw.). Diese Rolle hat eine andere Form — der Human-critical-Anteil ist deutlich höher, der KI-augmentierte Anteil ist niedriger, und die finanzielle Schicht ist wesentlich anders, weil der Output der Rolle SELBST das gemessene Substitut ist. Wir werden sie in einer v1.5-Korpus-Erweiterung ergänzen. Behandeln Sie diesen Beitrag vorerst als den Befund für den angewandten ML-Ingenieur, nicht als den Foundation-Model-Lab-Befund.
Was Sie damit tun sollten
Der ruhig-ökonomische Zug für einen angewandten ML-Ingenieur 2026 ist, die KI die Eval-Reports und die API-Handler machen zu lassen und die freigewordenen Stunden auf den Regressions-Debugging- Muskel und das Urteilsvermögen im Pipeline-Design zu verwenden. Das sind die Zellen, in denen sich Seniorität aufsummiert. Mustererkennung für Produktionsregressionen ist die Art von Fähigkeit, die mit Wiederholungen schärfer wird und schwer zu übertragen ist; Modellierungsentscheidungen, die im Notebook gut aussehen und in der Produktion scheitern, lehren eine Art operativer Strenge, die KI nicht stellvertretend für Sie einüben kann.
Berechnen Sie Ihren spezifischen Wagecard unter wagecore.ai/start. Wenn Sie in einem Foundation-Model-Lab sind, ist die nächste Entsprechung in unserem Korpus die Rolle Machine-Learning-Engineer mit manuellen Overrides; wir weisen darauf auf der Ergebnisseite hin. Matrix-abgeleiteter Befund unter /roles/machine-learning-engineer , Live-Cross-Cell-Befund unter /insights/machine-learning-engineer . Methodik offen unter /methodology.