Quando a IA tem de filmar a sua própria revisão

Quando é aberto um pull request, meu ou de um colega que me pediu para o rever, são estas as linhas que colo no agente:

Agora vamos rever este: [adiciona o link do PR no GitHub]

Mas quero que o corras localmente E2E e vejas se está tudo a correr bem, e que faças gravações disso com o Playwright. Quero também que o ataques, que tentes parti-lo E que o testes a fundo [acrescenta aqui mais contexto, se for preciso, por exemplo tanto no âmbito pessoal como no da organização].

Depois deixo-o trabalhar: corre a mudança na minha máquina, de ponta a ponta, com o Playwright a gravar o browser à medida que avança. O Playwright é uma biblioteca de automação de browsers que o agente consegue comandar, e é capaz de filmar as páginas que abre. O que me chega é um relatório escrito, com as gravações ao lado e screenshots dos momentos que assinala.

Muita coisa mudou desde que, em julho, escrevi sobre rever a olho o código da IA, incluindo a maneira como revejo pull requests. Esta forma de rever tem-me impressionado nos últimos tempos, e acho que a maioria dos programadores ficaria surpreendida com a qualidade a que chegou.

O que disse em julho, e o que mudou

O meu argumento na altura era que, quando o agente corre o código por ti, a revisão não desaparece. Desloca-se para a prova, e o remédio que propus foi abrires tu próprio os logs e encontrares lá aquilo que o agente dizia que lá estava.

Esse remédio continua a funcionar, mas na maior parte das vezes já não preciso dele. O texto de julho também dizia que o tipo lento de revisão era correr a mudança, segui-la passo a passo e tentar parti-la, e pôr o agente a mostrar o seu trabalho. O que é novo é uma maneira de pedir tudo isso numa só mensagem e de receber o trabalho de volta numa forma que consigo verificar sem o refazer. É o agente que faz a execução, e as gravações mostram-me o que aconteceu no ecrã.

Os modelos tendem para a resposta mais rápida. Quando lhes perguntam se uma mudança funciona, preferem dizer que sim a ir verificar, e já me aconteceu ver um deles descrever logs que não existiam. Uma resposta que soa a trabalho acabado é o caminho mais curto para o fim do turno.

Não é só a minha experiência. O system card que a Anthropic publicou para o Claude Opus 4.8 enumera falhas do uso interno da própria empresa, e uma delas é quase exatamente o meu caso. O modelo disse que estava a tomar conta dos pull requests de um investigador quando não estava. A mesma lista regista-o a dar como feita uma verificação que não chegou a fazer.

Dizer a um modelo que tenha mais cuidado é um pedido, e um pedido é o que ele salta quando tem pressa. Uma gravação muda aquilo que o modelo tem de entregar.

Porque é que uma gravação é mais difícil de falsificar

Uma frase sobre o que aconteceu pode ser escrita sem que nada aconteça. Uma gravação exige que alguma coisa tenha mesmo corrido, e o que quer que tenha corrido fica no ecrã para eu julgar.

Quando o agente tem de se filmar a correr a mudança, a forma mais barata de cumprir o pedido é corrê-la a sério. Para tudo o que fica diante da câmara, deixa de haver espaço para um parágrafo confiante fazer as vezes do trabalho. Por si só, um relatório é o único relato do que aconteceu, e não consigo distinguir um teste de uma frase sobre um teste a não ser refazendo-o eu próprio. A gravação separa a frase do acontecimento. Se o agente diz que testou o formulário vazio, o formulário vazio está no vídeo ou não está. Tudo o que o relatório diz e nunca chegou à câmara volta a ser uma afirmação.

O filme mostra o que o agente tentou, e o que deixa de fora marca aquilo de que não tenho prova: o ecrã que nunca abriu, o formulário que nunca submeteu com dados inválidos, a segunda conta em que nunca iniciou sessão.

Há um segundo efeito, e importa na mesma medida. Diante da câmara, fingir que um problema não aconteceu, ou inventar um, deixa de ser um atalho seguro para o agente, porque o vídeo está lá para ser verificado. Por isso, quando encontra um, chama-me a atenção para ele em vez de o enterrar no resumo.

Raramente preciso de ver um vídeo inteiro para que isto funcione. A maior parte do efeito acontece antes de eu abrir o que quer que seja, porque é pedir o filme que põe o agente a correr a mudança. Aquilo para que olho são os screenshots dos momentos que importam, e isso inclui os sucessos. Gosto tanto de ver o fluxo terminar como deve, em cada âmbito que pedi, como de ver o erro no ecrã ou uma página que abriu para uma conta que nunca lá devia ter chegado. Por trás deles fica o vídeo, para quando um screenshot levantar uma dúvida.

O relatório passa a ser um índice da prova, que é um papel melhor para um resumo do que fazer as vezes da prova. Continuo a perguntar "isto é verdade", mas agora quem responde é um screenshot, ou, na pior das hipóteses, um pequeno trecho de vídeo, e uma parte maior do meu tempo vai para "isto importa".

Quando importa saber o que o servidor respondeu, vale a pena pedir o trace do Playwright além do vídeo. O vídeo são os píxeis. Um trace guarda, para cada ação, um snapshot da página antes e depois, com os pedidos de rede, os corpos das respostas e a consola do browser. Se o agente disser que o servidor respondeu com um 403, a resposta está no trace.

O Playwright MCP da Microsoft, uma das ferramentas que permitem a um agente comandar um browser, trabalha sobre a árvore de acessibilidade da página, uma vista estruturada dela em texto, e não sobre os píxeis. O filme é para mim, e é por isso que é útil: o agente age sobre uma vista em texto da página, e o filme mostra-me os píxeis para os quais ele não estava a olhar, sem a narração dele por cima. Mesmo assim, pode escolher que take me entrega, ou continuar a correr um fluxo até ele sair verde, por isso vale a pena pedir todas as gravações que fez, incluindo os takes falhados.

Ataca-o, e testa-o

O prompt pede duas coisas que puxam em sentidos diferentes, e de propósito.

Um modelo a quem se pede que confirme tende a confirmar. O "vejas se está tudo a correr bem" convida-o a procurar o que está a correr bem, por isso percorre o caminho para que a funcionalidade foi construída, vê o ecrã esperado e declara sucesso. Vale a pena ter essa execução em vídeo, porque um resultado positivo sem prova por trás é exatamente a afirmação de que o texto de julho mandava desconfiar. Mas só cobre o caso que o autor já tinha em mente.

Pede-lhe que parta a coisa e tem de ir procurar noutro lado: um campo obrigatório deixado em branco, o botão de submeter clicado duas vezes, a mesma página aberta em dois separadores, o ID na barra de endereço trocado por um que pertence a outra pessoa, o botão de retroceder premido a meio de um fluxo. Os bugs costumam esconder-se em sítios assim.

Um agente a quem só se diz para partir coisas tem o problema oposto. Pode passar a sessão inteira num único caso-limite engenhoso e nunca confirmar que o fluxo normal, aquele por onde passam todos os utilizadores, continua a funcionar de ponta a ponta. Quero a visita guiada ao fluxo normal e a investida contra ele na mesma execução, e é por isso que o E está em maiúscula.

As duas instruções também resultam melhor em vídeo do que num relatório escrito. Uma frase como "tentei parti-lo e não consegui" não me diz nada sobre o quanto se esforçou, e a gravação das tentativas diz-me muito. Consigo ver se forçou o formulário uma vez e passou à frente, ou se voltou com outra conta ou com outra ordem de passos. Os ataques que falharam fazem parte da prova de que a mudança aguenta.

A linha que só eu posso escrever

A última parte do prompt é um espaço por preencher que muda a cada pull request. É aí que digo ao agente onde está o risco.

O meu exemplo é "tanto no âmbito pessoal como no da organização". Quando uma funcionalidade tem de se comportar bem numa conta pessoal e dentro de uma organização, a maior parte do que pode correr mal está na junção entre as duas: algo que pertence a um âmbito a aparecer no outro, ou uma página que funciona para o dono e falha para um membro. O agente consegue ler o diff e tentar adivinhá-lo. Não sabe que caminhos os utilizadores percorrem de facto, nem que erro seria embaraçoso e qual seria grave. Eu sei, porque conheço o produto e sei o que quero que ele faça.

O que vai entre parênteses retos é a minha parte da revisão. Tira o agente daquilo que o diff sugere e leva-o para aquilo que sei que pode sair danificado, e a gravação mostra-me se ele foi mesmo lá.

O que o filme não mostra

O filme tem limites.

É o agente que escolhe o que filmar: os caminhos que percorre e, consoante as ferramentas, quando a gravação começa e acaba. Se o âmbito da organização que pedi não estiver na gravação, não tenho prova de que tenha sido testado, diga o relatório o que disser.

Tudo o que o Playwright grava acontece no browser. Os logs do servidor, os registos na base de dados e a tarefa em segundo plano que corre um minuto depois não estão nem no vídeo nem no trace. Um ecrã pode ficar verde por cima de um registo escrito na conta errada. Pode faltar uma verificação de autorização no servidor enquanto a interface esconde o botão na perfeição diante da câmara, e a API por trás continuaria a aceitar o pedido de qualquer pessoa que o enviasse diretamente.

É aqui que a metade do prompt que pede o ataque mostra o que vale. Um vídeo do caso feliz nunca toca nessa verificação, ao passo que um vídeo do agente a abrir um registo que pertence a outra conta, ou a enviar o pedido com o botão escondido, toca. Em tudo o que mexa com acessos, vale a pena nomear esse ataque na linha de contexto. Quando a mudança chega à base de dados ou ao servidor, as queries e os logs da mesma execução têm o seu lugar ao lado da gravação, guardados onde o relatório possa apontar para eles.

Uma gravação também pode parecer certa pela razão errada. Se o agente pôs um stub no lugar do backend para conseguir carregar a página, a gravação é uma gravação do stub. O prompt pede uma execução local e de ponta a ponta, e saber com o que é que a app estava de facto a falar vem antes de tudo o que ela mostrou. Os pedidos de rede no trace respondem a isso.

Uma nota prática: um vídeo do Playwright só é escrito em disco quando o contexto do browser fecha. Se o agente disser que gravou a execução e o ficheiro não existir ou estiver vazio, isso também é prova.

Dentro desses limites, o filme é o tipo lento de revisão de que falei em julho, com o agente a fazer a execução e o juízo a ficar comigo.

A decisão continua a ser minha

Os modelos melhoraram muito desde que escrevi o texto de julho, e a prova que tenho disso são as minhas próprias revisões. O que noto é que, quando o agente tem de correr a coisa e filmá-la, e alguma coisa se parte, ele di-lo, e eu posso vê-lo por mim próprio. E também não acredito na melhoria só por ele o dizer.

Os programadores que só conheceram a revisão por IA como um bot a deixar comentários num diff viram a versão mais pequena dela. Isto está mais perto de um tester sentado à minha máquina que cortaria caminho se eu deixasse, a usar a mudança como um utilizador a usaria, a tentar parti-la e a deixar a gravação para eu ver onde é que cortou caminho.

Ler o código continua a importar, e a gravação cobre aquilo a que a leitura não chega: o comportamento da coisa quando corre. Não é de graça. Uma execução demora mais do que uma leitura, a app precisa de dados com que valha a pena testar, e alguém continua a ter de olhar para o que volta.

Nada disto põe o agente no lugar de quem revê. Ele faz o trabalho pesado. Continuo a ser eu, no fim, a decidir o que está certo e o que quero. Quando a gravação mostra um fluxo que funciona mas não é o que o produto devia fazer, o agente não tem como saber isso, e quando assinala como bug um comportamento intencional, cabe-me a mim dizê-lo.

O texto de julho terminava na linha entre o diff que compreendeste e o diff que apenas viste. As gravações tornam mais barato chegar ao lado compreendido dessa linha. Não preciso de assistir a todas as execuções do princípio ao fim, só de ver os momentos que importam e de saber que caminhos a gravação cobre. O que mudou é que agora ponho a máquina a filmar o seu trabalho, e por isso a minha atenção vai menos para saber se fez o que disse e mais para saber se procurou nos sítios certos. Só consigo julgar isso porque sei para que serve o produto, e quando procura nos sítios errados, envio mais uma linha de contexto e peço-lhe que corra a mudança outra vez.