Engenheiros de machine learning constroem os sistemas que automatizam o trabalho das outras pessoas. A pergunta da recursão — “a IA substitui os engenheiros de ML que treinam a IA?” — é a pergunta que todo engenheiro de ML ouve no jantar. E é quase sempre a pergunta errada. A leitura real de exposição para a engenharia de ML é mais interessante: o cargo cai em território AI-augmented, a linha de custo operacional de IA para tarefas de engenharia de ML é excepcionalmente alta, e o trabalho Human-critical se concentra em uma faixa mais estreita do que para engenheiros de software.
As seis tarefas de engenharia de ML que modelamos
A engenharia de ML é um cargo híbrido — parte engenheiro de software, parte cientista aplicado, parte engenheiro de plataforma. Nosso corpus v1 modela tarefas representativas do cargo: treinar um modelo com um conjunto de dados rotulado, avaliar o desempenho do modelo, colocar em produção um modelo treinado, depurar regressões de modelo em produção, projetar o pipeline de treinamento (dados → features → treinamento → avaliação → deploy) e propor novas abordagens de modelagem.
A leitura no nível da célula
Treinar um modelo com um conjunto de dados rotulado é AI-augmented na nossa seed v1 — a parte mecânica (rodar jobs de fit, acompanhar hiperparâmetros, trocar uma learning rate) tem alta capacidade e as ferramentas de AutoML vêm comendo essa camada do trabalho há três anos. O que mantém a tarefa em AI-augmented e não em Replaceable são as decisões que os engenheiros de ML ainda detêm: qual versão do conjunto de dados usar no treinamento, qual regime de holdout é honesto para o deployment, se uma regressão em um slice importa. Essas decisões não são automatizáveis e ficam na mesma tarefa na nossa matriz.
Avaliar o desempenho do modelo e escrever o relatório de avaliação é AI-augmented. Produzir a tabela de métricas é mecânico. Decidir qual métrica importa para a decisão de deployment é julgamento. A IA é excelente na tabela, medíocre na conclusão.
Colocar em produção um modelo treinado atrás de uma API é AI-augmented. O boilerplate (handler FastAPI, batching, monitoramento) tem alta capacidade. As decisões que não são boilerplate — orçamento de latência, política de retry, estratégia de rollback de versão — ficam do lado humano. A célula está solidamente na faixa intermediária.
Depurar regressões de modelo em produção cai para Human-led + AI-assisted, e é aqui que o custo operacional de IA do cargo dispara. O eixo de confiabilidade aqui é ruim: a IA diagnostica regressões erradas com confiança, e um diagnóstico errado leva a custo de supervisão e custo de erro downstream simultaneamente. Os minutos de supervisão por sessão de depuração são altos. As horas de tarefa são poucas, mas o peso em dólares por hora é grande.
Projetar o pipeline de treinamento cai em Human-led + AI-assisted na ponta mais profunda. A IA pode rascunhar um DAG de pipeline; a IA não consegue decidir que o refresh dos dados tem que acontecer antes da meia-noite UTC porque o stakeholder europeu lê o dashboard às 7h CET, e o SLA do warehouse upstream é 2h UTC, e por isso a lógica de buffer precisa ser de três horas e não os 30 minutos do manual. Eixo de contexto alto. Ambiguidade alta.
Propor novas abordagens de modelagem é a tarefa Human-critical do cargo. A capacidade da IA é média — a IA consegue sugerir arquiteturas plausíveis. A confiabilidade é ruim — as sugestões são recombinações de padrões do corpus de treinamento que podem não se encaixar no problema real. O eixo de ambiguidade pontua no topo da escala de valor irredutível: decidir qual problema atacar é o que define a senioridade do engenheiro de ML. A IA não tem participação na direção de pesquisa da empresa.
Grosso modo, ao longo de uma semana típica
Para um engenheiro de ML de nível médio a sênior em uma empresa que faz deploy de modelos (não um laboratório de foundation model — essa é uma célula diferente), a distribuição baseline v1 entre as tarefas modeladas é: zero Replaceable, cerca de metade AI-augmented (treinamento, relatórios de avaliação, deploy de API em produção), e o restante dividido entre Human-led + AI-assisted (depuração de regressões, design de pipeline) e Human-critical (decisões de abordagem de modelagem). O pill de destaque é AI- augmented territory.
Isso parece semelhante à leitura da engenharia de software — e é, na superfície. A diferença aparece no eixo de custo operacional de IA, onde as tarefas de engenharia de ML têm os maiores números de minutos- de-supervisão-por-output de todo o nosso corpus. Depurar uma regressão consome horas de atenção humana por diagnóstico sugerido pela IA. A linha de custo operacional, portanto, não é dominada pela inferência — é dominada pelo tempo do revisor ao salário carregado de um engenheiro de ML sênior. O padrão Klarna se aplica de forma diferente aqui: um assistente de IA de alta capacidade que precisa de supervisão de engenheiro de ML está fazendo arbitragem de salário contra o pool de revisores mais caro da equipe.
A pergunta da recursão
A versão de jantar: “A IA vai substituir os engenheiros de ML que treinam a IA?” A resposta honesta da leitura v1 é: não até 2027. As duas células que parecem mais automatizáveis — treinamento e produção-de-tabela-de-avaliação — já estão em grande parte automatizadas, e estão assim desde o AutoML. O trabalho remanescente do engenheiro de ML está concentrado em design de pipeline, depuração de regressões e escolhas de modelagem — três células onde o gap capacidade-confiabilidade é maior e o custo operacional de IA é mais alto.
A leitura estrutural é que a engenharia de ML é um dos poucos cargos onde a capacidade em ascensão de fato eleva a demanda salarial pelo trabalho human-critical remanescente, porque maior capacidade nas tarefas da metade de baixo libera horas do engenheiro de ML para o trabalho de alta alavancagem de direção de pesquisa que compõe contra os ativos de modelo defensáveis da empresa. O framework de alavancagem-sem- permissão de Naval se aplica: engenheiros de ML que usam assistência de IA para cobrir a camada mecânica extraem mais das mesmas horas, não menos.
O que não modelamos — a célula do laboratório de foundation model
Nosso corpus v1 modela o engenheiro de ML aplicado típico em uma empresa que faz deploy de modelos. Não modelamos o engenheiro de ML de laboratório de foundation model (Anthropic, OpenAI, DeepMind, Mistral, etc.). Esse cargo tem formato diferente — a fatia Human-critical é bem maior, a fatia AI-augmented é menor, e a camada financeira é significativamente diferente porque o output do cargo É o substituto sendo medido. Vamos adicioná-lo em uma expansão de corpus v1.5. Por ora, trate este post como a leitura do engenheiro de ML aplicado, não a leitura do laboratório de foundation model.
O que fazer com isso
O movimento economicamente calmo para um engenheiro de ML aplicado em 2026 é deixar a IA fazer os relatórios de avaliação e os handlers de API, e gastar as horas liberadas no músculo de depuração de regressões e no julgamento de design de pipeline. Essas são as células onde a senioridade compõe. O reconhecimento de padrões para regressões em produção é o tipo de habilidade que fica mais afiada com repetições e é difícil de transferir; escolhas de modelagem que parecem boas num notebook e falham em produção ensinam um tipo de rigor operacional que a IA não consegue ensaiar por você.
Calcule seu Wagecard específico em wagecore.ai/start. Se você está em um laboratório de foundation model, a correspondência mais próxima no nosso corpus é o cargo de machine-learning-engineer com overrides manuais; vamos dizer isso na página de resultado. Leitura derivada da matriz em /roles/machine-learning-engineer , leitura cross-cell ao vivo em /insights/machine-learning-engineer . Metodologia aberta em /methodology.