Aqui está o que aprendemos desenvolvendo capacidades de teste ponta a ponta na máquina virtual do Devin.
Há 3 meses, entrei na Cognition para ajudar a construir o futuro da engenharia de software. O Devin percorreu um longo caminho desde seu lançamento como o primeiro engenheiro de software de IA, e fiquei impressionado ao ver a equipe por trás dele usando o Devin diariamente.
Uma coisa que se destacou foi como o Devin usa seu computador para verificar o trabalho de forma autônoma na nuvem. Desde validar nossa integração com o Slack até testar funcionalidades complexas do Windsurf, a equipe sempre tem um exército de Devins em modo de teste. Neste post, vou compartilhar por que estamos tão focados na verificação de agentes ponta a ponta na nuvem e como estamos abordando sua construção.
A mudança para a engenharia de software assíncrona
Na Cognition, alcançamos recentemente um novo marco. Pela primeira vez, mais Devins estão sendo acionados de forma assíncrona, por meio de eventos, automações, agendamentos e outros Devins. Esperamos que isso continue a acelerar com nosso recente lançamento do Auto-Triage.
À medida que fazemos a transição para este mundo assíncrono, é crucial que os desenvolvedores possam retornar a resultados verificados e prontos para serem mesclados. No início deste ano, lançamos o Devin Review, uma ferramenta de revisão de código que amplia a compreensão humana de diffs de código complexos. Ela não apenas sinaliza bugs - o Devin fecha o ciclo corrigindo cada descoberta até que o diff fique limpo. Mas uma revisão limpa por si só muitas vezes não é suficiente - os engenheiros querem ver a alteração testada de ponta a ponta, da mesma forma que a testariam pessoalmente.
É uma ótima sensação quando o Devin cria um PR corrigindo uma reclamação de usuário antes mesmo de você ter a chance de ver a mensagem no canal de bugs. O que torna isso mágico é quando esse PR vem com a prova de que a correção realmente funciona. E essa magia pode em breve se tornar uma necessidade - à medida que mais PRs surgem do aumento de agentes proativos, alterações não verificadas rapidamente se tornarão ingerenciáveis.
Desde o Início
Desde o lançamento do Devin, ele sempre foi capaz de demonstrar seu trabalho em uma máquina virtual na nuvem. Cerca de 6 meses atrás, expandimos as capacidades de uso do computador do Devin. O que isso significa na prática é que adicionamos ferramentas ao harness do Devin para tirar screenshots, mover o mouse, clicar, arrastar, digitar, pressionar teclas, rolar, esperar, ampliar e iniciar/parar gravações. O uso do computador já existe há algum tempo, mas sentimos que a coorte mais recente de modelos dos laboratórios de fronteira começou a realmente ficar boa na utilização dessas ferramentas.
O uso do computador desbloqueou algumas novas capacidades divertidas para o Devin, como construir e jogar um jogo de desktop, ou usar seu navegador para pedir produtos na Amazon. Mas o verdadeiro avanço que notamos foi a capacidade do Devin de testar seu próprio trabalho. O Devin inicia o aplicativo, navega por ele e confirma que suas alterações realmente funcionam, da mesma forma que um engenheiro faria. Tudo é executado na nuvem e pode ser escalado em paralelo. Isso realmente me impactou quando vi engenheiros executando de 10 a 20 Devins em paralelo, cada um com seu próprio servidor de desenvolvimento, trabalhando em alterações – algo simplesmente impossível de fazer em um único laptop. O teste automatizado na nuvem começou a nos poupar um tempo enorme, já que não precisamos mais executar e verificar o código localmente.
Para ser honesto, chegar até aqui não foi fácil. Encontramos muitos modos de falha ao longo do caminho, e cada um nos ensinou algo sobre o que é necessário para tornar este sistema mais confiável.
Aumentando a Confiabilidade
Nas versões iniciais, era muito comum o Devin se perder durante os testes. Isso acontecia de várias maneiras: testando em excesso partes não relacionadas do produto, perdendo-se na configuração antes de chegar à funcionalidade, ou simplesmente deixando de testar o comportamento central que o PR realmente pretendia alterar.
Para resolver isso, quando o Devin entra no modo de teste, primeiro fazemos com que ele escreva um plano de teste detalhando um alvo claro sobre o que testar. Este plano deve ser baseado no código fonte, não em suposições. Sem o embasamento no código, descobrimos que os modelos tendem a assumir que podem percorrer caminhos no aplicativo que não existem. Além disso, o plano de teste aumenta enormemente a complexidade das alterações que o Devin consegue testar com sucesso. Alguns de nossos pedidos mais ambiciosos incluíam funcionalidades que exigiam vários serviços em execução, configurações específicas de administrador ativadas e os flags corretos habilitados antes mesmo que o comportamento pudesse ser acessado. Ao ler o código antecipadamente, o Devin tem muito mais chances de configurar o ambiente corretamente, em vez de descobrir algo faltando no meio do teste. O plano de teste atua como uma forma de pré-alinhamento e torna o Devin menos propenso a se desviar durante o teste ativo.
Conforme o Devin executa o plano, ele adiciona suas próprias anotações na linha do tempo. Elas incluem coisas como notas de configuração, o início de cada teste nomeado e asserções marcadas como aprovadas, reprovadas ou não testadas. Descobrimos que o Devin mentirá menos sobre suas descobertas se anotar o comportamento esperado imediatamente antes de realizar uma ação - muito parecido com o desenvolvimento orientado a testes: se você se comprometer com a expectativa antecipadamente, fica muito mais difícil racionalizar um resultado inesperado como aprovado.
Algumas partes do fluxo de teste se repetem em quase todas as execuções. Fazer login é o exemplo clássico: conduzir um formulário de login através do uso do computador geralmente significa digitar um e-mail, completar o SSO, clicar em redirecionamentos e esperar cada carregamento de página, screenshot por screenshot. Isso pode ser caro tanto em tempo quanto em tokens. Para melhorar a confiabilidade e o custo dessas ações, o Devin extraiu o trabalho para um script determinístico que reside em uma skill de teste em nosso repositório. Dessa forma, o Devin pode executar o script e obter uma sessão de navegador autenticada em segundos e pular para a parte central do teste. A natureza determinística desses scripts ajudou a diminuir drasticamente a instabilidade. Atualizamos o Devin para também fechar esse ciclo por conta própria. Quando ele descobre uma etapa de configuração da maneira mais difícil, o Devin pode sugerir salvar esse conhecimento como uma skill de teste no repositório e propor a correção de volta ao usuário como um PR de um clique.
Também estamos experimentando direcionar a fase de teste para modelos diferentes. Como o teste depende de pontos fortes diferentes da escrita de código, como ler screenshots, rastrear o estado da IU e decidir a próxima ação no navegador, alguns modelos são simplesmente melhores nisso do que aquele que você normalmente escolheria para editar código.
Usando Testes Autônomos no Devin Hoje
Atualmente, o Devin entra no modo de teste de duas maneiras: um pedido explícito para testar uma alteração, ou, após o Devin criar um PR, ele se oferece para testar a alteração, se aplicável. A partir daí, ele criará o plano de teste e começará a trabalhar.
Muitas vezes, quando você está começando a usar as capacidades de teste do Devin, ele precisará de sua ajuda. Um bom exemplo é se ele precisar de segredos ao executar seu aplicativo localmente. Para tornar esse processo mais tranquilo, o Devin pode pedir a você na sessão quaisquer credenciais ou outras informações que possam estar faltando. Para casos mais difíceis, você pode assumir o controle do computador do Devin e inserir coisas como códigos OTP. A boa notícia é que, uma vez que o Devin termina de configurar seu repositório, ele é capaz de salvar uma configuração declarativa na forma de um blueprint YAML que produz um snapshot para cada sessão futura inicializar.
O que você recebe de volta
Quando o Devin termina de testar, ele não diz apenas se o aplicativo funcionou. Uma gravação bruta da tela é útil, mas sentimos que não era suficiente por si só - você precisa entender o que está vendo, por que o Devin tomou cada ação e quais partes do teste passaram ou falharam.
Para uma revisão rápida, o Devin retorna um relatório de teste com screenshots rotuladas de momentos-chave na execução, para que você veja rapidamente o que o Devin testou e a aparência do aplicativo ao longo do caminho.
Se você quiser uma revisão mais aprofundada, o Devin também produz um vídeo de teste com uma interface de player rica que tem capítulos para permitir que você salte entre as seções de teste, percorra toda a execução e inspecione as asserções que passaram ou falharam em uma visualização de lista cronológica. No pós-processamento, o tempo ocioso entre as ações é comprimido, enquanto os momentos ao redor das ações são reproduzidos em velocidade normal. Isso faz com que uma execução longa se condense em uma gravação que você pode realmente assistir. Esses artefatos estão disponíveis em nossa interface web e também são distribuídos para o Slack se o Devin foi iniciado a partir de lá.
Limitações
O uso do computador ainda tem limitações. Um exemplo é o timing - se o Devin está testando uma notificação toast, um screenshot tirado muito cedo ou muito tarde pode perder o toast completamente, e os modelos podem ficar confusos sobre se o comportamento esperado realmente aconteceu.
Outro modo de falha é "trapacear". Deixados por conta própria, os modelos podem às vezes depender excessivamente da execução de JavaScript no navegador para acionar estados programaticamente, em vez de clicar na IU. Isso pode ser útil para testar a funcionalidade, mas os usuários geralmente querem ver o Devin exercitar o aplicativo da mesma forma que um usuário real faria.
Estamos trabalhando ativamente nesses problemas por meio de evals aprimorados, proteções mais rigorosas no harness e cada nova geração de modelos que se torna melhor no uso do computador.
O futuro do desenvolvimento assíncrono é verificado
Nos últimos meses, as execuções de teste aprovadas por dia no Devin mais que dobraram. Esse crescimento reflete algo simples: agentes assíncronos são úteis apenas se os desenvolvedores puderem confiar no que eles retornam. Muitas vezes, essa confiança não pode vir apenas do código: para muitas alterações, você quer saber se o aplicativo foi realmente executado, se os fluxos importantes foram testados e se o resultado foi capturado de uma forma que você possa inspecionar facilmente.
É para isso que serve o teste autônomo no Devin. O Devin planeja o teste, opera o aplicativo, grava e anota o que aconteceu e, finalmente, retorna artefatos que tornam o resultado revisável. Ainda há muito a melhorar, mas acreditamos que este é o formato certo para o futuro: agentes que não apenas completam o trabalho de forma assíncrona, mas retornam com provas.
Estamos constantemente surpresos com quanto tempo o Devin nos poupa ao testar seu próprio trabalho, e sentimos que muitos clientes ainda subutilizam o recurso de teste automatizado do Devin. Para apoiar a experimentação, estamos atualmente cobrando 1/5 do custo de uso normal durante o modo de teste.
Experimente nosso trabalho em devin.ai ou windsurf.com. E se trabalhar em problemas como esses parecer divertido, entre em contato com ido [at] cognition.ai
