FDE sem improviso: o harness que transforma a missão do cliente em produto verificável

Forward Deployed Engineering reduz a distância entre um problema real e um sistema em produção. Essa proximidade, porém, não elimina arquitetura. Ela aumenta a necessidade de um contrato que preserve intenção, autoridade, evidência e aprendizado enquanto o contexto do cliente muda.

Sem esse contrato, o FDE vira um herói local: conhece tudo, corrige tudo e deixa para trás uma variante que ninguém mais consegue operar. Com um harness explícito, a missão vira uma sequência verificável de decisões e o caso particular devolve capacidade reutilizável à plataforma.

Resumo executivo

O papel do FDE pode ser descrito por um loop:

missão → descoberta → spec → build → evals/controles → produção → adoção
   ↑                                                               ↓
   └──────────── evidência, feedback e padrão reutilizável ─────────┘

O harness não é um framework de interface nem uma coleção de prompts. É o sistema ao redor do modelo que liga objetivo, contexto, ferramentas, identidade, políticas, verificadores, receipts e autoridade de aceite.

1. A missão precisa virar contrato executável

“Melhorar atendimento” ou “automatizar análise” não define o que pode ser executado. Antes do build, registre:

• outcome e população afetada;
• baseline e sinal de aceite;
• dados e sistemas autorizados;
• ações permitidas e proibidas;
• owner do problema e autoridade de release;
• condições de parada, escalada e rollback.

Esse contrato separa descoberta de autorização. Compreender uma dor não concede acesso a todos os dados nem permissão para alterar produção.

2. Descoberta deve produzir artefatos, não apenas entendimento tácito

O FDE observa o workflow, entrevista pessoas e encontra exceções. Se esse conhecimento permanecer em conversas ou na memória de uma pessoa, ele não sobreviverá à sessão. Transforme a descoberta em mapa de estado, exemplos, glossário, decisões e casos de avaliação.

As descrições públicas da OpenAI reúnem discovery, scoping, system design, build e rollout na função de FDE. A leitura técnica correta não é abolir especialidades. É preservar a continuidade entre o que foi observado e o que será construído, sem perder os gates de segurança e operação.

3. A spec controla a divergência

O primeiro produto da descoberta é uma spec curta e testável:

A spec não precisa prever tudo. Precisa tornar visível o que mudou, quem decidiu e qual evidência autoriza o próximo passo.

4. Build com IA continua sendo engenharia

Um modelo pode gerar código, consultas, interfaces e configurações. O harness decide quais ferramentas existem, quais credenciais podem ser usadas, em qual sandbox a ação ocorre e qual saída pode atravessar a fronteira para um ambiente real.

O FDE deve conseguir alterar o produto e também recusar um atalho. Velocidade local não justifica identidade compartilhada, segredo em contexto, acesso de rede irrestrito ou deploy sem rollback. A proximidade do cliente aumenta a consequência de uma ação errada.

5. Evals e controles precisam representar o workflow

Benchmarks genéricos ajudam a escolher candidatos. O gate de produção precisa usar tarefas, dados sanitizados, exceções e critérios do contexto real. Organize a evidência em camadas:

1. contratos determinísticos para schema, autorização e invariantes;
2. integração seletiva para ferramentas, identidade e ambiente;
3. evals por classe de tarefa, com graders e revisão de falhas;
4. ensaios de abuso, indisponibilidade e recuperação;
5. aceite humano identificado para efeitos relevantes.

Um pass sem versão, caso, verificador e origem não é evidência portátil. O receipt precisa permitir reconstruir o que foi pedido, executado, observado e aceito. [R3-C2]

6. Produção é uma fronteira, não uma cerimônia

Antes do rollout, o sistema precisa declarar identidade, ambientes, limites de custo e tempo, observabilidade, suporte, interrupção e rollback. “Human in the loop” não basta: o humano precisa saber quando participa, que informação recebe e que decisão pode tomar.

O deploy inicial deve ser limitado por população, volume ou classe de caso. A ampliação depende de qualidade, adoção e operação observadas, não apenas de ausência de incidente visível.

7. Adoção também produz evidência

Uso não é outcome. Meça se as pessoas incorporaram a solução ao workflow, se a qualidade permaneceu aceitável e se o custo por resultado correto melhorou. Registre rejeições, overrides e caminhos paralelos: eles revelam onde a descoberta ou o design estavam incompletos.

O DORA trata IA como amplificadora do sistema sociotécnico existente e associa foco no usuário a melhor desempenho organizacional. Isso não prova causalidade para uma implementação. Sustenta a disciplina de não separar engenharia de feedback real.

8. O caso precisa melhorar a plataforma

Palantir descreve forward deployment como uma forma de manter engenheiros perto dos problemas e devolver aprendizado à engenharia central. A Cohere acrescenta uma condição de saída: construir capacidade no cliente, não dependência do FDE.

Ao encerrar um ciclo, classifique o que foi aprendido:

• específico: regra legítima daquele domínio;
• configurável: variação que deve virar policy ou parâmetro;
• reutilizável: componente, ferramenta ou eval para outros casos;
• estrutural: mudança de arquitetura ou roadmap;
• descartável: experimento que não deve sobreviver.

Sem essa triagem, cada cliente vira fork. Com ela, o próximo ciclo começa com mais capacidade e menos improviso.

O receipt mínimo de forward deployment

mission: outcome + owner + baseline
spec: version + scope + acceptance
execution: identity + environment + tools + limits
verification: cases + graders + controls + result
release: approver + artifact + rollback
adoption: population + usage + quality + exceptions
learning: decision + reusable_asset + owner

Esse documento não precisa conter dados sensíveis. Deve conter referências, hashes e identificadores suficientes para que uma pessoa autorizada reconstrua a decisão.

Sinais de que o modelo está falhando

• o mesmo FDE precisa estar presente para toda alteração;
• exceções viram código específico sem taxonomia;
• evals são demonstrações escolhidas depois do resultado;
• produção usa mais autoridade que o piloto;
• feedback chega por conversas e não altera casos, specs ou roadmap;
• cliente não consegue operar ou avaliar sem o fornecedor;
• velocidade é medida até a demo, não até outcome aceito.

Fontes diretas e limites

1. OpenAI — Forward Deployed Engineer-seattle-seattle/).
2. OpenAI — Forward Deployed Software Engineer.
3. Anthropic e DXC — aliança e formação de FDEs.
4. Palantir — Architecture Center.
5. Cohere — FDEs should build capability, not dependency.
6. DORA — State of AI-assisted Software Development 2025.
7. DORA — User-centric focus.

As fontes corporativas descrevem funções e métodos declarados por seus autores; não provam resultado universal nem tornam FDE um cargo padronizado. O loop, a spec, o receipt e os sinais de falha são síntese técnica da FORGE, não standard de mercado.

Nota editorial e de responsabilidade

Este artigo é informativo. Não substitui avaliação de arquitetura, segurança, privacidade, trabalho ou contratação. Trustyu e Tech Human atuam comercialmente em arquitetura, governança e engenharia de IA. Pesquisa, estrutura e redação tiveram assistência de IA; Fernando Parreiras responde pela tese, revisão factual e autorização de publicação. Não houve revisão humana independente adicional.