Forward Deployed Engineer: o engenheiro que leva a IA do slide para a operação

Toda empresa que já tentou implantar inteligência artificial conhece a distância entre a demonstração impressionante e o resultado em produção.

No meio do caminho estão dados bagunçados, sistemas legados e processos que ninguém documentou. É nesse espaço que atua um profissional que ganhou enorme relevância: o Forward Deployed Engineer, ou FDE.

Um artigo de Gergely Orosz, na newsletter The Pragmatic Engineer, mergulha nessa função que a gestora a16z chamou de "o emprego mais quente da tecnologia".

Afinal, o que faz um FDE?

Em termos simples, o FDE é um engenheiro de software que alterna entre dois mundos.

Parte do tempo ele está dentro do cliente, sentado ao lado dos usuários, entendendo o problema e construindo a solução diretamente na infraestrutura dele. Na outra parte, volta para o time de produto da própria empresa e contribui com o código principal, levando para dentro aquilo que aprendeu no campo.

Essa combinação é o que diferencia o FDE de papéis parecidos, como arquiteto de soluções, engenheiro de vendas ou consultor. O consultor faz recomendações pontuais. O arquiteto de soluções costuma atuar de forma mais consultiva, montando provas de conceito com dados anonimizados. O FDE coloca a mão no código, trabalha com ambiguidade e permanece com o cliente até o impacto acontecer.

A Palantir resume bem a ideia: enquanto o desenvolvedor tradicional foca em "uma capacidade, muitos clientes", o FDE foca em "um cliente, muitas capacidades".

A origem na Palantir

A função nasceu na Palantir no início da década de 2010, com o apelido interno de "Delta". Até por volta de 2016, a empresa tinha mais FDEs do que engenheiros de software convencionais. Faz sentido: seus clientes eram governos, forças armadas e grandes corporações tradicionais, ambientes em que integrar tecnologia esbarra muito mais em burocracia do que em limitação técnica.

A estratégia foi enviar engenheiros com mentalidade de startup, cuja pergunta central era "como faço isso funcionar?" e não "por que isso não vai funcionar?". O resultado foi uma integração muito mais rápida do que os próprios clientes conseguiriam sozinhos. Quando a plataforma Foundry foi lançada, muitos desses profissionais voltaram para o produto, trazendo a experiência de campo para dentro do core.

E por que ganha tanto destaque agora?

A resposta está nos modelos de linguagem. Integrar LLMs em processos reais é difícil, cheio de variáveis e altamente dependente do contexto de cada negócio. A OpenAI criou seu time de FDEs no início de 2025, começando com dois profissionais e passando de dez em poucos meses, espalhados por Estados Unidos, Europa e Ásia.

O modelo de trabalho deles tem três fases. Primeiro, o escopo: alguns dias com o cliente, mapeando processos, identificando onde está o maior valor e prototipando com dados sintéticos. Depois, a validação: construir avaliações de qualidade, as chamadas evals, e confirmar se aquilo que foi desenhado é mesmo o mais valioso. Só então vem a entrega, sempre buscando a menor unidade possível que resolva o problema de ponta a ponta.

Um exemplo citado é o projeto com a John Deere. A equipe foi a campo, conversou com agricultores e ajudou a escalar recomendações personalizadas que antes eram feitas por telefone, dentro do prazo apertado da safra seguinte. Em outro caso, o trabalho com um cliente de call center gerou dados que melhoraram o modelo de voz da própria OpenAI, beneficiando todos os clientes.

Lições para quem lidera tecnologia

Olhando para o FDE, enxergo três lições valiosas para CIOs, CTOs e conselheiros.

A primeira é que adoção de IA não acontece por decreto nem por licença comprada. Ela acontece quando alguém com profundidade técnica senta ao lado do usuário, entende a dor real e constrói algo que funciona naquele contexto. É discovery contínuo aplicado na prática.

A segunda é que validar antes de entregar não é perda de tempo. A fase de validação da OpenAI existe porque o que o cliente descreve raramente corresponde à realidade dos dados e sistemas. Encontrar o muro cedo e ajustar o escopo é o que separa um piloto que morre de um produto que escala.

A terceira é que o conhecimento de campo precisa voltar para o produto. Sem esse ciclo, cada implantação vira um projeto artesanal. Com ele, cada cliente torna a plataforma melhor para o próximo.

Há também um alerta. A função soma papéis de consultor e engenheiro de plataforma, e saber dizer "não" a demandas paralelas faz parte do sucesso. Quem criar esse papel internamente precisa definir onde está a ênfase: vendas, sucesso do cliente ou evolução do produto.

Nem toda empresa precisa contratar FDEs, mas toda empresa que leva IA a sério precisa de pessoas com essa mentalidade. Vale olhar para o seu time e perguntar: quem hoje está, de fato, sentado ao lado do negócio transformando tecnologia em resultado? Se a resposta for ninguém, talvez seja aí que esteja o verdadeiro gargalo da sua estratégia de IA.