Engenheiro de IA sênior não existe

Publicado em 22 de jul. de 2026· 24 min de leitura

Ou, porquê eu acho que não existe.

Esse artigo nasceu de um desconforto meu que passa na minha cabeça faz alguns meses.

Todo mundo nessa área veio de outro lugar, o que não é ruim.

Minha formação inteira foi em dados. Engenharia de dados e ciência de dados, pipeline, modelagem, estatística, experimento, e muita, muita EDA. Anos abrindo datasets, caçando outliers, desconfiando de coluna, montando hipótese, otimizando meu deck no Heartstone e outros. Também implementei rotina de coleta, ingestão, transformação, orquestração, coisa rodando agendada todo dia alimentando decisões importantes. E eu acho que eu melhorei minhas skills de engenharia.

Mas é engenharia de um regime específico: batch, uma execução por vez, tolerância a atraso, e se quebrar às 3 da manhã, dá pra reprocessar às 9 sem ninguém morrer. Isso não é a mesma coisa que uma aplicação conversacional com fila, atendendo muitos usuários simultâneos, onde cada request tem alguém esperando do outro lado, latência é produto, e “reprocessa depois” não existe porque o usuário já foi embora.

Quando fui colocar meu primeiro agente em produção, descobri que nada do meu repertório me preparou pra essa outra parte. Eu não sabia desenhar uma API que aguenta retry sem duplicar efeito colateral. Eu nunca tinha pensado seriamente em idempotência, connection pool, graceful shutdown, backpressure, ou no que acontece com a fila quando o provider de LLM devolve 429 por dez minutos com clientes esperando.

Eu tenho gaps de engenharia de software. Gaps reais, do tipo que até o momento eu acredito que não se resolve com um curso de fim de semana, porque são gaps de cicatriz, de coisa que você só aprende quebrando e resolvendo coisas. E o mercado inteiro está fingindo que gente como eu, com três anos de LLM em cima de outras coisas, é “engenheiro de IA sênior”. E eu não acho que isso ta errado também?

Mas, o ponto que eu quero trazer é que ninguém é. Não porque falta gente boa, mas porque a régua que define sênior nessa área ainda não teve tempo de existir.

Vamos por partes.

O título mais quente do mercado tem três anos de idade

Primeiro os números.

O relatório Jobs on the Rise 2026 do LinkedIn colocou AI Engineer como o cargo que mais cresce nos Estados Unidos, com 143% de crescimento ano contra ano nas vagas. Quatro dos cinco cargos que mais crescem são relacionados a IA. Entre 2023 e 2025 foram 639 mil vagas relacionadas a IA só nos EUA. Estimativas de mercado apontam algo em torno de 1,6 milhão de posições abertas contra ~518 mil candidatos qualificados, um gap de demanda de 3,2 pra 1.

Agora a parte que interessa. O termo “AI Engineer”, no sentido atual, foi popularizado pelo swyx no artigo The Rise of the AI Engineer, em julho de 2023. O título praticamente não existia em 2022. A definição dele é honesta sobre o que o cargo é: Um engenheiro de software que constrói com IA, sabendo o suficiente de conceitos e limitações de modelo pra colocar aquilo num produto, sem ser pesquisador nem ML engineer.

Faz a conta. Se o cargo nasceu em meados de 2023, a pessoa com mais tempo de estrada possível como AI Engineer tem hoje uns três anos de experiência. E mesmo assim as vagas pedem, “5+ anos de experiência com LLMs em produção”. O Indeed Hiring Lab documentou que a fração de vagas tech pedindo 5+ anos de experiência subiu de 37% pra 42% entre 2022 e 2025, exatamente no período em que a tecnologia mais pedida tinha menos de 3 anos de vida. É o velho meme do “requer 10 anos de Kubernetes” quando o Kubernetes tinha 4, só que em escala industrial.

Quando a vaga pede mais anos de experiência do que a tecnologia tem de existência, o que a vaga está pedindo, na prática, é “seja sênior em outra coisa e finja que sempre foi daqui”.

E é isso que o mercado fez. Como não existe estoque de engenheiro de IA formado, todo mundo que ocupa essas vagas hoje é um convertido (amém no meu caso). E convertido carrega a bagagem e os buracos da vida anterior. Na minha leitura, são três perfis dominantes disputando as mesmas vagas, e cada um chega com um gap estrutural diferente que quase nunca aparece na entrevista.

Pra que direção eu vou?

Pra que direção eu vou?

Perfil 1: o que veio de dados (oi, meu chapa, prazer)

Cientista de dados, analista sênior, engenheiro de ML da era pré-LLM. Sabe estatística, sabe o que é overfitting, sabe que avaliação offline não garante nada online, já viu métrica mentir. Esse perfil tem uma vantagem enorme que o mercado demorou pra perceber: A parte mais difícil de IA generativa em produção é avaliação, e avaliação é literalmente o ofício de quem veio de dados. Definir métrica, desenhar experimento, desconfiar de resultado bom demais, controlar falso positivo. Twyman’s Law é nosso território.

O gap é o resto. E o resto é grande.

Quem veio de dados tipicamente construiu a carreira inteira em ambientes onde o código termina quando o insight sai ou quando o pipeline roda. Notebook, DAG batch, dashboard. E mesmo quem construiu um pipeline bão, como eu, construiu pro regime errado, o pipeline batch perdoa de um jeito que sistema online não perdoa. A disciplina de engenharia de software que transforma código em sistema que atende gente em tempo real, testes automatizados, CI/CD, design de API, observabilidade, tratamento de erro como cidadão de primeira classe, capacidade sob concorrência, normalmente nunca foi cobrada. O relato clássico de transição de data science pra AI engineering no Towards Data Science aponta exatamente isso, o buraco principal é engenharia de produção (APIs, containers, filas), e só depois vem a camada de IA por cima.

A minha própria autocrítica, da minha própria lista:

Eu sei provar que um teste A/B está bem calibrado, e não sei estimar quanto custa por mês o endpoint que estou desenhando, em compute, em latência p99, mas sei sei de custo de tokens.
Eu sei escrever SQL que o time inteiro entende, e meu Python das ruas era muito gambiarrado, que só foquei em resolver estutando TDD, testes e CI/CD pra ir validando meus próprios projetos depois que o JP falou pra mim: “Um cientista de dados é alguém que sabe mais de estatística do que um engenheiro de software, e mais de engenharia de software do que um estatístico. E nenhum dos três sabe como fazer deploy”.
Eu sei o que é data drift, e nunca tinha configurado até pouco tempo atrás um alerta bom de verdade, do tipo que acorda alguém de forma confiavel com um acionavel.
Eu falo de idempotência com confiança desde que ninguém peça pra eu implementar a fila que garante isso para troca mensagens.

O perigo desse perfil é se esconder atrás da estatística. Como avaliação virou a habilidade da moda, é tentador ficar no papel de “pessoa dos evals” e nunca encostar na parte do sistema que dói. Só que engenheiro de IA que não consegue subir o próprio serviço é analista com título novo.

Perfil 2: o que veio de software

O dev frontend/backend/full-stack que surfou a onda. Esse perfil chega com o que falta pro primeiro, sabe colocar coisa em produção, idealmente sabe o custo de manter sistema vivo, pensa em contrato de API, em rollback, e é mais cobrado em teste. A definição do swyx foi desenhada praticamente pra ele, e o Pragmatic Engineer com a Chip Huyen reforça que o AI Engineer está muito mais perto da engenharia de software do que da pesquisa.

O gap dele é o inverso do meu, e é mais sutil, porque não aparece como falta de skill, aparece como mentalidade errada de correção e em alguns casos, falta de profundidade.

Engenharia de software clássica é construída sobre determinismo. Input igual, output igual, teste passa ou não passa. LLM quebrou isso, sem contar as peças como RAG e outros. A mesma pergunta, duas respostas diferentes, ambas possivelmente boas. O dev que chega em IA tentando escrever unit test pra output de modelo descobre que o instrumento não morde. Pesquisa acadêmica sobre a integração de LLMs em produtos documenta exatamente essa dor, avaliar LLM exige uma mentalidade de pesquisa, formular hipótese, definir métrica customizada, iterar sobre variações, e nada disso é ensinado ou praticado na formação tradicional de engenharia de software.

Na prática, os sintomas desse gap são fáceis de reconhecer:

Trata prompt como string mágica, não como artefato versionado com suite de avaliação em cima, as vezes nem iterando para ter o melhor prompt possível.
Confunde demo com produto. O agente funcionou três vezes no vídeo pro Slack, logo está pronto. Não está, e a diferença entre 95% e 99% de acerto por passo é a diferença entre produto e piada.
Não tem instinto de amostra. Avalia mudança de prompt olhando 5 exemplos e decide. Quem veio de dados sente dor física vendo isso.
Otimiza a arquitetura antes de medir o baseline, porque construir sistema é a zona de conforto e medir qualidade não é.

O dev tem a fundação certa pra metade do trabalho. A outra metade, é epistemológica, “como eu sei que isso está bom, e quanto de errado eu tolero?”, é exatamente a que ele nunca precisou desenvolver.

Perfil 3: o que chegou pelas plataformas de automação

Esse é o perfil novo, e é o que mais cresce na base da pirâmide. É a pessoa que entrou por n8n, Make, Zapier, Dify, Flowise, ou direto pelos builders visuais de agente. Às vezes vem de negócio, de cs, de administração. Já apareceram títulos formais de vaga como n8n Automation Engineer e AI Automation Engineer, o mercado de automação no-code é avaliado em US$ 13,8 bilhões, e três dos cinco repositórios de agentes mais estrelados do GitHub são builders visuais, Langflow, Dify e Flowise. Isso não é acidente, é onde o volume está.

Vou dar o crédito que é devido antes de dar a notícia ruim. Esse perfil tem uma virtude real: proximidade com o problema de negócio e velocidade de entrega de POC. Enquanto o de dados está calibrando o eval e o dev está desenhando a arquitetura, essa pessoa já montou o protótipo, já colocou na frente do usuário, já validou se a ideia tem tração. Em um mercado onde o MIT mediu que 95% dos pilotos de IA generativa corporativa falham em gerar impacto, muito por falta de integração com o workflow real, validar rápido tem muito valor.

Agora a notícia ruim, e aqui eu vou ser direto porque acho que a indústria de cursos está mentindo pra essas pessoas, esse é o perfil mais fraco dos três, e por uma margem que não fecha rápido. Os outros dois chegam com uma década de fundação em uma das metades do trabalho, e precisam construir a outra metade. Esse perfil chega sem nenhuma das duas. Não tem a base de estatística e avaliação do primeiro, não tem a base de engenharia do segundo, e o que ele tem, fluência em uma ferramenta visual, é exatamente a parte que comoditiza mais rápido. O gap não é uma lista de skills faltando, é a fundação inteira:

Não sabe o que não sabe. O nó “AI Agent” do n8n esconde o loop, o parsing, o retry, o contexto. Quando quebra de um jeito que a plataforma não previu, não existe modelo mental pra debugar, porque a pessoa nunca viu o que tem dentro.
Zero disciplina de versionamento e ambiente. O workflow de produção é editado em produção. Não tem dev/staging, não tem review, não tem rollback. Um erro de clique é um incidente.
Segurança e dados pessoais como reflexão tardia. Credencial compartilhada, dado de cliente passando por três SaaS sem ninguém ter avaliado base legal, prompt injection nem entra no radar.
Escala como surpresa. A automação que roda 50 vezes por dia vira 50 mil, e descobre-se junto o rate limit, o custo, e que aquele webhook nunca teve fila.

E o problema de tempo é estrutural. O de dados fecha o gap de engenharia em um ou dois anos de produção porque já sabe programar, já pensa em sistema, só nunca foi cobrado para se ter rigor. O dev fecha o gap de avaliação em meses, porque rigor metodológico é aprendível pra quem já tem disciplina técnica. O de automação precisa construir o que os outros dois levaram uma década construindo: lógica de programação, fundamentos de sistema, base estatística. Não existe atalho pra isso, e a plataforma que abstrai tudo é ativamente um obstáculo, porque cada hora nela é uma hora aprendendo a interface de um produto em vez do fundamento por baixo.

O caminho honesto pra esse perfil, na minha leitura, não é “vire engenheiro de IA”. É um destes dois, usar a proximidade com o negócio como trampolim pra produto, onde entender o problema e prototipar rápido é a competência central e a falta de fundação técnica não é fatal, ou aceitar que fechar o gap técnico é um projeto de anos começando do zero, sem plataforma no meio. O que não existe é a terceira opção que os cursos vendem, seis meses de n8n e uma certificação te colocando na mesma prateleira de quem carrega dez anos de fundação. O mercado pode até contratar assim no hype. Ele corrige na primeira demissão em massa.

O mesmo abismo, três margens diferentes

Colocando lado a lado, o desenho fica assim:

 Perfil     |  Traz de casa                |  Gap             |  Tempo pra fechar
-----------------+----------------------------------+------------------+--------------------
 Dados      |  avaliação, estatística,     |  engenharia em   |  1-2 anos
            |  desconfiança metodológica   |  produção        |  em produção
-----------------+----------------------------------+------------------+--------------------
 Software   |  sistemas, produção,         |  mentalidade     |  meses, com
            |  disciplina de engenharia    |  probabilística  |  disciplina (somente evals)
-----------------+----------------------------------+------------------+--------------------
 Automação  |  velocidade de POC,          |  a fundação      |  anos, começando
            |  contexto de negócio         |  inteira         |  do zero

Repara que a simetria é só entre os dois primeiros. O de dados tem o rigor que falta no dev, o dev tem a produção que falta no de dados, e cada um consegue atravessar pro outro lado porque já tem metade da ponte construída. O terceiro perfil não está nessa troca, ele tem uma habilidade legítima, validar ideia rápido, mas não tem margem nenhuma da ponte.

Se você pudesse fundir os dois primeiros, aí sim, teria um engenheiro de IA sênior. Mas essa pessoa não existe em quantidade estatisticamente relevante, porque não deu tempo. O campo tem três anos. As vagas “sênior” estão sendo preenchidas por gente que é sênior em uma coluna da tabela e estagiário nas outras, eu incluso.

E os números de produção confirmam que o mercado inteiro está operando nesse regime. Os estudos de 2026 de Gartner, Forrester, McKinsey e MIT colocam a taxa de falha de iniciativas de IA agêntica entre 77% e 95%. Tem uma conta nesse material que vale decorar:,um agente com 95% de confiabilidade por passo, executando um workflow de 20 passos, entrega 36% de sucesso fim a fim (0,9⁵²⁰). Isso não é problema de modelo. É problema de gente que sabe avaliar mas não sabe operar, somada a gente que sabe operar mas não sabe avaliar, somada a gente que entregou rápido sem saber nem uma coisa nem outra.

Como cada perfil fecha o próprio gap

A regra geral é a mesma pros três, o seu plano de estudo é a coluna do vizinho, e o jeito de estudar é buscando mais responsabilidades em produção, não só em cursos.

Se você veio de dados (de novo, oi, meu chapa), o caminho é assumir a parte do sistema em vez de se voluntariar de novo pra parte da análise. Pegar o serviço que você já avalia e passar a ser dono do deploy dele. Aprender Docker, uma esteira de CI, um framework de API, e uma stack de observabilidade, não no abstrato, mas no seu serviço. Fazer o exercício de estimar custo por request antes de subir e conferir depois. E resistir à tentação de aceitar o papel de “pessoa dos evals” como identidade permanente, porque é confortável demais.

Se você veio de software, o caminho é adquirir a disciplina de medição antes de mais arquitetura. Nenhuma mudança de prompt, modelo ou pipeline sem um conjunto de avaliação rodando antes e depois, nem que sejam 50 exemplos anotados na mão, porque 50 exemplos anotados batem qualquer vibe check. Aprender o básico de estatística aplicada, tamanho de amostra, intervalo de confiança, falso positivo, no nível de quem usa, não de quem prova teorema. Ler Trustworthy Online Controlled Experiments do Kohavi dói menos do que parece e resolve metade disso.

Se você veio da automação, o primeiro passo é uma decisão, não um curso.

Decisão 1, migrar pra produto, onde sua velocidade de POC e leitura de negócio são a competência central, e parar de competir numa corrida onde você largou dez anos atrás. É uma carreira boa, e provavelmente a melhor troca de retorno por esforço disponível pra você.
Decisão 2, se quiser mesmo o caminho técnico, aceitar o tamanho real do projeto, aprender a programar, sem plataforma no meio, reimplementar em Python puro o workflow mais crítico que você mantém só pra ver o que a ferramenta escondia, e estudar a fundação (lógica, sistema, estatística básica) na ordem que os outros dois perfis estudaram.

O que eu recomendo não fazer é a não-decisão, acumular certificação de plataforma achando que está acumulando senioridade.

O que os caminhos têm em comum, nenhum deles é “aprenda o framework X”. E isso me leva pra parte provocativa do artigo.

Não é sobre ferramenta

Tem uma indústria inteira de curso, thread e bootcamp vendendo a ideia de que a diferença entre você e uma vaga de engenheiro de IA é dominar o framework da vez. LangChain em 2023, CrewAI em 2024, agora agente disso, SDK daquilo. Vagas listam frameworks como se fossem competências.

Então vamos fazer um teste. Uma implementação dumb de um agente de suporte que consulta o status de um pedido via tool, nas cinco bibliotecas mais famosas do mercado. Presta atenção no que muda de uma pra outra.

OpenAI Agents SDK

from agents import Agent, Runner, function_tool

@function_tool
def buscar_pedido(pedido_id: str) -> str:
    """Busca o status de um pedido."""
    return db.get(pedido_id)

agent = Agent(
    name="suporte",
    instructions="Você responde o status de pedidos.",
    tools=[buscar_pedido],
)
resultado = Runner.run_sync(agent, "Cadê meu pedido 123?")py

LangGraph

from langgraph.prebuilt import create_react_agent

def buscar_pedido(pedido_id: str) -> str:
    """Busca o status de um pedido."""
    return db.get(pedido_id)

agent = create_react_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[buscar_pedido],
    prompt="Você responde o status de pedidos.",
)
agent.invoke({"messages": [{"role": "user", "content": "Cadê meu pedido 123?"}]})

CrewAI

from crewai import Agent, Task, Crew
from crewai.tools import tool

@tool("buscar_pedido")
def buscar_pedido(pedido_id: str) -> str:
    """Busca o status de um pedido."""
    return db.get(pedido_id)

suporte = Agent(role="Suporte", goal="Responder o status de pedidos",
                backstory="Atendente de e-commerce.", tools=[buscar_pedido])
tarefa = Task(description="Cadê meu pedido 123?",
              expected_output="Status do pedido", agent=suporte)
Crew(agents=[suporte], tasks=[tarefa]).kickoff()

Pydantic AI

from pydantic_ai import Agent

agent = Agent("anthropic:claude-sonnet-4-5",
              system_prompt="Você responde o status de pedidos.")

@agent.tool_plain
def buscar_pedido(pedido_id: str) -> str:
    """Busca o status de um pedido."""
    return db.get(pedido_id)

resultado = agent.run_sync("Cadê meu pedido 123?")

LlamaIndex

from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.anthropic import Anthropic

def buscar_pedido(pedido_id: str) -> str:
    """Busca o status de um pedido."""
    return db.get(pedido_id)

agent = FunctionAgent(tools=[buscar_pedido], llm=Anthropic(),
                      system_prompt="Você responde o status de pedidos.")
resposta = await agent.run("Cadê meu pedido 123?")

É o mesmo programa.

Uma função com docstring, um objeto agente, um system prompt, um invoke. As diferenças são cosméticas, um decorator aqui, um backstory obrigatório ali (o CrewAI exige que você escreva ficção sobre o seu atendente, o que diz mais sobre o framework do que sobre o problema), um await pra lá. Um dev razoável migra de qualquer um pra qualquer outro em uma tarde com a documentação aberta. Por baixo, os cinco fazem exatamente a mesma coisa, montam uma lista de mensagens, descrevem a tool em JSON, chamam a mesma API de chat completion num loop de while, e fazem parse da resposta. Aliás, esse loop cru, sem framework nenhum, são umas 30 linhas de Python. Seria a sexta implementação e caberia aqui do mesmo jeito.

Agora a pergunta provocativa, se a diferença entre os cinco frameworks é o nome do import, como é que “domina LangChain” pode ser critério de senioridade? Colocar framework como requisito central de vaga de IA é como contratar escritor por marca de teclado. E o contrário é igualmente amargo, se a sua vantagem competitiva é conhecer a sintaxe de uma dessas bibliotecas, a sua vantagem competitiva é uma tarde de leitura de documentação. Isso não é um fosso, é uma poça.

O que nenhum dos cinco blocos mostra é o trabalho de verdade, e é idêntico nos cinco:

O que acontece quando buscar_pedido retorna vazio e o modelo, prestativo que é, inventa um status pro cliente?
Como você sabe que a resposta está boa? Contra qual conjunto de teste, medido como, com qual threshold de aceite?
O que acontece no timeout, no 429, no pedido que não existe, no usuário que cola um prompt injection no campo de ID?
Quanto custa cada conversa, e quem olha quando o custo dobra numa terça-feira?
Cadê o trace de cada passo quando o agente de 20 passos entrega os 36% de sucesso da conta lá de cima?

Esse trabalho não tem framework. Esse trabalho é o cargo. E repara que ele exige exatamente a fusão dos três perfis: a pergunta do eval é do pessoal de dados, a pergunta do timeout é do dev, e a pergunta “o cliente aceita receber isso?” é de quem está perto do negócio. A ferramenta é a parte que qualquer um dos três aprende na primeira semana.

Framework é o que você usa. Critério é o que você tem. Vaga que pede framework está contratando pelo que se aprende em uma tarde e ignorando o que se aprende com o tempo.

AI Enablers, o papel que não disputa a vaga

Antes do clássico entre artigos, recomendações da minha cabeça, vale abrir espaço pra um papel que ficou de fora dos três perfis de propósito, porque ele não está disputando a vaga de engenheiro de IA. E justamente por isso quase ninguém fala dele direito, o AI Enabler.

O enabler é a pessoa cujo trabalho não é construir o sistema de IA, é fazer o resto da empresa conseguir usar e construir. O mercado já formalizou variações disso, AI enablement lead, adoption specialist, gerente de treinamento de IA, o dono do “centro de excelência”. A definição de AI enablement que eu acho mais honesta é: Adoção é assinar o contrato da ferramenta, enablement é tudo que faz a ferramenta virar resultado, dado limpo alimentando, gente treinada usando, governança segurando, operação pegando o desvio.

Por que esse papel importa mais do que o título sugere? Volta no número que atravessa esse texto inteiro, 95% dos pilotos de IA generativa corporativa falham, e a causa dominante não é modelo ruim, é falta de integração com o workflow real e falta de visibilidade operacional. Lê de novo, a maior parte da falha da indústria não está na camada que o engenheiro de IA resolve. Está na camada entre o sistema e as pessoas. Essa camada é o território do enabler. Tem dado de campo mostrando o tamanho da alavanca, programas de enablement baseados em champions e casos de uso por função quase triplicaram o uso semanal de IA em 60 dias. Nenhuma melhoria de prompt entrega 3x de adoção.

O que o enabler faz, concretamente:

**Seleciona onde IA entra e, mais importante, onde não entra.**O filtro de casos de uso é a decisão de maior ROI da empresa inteira, e é uma decisão de negócio com verniz técnico, não o contrário.
**Constrói a ponte de capacidade.**Treinamento por função, champions internos, biblioteca de casos que funcionaram. É o trabalho de fazer o analista de operações resolver sozinho o que antes virava ticket.
Segura a governança sem matar a velocidade. Qual dado pode entrar no modelo, qual output precisa de revisão humana, o que a LGPD permite. O enabler ruim vira o departamento do “não”. O bom transforma a regra em trilho, não em muro.
Mede adoção como produto. Uso semanal, tempo de ciclo antes e depois, tarefa que deixou de existir. Enabler que não mede é evangelista, e evangelista sem métrica é custo.

Tem uma tese que vale pra infraestrutura de dados e vale dobrada aqui, a boa é a que some da frente das pessoas e deixa elas resolverem sozinhas. O enabler é essa tese encarnada num cargo, o valor dele não é o que ele constrói, é quantas pessoas ele destrava. O engenheiro de IA multiplica a capacidade de um sistema. O enabler multiplica a capacidade de uma organização. São alavancas diferentes, e a segunda é frequentemente maior, porque o gargalo das empresas em 2026 não é falta de modelo bom, é falta de gente que saiba encaixar o modelo no trabalho de verdade.

E aqui fecha um circuito com o terceiro perfil lá de cima. Eu fui duro com quem chegou pelas plataformas de automação querendo a vaga de engenharia, e mantenho. Mas repara, proximidade com o negócio, velocidade de POC, facilidade de mostrar valor pra não-técnico, esse é literalmente o kit do enabler.

O perfil de automação que aceita que não vai fechar o gap de engenharia rápido e migra pra enablement não está rebaixando a carreira. Está indo pro papel onde as forças dele são a competência central em vez de compensação pela fraqueza. Com um aviso, enabler de verdade precisa entender o suficiente da engenharia pra não vender milagre, e o suficiente de avaliação pra não aceitar demo como prova. Os fundamentos continuam cobrando ingresso, só que em dose menor.

O erro simétrico também existe, e eu vejo empresa cometendo, contratar enabler e cobrar dele entrega de engenharia, ou contratar engenheiro e cobrar dele adoção organizacional, ou contratar devs e pensar em projetos de ciência de dados. São papéis distintos com métricas distintas.

Recomendações da minha cabeça

O que eu levo desses pensamentos, no momento, em ordem de importância.

Pare de se descrever pela origem e comece a mapear o gap. “Sou de dados”, “sou dev”, “sou de automação” descreve seu passado, não seu valor. O mercado tem excesso do que você já é e escassez do que você ainda não é.
Estude a coluna do vizinho, em produção. Curso preenche vocabulário, não cicatriz. Quem é de dados assume um deploy. Quem é dev assume um eval. Quem é de automação reescreve um workflow sem a plataforma. Uma vez cada um já muda seu patamar de conversa.
Desconfie de qualquer senioridade autodeclarada nessa área, inclusive a sua. O cargo tem três anos. Quem se apresenta como sênior em IA é sênior em outra coisa, o que é ótimo, desde que a pessoa saiba dizer em quê. Na entrevista, pergunte “me conta o que você não sabe fazer”, quem responde rápido e específicar é quem entendeu o momento.
Ferramenta entra no rodapé do currículo, não no título. Se cinco frameworks produzem o mesmo programa com imports diferentes, listar framework como skill principal comunica que você não sabe onde mora o valor. Liste o que não comoditiza, avaliação, operação, custo, segurança, domínio de negócio.
Aproveite que a régua não existe pra construir a sua em público. É a parte boa da bagunça, como não tem sênior, o custo de entrada é o menor que vai existir. Documente o que você quebrou e consertou. Em campo sem régua, evidência pública de aprendizado vale mais que título.
Se você contrata, pareie dados com software e pare de procurar o unicórnio. A vaga de “AI Engineer sênior, 5 anos de LLM” vai continuar aberta, porque descreve uma pessoa que não existe. Um de dados e um dev, com sobreposição forçada de trabalho, cobrem hoje o que o unicórnio cobriria em 2030. Contratar fluência em plataforma como se fosse engenharia é como foi contratar “especialista em Excel” como analista financeiro, funciona até a primeira pergunta que a ferramenta não responde.

Conclusão

Engenheiro de IA sênior não existe porque senioridade é função de tempo de exposição a falha, e o campo não acumulou tempo. O que existe são três diásporas convergindo pro mesmo cargo

Os 95% de pilotos que falham não falham por falta de gente que decorou framework. Falham na fronteira entre os três perfis, no pedaço do trabalho que nenhuma das cinco bibliotecas lá de cima resolve, porque não é problema de biblioteca. Enquanto o mercado publica vaga pedindo cinco anos de experiência numa tecnologia de três, a vantagem real está com quem olha pro próprio gap sem constrangimento e atravessa pra margem que falta.

Sênior, nessa área, por enquanto, é só o júnior que sabe exatamente em que ele é júnior.

#carreira #ia-aplicada