Engenheiro de campo: a profissão mais quente da IA e como fazê-la direito

O cargo mais quente da IA tem um problema de definição

Labs, startups e fundos de private equity estão todos contratando engenheiros para trabalhar dentro da operação de seus clientes. O cargo — forward deployed engineer (FDE, ou “engenheiro de campo”) — virou o mais disputado da inteligência artificial. O problema: quase ninguém concorda sobre o que, exatamente, essa pessoa deve fazer. É engenheiro de vendas? Consultor? Rep que escreve Python?

Quem faz o alerta é Vinoo Ganesh, CEO da Kepler e uma das pessoas que ajudou a inventar a função: ele liderou o programa Project Frontline, na Palantir, que transformou cerca de 250 engenheiros de software em FDEs — muitos dos quais hoje comandam times desse tipo em OpenAI, Anthropic, xAI e Anduril. Antes disso, passou por Citadel.

Em um jantar com fellows do programa da a16z, ele percebeu que todos usavam as mesmas duas palavras para descrever empregos “que não tinham quase nada em comum”. Num extremo, um FDE era um vendedor que entrava “na segunda chamada”; no outro, um consultor com laptop e contrato de prestação de serviço.

A lição do Phoenix: por que a função existe

Ganesh conta uma história que, segundo ele, o transformou em FDE. Em 2013, na Palantir, ele trabalhou em um sistema de armazenamento transacional chamado Phoenix, “desenhado por alguns dos melhores engenheiros” que já conheceu, com especificações claras e testes perfeitos em ambientes controlados. Ao ser implantado em um banco, os dados reais tinham buracos que os dados de teste nunca tiveram: um timestamp em branco caiu no “epoch” e a lógica de retenção pediu um balde de dez minutos para cada janela entre 1º de janeiro de 1970 e o presente — cerca de 2,3 milhões de keyspaces, num sistema que precisava de cinco megabytes por file handle. O servidor estourou a memória; religá-lo exigiria 14 terabytes de RAM.

O erro não foi falta de pesquisa com usuário. “O que nunca tínhamos feito era ficar dentro do prédio enquanto o sistema rodava contra os dados de produção.” O FDE existe para cobrir exatamente essa lacuna entre o design e a realidade diária.

Coletar substantivos e verbos

Na visão de Ganesh, o trabalho central do FDE é mapear o modelo operacional do cliente — o que ele chama de “coletar substantivos e verbos”. Os substantivos são os objetos que a operação trata como reais (uma posição, uma negociação, uma contraparte); os verbos são como esses objetos se movem (como uma operação é registrada, o que precisa ser verdade para fechar os livros, quem aprova uma exceção às 23h).

“Quase nada disso está escrito — é vivido”, resume. Ele dá um exemplo concreto: por quase um ano, sua equipe tentou migrar um cliente de CSV para Parquet sem sucesso; uma engenheira de qualidade de dados bloqueava toda tentativa. Um FDE foi observar o trabalho dela e descobriu que ela baixava os CSVs, abria no Windows e “olhava as linhas” — aquela era a checagem de qualidade. O Parquet não tinha visualizador nativo. Construíram um visualizador em uma noite; a migração foi aprovada em dois dias e o pipeline caiu de 17 horas para 2.

O output precisa ser um produto

O ponto onde a maioria das funções de FDE erra, diz Ganesh, é transformar o contexto em produto — não em um cliente feliz. “Um engajamento de FDE que termina com uma conta encantada e nada mudou no produto falhou na única coisa para a qual a função existe.” Ele aprendeu isso caro: um script apelidado de “vinoo.groovy”, feito numa tarde para segurar as pontas, rodou por anos num cliente de quase 100 mil pessoas.

É aí que a coisa se divide, segundo ele. Sem uma plataforma por baixo, você mapeia o modelo de uma empresa, entrega algo sob medida e perde tudo quando o contrato acaba — “isso é consultoria, paga bem, as pessoas são excelentes, e não compõe”. Com uma plataforma por baixo, cada empresa mapeada torna o próximo deploy mais rápido e o produto mais afiado. “Essa é a diferença entre vender horas e construir um ativo.”

Onde está o fosso competitivo

Para Ganesh, o fosso dessa era não está no modelo — que fica mais barato a cada mês e é alugado de terceiros — nem no talento, já disputado a preços descobertos. “O rascunho não é o ativo. Saber quais partes dele estão erradas é o ativo, e isso só vem de ter sido corrigido.”

O fosso é o entendimento acumulado, atual e verificado de como as empresas de um setor realmente operam, mantido numa plataforma que consegue prová-lo. “Um concorrente pode contratar seus engenheiros, copiar sua interface e ler este artigo. O que ele não consegue atalhar é a sequência de estar errado dentro de um cliente, ser corrigido, dobrar a correção na plataforma e chegar na próxima empresa já sabendo quais perguntas importam.”

A recomendação prática para quem está montando a função: o FDE deve responder à área de produto, não a vendas. “Aponte a função para vendas e o incentivo vira fechar a conta da frente. Aponte para produto e cada deploy é obrigado a produzir algo que o próximo deploy pode usar como ponto de partida.”