Grande parte dos testes de agentes de inteligência artificial começa com uma premissa confortável: o problema já está bem descrito, os arquivos relevantes estão disponíveis e o objetivo pode ser medido por uma resposta correta ou por um conjunto de testes automatizados. O mundo real raramente oferece esse cenário. Em uma empresa, o pedido pode chegar como “o processo está lento”, “os clientes estão abandonando” ou “precisamos de um painel melhor”. Antes de escrever código, alguém precisa descobrir o que essas frases realmente significam.
É justamente essa distância entre resolver uma tarefa e entregar uma solução que o FDE-Gym tenta medir. Apresentado em um artigo recente, o benchmark reúne 95 tarefas de entrega ponta a ponta, baseadas em 20 cenários de clientes de 18 setores. Os agentes precisam conversar com stakeholders, investigar sistemas semelhantes aos de produção, esclarecer requisitos ambíguos e implementar mudanças que melhorem uma métrica definida pelo próprio cliente.
O problema não termina quando o código funciona
Benchmarks tradicionais de agentes de programação costumam partir de uma descrição estruturada: um relatório de erro, uma especificação técnica ou um cartão de tarefa. O agente recebe um objetivo relativamente estável, modifica um repositório e é avaliado por testes, compilação ou comparação com uma solução de referência. Esse formato é valioso para medir capacidade de programação, mas deixa de fora uma parte enorme do trabalho profissional.
Em projetos reais, o requisito inicial frequentemente está incompleto. Um cliente pode pedir um sistema de agendamento sem mencionar que determinados horários devem ser reservados para emergências. Pode solicitar um relatório sem explicar quais decisões serão tomadas a partir dele. Pode afirmar que quer mais velocidade quando, na verdade, o gargalo mais caro está na quantidade de retrabalho gerada por informações inconsistentes.
O engenheiro de campo, conhecido pela sigla FDE, precisa transformar uma reclamação em uma definição operacional do problema. Para isso, faz perguntas, identifica restrições, consulta usuários e observa como o sistema é utilizado. A qualidade da entrega depende tanto dessa investigação quanto da implementação técnica.
O FDE-Gym coloca essa camada de descoberta dentro do ambiente de avaliação. Em vez de premiar apenas uma resposta tecnicamente correta, o benchmark observa se o agente consegue produzir uma melhoria concreta para o cliente. A pergunta deixa de ser “o código passou nos testes?” e passa a incluir “o sistema agora ajuda a organização a alcançar seu objetivo?”.
Como funciona uma entrega mais próxima da realidade
Os cenários do FDE-Gym simulam ambientes de clientes e incluem stakeholders com quem o agente pode interagir. Também há sistemas modificáveis, dados operacionais e uma métrica de sucesso associada à situação. O agente não recebe necessariamente todas as informações de que precisa no início. Ele tem de decidir o que investigar, quem consultar e quando já possui evidências suficientes para agir.
Essa estrutura cria uma sequência de decisões que benchmarks convencionais normalmente separam ou ignoram. Primeiro, o agente interpreta a demanda inicial. Depois, formula perguntas. Em seguida, examina o sistema existente, identifica limitações, escolhe uma estratégia de intervenção e executa mudanças. Por fim, precisa verificar se a solução realmente alterou o resultado relevante.
A avaliação usa uma pontuação normalizada entre zero e um. Zero representa um sistema que permaneceu essencialmente inalterado; um representa o desempenho de uma solução de referência. Há também penalidades relacionadas às interações com stakeholders, às tentativas de execução e ao uso de recursos. Isso é importante porque um agente pode aumentar suas chances de acerto fazendo perguntas indefinidamente, testando inúmeras alternativas ou transferindo o custo da investigação para o cliente.
O desenho do teste tenta capturar uma realidade conhecida por qualquer equipe de tecnologia: uma solução pode estar correta em termos locais e ainda assim ser ruim para o negócio. Uma alteração que passa nos testes automatizados, mas piora o tempo de atendimento, confunde os operadores ou não respeita uma regra comercial crítica, não é uma entrega bem-sucedida.
O que esse benchmark revela sobre agentes
O FDE-Gym desloca a discussão sobre agentes de “quanto código eles conseguem gerar” para “quanto valor conseguem entregar sob incerteza”. Essa mudança parece pequena, mas altera profundamente o tipo de comportamento que deve ser treinado.
Um agente competente precisa saber reconhecer quando não entendeu o pedido. Deve distinguir uma informação importante de uma preferência secundária. Também precisa resistir à tentação de modificar o sistema imediatamente, antes de conhecer os critérios de sucesso. Em muitas situações, a melhor ação inicial não é escrever uma função, mas formular uma pergunta precisa.
Outro ponto relevante é a gestão de contexto. O agente precisa combinar informações vindas de conversas, documentação, código, dados e observação do sistema. Esses sinais podem ser incompletos ou contraditórios. Um stakeholder pode descrever um fluxo ideal, enquanto os registros mostram um comportamento diferente. A entrega exige reconciliar essas fontes, não apenas copiar a última instrução recebida.
Há ainda o problema da validação. Um agente pode afirmar que resolveu a causa de uma falha porque uma tela foi alterada ou porque uma consulta ficou mais rápida. Mas a métrica do cliente talvez não tenha melhorado. A avaliação orientada ao resultado força o sistema a verificar consequências, medir efeitos e corrigir o plano quando a primeira hipótese não se confirma.
Esse tipo de capacidade também é central para agentes que atuam em operações, análise de dados, suporte e administração de sistemas. O trabalho não é uma sequência de comandos independentes. É um processo de diagnóstico, negociação, execução e aprendizado.
O impacto para empresas brasileiras
Para empresas brasileiras, a proposta é especialmente relevante porque muitos projetos de tecnologia começam com requisitos informais e sistemas legados. Processos importantes podem depender de planilhas, mensagens, integrações frágeis e regras que nunca foram documentadas. Um agente treinado apenas para cumprir especificações formais terá dificuldade para operar nesse ambiente.
Imagine uma rede de clínicas que pede uma ferramenta para reduzir faltas. O problema pode parecer simples: enviar lembretes automáticos. Porém, a solução adequada talvez dependa de segmentar pacientes, compreender políticas de confirmação, respeitar diferentes canais de contato e separar consultas que exigem preparação prévia. Uma implementação rápida pode gerar mais mensagens, mas não necessariamente mais comparecimentos.
O mesmo ocorre em uma indústria que quer reduzir atrasos de manutenção. O agente precisaria conversar com equipes, entender prioridades, verificar a qualidade dos registros e descobrir se o problema está na programação, na disponibilidade de peças ou na comunicação entre turnos. O código é apenas uma parte da solução.
Esse cenário sugere uma oportunidade para consultorias, integradores e departamentos de tecnologia. Em vez de vender agentes como geradores automáticos de software, será mais útil posicioná-los como sistemas de entrega supervisionada. Eles podem investigar, propor hipóteses, executar tarefas repetitivas e apresentar evidências, enquanto profissionais humanos preservam decisões de alto impacto.
Também há uma lição para a adoção interna. Antes de medir quantos chamados um agente consegue responder, uma organização deveria definir qual resultado deseja melhorar: tempo de resolução, conversão, disponibilidade, margem, satisfação ou redução de retrabalho. Sem essa métrica, a automação corre o risco de produzir atividade sem produzir valor.
Os limites de medir o mundo real em uma simulação
Um benchmark mais realista não é automaticamente um retrato perfeito da realidade. O FDE-Gym depende de cenários simulados, stakeholders roteirizados e sistemas preparados para a avaliação. Pessoas reais podem ser mais imprevisíveis, fornecer informações incompletas por razões políticas e mudar de opinião ao longo do projeto. Sistemas de produção também carregam riscos que uma simulação não consegue reproduzir integralmente.
Existe ainda a possibilidade de um agente aprender padrões específicos do benchmark. Se os cenários, métricas e formas de interação forem conhecidos, o sistema pode otimizar para a avaliação sem desenvolver uma competência geral de entrega. Por isso, será importante testar agentes em setores, culturas organizacionais e arquiteturas diferentes, além de verificar se suas decisões continuam explicáveis e auditáveis.
A métrica também exige cuidado. Uma melhoria numérica pode esconder custos humanos, riscos de segurança ou dependências frágeis. Uma solução que reduz o tempo de atendimento, mas aumenta reclamações ou cria exposição de dados, não deveria ser considerada um sucesso. O resultado empresarial precisa ser combinado com critérios de confiabilidade, privacidade e manutenção.
Da automação de tarefas à responsabilidade pela entrega
O valor do FDE-Gym está em tornar visível uma parte do trabalho que a indústria de IA frequentemente deixa implícita. Entregar software não é apenas transformar instruções em código. É entender uma situação, descobrir o que está faltando, escolher uma intervenção proporcional e verificar se ela melhorou a vida de alguém.
Essa visão também muda o papel do profissional humano. Em vez de revisar cada linha produzida por um agente, equipes podem concentrar sua atenção na formulação do problema, na definição de métricas, na aprovação de mudanças sensíveis e na análise das consequências. A supervisão deixa de ser uma inspeção puramente técnica e passa a ser uma responsabilidade sobre o resultado.
O próximo salto dos agentes talvez não seja escrever programas mais longos. Pode ser aprender a fazer perguntas melhores antes de escrever qualquer programa. Quando uma IA consegue entender que o pedido inicial é apenas um sintoma, investigar o contexto e conectar sua ação a uma métrica real, ela deixa de ser somente uma ferramenta de produção. Começa a participar do processo de descoberta.
Mas essa participação precisa ter limites claros. Um agente que atua em sistemas empresariais deve registrar suas hipóteses, declarar incertezas, explicar por que escolheu determinado caminho e permitir intervenção humana. A capacidade de agir no mundo real só será valiosa se vier acompanhada da capacidade de prestar contas.