Gli ingegneri di machine learning costruiscono i sistemi che automatizzano il lavoro altrui. La domanda sulla ricorsività — «l'IA sostituisce gli ingegneri ML che addestrano l'IA?» — è la domanda che a ogni ingegnere ML viene posta a cena. È per lo più la domanda sbagliata. La vera lettura dell'esposizione per l'ingegneria ML è più interessante: il ruolo si colloca in territorio potenziato dall'IA, il costo operativo dell'IA per i task di ingegneria ML è eccezionalmente alto, e il lavoro Human-critical si concentra in una banda più stretta di quanto avvenga per gli ingegneri software.
I sei task di ingegneria ML che abbiamo modellato
L'ingegneria ML è un ruolo ibrido — in parte ingegnere software, in parte scienziato applicato, in parte ingegnere di piattaforma. Il nostro corpus v1 modella task rappresentativi del ruolo: addestrare un modello su un dataset etichettato, valutare le prestazioni del modello, mettere in produzione un modello addestrato, fare debug di regressioni del modello in produzione, progettare la pipeline di addestramento (dati → feature → addestramento → valutazione → deploy) e proporre nuovi approcci di modellazione.
La lettura a livello di cella
Addestrare un modello su un dataset etichettato è AI-augmented nel nostro seed v1 — la parte meccanica (lanciare i job di addestramento, tracciare gli iperparametri, cambiare un learning rate) è ad alta capacità, e gli strumenti di AutoML si mangiano questo strato del lavoro da tre anni. Ciò che tiene il task in AI-augmented e non in Replaceable sono le decisioni che gli ingegneri ML mantengono: quale versione del dataset usare per l'addestramento, quale regime di holdout è onesto per il deployment, se una regressione su uno slice conta. Quelle decisioni non sono automatizzabili, e si collocano sullo stesso task nella nostra matrice.
Valutare le prestazioni del modello e scrivere il report di valutazione è AI-augmented. Produrre la tabella delle metriche è meccanico. Decidere quale metrica conta per la decisione di deployment è giudizio. L'IA è eccellente sulla tabella, mediocre sulla conclusione.
Mettere in produzione un modello addestrato dietro un'API è AI-augmented. Il codice standard (handler FastAPI, batching, monitoraggio) è ad alta capacità. Le decisioni non standard — budget di latenza, politica di retry, strategia di rollback di versione — stanno dal lato umano. La cella si colloca saldamente nella banda intermedia.
Fare debug di regressioni del modello in produzione scende a Human-led + AI-assisted, ed è qui che il costo operativo dell'IA del ruolo schizza in alto. L'asse di affidabilità qui è scarso: l'IA diagnostica erroneamente le regressioni con sicurezza, e una diagnosi errata comporta contemporaneamente costo di supervisione e costo di errore a valle. I minuti di supervisione per sessione di debug sono alti. Le ore di task sono poche, ma il peso in dollari per ora è grande.
Progettare la pipeline di addestramento si colloca in Human-led + AI-assisted nella parte profonda. L'IA può abbozzare un DAG di pipeline; l'IA non può decidere che il refresh dei dati deve concludersi prima di mezzanotte UTC perché lo stakeholder europeo legge la dashboard alle 7 del mattino CET, e lo SLA del warehouse a monte è alle 2 UTC, e quindi la logica di buffer deve essere di tre ore e non i 30 minuti da manuale. Asse di contesto alto. Ambiguità alta.
Proporre nuovi approcci di modellazione è il task Human-critical del ruolo. La capacità dell'IA è media — l'IA può suggerire architetture plausibili. L'affidabilità è scarsa — i suggerimenti sono ricombinazioni di pattern del corpus di addestramento che possono non adattarsi al problema reale. L'asse di ambiguità si colloca in cima alla scala del valore irriducibile: decidere quale problema affrontare è ciò che definisce la seniority dell'ingegnere ML. L'IA non ha una posta in gioco nella direzione di ricerca dell'azienda.
Grosso modo nell'arco di una settimana tipo
Per un ingegnere ML di livello intermedio-senior in un'azienda che mette in produzione modelli (non un laboratorio di modelli fondativi — quella è un'altra cella), la distribuzione base v1 sui task modellati è: zero Replaceable, circa metà in AI-augmented (addestramento, report di valutazione, deployment di API in produzione), il resto diviso tra Human-led + AI-assisted (debug di regressioni, progettazione di pipeline) e Human-critical (decisioni sull'approccio di modellazione). Il pill principale è territorio potenziato dall'IA.
Assomiglia alla lettura dell'ingegneria software — e lo è, in superficie. La differenza emerge sull'asse del costo operativo dell'IA, dove i task di ingegneria ML hanno i valori di minuti-di-supervisione-per-output più alti di tutto il nostro corpus. Fare debug di una regressione richiede ore di attenzione umana per ogni diagnosi suggerita dall'IA. Il costo operativo non è quindi dominato dall'inferenza — è dominato dal tempo del revisore al salario caricato di un ingegnere ML senior. Il pattern Klarna si applica in modo diverso qui: un assistente IA ad alta capacità che necessita della supervisione di un ingegnere ML fa arbitraggio salariale contro il pool di revisori più costoso del team.
La domanda sulla ricorsività
La versione da cena tra amici: «L'IA sostituirà gli ingegneri ML che addestrano l'IA?». La risposta onesta dalla lettura v1 è: non entro il 2027. Le due celle che sembrano più automatizzabili — addestramento e produzione delle tabelle di valutazione — sono già in gran parte automatizzate, e lo sono dall'AutoML. Il lavoro residuo dell'ingegnere ML si concentra su progettazione di pipeline, debug di regressioni e scelte di modellazione — tre celle dove il divario capacità-affidabilità è più ampio e il costo operativo dell'IA è più alto.
La lettura strutturale è che l'ingegneria ML è uno dei pochi ruoli in cui l'aumento di capacità di fatto alza la domanda salariale per il lavoro human-critical residuo, perché una capacità maggiore sui task della metà inferiore libera ore dell'ingegnere ML per il lavoro di direzione di ricerca ad alta leva che si capitalizza contro gli asset di modello difendibili dell'azienda. Il framework della leva senza permesso di Naval si applica: gli ingegneri ML che usano l'assistenza dell'IA per coprire lo strato meccanico ottengono di più dalle stesse ore, non di meno.
Ciò che non modelliamo — la cella del laboratorio di modelli fondativi
Il nostro corpus v1 modella il tipico ingegnere ML applicato in un'azienda che mette in produzione modelli. Non modelliamo l'ingegnere ML di un laboratorio di modelli fondativi (Anthropic, OpenAI, DeepMind, Mistral, ecc.). Quel ruolo ha una forma diversa — la quota Human-critical è molto più alta, la quota AI-augmented è più bassa, e lo strato finanziario è sensibilmente diverso perché l'output del ruolo È il sostituto che viene misurato. Lo aggiungeremo in un'espansione del corpus v1.5. Per ora, tratta questo articolo come la lettura dell'ingegnere ML applicato, non quella del laboratorio di modelli fondativi.
Cosa farne
La mossa economicamente serena per un ingegnere ML applicato nel 2026 è lasciare che l'IA faccia i report di valutazione e gli handler delle API, e dedicare le ore liberate al muscolo del debug di regressioni e al giudizio nella progettazione di pipeline. Queste sono le celle dove la seniority si capitalizza. Il riconoscimento di pattern per le regressioni in produzione è il tipo di abilità che si affina con le ripetizioni ed è difficile da trasferire; le scelte di modellazione che sembrano buone in un notebook e falliscono in produzione insegnano un tipo di rigore operativo che l'IA non può provare al posto tuo.
Calcola la tua Wagecard specifica su wagecore.ai/start. Se sei in un laboratorio di modelli fondativi, la corrispondenza più vicina nel nostro corpus è il ruolo machine-learning-engineer con override manuali; lo indicheremo nella pagina dei risultati. Lettura derivata dalla matrice su /roles/machine-learning-engineer, lettura inter-cella in tempo reale su /insights/machine-learning-engineer. Metodologia aperta su /methodology.