Quando a IA testa o próprio trabalho, prova vale mais do que confiança

O agente não entrega apenas código

Em 11 de setembro de 2026, a OpenAI publicou um estudo de caso sobre o uso do GPT-6 Astra pela Cognition no Devin, seu agente de engenharia de software. O relato mostra uma mudança importante na forma de apresentar o trabalho de uma IA: o agente não apenas modifica o software, mas executa a aplicação, registra seu comportamento e produz um relatório sobre os testes realizados.

No exemplo descrito, o Devin testa um jogo em um simulador de iPhone e devolve uma gravação da execução, acompanhada por um relatório que identifica verificações concluídas e áreas que permaneceram sem teste. Em outro fluxo, uma captura de tela enviada por um cliente serve de entrada para corrigir um problema e produzir uma nova imagem que mostra o resultado.

A notícia é relevante para qualquer empresa que considere delegar tarefas a agentes. O valor não está somente na capacidade de fazer. Está na capacidade de demonstrar o que foi feito, sob quais condições e com quais lacunas. Quando a IA começa a gerar a própria evidência, a revisão humana pode mudar de natureza, mas não pode desaparecer por decreto.

Mostrar que funciona não é provar que está pronto

Uma gravação, uma captura de tela ou uma sequência de testes pode demonstrar que determinado caminho funcionou. Essa evidência é útil porque aproxima o revisor do comportamento real do produto. Ainda assim, ela não prova que todos os caminhos relevantes foram cobertos, que os dados usados representam o ambiente de produção ou que uma mudança não criou efeitos colaterais.

O relatório citado no caso da Cognition inclui tanto verificações aprovadas quanto áreas não testadas. Essa segunda parte é decisiva. Uma demonstração que exibe apenas sucesso pode gerar confiança excessiva. Uma evidência madura também declara fronteiras, pressupostos, falhas e incertezas.

Para a empresa, a pergunta deixa de ser apenas se o agente concluiu a tarefa. É preciso saber qual afirmação a evidência sustenta. Um vídeo pode comprovar que uma tela abriu. Um teste automatizado pode verificar uma regra específica. Uma comparação de resultados pode indicar equivalência em um conjunto de casos. Nenhum desses artefatos, sozinho, garante que a mudança está pronta para todas as consequências do negócio.

Critérios de aceitação precisam existir antes da execução

Se o agente define a solução, escolhe o teste e interpreta o resultado sem uma referência externa, ele pode construir uma verificação que confirma a própria interpretação do pedido. O fluxo parece completo, mas solução e prova compartilham o mesmo pressuposto equivocado.

Critérios de aceitação reduzem esse risco quando são definidos antes da implementação. Eles descrevem o comportamento esperado, as situações que devem falhar, as restrições de segurança, os dados permitidos e as condições que exigem revisão. A IA pode ajudar a detalhá-los, mas a área responsável pelo processo precisa validar se eles representam a necessidade empresarial.

Esse cuidado vale além do desenvolvimento de software. Um agente que prepara uma campanha, atualiza um cadastro ou reconcilia documentos também precisa de condições observáveis de sucesso. Quanto maior a autonomia, mais importante é separar a intenção original da evidência criada depois da execução.

O teste deve ser independente naquilo que importa

Independência não exige necessariamente outro fornecedor ou uma equipe separada para cada mudança. Exige que a verificação não dependa apenas das escolhas internas feitas durante a solução. Casos críticos podem vir de requisitos aprovados, incidentes anteriores, reclamações de clientes, regras regulatórias e exemplos mantidos por pessoas que não produziram a alteração.

A empresa pode usar o mesmo agente para executar parte dos testes e, ao mesmo tempo, preservar conjuntos de referência que ele não pode editar. Também pode reservar a aprovação para outro responsável, comparar a saída com uma versão anterior e repetir verificações em um ambiente controlado.

Em processos de maior impacto, uma segunda ferramenta ou uma revisão humana independente ajuda a identificar pontos cegos comuns. O objetivo não é desconfiar de toda automação. É impedir que a capacidade de gerar uma explicação seja confundida com a capacidade de validar a própria decisão.

Evidência útil precisa carregar contexto

Um resultado só pode ser interpretado quando sabemos o que o produziu. Versão do código, configuração, modelo, ferramentas autorizadas, dados de teste, horário, ambiente e sequência de ações formam o contexto mínimo para reproduzir uma verificação.

Sem esse registro, a empresa recebe um artefato convincente, mas frágil. Uma captura de tela pode ter vindo de uma versão diferente. Um teste pode ter ignorado uma integração real. Um relatório pode resumir corretamente uma execução que ninguém consegue repetir.

A proveniência transforma a evidência em memória operacional. Ela permite comparar versões, investigar incidentes e compreender por que uma aprovação parecia razoável naquele momento. Também facilita a auditoria sem exigir que o revisor leia toda a conversa do agente ou reconstrua decisões a partir de registros dispersos.

O NIST trata verificação como parte do ciclo

O Secure Software Development Framework do NIST organiza práticas para preparar a organização, proteger o software, produzir componentes bem protegidos e responder a vulnerabilidades. O documento recomenda revisar e analisar código, testar o software executável, verificar componentes de terceiros e registrar os resultados das verificações.

A orientação é compatível com agentes que implementam e testam, desde que a automação fortaleça o ciclo em vez de ocultá-lo. A organização continua responsável por definir requisitos, proteger ambientes, controlar alterações, conservar registros e corrigir causas de falhas.

O perfil complementar do NIST para desenvolvimento de software de IA generativa amplia esse olhar para modelos e sistemas de IA. Ele reforça que riscos surgem durante todo o ciclo de vida e que produtores e compradores precisam integrar práticas de segurança ao trabalho cotidiano, não apenas realizar uma inspeção no fim.

Ambientes de teste também precisam de limites

Um agente capaz de instalar dependências, executar aplicações e interagir com serviços precisa de acesso suficiente para testar. Esse mesmo acesso pode alcançar credenciais, dados reais ou recursos de produção se o ambiente não separar claramente experimentação e operação.

A configuração deve aplicar permissões mínimas, segredos temporários, dados sintéticos quando possível e bloqueios para ações irreversíveis. Conexões externas, criação de contas, envio de mensagens e alterações em produção merecem aprovação específica. O ambiente precisa registrar tentativas negadas, não apenas ações concluídas.

Testar de ponta a ponta não significa usar todo o sistema real. Significa representar com fidelidade as interfaces e consequências relevantes. Simuladores e serviços substitutos podem reproduzir respostas de integrações sem expor clientes ou operações. Quando um teste exige produção, o escopo deve ser pequeno, reversível e acompanhado.

A revisão humana muda de leitura para julgamento

O caso da Cognition apresenta a expectativa de reduzir a quantidade de código examinada manualmente. Esse objetivo só é sustentável se o tempo economizado for transferido para um julgamento melhor, e não apenas removido do processo.

O revisor pode concentrar atenção na coerência entre pedido, mudança e evidência. Ele observa quais riscos foram testados, por que certos caminhos ficaram de fora e se o comportamento demonstrado corresponde à experiência esperada. Em vez de percorrer cada linha, investiga pontos de decisão, permissões, dependências e consequências.

Essa mudança exige capacitação. Pessoas que aprovam trabalho de agentes precisam saber formular critérios, reconhecer evidência insuficiente e pedir uma nova execução. Também precisam entender quando a leitura detalhada do código continua indispensável, como em controles de acesso, tratamento de dados sensíveis e mudanças que alteram a fronteira de confiança.

Métricas devem distinguir atividade de confiança conquistada

Quantidade de tarefas concluídas, testes executados ou relatórios produzidos mede atividade. Para avaliar o sistema, a empresa precisa acompanhar se defeitos escapam, se testes podem ser reproduzidos, se áreas não cobertas são declaradas e se revisores encontram divergências entre a evidência e o comportamento real.

As métricas devem ser ligadas ao tipo de mudança. Uma correção visual pede evidências diferentes de uma alteração em cobrança, identidade ou autorização. O mesmo índice agregado pode esconder risco quando combina tarefas triviais e decisões sensíveis.

Uma prática simples é classificar mudanças por consequência e associar a cada classe um pacote mínimo de evidências. Quanto maior o impacto potencial, maior a exigência de independência, reprodução, aprovação e monitoramento depois da implantação. Assim, a autonomia cresce junto com a capacidade de demonstrar controle.

Um pacote de evidências torna a delegação revisável

Antes de aprovar uma mudança feita por IA, a organização pode exigir um pacote curto e padronizado. Ele inclui a solicitação original, critérios de aceitação, resumo da alteração, testes executados, resultados, gravações ou capturas relevantes, áreas não testadas, dependências modificadas e plano de reversão.

O pacote não deve virar burocracia automática. Seu tamanho acompanha a consequência. Uma alteração interna e reversível pode ter poucos itens. Uma função que movimenta recursos, publica conteúdo ou afeta dados pessoais exige mais contexto e validação.

A padronização facilita a revisão e cria histórico para melhorar os próprios testes. Quando um problema chega à produção, a equipe compara o incidente com o pacote aprovado e identifica qual pressuposto faltou. Esse aprendizado volta aos critérios de aceitação e aos casos de referência do agente.

Conclusão

O uso do GPT-6 Astra pela Cognition mostra que agentes de software estão avançando da geração de código para a demonstração do próprio trabalho. Gravações, relatórios e testes executáveis tornam a entrega mais observável e podem deslocar a revisão humana para decisões de maior valor.

Esse avanço não autoriza a empresa a aceitar qualquer evidência produzida pelo mesmo sistema que realizou a tarefa. Critérios prévios, casos independentes, proveniência, ambientes limitados e declaração explícita de lacunas são o que transforma uma demonstração em base responsável para aprovação.

Na minha visão, a maturidade da automação aparece quando o agente consegue dizer não apenas que terminou, mas exatamente o que conseguiu provar e o que ainda não sabe. A empresa que preserva essa diferença delega execução sem delegar o significado de pronto.

IA com propósito não pede confiança cega nem revisão manual de tudo. Pede evidência proporcional à consequência. Quando cada entrega vem acompanhada de escopo, contexto e limites, a autonomia deixa de ser uma promessa de velocidade e se torna uma capacidade que a organização consegue governar.