A Microsoft publicou em 16 de setembro de 2026 um alerta direto para equipes que medem agentes de programação: uma avaliação só é tão confiável quanto o sandbox onde ela acontece. No texto técnico, a empresa argumenta que um agente pode parecer competente quando, na prática, apenas teve acesso a informação que não deveria estar disponível no teste.
Esse ponto é importante porque benchmarks de agentes não medem apenas geração de código. Eles medem busca, leitura de arquivos, uso de ferramentas, execução de comandos e capacidade de corrigir erros. Se o ambiente vaza a solução, o histórico do problema ou pistas fora do escopo, o resultado passa a medir contaminação de contexto.
O que a avaliação deve provar
A pergunta central não é se os agentes de programação chegaram ao resultado esperado. A pergunta é o que o teste realmente provou. Um benchmark pode medir habilidade de editar código em um repositório desconhecido, resolver falhas de teste, seguir uma especificação, diagnosticar regressões ou operar com restrições de segurança. Cada objetivo exige fronteiras diferentes.
Se o agente consegue consultar materiais que contêm a resposta, o teste deixa de medir raciocínio ou navegação autônoma. Se o ambiente permite acessar arquivos fora do escopo, o resultado pode depender de dados que um desenvolvedor real não teria. Se comandos têm permissões amplas demais, a avaliação pode ignorar riscos operacionais relevantes.
A Microsoft defende começar pela definição do que se quer medir. Depois disso, o sandbox precisa impor o conjunto mínimo de arquivos, ferramentas, rede, permissões e logs necessários para aquela medição. Em avaliações sérias, o ambiente é parte do experimento, não apenas infraestrutura.
O risco de números bonitos
O mercado tende a comparar agentes por taxa de sucesso, tempo até solução e custo por tarefa. Esses números ajudam, mas podem esconder diferenças fundamentais. Um agente que resolve mais tarefas em um sandbox permissivo pode ser menos confiável que outro testado em um ambiente mais restrito e auditável.
Para times de engenharia, isso vale também dentro de casa. Avaliar agentes de programação em repositórios reais exige controlar quais branches, issues, documentos e logs entram no contexto. Também exige separar tarefas usadas em treinamento, exemplos internos e validação final. Caso contrário, a equipe pode aprovar uma ferramenta que performa bem apenas porque reconhece padrões vistos antes.
Como aplicar em times reais
Um bom desenho de avaliação deve registrar a tarefa, o estado inicial do repositório, comandos permitidos, acesso à rede, variáveis de ambiente, arquivos disponíveis e critérios de aprovação. Também precisa guardar logs suficientes para auditoria sem expor segredos.
Essa disciplina reduz duas falhas comuns. A primeira é acreditar em uma métrica que não representa o trabalho real. A segunda é liberar agentes com permissões amplas demais antes de entender o impacto em código, dependências e dados sensíveis.
O recado da Microsoft é pragmático: agentes de programação podem ser úteis, mas só devem ser comparados em ambientes desenhados para provar a capacidade certa. Sem sandbox bem definido, a avaliação pode confirmar confiança onde havia apenas vazamento de informação.
