Cognition Aposta que os Testes do Devin GPT-6 Astra Podem Substituir a Revisão de Código por Evidências

A Cognition expandiu os testes do Devin GPT-6 Astra para três produtos, transformando a verificação no mais recente campo de disputa da engenharia de software autônoma. O modelo agora oferece suporte a testes dentro do Devin Cloud, Devin Desktop e Devin CLI. Ele pode operar aplicações, inspecionar resultados e devolver evidências visuais junto a relatórios escritos.

A mudança importante não é que o Devin consegue gerar mais código. Agentes de programação já produzem patches, abrem pull requests e executam suítes de testes. A Cognition agora quer que o Devin apresente evidências de que suas alterações funcionam, reduzindo o quanto os engenheiros precisam inspecionar manualmente o código gerado.

Essa promessa pressiona o desenvolvimento tradicional centrado na revisão. Ela também levanta uma questão difícil para a Cognition, a OpenAI e todos os agentes de programação concorrentes. Um agente pode avaliar de forma confiável o trabalho produzido pelo mesmo sistema automatizado, ou a atenção humana apenas migra da revisão de código para a revisão de evidências?

Os Testes do Devin GPT-6 Astra Agora Produzem Evidências Revisáveis

A Cognition está posicionando as evidências de teste, e não apenas a geração de código, como a entrega que os engenheiros devem avaliar.

A OpenAI publicou seu caso de testes do Devin em 11 de setembro de 2026. A empresa afirma que a Cognition está aplicando o GPT-6 Astra em seu agente de nuvem, interface de linha de comando e aplicação desktop.

A Cognition já havia adicionado o Astra ao Devin em 3 de setembro. Seu lançamento do modelo afirma que o Astra está disponível diretamente no Devin Desktop e no Devin CLI. O modelo também faz parte da combinação de modelos usada pelo Devin Cloud.

A integração separa duas tarefas que produtos de programação frequentemente apresentam como um fluxo de trabalho contínuo. Um modelo pode implementar uma alteração, enquanto o Astra pode ajudar a conduzir a fase de testes. Essa distinção importa porque editar código e validar uma aplicação exigem capacidades diferentes.

Um modelo de programação raciocina principalmente sobre repositórios, especificações e alterações no código-fonte. Um testador de aplicações também precisa interpretar telas, acompanhar o estado da interface, operar software e reconhecer se o comportamento observado corresponde ao resultado pretendido.

A Cognition afirma que o Astra tem desempenho particularmente bom nesse segundo conjunto de tarefas. A empresa relata resultados de ponta em um benchmark interno de testes. Ela não publicou detalhes suficientes para que terceiros reproduzam ou verifiquem de forma independente esse resultado específico.

Os exemplos públicos esclarecem o que a Cognition entende por verificação autônoma. Em uma demonstração, o Devin testa Otter Run, um jogo para iPhone, dentro de um simulador. Ele devolve uma gravação do jogo em execução e um relatório que descreve quais verificações foram aprovadas.

O relatório também identifica áreas que o Devin não testou. Essa ressalva é importante porque um vídeo bem produzido poderia sugerir uma cobertura mais ampla do que a execução realmente alcançou.

A gravação mostra comportamentos observáveis, enquanto o relatório define o escopo alegado. Juntos, eles dão ao revisor algo mais próximo de um artefato de teste do que de um resumo convencional produzido por agente.

Outro fluxo de trabalho começa com uma captura de tela de um bug fornecida pelo cliente. A Cognition afirma que a equipe pode enviar essa imagem ao Devin, que diagnostica o problema, altera o código e devolve outra captura de tela mostrando o resultado.

A sequência conecta um defeito visível a um resultado visível. Ela pode encurtar o ciclo de feedback para problemas de interface difíceis de explicar apenas por logs ou comentários em pull requests.

No entanto, uma captura de tela prova apenas o que apareceu em um momento específico. Ela não estabelece que caminhos relacionados ainda funcionam, que a implementação subjacente é sustentável ou que o defeito permanece corrigido sob condições diferentes.

Portanto, o recurso mais útil é o pacote de evidências. Os engenheiros podem comparar o comportamento solicitado, o plano de testes declarado, as ações registradas e quaisquer áreas não testadas antes de decidir se fazem o merge.

Isso altera a unidade de revisão. Em vez de receber apenas um diff e uma garantia escrita pelo agente, o engenheiro recebe uma afirmação sustentada por um rastreio de execução.

Essa mudança cria a aposta central da Cognition. Se os revisores confiarem no rastreio, poderão gastar menos tempo reconstruindo o que aconteceu a partir do código gerado. Se não confiarem, os artefatos adicionais se tornam outra camada que exige inspeção.

Por Que a Verificação se Tornou o Gargalo dos Agentes de Programação

O recurso limitante no desenvolvimento com agentes está migrando da produção de código para a capacidade de revisão confiável.

Agentes de programação podem criar alterações mais rapidamente do que a maioria das equipes consegue avaliá-las. Quando vários agentes operam simultaneamente, cada sessão bem-sucedida pode gerar outra branch, pull request, relatório de teste ou decisão de acompanhamento.

A Cognition afirma que seus próprios engenheiros executaram entre 10 e 20 sessões do Devin em paralelo. Cada sessão pode operar um servidor de desenvolvimento separado na nuvem. Esse grau de concorrência seria pouco prático no laptop de um único engenheiro.

Mais concorrência não cria automaticamente mais valor em produção. Em vez disso, ela pode gerar uma fila de alterações plausíveis aguardando verificação humana.

Essa fila é especialmente difícil porque código gerado pode parecer razoável antes de falhar em execução. Um revisor pode precisar reconstruir o ambiente, executar a aplicação, repetir o fluxo relatado e examinar comportamentos próximos.

A Cognition descreveu esse desafio como parte de uma mudança mais ampla rumo ao desenvolvimento assíncrono. Atualmente, mais sessões do Devin são acionadas por agendamentos, automações, eventos e outras instâncias do Devin do que por solicitações interativas diretas.

Um agente de programação assíncrono trabalha enquanto seu responsável humano se dedica a outra coisa. O arranjo só economiza atenção quando o resultado devolvido é compreensível e suficientemente confiável.

Sem verificação, os engenheiros retornam a uma pilha de diffs sem explicação. Eles precisam recuperar o contexto de cada tarefa antes de decidir se o trabalho é útil.

O relato anterior da Cognition sobre verificação por agentes afirma que execuções diárias de testes aprovadas mais que dobraram ao longo de vários meses. Trata-se de atividade de produto reportada pela empresa, não de uma medida independente de confiabilidade ou valor para o cliente.

Ainda assim, a direção faz sentido. À medida que agentes geram mais alterações, as equipes precisam de evidências compactas que indiquem quais resultados merecem atenção.

O objetivo não é eliminar imediatamente o julgamento humano. É tornar esse julgamento menos custoso ao aproximar observações relevantes da tarefa concluída.

Um pacote de evidências útil pode responder a várias perguntas antes que um engenheiro leia a implementação. A aplicação iniciou corretamente? O recurso alterado apareceu? Qual caminho de usuário o agente percorreu? O que ficou fora do teste?

Essas perguntas costumam ser mais valiosas do que a afirmação de um agente de que todos os testes passaram. Uma suíte de testes convencional avalia apenas as asserções que alguém antecipou e codificou.

Gravações de interface podem revelar mudanças de estado que nunca foram representadas em testes unitários. Notas de escopo escritas também podem expor cobertura ausente, em vez de escondê-la em um longo log de execução.

A pressão vai além da Cognition. O Codex da OpenAI, sistemas de programação apoiados pela Anthropic, agentes para desenvolvedores do Google, Cursor e frameworks de código aberto disputam todos as cargas de trabalho de engenharia.

Cada produto pode melhorar sua pontuação em geração de código. No entanto, a adoção empresarial depende do que acontece após a geração, quando uma pessoa responsável precisa aprovar uma alteração consequente.

É por isso que o principal adversário não é um modelo rival. É o fluxo de trabalho centrado na revisão, construído em torno da leitura de cada linha relevante antes de confiar no resultado.

Esse fluxo de trabalho existe por bons motivos. O código comunica arquitetura, custos futuros de manutenção, premissas de segurança e comportamento em caso de falha que uma demonstração curta talvez nunca revele.

A Cognition não afirma que essas preocupações desaparecem. Seu objetivo declarado é fazer com que os engenheiros examinem menos código ao longo do tempo, enquanto entregam mais trabalho concluído.

Essa formulação deixa espaço para revisão seletiva. As equipes podem inspecionar módulos de alto risco de perto, aceitando ao mesmo tempo revisões orientadas por evidências para correções restritas de interface, migrações rotineiras ou ferramentas internas bem delimitadas.

O efeito prático dependerá de quão bem as equipes preservam o contexto das tarefas. Uma base de conhecimento de engenharia pode ajudar revisores a conectar as evidências de um agente a requisitos, decisões de design e falhas anteriores.

A verificação se torna mais valiosa quando reflete essas fontes. Uma gravação limpa significa menos quando o agente entendeu erroneamente o requisito que definia o sucesso.

Astra Transforma Testes em uma Habilidade Separada de Agente

A contribuição do Astra vem da combinação de uso do computador, julgamento visual, raciocínio sobre a base de código e relatórios concisos em um único ciclo de testes.

Um modelo de uso do computador interpreta uma interface visual e realiza ações como clicar, digitar, rolar e navegar entre telas. Os testes acrescentam outra exigência: essas ações precisam sustentar afirmações explícitas sobre o comportamento esperado.

O ciclo de testes da Cognition começa com um plano fundamentado no repositório. O agente examina o código relevante antes de declarar o que testará. Isso reduz a chance de ele inventar caminhos de interface ou premissas não sustentadas pela aplicação.

O plano também cria um ponto de referência para o relatório final. Os revisores podem ver se a execução cobriu o comportamento pretendido, em vez de julgar uma gravação sem critérios declarados.

Durante a execução, o Devin pode anotar a linha do tempo com notas de configuração e etapas nomeadas de teste. Ele pode marcar asserções como aprovadas, reprovadas ou não testadas.

A Cognition afirma que exigir que o agente declare uma expectativa antes de agir reduz a racionalização. O agente tem menos liberdade para reinterpretar uma tela inesperada como sucesso após ver o resultado.

Isso se assemelha ao desenvolvimento orientado por testes, no qual o comportamento esperado é definido antes da implementação. Aqui, o compromisso ocorre durante a verificação comportamental, em vez de antes de cada alteração no código.

O agente pode então operar um navegador, simulador ou aplicação desktop. Ele captura o que aconteceu e devolve artefatos que um humano pode inspecionar de forma assíncrona.

O Astra parece adequado a essa etapa porque o modelo foi treinado para uso do computador e tarefas profissionais longas, com múltiplas etapas. A OpenAI afirma que ele pode instalar software, solucionar problemas visíveis e executar verificações de qualidade de frontend.

Nos resultados de uso do computador publicados pela OpenAI, o Astra obteve 72,6% no OSWorld 2.0. O GPT-5.6 Sol obteve 65,7% na comparação reportada.

A OpenAI também afirma que o Astra concluiu essas tarefas simuladas em cerca de 40 minutos, em média. O modelo anterior exigiu aproximadamente 75 minutos. Esses números vêm da configuração de avaliação da OpenAI e não devem ser tratados como medições universais de produção.

O mesmo lançamento relata uma pontuação de 57,9% para o Astra no Terminal-Bench 4.0. O GPT-5.6 Sol recebeu 37,3%, enquanto o Claude Fable 5.1 recebeu 55,8%.

No FrontierCode 1.1 Extended, o Astra obteve 64,5%. O Claude Fable 5 obteve 64,9%, deixando o Astra ligeiramente atrás desse modelo no benchmark da Cognition.

A Cognition descreve o FrontierCode como uma avaliação proprietária de tarefas reais de engenharia. Sua pontuação considera qualidade e capacidade de merge, e soluções que não atendem a critérios bloqueadores não recebem crédito.

Essas comparações sugerem que o apelo do Astra não se resume a um desempenho bruto superior em programação. A declaração pública da Cognition enfatiza relatórios mais claros, testes mais abrangentes e vídeos mais fáceis de acompanhar.

Essas qualidades afetam diretamente o tempo de revisão. Uma execução tecnicamente bem-sucedida ainda pode desperdiçar a atenção humana se suas evidências forem confusas, prolixas ou desconectadas da alteração solicitada.

Um relatório conciso deve identificar o comportamento testado, o ambiente, o resultado observado e a incerteza restante. Uma gravação útil deve tornar fáceis de localizar as transições importantes, em vez de obrigar um revisor a percorrer uma sessão sem edição.

A Cognition também criou scripts determinísticos para trabalhos repetidos de configuração. Um script determinístico executa uma sequência definida, em vez de pedir que o modelo improvise cada ação.

A autenticação é um exemplo. Conduzir um fluxo de login por meio de capturas de tela pode consumir tempo e introduzir falhas não relacionadas ao recurso testado.

Um script salvo pode criar rapidamente uma sessão autenticada no navegador. O agente pode então concentrar seu raciocínio no comportamento que importa.

Esse design híbrido revela uma importante lição de engenharia. Testes autônomos melhores não significam atribuir todas as operações a um modelo de linguagem.

Sistemas confiáveis reservam etapas previsíveis para a automação convencional. Eles usam o modelo onde interpretação, recuperação ou navegação flexível agregam valor.

A Cognition também permite que Devin proponha habilidades de teste reutilizáveis após resolver um problema difícil de configuração. O usuário pode revisar essa automação antes de adicioná-la ao repositório.

Com o tempo, isso pode transformar descobertas repetidas em infraestrutura estável. O caminho improvisado pelo modelo torna-se um script revisado para execuções futuras.

A combinação também controla a variabilidade. Se cada teste começa com um comportamento de configuração diferente, comparar resultados se torna difícil e diagnosticar falhas fica caro.

Astra fornece percepção e raciocínio flexíveis. Scripts determinísticos restringem ações repetitivas. O plano de teste define o sucesso, enquanto o relatório de evidências expõe o que a execução cobriu.

Esse mecanismo é mais relevante do que outra liderança em benchmarks. Ele delineia como agentes de programação podem deixar de produzir correções plausíveis e passar a participar de fluxos de engenharia controlados.

O Agente Ainda Não Pode Corrigir Sua Própria Prova Sozinho

As evidências podem reduzir o esforço de revisão, mas não podem tornar a autoverificação independente, completa ou automaticamente confiável.

O risco mais claro é a falha correlacionada. Se um agente interpreta mal a tarefa durante a implementação, o mesmo sistema pode levar esse mal-entendido para seu plano de teste.

O código e o teste podem então concordar entre si, enquanto ambos divergem do requisito real do usuário. Um relatório limpo documentaria consistência, não correção.

Testes independentes reduzem esse problema quando vêm de especificações, de outro engenheiro ou de um sistema de avaliação separado. Suítes de regressão existentes também oferecem restrições que o agente de implementação não inventou durante a sessão.

A abordagem da Cognition ajuda ao fundamentar os planos no código-fonte e declarar expectativas antes de cada ação. Essas medidas podem reduzir desvios, mas não criam independência real.

A empresa descreveu abertamente falhas anteriores. Às vezes, Devin testava áreas não relacionadas, ficava preso na configuração do ambiente ou não detectava o comportamento que uma pull request pretendia alterar.

Esses problemas explicam por que o sistema precisa de planos, anotações e ferramentas de configuração determinísticas. Eles também mostram que evidências refinadas dependem de uma orquestração que vai além do modelo subjacente.

A prova visual tem limites adicionais. Um vídeo pode mostrar que um fluxo funcionou em um ambiente e estado de dados específicos. Ele não pode estabelecer ampla correção em navegadores, permissões, condições de carga ou entradas maliciosas.

Um relatório pode identificar com precisão essas lacunas como não testadas. Os revisores ainda precisam decidir se os caminhos omitidos importam o bastante para bloquear a implantação.

A cobertura torna-se especialmente importante para alterações de backend, infraestrutura e segurança. Muitas falhas graves não produzem um sintoma visual óbvio durante uma execução curta.

Uma migração de banco de dados pode parecer bem-sucedida antes de corromper um caso de borda. Uma alteração de permissão pode funcionar para a conta demonstrada enquanto expõe dados de outro tenant.

Código sensível à segurança exige pensamento adversarial, não apenas a confirmação de que o comportamento esperado ocorreu. As equipes precisam de testes projetados para quebrar premissas, em vez de apenas reproduzir o caminho feliz.

A própria OpenAI aplica restrições às capacidades avançadas de cibersegurança do Astra. O modelo pode ajudar com revisão segura e correção de código, enquanto alguns fluxos de trabalho relacionados a exploits permanecem limitados ou monitorados.

A cobertura independente sobre o lançamento do Astra também destacou questões de segurança ainda não resolvidas em torno de trabalhos autônomos complexos. A confiabilidade no mundo real permanece menos certa do que as demonstrações controladas sugerem.

A qualidade de software apresenta um desafio de longo prazo. Passar nos testes de hoje não mostra se alterações repetidas feitas por agentes deixam uma base de código compreensível e adaptável.

Uma análise crítica dos limites dos benchmarks de programação argumenta que os testes atuais frequentemente deixam de captar a erosão estrutural. O código pode continuar funcional enquanto se torna mais difícil de modificar com segurança.

Essa preocupação limita diretamente a proposta de “revisar menos código”. Engenheiros leem código por mais do que correção imediata. Eles examinam abstrações, limites de responsabilidade, lógica duplicada, observabilidade e custo futuro de manutenção.

Um vídeo de execução não pode revelar todas essas qualidades. Tampouco um relatório focado no comportamento visível.

A política de revisão adequada provavelmente dependerá do risco. Um ajuste visual em um dashboard interno merece um escrutínio diferente de lógica de autenticação, processamento de pagamentos ou infraestrutura crítica para a segurança.

As equipes podem definir barreiras de merge que combinam tipos de evidência. Uma alteração de baixo risco pode exigir uma suíte aprovada, um fluxo de usuário gravado e um relatório completo de escopo.

Uma alteração de maior risco também pode exigir revisão humana de design, testes de segurança independentes e inspeção manual de arquivos sensíveis. As evidências do agente podem apoiar esses controles sem substituí-los.

Outra questão é a integridade das evidências. Os revisores precisam confiar que as gravações correspondem ao commit enviado, ao ambiente, à configuração e aos dados de teste.

Se os artefatos puderem se desvincular do código exato sob revisão, poderão descrever uma compilação anterior ou configurada de forma diferente. Uma proveniência robusta deve conectar cada afirmação ao seu estado de execução.

A Cognition não detalhou publicamente todos os controles de proveniência por trás do fluxo de trabalho destacado. Seu benchmark interno também continua proprietário, limitando a comparação entre laboratórios independentes.

Portanto, a alegação do benchmark deve ser interpretada como um sinal de produto, não como uma medida consolidada da qualidade de testes autônomos.

Até mesmo os resultados públicos da OpenAI medem tarefas delimitadas. Repositórios de produção contêm premissas não documentadas, dependências instáveis, serviços privados e regras de lançamento específicas de cada organização.

O Astra pode melhorar a capacidade do agente de navegar essa complexidade. Ele não elimina a necessidade de julgamento de engenharia sobre quais evidências são suficientes.

A distinção central está entre prova e evidência. Na prática comum de engenharia de software, os testes fornecem evidências de que comportamentos selecionados funcionaram sob condições definidas.

Raramente eles provam a correção total. A linguagem pública da Cognition às vezes usa “provar” de modo coloquial, mas as equipes devem manter a interpretação mais restrita da engenharia.

Essa cautela não torna o recurso menos importante. Ela define onde o recurso pode gerar valor sem incentivar uma confiança insegura.

Três Sinais Mostrarão Se os Engenheiros Podem Revisar Menos Código

O próximo teste é saber se a Cognition consegue converter demonstrações mais fortes em adoção mensurável e consciente de riscos entre equipes de produção.

O primeiro sinal é a reprodutibilidade independente. A Cognition deve publicar detalhes suficientes sobre seu benchmark de testes para que pessoas externas entendam a seleção de tarefas, a pontuação, o roteamento de modelos e o tratamento de falhas.

Resultados reproduzíveis reforçariam a alegação de que o Astra melhora os testes, em vez de apenas produzir artefatos com aparência melhor. Eles também mostrariam com que frequência o sistema relata falhas ou cobertura incompleta com honestidade.

A qualidade das evidências deve ser avaliada separadamente da conclusão da tarefa. Um agente de testes pode chegar ao resultado certo e ainda fornecer um relatório inutilizável, ou criar documentação persuasiva para um teste incompleto.

Medições úteis poderiam incluir precisão das asserções, defeitos não detectados, falsos positivos, calibração de cobertura e tempo do revisor. Elas também deveriam acompanhar se os revisores tomam a decisão correta de merge.

Se avaliações independentes confirmarem melhorias nessas dimensões, o fluxo de revisão reduzida da Cognition ganhará credibilidade. Se os resultados variarem acentuadamente entre repositórios, as equipes precisarão de regras de implantação mais restritas.

O segundo sinal é o comportamento em produção. A Cognition afirma que as execuções diárias de testes aprovadas aumentaram, mas o volume de aprovações por si só não comprova software melhor nem menor custo de revisão.

Os indicadores mais sólidos são alterações integradas, taxas de defeitos que escapam para produção, frequência de reversões e tempo gasto na revisão de cada contribuição aceita. As equipes devem comparar esses resultados com alterações semelhantes tratadas por meio de revisão convencional.

A Cognition já explorou “horas produtivas de engenharia” como métrica de negócio. Sua avaliação usou 233 sessões reservadas e relatou que cerca de metade ficou dentro de um fator de dois em relação às estimativas humanas.

A empresa também reconheceu que as estimativas individuais continuam ruidosas. Erros de duas ou três vezes para qualquer direção são comuns, segundo sua análise publicada.

Essa franqueza importa porque alegações de produtividade podem se desconectar dos resultados de software. Uma estimativa de horas economizadas não captura o custo de um defeito descoberto após a implantação.

A evidência mais convincente conectaria a redução do tempo de revisão a uma qualidade estável ou em melhoria. Se as equipes inspecionarem menos código, mas enfrentarem mais regressões, o fluxo de trabalho apenas transfere o custo para etapas posteriores.

Se o tempo de revisão cair sem piorar defeitos, reversões ou manutenção, a tese central da Cognition se torna muito mais forte.

O terceiro sinal é como os concorrentes redesenham a verificação. Provedores de modelos e empresas de agentes de programação podem responder com agentes revisores independentes, rastros de execução mais robustos ou formatos padronizados de evidência.

Uma resposta competitiva significativa confirmaria que a verificação se tornou a principal camada do produto. Ela também ofereceria aos compradores alternativas para evitar que um agente avalie sua própria produção.

Modelos separados de implementação e revisão podem introduzir diversidade útil. Diferentes provedores, prompts ou sistemas de geração de testes têm menor probabilidade de reproduzir exatamente o mesmo mal-entendido.

No entanto, a diversidade de modelos, por si só, não garante independência. Dois agentes ainda podem depender da mesma especificação incompleta ou da mesma suíte de testes existente.

Os melhores sistemas combinarão design de testes independente, controles determinísticos, proveniência de artefatos e políticas explícitas de risco. A revisão humana poderá então se concentrar em decisões que a automação não pode comprimir com segurança.

Líderes de engenharia devem começar selecionando tarefas delimitadas em que o comportamento observável reflita fortemente o sucesso. Correções de bugs de interface, fluxos internos rotineiros e regressões bem especificadas são candidatos sensatos.

Eles devem exigir que Devin declare o que não testou. Também devem comparar suas evidências com o commit enviado e manter os controles normais para alterações sensíveis.

Os desenvolvedores podem usar o novo fluxo de trabalho como um filtro de atenção, e não como uma autoridade. O relatório indica onde olhar, a gravação mostra o que aconteceu, e o código permanece disponível quando o risco exige inspeção.

O resultado que a Cognition busca é plausível, mas não automático. Melhores testes podem reduzir o esforço de revisão apenas quando as evidências permanecem fundamentadas, delimitadas e conectadas aos resultados em produção.

A pergunta mais importante para as equipes é, portanto, prática: quais mudanças podem ser aprovadas com base em evidências de execução e quais ainda exigem a leitura de cada linha consequencial? Teste esse limite deliberadamente antes de tornar os testes do Devin GPT-6 Astra parte do seu processo padrão de merge.