A morte da revisão de código: o que os dados realmente dizem — Laurie Voss, Arize AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The Death of the Code Review: What the Data Actually Says — Laurie Voss, Arize AI · Canal: AI Engineer · 23:58 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Segurança de IA

Resumo

O aumento da geração de código por agentes tornou a revisão humana um gargalo: em um estudo com mais de 100 mil desenvolvedores, o uso de agentes autônomos elevou o código produzido em 741%, mas o software entregue, em apenas 30%. A palestra examina limites de revisões humanas em grande escala, benchmarks que vão além de testes aprovados e ferramentas que automatizam a revisão. Experimentos mostram que tirar pessoas da análise direta não elimina a revisão: transfere o trabalho para a construção de testes, critérios e sistemas de avaliação, que também precisam de supervisão. A recomendação final é investir menos tempo revisando PRs linha por linha e mais em criar um harness de revisão confiável, com critérios claros, contexto da empresa e evals.

Pontos-chave

Agentes podem produzir muito mais código sem aumentar na mesma proporção o software que chega à produção; a revisão é um dos gargalos.
A capacidade humana de revisar código não escala simplesmente com mais esforço: estudos citados apontam queda de eficácia acima de certos volumes de leitura.
Testes aprovados não bastam para determinar se uma mudança é segura, sustentável e adequada para merge.
Benchmarks de mergeabilidade podem influenciar diretamente o treinamento e o comportamento futuro dos modelos.
Revisores automatizados usam múltiplas passagens e filtragem de falsos positivos; alguns também geram correções para os problemas que encontram.
Experimentos sem revisão humana ainda dependem de sistemas, testes e critérios construídos por pessoas, e podem deixar riscos não cobertos pelos testes.
A revisão humana tende a migrar da leitura direta do código para o desenho e a supervisão dos sistemas que avaliam o código.
Prompt injection e mensagens de commit enganosas podem manipular revisores automatizados, o que torna necessária a revisão dos próprios sistemas de revisão.
A observabilidade do comportamento em produção ganha importância quando mais código é aprovado automaticamente.
A recomendação prática é codificar critérios de qualidade, contexto de domínio e conhecimento da empresa em um harness de revisão confiável.

Capítulos

Início	Capítulo	Resumo
00:01	A revisão de código como novo gargalo	Laurie Voss apresenta o aumento da produção de código por agentes e a diferença entre código escrito e software efetivamente entregue.
02:36	Por que revisar mais não resolve	A palestra cita migrações de código em grande escala e estudos que mostram os limites de revisão humana intensiva.
04:41	Revisão automatizada e critérios de mergeabilidade	A palestrante compara a revisão por agentes com a avaliação humana e argumenta que passar nos testes não garante uma alteração pronta para merge.
10:54	Ferramentas de revisão em produção	São apresentados serviços de revisão automatizada, técnicas para reduzir falsos positivos e sistemas que também propõem correções.
15:06	O que acontece quando humanos saem do loop	Experimentos de compiladores e migrações mostram que testes automatizados podem ajudar, mas não cobrem todos os riscos e dependem de critérios humanos.
18:44	Os limites da automação e a revisão em produção	A palestra aborda experiências malsucedidas sem leitura humana, riscos de prompt injection e a importância de observar o comportamento em produção.
22:24	A recomendação: construir um sistema de revisão	Voss conclui que a revisão não desapareceu, mas que equipes devem transferir o julgamento humano para a criação e a supervisão de sistemas confiáveis.

Citações

Produzir código ficou muito mais barato de repente. Saber se podemos confiar nele continua muito caro. — 02:05

Não confie no código por padrão. Presuma que há algo errado com ele. — 12:58

Eu estava errado. Por favor, leiam o código. — 18:44

As equipes que vencerem os próximos anos não serão as que gerarem mais código, mas as que conseguirem explicar, com evidências, por que confiam no que entregaram. — 22:56

Parem de revisar PRs. Esse é o nível de abstração errado para 2026. — 23:28

Conceitos e entidades

Laurie Voss (pessoa): Palestrante e responsável por relações com desenvolvedores na Arize AI.
Arize AI (empresa): Empresa de IA mencionada como a organização em que Laurie Voss trabalha.
code review (conceito): Processo de avaliar alterações de código antes de integrá-las ou enviá-las à produção.
mergeability (conceito): Qualidade de uma alteração que determina se ela está realmente pronta para ser integrada, além de simplesmente passar nos testes.
SWE-bench (benchmark): Benchmark citado para avaliar tarefas de engenharia de software por meio de pull requests e testes.
FrontierCode (benchmark): Benchmark apresentado como uma tentativa de avaliar alterações segundo critérios de revisão humana, incluindo regressões, segurança e manutenção.
Cursor (ferramenta): Produto de desenvolvimento com IA cuja arquitetura de revisão de código é discutida na palestra.
GitHub Copilot code review (ferramenta): Recurso de revisão de código do GitHub Copilot, citado como um serviço amplamente usado.
CodeRabbit (empresa): Empresa que oferece um revisor automatizado de pull requests.
OpenClaw (ferramenta): Projeto cujo criador, Peter Steinberger, é citado ao defender que se projetem os ciclos de trabalho dos agentes.
Bun (ferramenta): Runtime cuja migração de Zig para Rust é citada como exemplo de trabalho realizado por agentes.
Codex (ferramenta): Sistema da OpenAI descrito como capaz de revisar suas próprias alterações e executar o código para verificar correções.
CriticGPT (modelo): Modelo da OpenAI citado como ferramenta para identificar bugs em código escrito por modelos.
prompt injection (conceito): Ataque que tenta manipular um sistema de IA por meio de instruções inseridas no conteúdo que ele processa.
harness de revisão (conceito): Sistema de testes, regras, contexto e evals que organiza e verifica a revisão automatizada de código.

Tradução completa (pt-BR)

00:01 [música] Olá, pessoal. Obrigada por acompanharem uma sessão sobre a morte da revisão de código com outra sessão sobre a morte da revisão de código. Quem sabe como essas decisões são tomadas, mas a Swix decidiu que seria engraçado colocar as duas em sequência. Oi. Sou Lori. Sou chefe de relações com desenvolvedores na Arize AI.

00:32 Alguns de vocês talvez se lembrem de mim da época em que fui cofundadora da npm, Inc. Hoje em dia, penso em IA e em como testá-la. Estou aqui para falar de um problema que todo mundo está percebendo agora. A ascensão dos agents de IA aumentou drasticamente a velocidade com que os desenvolvedores conseguem produzir código. Mas a velocidade com que os humanos conseguem revisar código… Sim, estou dando uma palestra agora. Obrigada, Notion. Um ótimo lembrete. A velocidade com que os humanos conseguem revisar código permaneceu exatamente a mesma.

01:04 E isso está criando um novo gargalo que todo mundo está sentindo. Equipes de engenharia em todo o setor estão sentindo isso. Então, o que podemos fazer a respeito? Algumas opções são: podemos eliminar completamente a revisão humana. Algumas pessoas estão tentando isso. Podemos automatizar as revisões de forma confiável? Algumas pessoas também estão tentando isso. O que vamos fazer hoje, o que vou fazer por vocês, é analisar o que o setor realmente está fazendo agora e tentar descobrir o que vocês podem fazer hoje, quando saírem desta sala. Então, vamos começar com dois

01:35 números. Recentemente, três economistas acompanharam mais de 100 mil desenvolvedores do GitHub e os cruzaram com dados de telemetria que mostravam exatamente quando cada um começou a usar IA. Os desenvolvedores que ativaram agents autônomos escreveram 741% mais código, mas apenas 30% mais software foi lançado. Essa é a dimensão do problema. Eles estavam escrevendo código quase oito vezes mais rápido. Mas o volume de software que efetivamente lançaram cresceu apenas um terço. E os autores do

02:05 estudo são categóricos: a revisão era o gargalo. O problema é que o caminho até a produção ainda passa por humanos, e as etapas humanas, em particular a revisão de código, estrangulam tudo o que vem depois. Produzir código ficou de repente muito mais barato. Saber se é confiável continua sendo muito caro, especialmente quando se trata de código sensível, com grande raio de impacto. Como podemos reduzir esse segundo número e, assim, fazer com que a quantidade de software que lançamos volte a acompanhar a quantidade de código que conseguimos

02:36 escrever? Vamos primeiro ampliar a perspectiva. Vamos deixar claro que o problema é real. A geração já não é mais o gargalo. A Stripe e a Anthropic relataram, nos materiais de lançamento do Fable deste ano, a migração de uma base de código Ruby com 50 milhões de linhas em um único dia. Eles estimavam que esse trabalho levaria mais de dois meses para uma equipe. A Bun, que agora faz parte da… relatou ter migrado mais de um milhão de linhas de Zig para Rust em seis dias. E, é claro, todos nós nesta sala estamos sentindo isso em menor

03:07 escala. Nossos agents estão gerando aplicativos inteiros e nós meio que apertamos o botão de merge, nos sentindo culpados por não termos lido esses diffs de código, e simplesmente torcemos para que funcione. Não dá para continuar assim. Então, a resposta óbvia, que algumas pessoas estão tentando, é simplesmente revisar mais. Você pega pessoas cujo trabalho antes era revisar código e também escrever código e diz: “Agora seu trabalho é revisar código o tempo todo”. E isso não funciona, em parte porque é muito entediante e essas pessoas

03:38 se esgotam muito rápido. Mas os números também mostram que não dá. O melhor estudo que temos sobre isso foi feito há duas décadas na Cisco. Durante 10 meses, eles analisaram 2.500 revisões e 3,2 milhões de linhas de código. O estudo diz que os revisores deixam de encontrar defeitos de forma eficaz se tentam ler mais de 400 linhas de código de uma vez, e a eficácia deles despenca completamente se tentam revisar mais de 450 linhas

04:08 de código em uma hora. Se fizerem as contas, isso significa que uma pull request de um agent com 10 mil linhas, nesse ritmo, levaria três ou quatro dias úteis para receber uma revisão humana de verdade. Isso é uma pull request de um único agent. Dez mil linhas é, sem dúvida, um número totalmente esperado de linhas de código para um agent que está fazendo muito trabalho por você. E agora um desenvolvedor pode executar uma dúzia de agents ao mesmo tempo. Embora eu tenda a desconfiar das pessoas que fazem isso. Então, nós

04:41 não podemos simplesmente revisar com mais afinco, e todos nós estamos sentindo isso também. As pessoas que estão tentando revisar com mais afinco estão se esgotando. Então, qual é a alternativa? Algumas pessoas decidiram parar completamente de ler o código. Peter Steinberger, criador do OpenClaw, diz que você não deveria mais escrever prompts para agents de programação. Deveria projetar os loops que dão prompts aos seus agents. Andre Karpathy, um dos engenheiros fundadores da OpenAI, defendeu a mesma ideia de tirar a si mesmo do loop, porque o humano no loop está segurando o sistema.

05:12 Mas isso vai além de declarações ousadas no Twitter. Em fevereiro deste ano, a OpenAI publicou um relato sobre a criação de um produto interno, nas palavras deles, “sem código escrito manualmente”. Eles começaram com um repo completamente vazio e os agents escreveram tudo. Cinco meses depois, tinham cerca de um milhão de linhas de código, cerca de 1.500 pull requests integradas e haviam usado três engenheiros para fazer isso. Até a estrutura do agent que revisava o agent e coisas desse tipo

05:42 também foi escrita por agents. O que eles disseram foi: “Os humanos podem revisar pull requests, mas isso não é obrigatório”. “Transferimos quase todo o esforço de revisão para ser feito de agent para agent.” Acho interessante no experimento da OpenAI que eles não nos disseram o que o produto fazia e não revisaram um produto open source; não lançaram um produto open source dizendo: “Foi assim que fizemos e é assim que vocês deveriam fazer”, o que me sugere que ainda há lacunas nessa estratégia. Mas é uma possibilidade. Se a OpenAI diz que dá para fazer,

06:14 talvez dê mesmo. Mas uma possibilidade — a OpenAI diz que isso é algo que você pode fazer. A aposta é que o design do loop substitui a inspeção. Se você consegue criar um loop bom o bastante para revisar todo o seu código, isso depende inteiramente do que o loop consegue ver. Mas essa é uma ressalva enorme. O que exatamente o loop consegue ver, e ele é confiável o bastante para fazer revisões de código? Durante anos, o parâmetro que o setor usou como indicador de qualidade foi saber se

06:46 os testes passaram, porque era isso que os benchmarks mediam. Em março deste ano, um grupo de pesquisa chamado Meter, que vocês provavelmente já conhecem, testou diretamente esse indicador. Eles contrataram quatro mantenedores ativos de projetos open source, dos mesmos projetos open source usados pelo SWE-bench, e pediram que analisassem pull requests que já haviam passado no SWE-bench. Então, o SWE-bench dizia que aquela pull request era boa o bastante para ser integrada, e

07:16 eles pediram aos revisores de open source que analisassem exatamente a mesma pull request e dissessem se ela era mesmo boa o bastante para ser integrada. E ela só era considerada boa o bastante para ser integrada em cerca de metade das vezes. As falhas não eram de correção, porque, obviamente, as pull requests passavam em todos os testes. Eram relacionadas à qualidade do código e a alterações que quebravam silenciosamente outros trechos de código, coisas que ficavam fora do conjunto de testes. Uma ressalva mencionada pela Meter é que os agents não tiveram a oportunidade de iterar com base no feedback. Então, um colaborador humano, obviamente, ao ser informado de que sua pull request não é

07:48 vai ser integrado, pode tentar de novo. Pode fazer outra tentativa. Mas essa ressalva não é realmente relevante para nossos propósitos, porque isso é simplesmente colocar um humano no loop, e o que estamos tentando descobrir é se conseguimos tirar o humano completamente do loop. A Cognition, criadora do Devin, criou um benchmark em torno da pergunta real do mantenedor: você integraria isso? Eles o chamaram de Frontier Code e o lançaram em junho. Mais de 20 mantenedores criaram 150 tarefas a partir dos próprios repositórios,

08:19 cada uma exigindo mais de 40 horas de trabalho especializado. O FrontierBench avalia correção comportamental, regressões, segurança, escopo, disciplina, qualidade dos testes e facilidade de manutenção. É uma rubrica de revisão humana que pode ser verificada por máquina. E o que descobriram foi que o Fable 5, antes de ser retirado e depois recolocado, pontua 88% no SWE-bench Pro, mas apenas 29% no recorte mais difícil do Frontier Code. Portanto, o mesmo modelo, na mesma superfície e com o mesmo trabalho, tem um desempenho 51 pontos inferior quando você

08:51 pergunta não se ele passa nos testes, mas se você realmente integraria o resultado. E não é um modelo tendo um dia ruim. No mesmo conjunto de testes, o GPT 5.5 pontua menos de 6%. Portanto, os modelos mais fortes que temos estão muito longe de passar pela revisão humana de maneira confiável. Alguém precisa definir por escrito o que realmente significa estar pronto para integração. É evidente que ainda não fizemos isso. No momento em que alguém fizer isso, algo vai

09:21 acontecer. Sarah Guo, uma investidora de destaque em IA, escreveu sobre isso e disse que resolver esse benchmark — um benchmark de verdadeira capacidade de integração — será um ponto de virada crucial no desenvolvimento de modelos de programação. No ensaio em que falou sobre isso, ela explicou por que os modelos ficaram tão bons em gerar código tão rapidamente: porque um compilador é um verificador gratuito, uma suíte de testes é um verificador gratuito, e qualquer coisa que você consiga verificar a baixo custo pode servir de base para treinamento

09:52 até que o modelo supere esse critério. E é isso que vem acontecendo nos principais laboratórios de treinamento de modelos. Portanto, um benchmark de capacidade de integração, se conseguíssemos criar um, não seria apenas uma medição: ele se tornaria imediatamente um sinal de treinamento para os modelos de ponta. Isso significa que, assim que alguém criar testes confiáveis para facilidade de manutenção, escopo, disciplina, regressões e segurança, os grandes modelos serão treinados com eles. E quem escrever o padrão de revisão de hoje estará escrevendo o comportamento padrão dos modelos do ano que vem.

10:22 Já temos um precedente; sabemos que isso já aconteceu. Em 2024, a OpenAI treinou um modelo chamado CriticGPT para encontrar bugs em código escrito por modelos. Os revisores humanos que trabalharam com ele superaram tanto o modelo sozinho quanto os humanos sozinhos. Então, a OpenAI criou um modelo para revisar os modelos e, assim, aprimorar o treinamento, criando um sinal de treinamento que agora está incorporado aos modelos. Isso melhorou os modelos quase instantaneamente. Mas os padrões de capacidade de integração ainda estão

10:54 no futuro. Neste momento, não temos uma boa rubrica que abranja tudo o que um humano decide considerar ao determinar se algo está pronto para integração. E prometi falar de algo que você pode fazer hoje. Então, quem está usando revisão automatizada agora? Uma empresa é a GitHub. O revisor do Copilot já fez 60 milhões de revisões e agora responde por mais de uma em cada cinco revisões de código em toda a GitHub. Portanto, a revisão automática de pull requests é o padrão dominante no maior serviço de hospedagem de código do mundo. Isso é mais do que um experimento. É uma implantação em produção em grande escala. A Cursor também está fazendo uma quantidade enorme de revisões de código. A Cursor publicou a arquitetura do seu revisor, então sabemos como isso funciona. E os detalhes mostram qual é realmente o trabalho. A primeira versão do revisor fazia oito rodadas de revisão em cada diff e depois embaralhava a ordem dos revisores para revisar o código de novo

11:25 e de novo, porque a ordem em que fazia essas revisões mudava o resultado. O que estavam fazendo era filtrar falsos positivos, porque um revisor automatizado que aponta algo como ruim quando, na verdade, é bom será ignorado. E não é só a Cursor que está fazendo isso. Há pesquisas sobre o assunto. Uma equipe da Universidade de Pequim testou a mesma ideia de forma independente: executar várias rodadas de revisão e manter o que elas têm em comum. E descobriram que isso elevou a qualidade da revisão

11:57 em até 44%. O truque das várias rodadas continua sendo redescoberto porque falsos positivos são o que acaba com um revisor, e isso realmente funciona. Então a Cursor reconstruiu seu revisor de código, para que o modelo raciocine sobre o diff, chame ferramentas e decida onde investigar. E meu detalhe favorito dessa reconstrução é que precisaram dizer ao modelo para desconfiar mais do código. O modelo tendia a olhar para o código e dizer: “Bem, parece bom para mim, então pode enviar.” O que é exatamente o que um

12:28 humano faria nessa situação. Precisaram dizer a ele: não confie no código por padrão. Parta do princípio de que há algo errado. E, nessa frase, está contida uma palestra inteira sobre o que é uma boa revisão. Trata-se de desconfiar por padrão. A próxima coisa que está acontecendo é que a revisão está começando a se fundir com o reparo. O revisor da Cursor agora cria um agent de correção a partir das próprias descobertas. Então, ele não apenas aponta o bug. Ele escreve um patch e devolve a você um diff para aprovar.

12:58 Aprovar esse diff é, obviamente, mais um humano no loop, justamente onde não queremos humanos no loop. A próxima coisa que a Cursor quer fazer é o revisor executar o código para provar que o bug relatado é real. A linha entre revisar e reescrever está ficando realmente muito tênue. E GitHub e Cursor não são, de forma alguma, os únicos fornecedores entrando nesse mercado. Ele está ficando muito concorrido. Há uma tonelada de empresas nesse setor. O CodeRabbit é o maior revisor especializado e já analisou mais de 13 milhões de pull requests. A Graptile

13:30 cria um grafo de todo o seu repositório para que o revisor consiga ver como uma mudança afeta partes distantes do código. A Graphite cria seu conjunto de avaliação com base em quais sugestões dela os desenvolvedores aceitam ou rejeitam. Mas o que vale notar sobre o que todas elas estão fazendo é que usam a mesma métrica para definir o sucesso: um humano aceitou minha resposta? A Cursor chama isso de taxa de resolução, e ela a elevou de 52% para mais de 70%.

14:03 Os revisores são treinados com julgamentos humanos de aceitação todos os dias e em grande escala. Eles estão treinando seus harnesses para melhorar segundo a definição de qualidade determinada pela aceitação humana. Isso é uma prévia do que os modelos vão fazer, só que essas empresas já lançaram isso. Portanto, o estado atual é: você pode gerar código automaticamente e revisar código automaticamente, mas os humanos ainda precisam revisar as revisões. Dá para eliminar essa etapa por completo? Dá para tirar o humano completamente do loop? Até onde sei, há dois projetos de destaque que tentaram fazer isso.

14:35 Em fevereiro deste ano, Nicholas Carini, da Anthropic, fez 16 agents criarem um compilador de C do zero em Rust. Ele conseguiu compilar o kernel do Linux ao longo de cerca de 2.000 sessões, sem nenhum humano no loop. Mas, se você ler o experimento com atenção, é verdade que não havia nenhum humano no loop. Nenhum humano aprovava o código enquanto ele era escrito, mas havia, sem dúvida, um humano supervisionando o processo. O sistema que revisava o código, o sistema que verificava se o código estava fazendo o que deveria fazer, todos esses

15:06 que ouvi falar até agora. Em fevereiro deste ano, Nicholas Carini, da Anthropic, fez 16 agents criarem um compilador de C do zero em Rust. Ele conseguiu compilar o kernel do Linux ao longo de cerca de 2.000 sessões, sem nenhum humano no processo. Mas, se você ler esse experimento com atenção, é verdade que não havia nenhum humano no processo. Nenhum humano aprovava o código enquanto ele era escrito, mas havia, sem dúvida, um humano supervisionando o processo. O sistema que revisava o código, o sistema que verificava se o código estava fazendo o que deveria, tudo isso

15:37 que foi escrito por um humano. O harness de testes, os sistemas de feedback, tudo isso. Eram testes automatizados com testes que um humano precisava escrever. O próprio alerta de Carini, quando escreveu sobre isso, foi que é fácil ver os testes passarem e presumir que o trabalho está feito — e que quase nunca está. Outro experimento muito divulgado, que já mencionei brevemente de passagem, foi quando a Bun portou todo o seu runtime de Zig para Rust. Foram cerca de um milhão de linhas de código escritas por agents

16:08 em seis dias. Obviamente, nenhum humano leu esse diff. O critério para esse experimento foi a suíte de testes existente. 99,8% da suíte de testes passou. Então, os testes fizeram um trabalho de verdade. Um fato curioso sobre esse experimento é que o PR em que os agents decidiram que tinham terminado todo o código em Zig e apagaram tudo em um único PR gigante foi sinalizado por outro robô como “isso é lixo de IA. Não é possível apagar todo o seu código”. Achei isso um aparte divertido.

16:40 Mas há algumas ressalvas importantes sobre esse experimento da Bun. Alguém examinou cuidadosamente o código portado e encontrou 13.044 blocos unsafe. Em uma base de código Rust de tamanho comparável, escrita por humanos, seriam cerca de 74. Ou seja, três ordens de magnitude a mais de blocos unsafe, que permitem acesso inseguro à memória. Um bloco unsafe é um trecho em que o autor afirma, em vez de provar, que a memória está sendo manipulada corretamente. Portanto, a suíte de testes pode certificar o comportamento na interface pública

17:11 Mas não pode certificar 13 mil afirmações que a suíte de testes nunca foi projetada para verificar. Então, com certeza, tiraram os humanos do processo. Mas, como resultado, agora ninguém sabe o que está escondido sob a superfície do código em Rust. Vamos voltar à OpenAI, que está na vanguarda disso, porque mostra o custo de pular a revisão humana. Eles não eliminaram a revisão; mudaram o lugar dela. O Codex revisa as próprias alterações e, em seguida, chama mais agents para revisar essas revisões

17:42 em um ciclo, até que todos os agents revisores estejam satisfeitos. A OpenAI tornou o Codex inicializável a cada alteração, para que ele possa executar uma cópia de si mesmo, examiná-la, olhar a interface e verificar se o bug foi corrigido. E eles expõem toda a pilha de logs ao agent. Uma frase do texto deles diz exatamente o mesmo que o estudo da Cisco: quando algo falhava, quase nunca adiantava simplesmente tentar com mais afinco. Às vezes, não funcionava. E há um detalhe que você vai reconhecer da sua própria semana

18:12 que, por um tempo, nesse projeto, eles precisavam passar toda sexta-feira limpando o lixo de IA. À mão, como humanos. Isso acabou não sendo escalável, então treinaram agents para identificar e remover o lixo de IA. A lição desse experimento é que a revisão não desapareceu. Ela foi reconstruída como um sistema, e esse sistema foi construído por humanos. Então, dá para eliminar completamente os humanos?

18:44 Alguém que tentou isso de verdade e depois mudou de ideia foi Dexter Horthy. Ele passou seis meses dizendo às pessoas para não revisar o código. Fez isso, de forma notória, na AIE no ano passado. Dizia às pessoas: “É só publicar; deixem o agent fazer o trabalho dele”. E, em março deste ano, no palco, voltou atrás. Disse: “Eu estava errado. Por favor, por favor, leiam o código. Tentamos não ler o código por uns seis meses. Não terminou bem. Tivemos que remover e substituir partes grandes daquele sistema”. Isso não é um benchmark. É alguém que fez esse experimento de verdade, tentou com código real em um sistema real

19:15 e voltou atrás no que havia dito. A OpenAI está fazendo isso, conviveu com os resultados e mudou publicamente de posição. Sarah Quo, no mesmo texto que mencionei antes, falou sobre por que isso acontece. Passar nos testes nunca dizia que a alteração era a alteração certa. Nunca dizia que aquele módulo existia porque havia três usuários externos dele. Nunca dizia que existe um cron job que ninguém vai admitir ter escrito e que depende da existência

19:45 daquele módulo. Há contexto fora da suíte de testes que os testes não conseguem encontrar. Então, em tudo o que vimos até agora, o ponto de verificação humano continua existindo. Ele muda de lugar, mas continua existindo em pontos previsíveis. Um deles é quando não dá para verificar a correção de forma barata. Outro é quando o raio de impacto é grande. Em ambientes preocupados com segurança, sempre que você diz às pessoas “ah, podemos simplesmente eliminar a revisão humana”, a resposta imediata é não.

20:18 E também sempre que alguém precisa colocar o próprio nome no resultado. Mas o que está acontecendo é que o papel humano não está desaparecendo. Está subindo na pilha, talvez vários níveis acima: de inspecionar o código diretamente para projetar e ajustar os sistemas que inspecionam o código e definir o que é bom. Isso levanta a pergunta óbvia: quem revisa esses sistemas? Se você criou um sistema que faz as revisões por você, como faz a metarrevisão do seu revisor? A resposta não vai surpreender: são os humanos. A Anthropic disponibiliza um revisor de segurança automatizado e, no

20:50 README, traz uma ressalva enorme: “Esta ação não está protegida contra ataques de injeção de prompt e só deve ser reutilizada para revisar PRs confiáveis”. Portanto, o revisor de código da Anthropic pode ser convencido a ignorar suas descobertas pela própria coisa que está revisando. E um estudo de março deste ano reproduziu esse resultado: código vulnerável disfarçado com uma mensagem de commit inofensiva enganou um agent revisor autônomo em 88% das tentativas. As mesmas tentativas, quando enviadas

21:22 a um revisor humano, só passaram 35% das vezes. Então, quando você tira o humano do processo, não perde apenas um revisor: perde aquilo que era difícil de enganar. As revisões automatizadas caem em código ruim apresentado com confiança. E código ruim apresentado com confiança é exatamente o tipo de código que os agents são muito bons em produzir. Eles são muito do tipo: “Isso está bom e estou pronto”. E às vezes estão errados. O outro problema é que a área ainda nem sequer concorda sobre como avaliar esses avaliadores.

21:53 Estruturas de benchmark já foram flagradas vazando respostas. Pesquisadores discordam até sobre como avaliar a qualidade da revisão. Isso deixa um revisor que não dá para automatizar nem dispensar: a produção. Quando a revisão antes do merge é feita toda por máquinas, observar o que o código realmente faz passa a ser o último revisor de pé. Depois que o código é publicado, os resultados dos testes deixam de ser o mais interessante; o que importa é a trajetória: o que o sistema realmente fez, passo a passo, quando foi executado contra

22:24 o mundo real. Não vou fazer aqui uma apresentação de vendas da Arize; já há apresentações de vendas da Arize suficientes nesta conferência. Mas, se você publica código revisado automaticamente, sistemas em produção que observam o que ele realmente faz no mundo real se tornam indispensáveis. Então, depois de todas essas evidências e de toda essa análise do que o mundo está fazendo em relação às revisões automatizadas de código, minha conclusão é que a revisão de código não está completamente morta, mas está mudando enormemente. Está sendo reconstruída como um sistema de engenharia. Os humanos estão

22:56 passando de motores que impulsionam a revisão de código — lendo o código linha por linha — a pilotos. E, considerando os números com que começamos, essa provavelmente é a troca certa. Cada camada desse sistema — o benchmark, o classificador, a rubrica, a suíte de testes, o eval — está, ela própria, sem revisão, até que alguém decida que essa é a sua tarefa. E as equipes que vencerem nos próximos anos não serão as que gerarem mais código. Serão as que conseguirem apresentar evidências de por que confiam no que publicaram. E comecei prometendo a vocês que eu

23:28 daria algo prático, com que você pudesse sair daqui e fazer ainda hoje. E isso é parar de revisar PRs. Esse é o nível de abstração errado para 2026. Seu julgamento humano é extremamente valioso, mas pode ser ampliado muito mais do que está sendo agora. Dedique seu precioso tempo a criar um harness de revisão confiável. Formalize suas definições de qualidade, o contexto da sua empresa e seu conhecimento do domínio; depois, coloque os agents para trabalhar com

23:58 isso. Você pode avançar muito mais rápido do que um terço se concentrar seus esforços em um nível mais alto da pilha de revisores, regras e evals. Espero que esta análise do que o setor está fazendo hoje tenha ajudado você a decidir o que deve fazer e o que esperar a seguir. Muito obrigada pelo seu tempo e pela atenção. >> [aplausos]

Transcrição original

[00:01] [music] Hello everybody. Thank you for following on a session about the death of the code review with a session about the death of the code review. Uh who knows howululing decisions get made, but uh Swix decided it would be funny for those two to be backtoback. Uh, hi. Uh, I’m Lori. I’m head of developer relations at Arise AI. Uh,

[00:32] some of you may remember me from when I used to co-found npm, Inc. These days, I think about AI and how to test it. Uh, I’m here to talk about a problem that everyone is seeing right now. The rise of AI agents has dramatically increased how fast developers can produce code. Uh, but the speed at which humans can review code. Uh, yeah, I am having a talk right now. Thank you, notion. very good reminder. Uh the team the speed at which humans can review code has stayed exactly the same.

[01:04] Um [snorts] and that is creating a new bottleneck that everybody is feeling. Engineering teams across the industry are feeling it. Uh so what can we do about it? Some options are uh we could skip human review entirely. Uh some folks are trying that. Can we automate reviews reliably? Some folks are trying that too. Uh what we’re doing going to do today, what I’m going to do for you is I’m going to look at what the industry is really doing right now uh and try to figure out what you can do uh today when you leave the room. So let’s start with two

[01:35] numbers. Uh recently three economists tracked more than 100,000 GitHub developers uh matched them against telemetry that showed exactly when each one started using AI. Uh the developers who turned on autonomous agents wrote 741% more code but only 30% more software shipped. Uh that is the scale of the problem right there. They were writing code nearly eight times faster. Uh but their actual ship software only rose by a third. Uh and the authors of

[02:05] the study are blunt that review was the bottleneck. Um the problem is that the route to production still runs through humans. uh and the human steps uh in particular code review uh choke everything downstream. Um producing code is suddenly a whole lot cheaper. Knowing whether to trust it is still very expensive, especially if you have uh sensitive code with a blast radius. Um how can we bring that second number down and thus bring this the amount of software that we ship back into line with the amount that we can

[02:36] code? Uh let’s zoom out first. Let’s be clear that the problem is real. generation is no longer the bottleneck. Uh Stripe in Anthropics launch materials for Fable this year reported migrating a 50 million line Ruby codebase in a single day. Uh which is work that they’d estimated would take over two months for a team. Um Bun, which is now part of reported that they migrated over a million lines of Zigg uh to Rust in six days. Uh and of course all of us in this room are feeling this on a smaller

[03:07] scale. uh our agents are generating whole apps and we’re just sort of hitting the merge button and feeling guilty about the fact that we haven’t read these code diffs and we’re just sort of hoping that it works. Uh we can’t possibly keep on going like that. Um so the obvious answer and the answer some people are trying is you just review more. You take people whose job was previously to review code as well as write code and just say review code all the time. This is your job now. Uh and that doesn’t work. uh partly because that’s really boring and those people

[03:38] burn out really fast. Um but also the numbers say that we can’t um the best study we have on this was done uh two decades ago at Cisco um over 10 months they took 2 and a half thousand reviews they took 3.2 2 million lines of code. Uh, and the study says that reviewers stop finding defects effectively if they try to read more than 400 lines of code in one sitting and their effectiveness completely falls off a cliff. Uh, if they try to review more than 450 lines

[04:08] of code in an hour. Uh, if you do the math on that mean that means that a 10,000line agent pull request at that pace would take three or four working days to get a real human review. that is one pull request from one agent. 10,000 lines is uh absolutely you know absolutely an expectable number of of lines of code uh for an agent that is doing a lot of work for you. Uh and a developer can now run a dozen agents at once. Um although I’m tend to be suspicious of the people who do um so we

[04:41] can’t just review harder and we’re all feeling that too. The people who are trying to review harder are burning themselves out. So what is the alternative? Uh some people have decided to just stop reading the code entirely. Uh Peter Steinberger who is the creator of OpenClaw uh says that you shouldn’t be prompting coding coding agents anymore. You should be designing the loops that prompt your agents. Uh Andre Karpathy who is one of OpenAI’s founding engineers has made the same argument about taking yourself out of the loop. Uh because the human in the loop is holding the system back.

[05:12] Uh but this goes beyond bold claims on Twitter. Uh in February this year, OpenAI published an account of building an internal product uh with in their words no manually written code. They started with a completely empty repository uh and agents wrote everything. Five months later they had about a million lines of code about 1500 merged pull requests uh pull requests uh and they had done used three engineers to do this. Uh even the scaffolding of the agent to review the agent and stuff

[05:42] like that was also written by agents. What they said was humans may review pull requests but they are not required to. Uh we’ve pushed almost all review effort towards being handled agent to agent. I think the interesting thing about the OpenAI experiment is that they did not tell us what the product did and they did not review an open they did not release an open source product saying and this is how we did it and this is how you should do it which suggests to me that there are still holes in that strategy. Um but it is one possibility. If open AAI says that you can do it,

[06:14] maybe you can do it. Um but one poss so agent open AI says that’s one thing you can do. The bet there is that loop design substitutes for inspection. Uh whether you can build a loop that is good enough uh to review all of your code for you depends entirely on what the loop can see. Uh but that is an enormous caveat. What exactly can the loop see and is it reliable enough to do code reviews? For years, the industry’s proxy for uh reliable for quality has been whether

[06:46] the tests passed uh because that is what the benchmarks measured. In March this year, uh a research group called Meter, who you’ve probably heard about before, uh tested that proxy directly. They hired four active maintainers of open- source projects uh from the same open source projects that Swebench tests against and they got them to look at uh PRs that had already passed SWEBench is greater. So SweetBench said this pull request is is good enough to merge and

[07:16] they got the open source reviewers to look at exactly the same PR and say is it really good enough to merge and it was only good enough to merge about half of the time. Uh, and the failures weren’t about correctness because obviously the PRs were passing all of the tests. They were about code quality and they were about changes that quietly broke other code, things external to the test suite. Uh, one caveat that meter mentions is that the agents got no chance to iterate on feedback. So, a human uh, contributor obviously being told that their PR isn’t

[07:48] going to get merged get another go at it. They can take another swing. Uh but that caveat doesn’t really isn’t really relevant to our purposes because that’s just putting a human in the loop and what we’re trying to see is whether or not we can take the human out of the loop entirely. Uh Cognition, the makers of Devon, uh built a benchmark around the maintainer’s actual question, which is would you merge this? Uh they called it frontier code and they launched it in June. Um more than 20 maintainers built 150 tasks from their own repositories,

[08:19] each one over 40 hours of expert work. Uh Frontierbench grades behavioral correctness, regression, safety, scope, discipline, test quality, and maintainability. This is a human review rubric uh made machine checkable. Um, and what they found was that Fable 5 before it got pulled and then unpulled, uh, scores 88% on Swebench Pro, but only 29% on the hardest slice of, uh, Frontier code. So, the same model on the same surface with the same job does 51 points less uh, less well if you’re

[08:51] asking not does it pass the tests, but whether or not uh, you would actually merge the result. Um, and this isn’t one model having a bad day. on the same set of tests uh GPT 5.5 scores under 6%. So the strongest models we have are nowhere near uh passing human review reliably. So somebody has to write down what mergeible actually means. That is it’s clear that we haven’t done that yet. Uh the moment they do something will

[09:21] happen. Sarah Guo who is a prominent investor in AI uh wrote about it and said that solving for that solving for that benchmark a benchmark of genuine mergeability uh will be a critical turning point in the development of coding models um in the essay where she was talking about this she made clear why models got so good so fast at generating code and that is because a compiler is a free verifier a test suite is a free verifier and anything that you can verify cheaply you can train against

[09:52] until you beat it and that is what has been happening uh at the major model trainers. Uh so a benchmark of mergeability if we could if we could make one wouldn’t only be a measurement it would immediately become a training signal for the frontier models. Uh which means maintainability scope discipline regression safe safety the moment somebody comes up with reliable tests for those the big models will be trained on them. Uh and whoever writes today’s review standard is writing next year’s

[10:22] default model behavior. Uh we have some prior art here knowing we have seen this happen already. Uh which is that in 2024 OpenAI trained a model called critic GPT to catch bugs in model written code. Uh human reviewers working on it beat the model alone uh and the human alone. Um, so OpenAI built a model to review the models in order to clean the training and it created a training signal that’s now built into the models. It made the models better almost instantly. But mergeability standards are still in

[10:54] the future. Right now we do not have a good rubric that captures everything that a human decides uh to uh consider when they are deciding whether something is mergeable. And I promised you something that you can do today. Um so who is actually running automated review right now? Uh one company is GitHub. GitHub is uh copilot’s reviewer has done 60 million reviews and now accounts for more than one in five uh code reviews on all of GitHub. So machine review of pull

[11:25] request is the mainstream default uh on the world’s largest code host. That is more than an experiment. That is a large production uh a large production deployment. Uh, Curser is also doing an enormous amount of code review. Cursor uh, has published its reviewer’s architecture, so we know how they’re doing this. Um, and the details tell you what the job really is. The first version of their reviewer uh, would run eight review passes over each diff uh, and then shuffle the order of the reviewers uh, to review the code again

[11:57] and again uh, because the order in which it did those reviews changed the outcome of those reviews. what they were doing was filtering for false positives because a reviewer, an automated reviewer that flags something as bad when it’s actually good, uh, is going to get ignored. Um, and it’s not just cursor who’s doing this. There’s research about it. Uh, a team at PKing University tested the same idea independently. Run several review passes, see keep what they agree on. Uh, and they found that it review raised

[12:28] review quality by up to 44%. Uh the multipass trick keeps getting rediscovered because uh false positives are the thing that kill a reviewer and it actually works. So then cursor rebuilt uh their code reviewer. Um so that the model reasons over the diff, calls tools and decides where to dig. Um and my favorite detail from their rebuild uh was that they had to tell the model to be more suspicious of the code. Uh the model tended to look at the code and say, “Well, that looks good to me, so ship it.” Which is exactly what a

[12:58] human would do in that situation. uh they had to tell it don’t trust the code by default. Assume there is something wrong with it. Um and somewhere in that sentence is a whole is a whole talk about what a good review actually is. Uh it is about being suspicious by default. Um the next thing that’s happening is that review is starting to fuse with repair. Cursor’s reviewer now spawns a fix agent from its own findings. So it doesn’t just flag the bug. uh it writes a patch uh and it hands you back uh a diff to approve. Uh

[13:30] you approving that diff is obviously another code is another human in the loop where we don’t want humans in the loop. Um the next thing cursor wants to do is the reviewer running the code to prove its own bug report is real. Um the line between reviewing and rewriting is getting very thin indeed. Um and GitHub and cursor are by no means the only vendors getting into this game. It is uh getting very crowded in there. There’s a ton of companies uh in the field. Uh Code Rabbit is the largest dedicated reviewer has now reviewed over 13 million poll requests. Uh Graptile

[14:03] builds a graph of your whole reposi of your whole repository so that the reviewer can see how a change lands in distant code. Uh graphite builds its evaluation set from which of its own suggestions developers accept or reject. Uh but the thing to notice uh about what every one of them is doing is that all of them are using the same metric as their definition of success which is is a human accepting my answer. Uh cursor calls it the resolution rate and it has driven it from 52% to over 70%. Um

[14:35] the reviewers are trained on human accept judgment every day at scale. They are training their harnesses to get better at the definition of good as defined by human acceptance. That is a preview of what the models are going to do except these companies have already shipped it. So the status quo is you can generate code automatically, you can review the code automatically, but humans still need to review the the reviews. Can you skip that part entirely? Can you get the human entirely out of the loop? Uh there are two prominent projects that I’ve that have

[15:06] tried so far that I’ve heard of. Uh in February this year, Anthropics Nicholas Carini had 16 agents build a C compiler from scratch in Rust. uh it was able to compile the Linux kernel uh across about 2,000 sessions with no human in the loop. But if you read that experiment closely, uh it’s true that there was no human in the loop. Uh no human approving the code as it was written, but there was absolutely a human on the loop. The system uh that reviewed the code, the system that checked whether the code was doing what it was supposed to do, all of

[15:37] that uh was written by a human. Um the test harness, the feedback systems, all of that stuff. Um it was automated testing with tests that took a human to write them. Um Carini’s own warning when he wrote about it was that it is easy to watch the tests pass and assume that the job is done uh and that it rarely is. Another very widely publicized experiment which I al which I already mentioned briefly [clears throat] in passing was when bun ported its entire uh runtime from zig to rust. That was about a million lines of code by agents

[16:08] in six days. Obviously no human read that diff. Um the gate for that experiment was the existing test suite. 99.8% of the test suite passed. Um so the test did real work. Uh a fun fact about that experiment is that the PR uh where they uh where the agents decided that the they were done with all of the Zig code and they deleted all of the Zig code in one giant PR was flagged by another robot as this is AI slop. You can’t possibly delete all of your code. Uh which I thought was a fun aside. Um,

[16:40] but there are some big caveats on that bun experiment. Somebody looked carefully at the ported code and it has 13,044 unsafe blocks. Uh, in a comparable human written uh, uh, Rush codebase of that size, uh, you would see about 74. So, three orders of magnitude more unsafe memory unsafe blocks. An unsafe block is a place where the author asserts rather than proves uh, that memory is being handled correctly. So the test suite can certify behavior at the public

[17:11] interface. Um it cannot certify 13,000 assertions that the test suite was never designed to look for. So they took humans out of the loop for sure. Uh but there’s now no knowing what is lurking under the surface of their rust as a result. So let’s go back to OpenAI who have pushed this the first list because they show what skipping human review costs. They didn’t delete review, they moved it. uh codeex reviews its own changes uh then calls in more agents to review

[17:42] those reviews um in a loop until every agent reviewer is satisfied. OpenAI made Codeex bootable at every single change so that Codeex can actually run a copy of Codeex, look at it, look at the UI, see if the bug is being fixed. Uh and they expose the whole logging stack to the agent. Um, and a line from their writeup says exactly what the Cisco study said, which is that when something failed, the fix was almost never to try harder. It didn’t work sometimes. Uh, and one detail that you’ll recognize

[18:12] from your own week is that for a while on this project, they had to spend every Friday cleaning up AI slop. Uh, by hand as humans. Um, so that eventually didn’t scale and so they trained agents to look for AI slop and get rid of the AI slop. uh review didn’t disappear is the lesson of this of of this experiment. Uh it got rebuilt as a system and that system is built by humans. So can you skip the human entirely? Uh

[18:44] someone who tried it for real and then changed his mind is Dexter Horthy. Uh he spent six months telling people not to review the code. He famously did that at AIE last year. Um he told people just ship, let the agent do its thing. Uh and in March this year on stage uh he took that back. Uh he said I was wrong. Please please read the code. We tried not reading the code for like six months. It did not end well. We had to rip out and replace large parts of that system. That is not a benchmark. That is somebody who ran this experiment for real. Tried it with real code on a real

[19:15] system uh and retracted his remarks. Uh OpenAI is running uh lived with the results um and reversed in public. Uh so Sarah Quo uh in the same writeup that I mentioned earlier talked about why that happens. Passing the test never told you that the change was the right change. It never told you that this module exists because there are three external users of this module. Uh it never told you that there’s this cron job that nobody will admit to writing that relies on

[19:45] that module existing. Um there is context outside of the test suite that the tests don’t uh can’t find. So in everything that we’ve looked at so far, the human uh checkpoint is continuing to survive. It is moving around uh but it is surviving in predictable places. One is where correctness isn’t cheaply checkable. Another is where uh the blast radius is large. In security conscious environments, every time you tell people, oh, we can just get rid of human review, you get an immediate no. Uh

[20:18] wherever someone has to put their name on the result. Uh but what’s happening is the human role isn’t disappearing. It is moving up the stack, possibly several levels up the stack from inspecting the code directly to designing and tuning the systems that inspect the code and designing the definition of good. Which raises the obvious question, who reviews those systems? If you’ve built a system that does your reviews for you, how do you do the meta review of your reviewer? Um and the answer won’t surprise you. It is humans. Uh, Anthropic ships an automated security reviewer and in its

[20:50] readme it has a huge caveat uh, which is this action is not hardened against prompt injection attacks uh, and should only be re used to review trusted PRs. So, Anthropics code reviewer uh, can be talked out of its findings by the very thing that it is reviewing. Um and that is a finding that has been reproduced in study in March this year reinforced uh that vulnerable code dressed up in an innocent commit message uh fooled an autonomous review agent in 88% of attempts. Uh the same attempts uh sent

[21:22] to a human reviewer uh passed only 35% of the time. So you you take the human out of the loop. Uh you don’t just lose a reviewer, you lose the thing that was hard to fool. So automated reviews fall for confidently framed bad code. And confidently framed bad code is exactly the kind of code that agents are very good at producing. They’re very like this is good and I am ready. Uh and they uh are wrong sometimes. Um and the other problem is the field doesn’t even agree yet on how to grade these graders. Uh

[21:53] benchmark scaffolds have been caught leaking answers. Researchers disagree on how to review quality at all. um which leaves one reviewer that you can’t automate and you can’t skip which is production. Uh once the premerge review is all machines watching what the code actually does becomes the last reviewer standing. Um once the code ships the test results stops being the interesting thing the trajectory does what the system actually did step by step uh when it ran against

[22:24] the real world. Uh I’m not going to give a pitch for a rise here. there are enough pitches for a rise at this conference. Uh but if you’re shipping automatically reviewed code, then systems in production that review what it actually does in the wild become indispensable. Um so after all that evidence, after all of that review of what the world is doing about automated code reviews, where I land is that code review isn’t completely dead, but it is changing an enormous amount. Uh it is being rebuilt as an engineered system. Humans are

[22:56] moving from being the engine that drives a code review uh reading code line by line uh to its pilots. Uh and given the numbers that we opened with that is probably the right trade. Every layer of that system, the benchmark, the classifier, the rubric, the test suite, the eval is itself unreed until somebody decides that that is their job. Um and the teams that win the next few years won’t be the ones that generate the most code. They’ll be the ones who can say with evidence why they trust what they shipped. Uh and I open by promising you that I

[23:28] would give you with something practical that you could walk away with something that you can do today. Uh and that is to stop reviewing PRs. Um it is the wrong level of abstraction for 2026. Your human judgment is extremely valuable, but it can be made to scale much further than it is scaling right now. Uh pour your precious time into building uh a reliable review harness. codify your definitions of good, your company context, your domain knowledge, and then uh crank up the agents to work with

[23:58] that. You can go much faster than one-third faster uh if you concentrate your efforts higher up the stack of reviewers, rules, and evals. Uh I hope this look at what the industry is doing today has helped you what to helped you decide what you should do and what to expect next. Uh and thank you so much for your time and attention. >> [applause]