O que aprendemos ao criar 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 fico impressionado ao ver a equipe por trás dele usando o Devin todos os dias.
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 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 ponta a ponta com agentes na nuvem e como estamos abordando sua construção.
A mudança para engenharia de software assíncrona
Na Cognition, recentemente atingimos 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 voltar 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. Ele não apenas sinaliza bugs - o Devin fecha o ciclo corrigindo cada descoberta até que o diff esteja limpo. Mas uma revisão limpa sozinha muitas vezes não é suficiente - os engenheiros querem ver a mudança testada de ponta a ponta, da mesma forma que a testariam eles mesmos.
É 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 mágica pode em breve se tornar uma necessidade - à medida que mais PRs surgem do aumento de agentes proativos, mudanças não verificadas rapidamente se tornarão incontrolá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ção. 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 se sair bem 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 se 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 nas alterações – algo que simplesmente não é possível fazer em um único laptop. O teste automatizado em nuvem começou a nos poupar uma quantidade enorme de tempo, já que não precisamos mais executar e verificar o código localmente.
Para ser honesto, chegar até aqui não foi tranquilo. 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 primeiras versões, era muito comum o Devin se desviar durante os testes. Isso acontecia de várias maneiras: testando excessivamente partes não relacionadas do produto, perdendo-se na configuração antes de alcançar a funcionalidade, ou simplesmente deixando de testar o comportamento central que o PR deveria 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 fundamentado no código-fonte, não em suposições. Sem o embasamento no código, descobrimos que os modelos tendem a assumir que podem seguir caminhos no aplicativo que não existem. Além disso, o plano de teste aumenta enormemente a complexidade das alterações que o Devin pode 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 as flags corretas habilitadas antes mesmo do comportamento estar acessível. 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.
À medida que o Devin trabalha através do plano, ele adiciona suas próprias anotações na linha do tempo. Estas 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 seu comportamento esperado imediatamente antes de realizar uma ação - muito parecido com o desenvolvimento orientado a testes, se você assumir o compromisso com a expectativa antecipadamente, fica muito mais difícil racionalizar um resultado inesperado como uma aprovação.
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 através de redirecionamentos e esperar em 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. Desta 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 este 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 encaminhar 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 UI e decidir a próxima ação no navegador, alguns modelos são simplesmente melhores nisso do que o típico modelo que você 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 oferecerá 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 assistência. Um bom exemplo é se ele precisar de segredos ao executar seu aplicativo localmente. Para tornar esse processo mais suave, 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 iniciar.
O que você recebe de volta
Quando o Devin termina o teste, ele não apenas informa se o aplicativo funcionou. Uma gravação de tela bruta é ú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 retornará um relatório de teste com screenshots legendadas de momentos-chave na execução, para que você possa ver rapidamente o que o Devin testou e como o aplicativo estava 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 possui capítulos para permitir que você salte entre as seções de teste, percorra a execução completa 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á.
Arestas difíceis
O uso do computador ainda tem arestas difíceis. 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 é a trapaça. Deixados por conta própria, os modelos podem às vezes confiar demais na execução de JavaScript no navegador para acionar estados programaticamente, em vez de clicar através da IU. Isso pode ser útil para testar a funcionalidade, mas os usuários geralmente querem ver o Devin exercitar o aplicativo da maneira que um usuário real faria.
Estamos trabalhando ativamente nesses problemas por meio de evals aprimorados, guardrails mais rigorosos 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, o número de execuções de teste aprovadas por dia no Devin mais que dobrou. Esse crescimento reflete algo simples: agentes assíncronos só são úteis se os desenvolvedores puderem confiar no que eles trazem de volta. Muitas vezes, essa confiança não pode vir apenas do código: para muitas alterações, você quer saber que o aplicativo foi realmente executado, os fluxos importantes foram exercitados e o resultado foi capturado de uma forma que você possa inspecionar facilmente.
É isso que o teste autônomo no Devin foi projetado para fornecer. 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 concluem o trabalho de forma assíncrona, mas voltam com provas.
Estamos constantemente surpresos com o quanto de tempo o Devin nos poupa ao testar seu próprio trabalho, e sentimos que muitos clientes ainda subutilizam a funcionalidade de teste automatizado do Devin. Para apoiar a experimentação, estamos atualmente cobrando 1/5 do custo normal de uso enquanto estiver no modo de teste.
Experimente nosso trabalho em devin.ai ou windsurf.com. E se trabalhar em problemas como estes parece divertido, entre em contato com ido [at] cognition.ai
