OpenAI revela como funciona o time de FDEs: 90% do código customizado foi substituído por skills do Codex

A OpenAI publicou uma análise de como trabalham os seus forward deployed engineers (FDEs). O time foi montado no início de 2025 para resolver um problema específico: o modelo, em teoria, sabe fazer muita coisa, mas as pessoas ainda não conseguem apoiar o fluxo de trabalho nele. Esse é o «deployment gap». O balanço de quatro projetos: de 3 a 6 meses até a produção em semicondutores, +50% de produtividade para contadores de impostos, salto de um modelo de voz de 60% para mais de 90% nos principais evals e cerca de 90% do código customizado descartado após o lançamento do Codex.

O lema do time é: comece pelo resultado, faça o que for preciso para dar certo e escale depois. Igor Akimov, autor do canal AI Product, observa que os fornecedores falam em coro sobre modelos superinteligentes, mas faltam implantações por vertical. Na avaliação dele, hoje os tokens são queimados principalmente por startups com dinheiro de terceiros. Os FDEs trabalham justamente onde essa lacuna precisa ser fechada na mão.

Chips, impostos e telecom: quatro casos com números

• Engenharia de semicondutores, meados de 2025. Cerca de 15 FDEs trabalharam em mais de 10 casos de uso: geração de testes, busca de causas de falhas e um assistente de arquitetura. A verificação consome cerca de 70% do esforço de um projeto no setor. Parte dos engenheiros chegou à OpenAI poucos dias antes do início e não entendia de chips. Eles sentaram com os engenheiros do cliente, estudaram a área e construíram as métricas em conjunto. Em 3 a 6 meses, todos os casos de uso chegaram à produção. Resultado: cerca de 48% de economia de tempo na geração de testes, ganho mediano de 22% de desempenho na otimização de kernels, e semanas de depuração viraram horas.
• Migração para o Codex. Quando o Codex amadureceu, todos os casos de uso foram transferidos para uma estrutura comum, com ele no centro. Os aplicativos customizados viraram plugins e skills, e as CLIs e interfaces próprias foram descartadas. Em cada projeto, cerca de 90% do código customizado foi embora. Em um dos casos, a primeira implantação levou 2 meses; a expansão para uma segunda equipe, 1 dia.
• IA fiscal para escritórios de contabilidade da Thrive Holdings. No piloto, foram processadas 7 000 declarações, e a produtividade subiu cerca de 50%. As mais difíceis foram as declarações de operações imobiliárias: foram 6 semanas de engenharia e revisões por profissionais da área para chegar a 90% de precision e recall.
• Voz para telecom. A voz responde por cerca de 90% dos atendimentos de suporte. O modelo marcava cerca de 60% nos principais evals, o que não basta para produção. O time de Research entrou no projeto: em 6 meses elevou o resultado a 80% e, depois, a mais de 90%. Esse modelo de voz agora também atende outros clientes.

Código customizado dura seis meses

Do ponto de vista da engenharia, a parte mais interessante é a história do Codex. Os projetos eram construídos sobre aplicativos, CLIs e interfaces feitos sob medida: cada cliente tinha o seu conjunto de ferramentas. Assim que a plataforma aprendeu a assumir a orquestração, tudo isso virou plugins e skills. A diferença entre 2 meses na primeira implantação e 1 dia na expansão mostra onde o custo se acumula. Quanto menos código exclusivo houver no projeto, mais barato fica cada novo cliente ou equipe.

Há também uma mudança de arquitetura. Segundo Akimov, a OpenAI abandonou o esquema multiagente em favor de um único agente com skills. Foi exatamente isso que a Anthropic recomendava. As duas maiores laboratórios chegam ao mesmo padrão: um agente mais um conjunto de habilidades plugáveis.

Para a economia dos tokens, a conclusão é direta. Enquanto cresce a camada de lógica própria em torno do modelo, crescem também o custo de manutenção e o risco de que, em seis meses, a plataforma passe a oferecer a mesma coisa de fábrica. O time adotou isso como princípio de trabalho: o critério de sucesso de um FDE é se tornar desnecessário a cada par de meses. Quando o Codex passou a montar de uma vez o que os engenheiros levavam meses para construir, a pergunta «o que fazer?» ganhou uma resposta simples: procurar um problema mais difícil.

O que o integrador deve levar

Há três ativos duradouros: o conhecimento do domínio, os datasets e métricas construídos junto com os especialistas do cliente e a compreensão de onde o modelo não dá conta. O caso fiscal confirma isso: o que levou a 90% de precision e recall nas operações imobiliárias não foram features, e sim seis semanas de revisão por profissionais. O caso de voz mostra o mesmo por outro ângulo: a passagem de 60% para mais de 90% exigiu trazer o Research. Para o gestor de produto e para o integrador, daí decorrem passos práticos:

• começar por evals e métricas acordadas com os especialistas do cliente, e não pela interface;
• construir a solução sobre primitivas da plataforma (skills, plugins), e não sobre CLIs próprias;
• manter um único agente com skills até que a abordagem multiagente prove sua necessidade nas métricas;
• prever que a estrutura em torno do modelo terá de ser reescrita a cada poucos meses.

Para os desenvolvedores que temem que o Codex tire o seu trabalho, esta análise traz uma resposta: o valor se desloca para a formulação de problemas e a medição de qualidade. Foi isso que fizeram as pessoas que, uma semana antes do início do projeto de chips, não sabiam nada sobre chips.