Machine-learning-engineers bouwen de systemen die het werk van andere mensen automatiseren. De recursievraag — “vervangt AI de ML-engineers die AI trainen?” — is de vraag die elke ML-engineer aan het diner krijgt. Het is meestal de verkeerde vraag. De werkelijke exposure-uitkomst voor ML-engineering is interessanter: de rol landt in AI-augmented gebied, de operationele AI-kostenregel voor ML-engineeringtaken is uitzonderlijk hoog, en het Human-critical werk concentreert zich in een smallere band dan bij software-engineers.
De zes ML-engineeringtaken die we hebben gemodelleerd
ML-engineering is een hybride rol — deels software-engineer, deels toegepast wetenschapper, deels platform-engineer. Ons v1-corpus modelleert representatieve taken over de rol heen: een model trainen op een gelabelde dataset, modelprestaties evalueren, een getraind model naar productie brengen, modelregressies in productie debuggen, de trainingspijplijn ontwerpen (data → features → training → eval → deploy), en nieuwe modelleringsbenaderingen voorstellen.
De uitkomst op celniveau
Een model trainen op een gelabelde dataset is AI-augmented in onze v1-seed — het mechanische deel (fit-jobs draaien, hyperparameters bijhouden, een learning rate wisselen) is sterk automatiseerbaar en AutoML-tools vreten deze werklaag al drie jaar op. Wat de taak in AI-augmented houdt en niet als Replaceable classificeert, zijn de beslissingen die ML-engineers nog steeds bezitten: welke datasetversie je traint, welk holdout-regime eerlijk is voor de deployment, of een regressie op een slice überhaupt telt. Die beslissingen zijn niet automatiseerbaar en ze zitten in onze matrix op dezelfde taak.
Modelprestaties evalueren en het eval-rapport schrijven is AI-augmented. De metriektabel produceren is mechanisch. Beslissen welke metriek telt voor de deployment-beslissing is oordeelsvorming. AI is uitstekend in de tabel, middelmatig in de conclusie.
Een getraind model achter een API naar productie brengen is AI-augmented. De boilerplate (FastAPI-handler, batching, monitoring) is sterk automatiseerbaar. De niet-boilerplate- beslissingen — latentiebudget, retry-policy, version-rollback- strategie — zitten aan de menselijke kant. De cel ligt stevig in de middenband.
Modelregressies in productie debuggen zakt naar Human-led + AI-assisted, en hier schieten de operationele AI-kosten van de rol omhoog. De betrouwbaarheidsas is hier zwak: AI stelt regressies met stelligheid verkeerd vast, en een misdiagnose leidt tegelijk tot toezichtskosten en tot vervolgkosten door stroomafwaartse fouten. De toezichtsminuten per debug-sessie zijn hoog. De taakuren zijn weinig, maar het dollargewicht per uur is groot.
De trainingspijplijn ontwerpen landt aan het diepe eind bij Human-led + AI-assisted. AI kan een pijplijn-DAG opstellen; AI kan niet beslissen dat de data-refresh vóór middernacht UTC moet landen omdat de Europese stakeholder het dashboard om 7 uur CET leest, de upstream-warehouse-SLA op 2 uur UTC ligt, en de bufferlogica daarom drie uur nodig heeft, niet de leerboek-30 minuten. Contextas hoog. Ambiguïteit hoog.
Nieuwe modelleringsbenaderingen voorstellen is de Human-critical-taak van de rol. De capaciteit van AI is middelmatig — AI kan plausibele architecturen suggereren. De betrouwbaarheid is zwak — de suggesties zijn herschikkingen van patronen uit het trainingscorpus die mogelijk niet passen bij het werkelijke probleem. De ambiguïteitsas scoort aan de top van de schaal van onherleidbare waarde: beslissen welk probleem je aanpakt is wat de senioriteit van de ML-engineer definieert. AI heeft geen belang bij de onderzoeksrichting van het bedrijf.
Grofweg over een typische week
Voor een mid-tot-senior ML-engineer bij een model-deployend bedrijf (geen foundation-model-lab — dat is een andere cel) is de v1-baseline-verdeling over de gemodelleerde taken: nul Replaceable, ruwweg de helft AI-augmented (training, eval-rapporten, productie-API-deployment), de rest verdeeld tussen Human-led + AI-assisted (regressie-debugging, pijplijnontwerp) en Human-critical (beslissingen over de modelleringsbenadering). De headline-pill is AI-augmented gebied.
Dat lijkt op de software-engineering-uitkomst — en is dat ook aan de oppervlakte. Het verschil komt naar boven op de as van de operationele AI-kosten, waar ML-engineeringtaken de hoogste toezichtsminuten-per-output-cijfers in ons hele corpus hebben. Een regressie debuggen kost uren menselijke aandacht per AI-gesuggereerde diagnose. De operationele kostenregel wordt daarom niet gedomineerd door inferentie — hij wordt gedomineerd door reviewertijd tegen het volledig belaste loon van een senior ML-engineer. Het Klarna-patroon geldt hier anders: een sterk capabele AI-assistent die ML-engineer-toezicht nodig heeft, bedrijft loonarbitrage tegen de duurste reviewerpool in het team.
De recursievraag
De dinerversie: “Gaat AI de ML-engineers vervangen die AI trainen?” Het eerlijke antwoord vanuit de v1-uitkomst is: niet tegen 2027. De twee cellen die het meest automatiseerbaar lijken — training en eval-tabel-productie — zijn al grotendeels geautomatiseerd, en dat sinds AutoML. Het resterende werk van de ML-engineer concentreert zich in pijplijnontwerp, regressie-debugging en modelleringskeuzes — drie cellen waar de kloof tussen capaciteit en betrouwbaarheid het grootst is en de operationele AI-kosten het hoogst zijn.
De structurele uitkomst is dat ML-engineering een van de weinige rollen is waar stijgende capaciteit de loonvraag voor het resterende Human-critical werk feitelijk verhoogt, omdat hogere capaciteit op de taken van de onderste helft ML-engineer-uren vrijmaakt voor het hefboomrijke onderzoeksrichtingswerk dat zich opstapelt tegen de verdedigbare model-assets van het bedrijf. Naval's raamwerk van permissionless leverage geldt: ML-engineers die AI-assistentie gebruiken om de mechanische laag af te dekken, halen meer uit dezelfde uren, niet minder.
Wat we niet modelleren — de foundation-model-lab-cel
Ons v1-corpus modelleert de typische toegepaste ML-engineer bij een model-deployend bedrijf. We modelleren niet de foundation-model-lab-ML-engineer (Anthropic, OpenAI, DeepMind, Mistral, enz.). Die rol heeft een andere vorm — het Human-critical-aandeel is veel hoger, het AI-augmented aandeel is lager, en de financiële laag is wezenlijk anders omdat de output van de rol ZELF het gemeten substituut is. We voegen die toe in een v1.5-corpusuitbreiding. Behandel deze post voorlopig als de toegepaste-ML-engineer-uitkomst, niet als de foundation-model-lab-uitkomst.
Wat je hiermee moet doen
De kalm-economische zet voor een toegepaste ML-engineer in 2026 is om AI de eval-rapporten en de API-handlers te laten doen, en de vrijgekomen uren te besteden aan de regressie-debugging-spier en het oordeel in pijplijnontwerp. Dit zijn de cellen waar senioriteit zich opstapelt. Patroonherkenning voor productieregressies is het soort vaardigheid dat scherper wordt met herhaling en moeilijk over te dragen is; modelleringskeuzes die er goed uitzien in een notebook en falen in productie leren een soort operationele striktheid die AI niet namens jou kan inoefenen.
Bereken je specifieke Wagecard op wagecore.ai/start. Als je bij een foundation-model-lab zit, is de dichtstbijzijnde match in ons corpus de rol machine-learning-engineer met handmatige overrides; we vermelden dat op de resultatenpagina. Matrix-afgeleide uitkomst op /roles/machine-learning-engineer , live cross-cell-uitkomst op /insights/machine-learning-engineer . Methodologie open op /methodology.