O novo sistema REVIEW.md do Claude Code: o que é?

Autoria: Rob Shocks · 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: Claude Codes New REVIEW.md System, What is it? · Canal: Rob Shocks · 16:39 · Assistir no YouTube

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

Resumo

Rob Shocks analisa o processo de revisão de código da Anthropic, criado para acompanhar o aumento da produção de código por agentes sem depender de revisão humana linha por linha. O sistema combina verificações automatizadas em seis camadas, aprovação humana proporcional ao risco, monitoramento e reversões rápidas. O vídeo também aborda ciclos excessivos de revisão por IA, o produto de revisão do Claude Code e a substituição interna do Git por Seon. Ao final, o apresentador sugere práticas que outras equipes podem adotar, como criar um REVIEW.md e medir reversões.

Pontos-chave

O aumento na produção de código torna inviável revisar manualmente cada linha, então a Anthropic deslocou boa parte da análise para verificações automatizadas.
A revisão deve identificar o que pode dar errado e escolher se uma pessoa ou uma ferramenta automatizada é mais adequada para detectar o problema.
O processo descrito tem seis camadas: verificação antes do pull request, revisão por IA, análise de segurança, verificações técnicas, aprovação humana conforme o risco e merge queue.
Mudanças de baixo risco podem dispensar aprovação humana quando as verificações automatizadas e de segurança forem aprovadas; mudanças de maior risco exigem mais aprovação.
A aprovação de um agent não substitui a aprovação de uma pessoa, e quem orientou a mudança continua responsável pelo pull request.
Reversões rápidas, flags e análise de incidentes ajudam a limitar o impacto de falhas que passam pelas verificações.
Um pull request passou por mais de 50 ciclos de revisão por IA; a análise indicou que muitos apontamentos recorrentes eram problemas antigos, não novos.
A Anthropic limitou os ciclos de revisão, ajustou o que é reavaliado em cada rodada e transformou incidentes anteriores em evals.
O produto de revisão do Claude Code apresenta achados, mas não aprova nem bloqueia pull requests.
Entre as práticas sugeridas para outras equipes estão adicionar um REVIEW.md, testar um revisor de IA em um repo e definir níveis de risco pela mudança.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio da revisão de código em escala	O vídeo apresenta o crescimento da produção de código na Anthropic e o gargalo que a revisão humana pode representar.
02:09	Por que revisar e como medir o processo	A Anthropic redefine a revisão como a tarefa de detectar riscos e estabelece métricas e metas para reduzir o gargalo humano.
04:17	As seis camadas de verificação	O apresentador descreve verificações automatizadas, revisão por IA, análise de segurança, aprovação conforme o risco e merge queue.
07:28	Armor e aprovação proporcional ao risco	O vídeo apresenta o Armor como patrocinador e detalha as regras de aprovação humana para mudanças de diferentes níveis de risco.
10:11	Reversões, ciclos de revisão e evals	O processo usa flags e reversões, enquanto um caso com mais de 50 rodadas de revisão leva a limites de ciclos e avaliações baseadas em incidentes.
13:58	O produto de revisão e práticas para outras equipes	O apresentador explica o produto de revisão do Claude Code, comenta Seon e lista práticas que equipes podem experimentar.

Citações

Não removemos a revisão, mas transferimos a maior parte da leitura para máquinas otimizadas para o tempo e a atenção das pessoas. — 00:32

O que poderia dar errado com este código que acabou de ser enviado? — 02:39

Se um agent fizer um trabalho ruim, o problema é seu. — 09:40

As fábricas de software são um sistema em movimento. — 12:55

Conceitos e entidades

Anthropic (empresa): Empresa cujo processo de revisão de código e desenvolvimento é analisado no vídeo.
Claude Code (ferramenta): Ferramenta de programação da Anthropic, cujo processo de revisão e produto de revisão são discutidos.
REVIEW.md (conceito): Arquivo recomendado para orientar revisores sobre o que é importante verificar no código de um projeto.
Seon (ferramenta): Sistema interno que a Anthropic adotou para substituir Git em seu mono repo.
antique (ferramenta): Ferramenta de revisão mencionada junto ao sistema Seon.
OpenRouter (empresa): Patrocinador apresentado no vídeo, descrito como um serviço que dá acesso a diversos modelos por uma API.
Armor (ferramenta): Produto em beta apresentado como uma camada que verifica tool calls de agentes de acordo com políticas.
Jev (modelo): Modelo da Type safe mencionado como parte da verificação de políticas do Armor.
Bar Shirni (pessoa): Criador de plug code citado por uma estimativa sobre os ganhos de qualidade com verificação.
Addy Osmani (pessoa): Profissional citado por seu trabalho sobre níveis de risco e quantidade de aprovadores.
merge queue (conceito): Etapa que executa novamente as verificações na branch principal com as mudanças aplicadas antes do merge.
evals (conceito): Avaliações baseadas em incidentes anteriores que a Anthropic usa para acompanhar a qualidade do revisor.

Tradução completa (pt-BR)

00:00 Então, agora o Claude Code escreve cerca de 90% do próprio código, e as coisas estão realmente acelerando na Anthropic. Se você está olhando para o aplicativo web neste momento, o ritmo das mudanças está muito rápido. Então, alguma coisa está funcionando. De junho a setembro, o número de pull requests mesclados — ou seja, o trabalho realizado — mais que dobrou. Mas o principal aqui é que o código que estava sendo revertido ou que antes dava errado diminuiu 40%. Então, que diabos está acontecendo na Anthropic? Bem, o que tentei fazer foi juntar as peças a partir de várias fontes diferentes nos últimos dias, para que você possa aprender a avançar nesse ritmo. E

00:32 durante todo esse tempo, estou fazendo o possível para separar o exagero de marketing dos ganhos práticos reais que vejo outras empresas com as quais trabalhei aplicarem nesse espaço. Então, qualquer pessoa que tenha trabalhado com agents percebe que não há problema em executar cem agents diferentes no seu codebase. O grande problema é que aparece uma tonelada de código, e ele precisa ser revisado e verificado de alguma forma. Para a maioria das organizações com que converso, o maior problema é a revisão de código. A equipe do Claude Code acabou de publicar como revisa código agora, e esta é a frase principal: “Não removemos a revisão, mas transferimos a maior parte da leitura para

01:04 máquinas otimizadas para o tempo e a atenção das pessoas, e investimos muito para tornar rápido e fácil desfazer erros.” Ou seja, o raio de impacto e a capacidade de recuperação desse impacto. Então, sou Rob, da Switch Dimension. Vou mostrar a vocês o processo da Anthropic camada por camada e, em seguida, vou mostrar onde o produto de revisão do Claude Code se encaixa. E, na verdade, não é onde você imaginaria. Depois, vou terminar com uma rápida análise do Seon. É a substituição deles para o Git, que se encaixa em todo esse processo. Então, se você é um desenvolvedor atuante, recomendo que fique por aqui. Também vamos falar sobre este pull request da Anthropic que passou por 50

01:37 rodadas de revisão por IA durante a noite. Isso é exagero? Vamos ver. Agora, vale lembrar que a Anthropic tem uma quantidade enorme de inference para dedicar a todos esses problemas. Talvez isso não se encaixe exatamente na forma como você gosta de desenvolver, mas nos dá indicações de para onde as coisas podem estar indo. E também vale lembrar que a Anthropic, é claro, vende inference e vende um grande sonho e uma visão de para onde tudo isso está caminhando. Então, tenha isso em mente enquanto analisamos o processo deles. Isso não quer dizer que não haja algo valioso que nós, desenvolvedores, possamos aproveitar. Nas mudanças do monorepo da Anthropic, o número de alterações incorporadas

02:09 por dia passou de algo como 2.500 em maio para mais de 30.000 em setembro. É um salto enorme. O Claude Code tem um repo próprio separado e está sob o mesmo tipo de pressão. Então, dá para imaginar que, nesse ritmo, uma revisão manual linha por linha não vai acontecer. Nas palavras deles, é extremamente difícil, se não impossível. Então, a pergunta que fazem a si mesmos é: para que serve a revisão de código? Bem, ela cumpre duas funções. A primeira é detectar problemas antes de serem lançados; a segunda é disseminar o entendimento do codebase

02:39 pela equipe. Porque, historicamente, quando você revisa o código de outras pessoas, passa a ter uma ideia do que está acontecendo e de como os outros trabalham. Então, a equipe voltou aos primeiros princípios nesse caso, e a pergunta acabou mudando. Em vez da pergunta de antes — uma pessoa revisou este código? —, eles perceberam que essa sempre foi apenas uma forma indireta de fazer a pergunta real: o que poderia dar errado com este código que acabou de ser enviado? E, então, qual verificação — automatizada ou feita por uma pessoa — é a mais adequada para detectar isso? E, obviamente, seria ótimo se pudéssemos reduzir ao máximo o gargalo causado pelas pessoas.

03:10 Agora, isso realmente parece que os desenvolvedores estão sendo substituídos no processo de revisão. Não acho que seja isso. Trata-se de levar nós, desenvolvedores, a um ponto melhor do processo. Bem, pelo menos espero que sim, senão vou ficar sem emprego. Outra coisa que mudou foi o momento em que a revisão acontece. Agora ela ocorre em outro ponto. Antes, era uma única verificação feita no final, logo antes de uma mesclagem. Mas agora, por causa dos agents, ela pode acontecer desde o primeiro prompt até a mesclagem, com verificações constantes ao longo do caminho. É mais como a verificação ortográfica enquanto você escreve. A próxima coisa que fizeram foi estabelecer uma meta ambiciosa: a maioria dos PRs nos

03:44 repos do Claude Code deve ser mesclada com, no máximo, uma pessoa no processo. E essa pessoa pode ser quem escreveu o código. Isso é uma mudança, porque normalmente a revisão era feita por outra pessoa. Era um segundo par de olhos. Então, eles acompanham as aprovações humanas por pull request, os comentários associados a esses pull requests e também quanto tempo cada pull request espera por uma pessoa antes de ser incorporado. Essas são as novas métricas que entram em jogo e que podem complementar ou até substituir as métricas DORA tradicionais. E a proteção que aplicam aqui são as taxas de reversão e de incidentes, porque, se elas aumentarem, não teremos

04:17 economizado tempo das pessoas, apenas o teremos transferido para outro lugar. Então, basicamente, se estamos fazendo com que os agents cuidem de toda a codificação e temos grandes quantidades de commits, pull requests e mesclagens, isso é fantástico. Mas será que o cliente acaba ficando realmente irritado? Os recursos estão quebrando? As coisas estão falhando cada vez mais? Porque isso significa que estamos apenas corrigindo os problemas mais tarde no processo. É isso que queremos evitar. Então, eles resumem todo o sistema como seis camadas de verificações, com reversões por baixo delas. Já falo sobre reversões há algum tempo. A grande ideia

04:47 aqui é que você pode deixar os agents agirem com o nível de restrição que quiser, mas, se algo der errado, há uma reversão para trazê-los de volta antes que isso entre em produção ou tenha qualquer impacto no cliente. Então, poucos problemas passam pelas seis camadas, e as reversões dão conta do restante caso algum problema consiga passar. A primeira camada é a verificação antes de alguém olhar. São todas aquelas verificações que fazemos: testes no navegador etc. Hoje, a maior parte da revisão acontece antes mesmo de o pull request existir. Então, o Claude recebe algo que pode executar, roda testes, compila, tira capturas de tela, faz testes de

05:21 integração. Em vez de simplesmente dizer “Sim, está pronto”, ele precisa provar que está pronto e mostrar o resultado. Então, um subagent entra em ação e revisa o diff com uma context window completamente nova. Bar Shirni, todos nós o conhecemos, é o criador do Plug Code. Tenho vários vídeos sobre ele na lista de vídeos para fazer, caso queira dar uma olhada. Ele estima que a verificação torna o resultado final de duas a três vezes melhor. Então, quando a mesma observação continua aparecendo, eles corrigem o problema na origem. O CLAUDE.md ou o AGENTS.md é um arquivo curto que descreve a stack do projeto,

05:52 as convenções e os objetivos, e os responsáveis pelo código escrevem o REVIEW.md, que explica ao revisor o que é importante no código deles. Você vai perceber que muitas ferramentas de revisão de código podem implicar demais com detalhes, apontando falsos positivos sobre coisas que talvez estejam um pouco erradas, mas que não afetam realmente o código. É importante impor um limite a isso para que essas pequenas alterações não nos sobrecarreguem. Outro problema de implicar demais com detalhes é que a ferramenta pode apontar problemas em versões anteriores do código que foram simplesmente incluídas no PR, mas que não fazem parte da mudança em questão. Já vi isso nos meus próprios workflows de produção e limitei o número de

06:24 apontamentos minuciosos por causa disso. Então, a segunda camada é uma revisão por IA em cada PR antes de uma pessoa olhar. Ela lê o diff, ou seja, as diferenças em relação ao repo inteiro, e também a intenção declarada no pull request. Esse revisor verifica cada apontamento antes mesmo de uma pessoa vê-lo. Vários agents procuram bugs em paralelo; depois, um grupo separado vota em cada um desses apontamentos. Então, o revisor só publica um apontamento se um número suficiente deles concordar que o problema é real. Certo, a terceira camada é uma revisão de segurança separada. Então, em

06:55 Nos próprios repos da Anthropic, um pull request não pode ser mesclado enquanto qualquer apontamento da revisão de bugs ou da revisão de segurança continuar em aberto. Então, essa é uma barreira rígida, e voltaremos a essa regra. Certo, a camada quatro cobre as verificações mais triviais que ainda bloqueiam uma mesclagem. São lint, verificação de tipos, testes em todas as plataformas e, claro, um teste de build. O template do pull request também pergunta como o autor testou a mudança e como desfazê-la. Certo, um recado rápido do nosso patrocinador, porque isso tem relação direta com o que estamos desenvolvendo hoje. Mais especificamente, trata-se de controlar o raio de impacto dos seus

07:28 agents. A maioria de vocês conhece a OpenRouter como uma única API que dá acesso a centenas de modelos diferentes. Você pode alternar entre eles, compará-los, e recebe uma única conta. Eu uso o serviço constantemente. Mas eles acabaram de lançar algo que me deixou genuinamente animado. Chama-se Armor e está em beta. O problema é o seguinte: quando seu agent consegue chamar uma ferramenta, ele pode realmente fazer coisas, executar comandos, acessar APIs, mexer nos seus arquivos, e qualquer hook ou filtro de regex que você configurar simplesmente não vai detectar essas chamadas ruins de forma confiável. Então, o Armor fica no meio. Antes de o agent executar uma chamada de ferramenta, o Armor verifica se ela está de acordo com a sua política usando o modelo Jev da Type safe.

08:01 Lembram daqueles caras? Depois, ele pode bloquear qualquer coisa que ultrapasse os limites. A Open router diz que ele supera o classificador automático do Claude code por uma fração do custo. E isso é graças ao modelo system one. Assim, você tem agents mais seguros sem deixá-los mais lentos nem construir todas essas proteções por conta própria. Confira a Open Router e o Armor no link da descrição abaixo. Certo, a camada cinco é a aprovação humana ajustada ao risco. E é aqui que acho que a coisa fica interessante. Mudanças de baixo risco, como documentação, texto ou mudanças aditivas protegidas por uma flag, não precisam de aprovação humana depois que as verificações automatizadas e de segurança ficam

08:34 verdes. O trabalho comum de produto precisa de uma pessoa. E o código de alto risco precisa de duas. Talvez vocês se lembrem de alguns dos meus vídeos anteriores sobre o trabalho de Addy Osmani. Ele trabalhava no Google e agora trabalha na Anthropic. Ele fala bastante sobre esse nível de raio de impacto e sobre quantos aprovadores devem ser envolvidos conforme o nível de criticidade. Basicamente, se algo pode causar uma grande confusão caso dê errado, peça para mais pessoas verificarem. Então, há cinco regras nesse sistema. A primeira é que a mudança feita determina o nível, não o autor. Um classificador lê a mudança e escolhe o nível. Um segundo classificador verifica se ela

09:07 precisa de uma pessoa de qualquer forma, e mudanças em qualquer tipo de arquivo de workflow de CI sempre precisam. Segunda regra: só autores confiáveis, que em sua maioria são da equipe responsável, podem seguir os caminhos mais leves. Terceira: a aprovação de um agent nunca conta como aprovação de uma pessoa. Uma revisão automatizada pode liberar uma mudança de baixo risco. Ela nunca vai preencher a vaga reservada a uma pessoa. É bom ver que ainda somos necessários como parte do processo, pelo menos por enquanto. Certo, a quarta regra: quem pediu a mudança é responsável por ela. Esse é o nível de responsabilidade. Em um PR escrito por um agent, a pessoa que orienta

09:40 as mudanças conta como revisora. Assim, sempre há alguém responsável e alguém a quem responsabilizar. Então, basicamente, esteja você executando centenas de agents ou não, você, como pessoa que orquestra esse sistema, é responsável pelo pull request. Em essência, se um agent fizer um trabalho ruim, o problema é seu. Foi a sua fábrica de software ou o seu nível de revisão que causou isso. A quinta regra: uma aprovação cobre um commit específico. Se um agent enviar um novo commit, alguém precisa aprová-lo novamente. Então, a camada seis é

10:11 a fila de mesclagem. Ela executa novamente todas as verificações em relação ao branch principal com as mudanças aplicadas. Basicamente, se você tem dois PRs acontecendo em momentos diferentes e eles passam juntos, eles não podem se combinar de um jeito que quebre o branch principal. Isso é muito importante quando você está trabalhando com muitos agents diferentes fazendo muitas mudanças diferentes ao mesmo tempo. Depois disso, novos comportamentos são lançados protegidos por uma flag. Primeiro, a equipe interna da Anthropic testa e experimenta para ver se algo está quebrado. Depois, o lançamento vai para um canal mais recente, onde um grupo maior de pessoas e clientes, talvez cerca de mil ou mais, testa. Assim, você descobre rapidamente

10:44 se algo está quebrado e pode reverter a mudança. Se todas essas mudanças correrem bem, você as transfere para o canal estável. Então, a espinha dorsal dessas seis camadas é que elas dependem de detectar rapidamente quando algo dá errado e de reverter rapidamente. As flags são desativadas sem um deploy. Há um rodízio semanal de plantão, e toda análise de incidente pergunta: “Em qual camada deveríamos ter detectado o problema?” É como uma retrospectiva, para podermos continuar melhorando o workflow e o sistema. Como de costume nos textos da Anthropic, eles também reconhecem, na prática, onde estão as lacunas. Então,

11:17 eles dizem que, nesse caso, não têm o que chamariam de disjuntor. Basicamente, se você estiver monitorando seu sistema e perceber que muitas partes do código feitas pelos agents estão começando a ser revertidas, vai querer apertar o controle do sistema bem rápido. É isso que eles chamam de disjuntor. É como uma fábrica típica. Se você tem um processo de engarrafamento de Coca-Cola e há um defeito na segunda etapa do processo inteiro, é melhor que todo o sistema pare ou desacelere, para que isso não afete um lote enorme de trabalho mais adiante. Nas palavras da Anthropic, o argumento é que desacelerar reduz a taxa de erros, principalmente porque você está

11:50 fazendo menos de tudo. Eles preferem ficar mais rápidos em perceber e corrigir problemas a deixar que um monte deles apareça. Agora, aqui está a história interessante que prometi. Um pull request da CLI do Claude Code passou por mais de 50 rodadas de revisão e correções feitas por IA durante a noite, antes que o autor o interrompesse. Então, todos aqueles níveis de revisão de que estamos falando ficaram girando e girando, porque ninguém estava acompanhando durante a noite. Quando executaram o git blame no que o revisor continuava sinalizando, com o git blame você consegue basicamente fazer uma análise de causa raiz e descobrir qual era o problema. Então, cerca de 59% desses problemas recorrentes que tentaram corrigir várias vezes eram código que já estava lá desde a primeira versão. Não necessariamente encontravam novos bugs. A cada rodada, encontravam mais alguns bugs antigos. Porque o que fizemos aqui foi criar um sistema que verifica e verifica e verifica. Se está tentando ser proativo, se está tentando fazer um bom trabalho, provavelmente vai continuar encontrando esses problemas. E acabamos presos nesses ciclos bobos. Então, a questão é mesmo saber até que ponto insistir e quando parar. E essa é realmente a armadilha dos agents. Uma pessoa pode ignorar uma implicância com seu código ou uma mudança baseada em preferência em alguns segundos, enquanto um agent, por ser proativo,

12:21 tenta corrigi-la, o que significa mais um commit, mais uma revisão, mais uma rodada. E é por isso que as fábricas de software são sistemas em constante mudança. Já falei muito sobre isso. Os desenvolvedores têm medo de onde se encaixam em tudo isso. Agora, você está projetando, construindo e cuidando de um sistema em constante mudança e crescimento, que só vai se tornar mais ambicioso com o passar do tempo. Vamos poder fazer coisas incríveis com essas fábricas de software se você começar a aprendê-las, se aproximar delas e se envolver. Então, nesse caso, a solução da Anthropic foi estabelecer limites para o número de rodadas de revisão. Depois de três rodadas, o revisor pediu ao autor que

12:55 parasse e repensasse toda a abordagem. Será que estamos exagerando um pouco? Nas rodadas seguintes, o revisor só revisa de novo o diff exato e sinaliza toda a categoria do bug em vez de apenas aquela linha, porque lidar com a categoria inteira significa resolver o problema por completo, sem deixar que ele apareça mais tarde. Além disso, o apontamento nunca se repete. E é aqui que entram os evals de agents, ou avaliações. Eles transformaram incidentes anteriores em um eval. Para fazer isso, usaram pull requests reais que de fato causaram incidentes no fluxo. Eles contaram com engenheiros que conhecem aquele código

13:26 dar um passo atrás e repensar toda a abordagem. Estamos exagerando um pouco? Nas passagens posteriores, o reviewer analisa novamente apenas o diff exato e aponta toda a categoria de bug, em vez de só aquela linha, porque, com toda a categoria reunida, estamos tratando o problema por completo; ele não vai aparecer mais adiante e, então, o apontamento nunca se repete. E é aqui que entram os evals de agent, ou avaliações. Eles transformaram incidentes anteriores em um eval. Foi assim que fizeram: pegaram pull requests reais que de fato causaram incidentes no fluxo. Eles tinham engenheiros que conheciam aquele código

13:58 confirme-os e, agora, execute o revisor diariamente contra esse conjunto. Está melhorando ou piorando? Esse é o benchmark deles. Então, onde o produto de revisão de código na nuvem se encaixa? Ele acabou de ficar disponível para o público em geral, pelo menos no nível empresarial; esperamos que chegue em breve a todos os outros. Essa é a versão pública da camada dois deles: a revisão por IA em cada pull request. Os agents analisam o diff em paralelo e, em seguida, uma etapa de verificação filtra os falsos positivos. Isso acontece bastante se você já usou qualquer outro tipo de ferramenta de revisão de código, sabe do que estou falando. Depois, os resultados são classificados por gravidade

14:29 e são publicados comentários em linha e uma verificação. A Anthropic afirma que, com isso, a maioria das revisões agora é cerca de três vezes mais rápida: antes levava aproximadamente 20 minutos, e agora leva de seis a 10. Você pode escolher entre rápida, padrão ou profunda para cada repo e, é claro, a análise mais profunda custa mais. Então, lembre-se de que falamos daquela regra da camada três: o produto nunca aprova nem bloqueia um PR. Isso corresponde às regras internas deles, segundo as quais a aprovação do agent nunca conta como aprovação de uma pessoa. Localmente, no Claude Code, no cursor ou em qualquer ferramenta desse tipo, a revisão de código faz uma análise mais superficial antes de você

15:01 abrir um PR, e a revisão de segurança cobre a camada de segurança. Como desenvolvedor, pessoalmente, o que eu faria seria estudar como eles estão fazendo isso e, depois, criar minha própria versão ou meu próprio agent para fazer exatamente a mesma coisa, de acordo com a maneira como eu ou minha empresa gostamos de trabalhar. Certo, mais um último tópico rápido: algo que talvez não afete todo mundo agora, mas que pode nos afetar no futuro. A Anthropic substituiu o Git no mono repo por um sistema interno chamado Seon, além de uma ferramenta de revisão que estão chamando de antique. Esse é um problema específico da Anthropic. O branch principal tem quase 100 GB de histórico, e o CI faz checkout dele

15:36 25 milhões de vezes por dia. Uma equipe de sete pessoas desenvolveu isso na Anthropic e concluiu a migração em cerca de cinco meses, o que dá uma ideia da escala desse projeto. Até onde sei, ninguém de fora da Anthropic testou isso, mas eles relatam que ocupa 200 vezes menos espaço do que o antigo espelhamento do Git. Então, isso é realmente interessante, mas o que uma equipe comum pode copiar agora? Primeiro, dê ao seu agent verificações que ele possa executar. Adicione um review.md. Coloque um revisor de IA em um repo e ajuste-o por algumas

16:08 semanas. Defina níveis de risco de acordo com a mudança, não com o autor. Qual é o raio de impacto dessa mudança? Nunca deixe a aprovação de um agent substituir a de uma pessoa e meça quantos reverts você está tendo ou quantas coisas inevitavelmente estão dando errado. Então, esta é uma questão subjetiva. Digam nos comentários: vocês deixariam um pull request de baixo risco ser integrado sem nenhuma aprovação de vocês, como pessoas, se todas as verificações no workflow da sua fábrica estivessem verdes? E isso depende mesmo do tipo de base de código em que vocês trabalham ou de qual é o raio de impacto

16:39 Então, me digam sim ou não e expliquem por quê. E quero muito saber a opinião dos desenvolvedores que trabalham na área. Não estou falando dos seus projetos feitos com vibe coding. Se você quer aprender a desenvolver com agents como esses, é para isso que existe o programa de aceleração da switchdimension.com. Confira; o link está na descrição. Se esta análise foi útil, inscreva-se, porque vem muito mais conteúdo desse tipo. E, se você se interessa pelo ciclo de vida do desenvolvimento de software descrito pela Anthropic, confira este vídeo de algumas semanas atrás sobre intenção.

Transcrição original

[00:00] So, Claude Code now writes about 90% of its own code, and things are really speeding up at Anthropic. If you’re looking at the web app at the moment, the rate of change is really fast. So, something is working. Between June and September, merged pull requests, that’s work being done, more than doubled. But, the key thing here is the code that was being reverted or had previously been going wrong dropped by 40%. So, what the heck is going on at Anthropic? Well, what I’ve tried to do is piece it together from several different sources over the last couple of days, so you can learn how to move at this pace. And all

[00:32] the while, I’m doing my best to separate the marketing hype from the actual practical gains that I’m seeing other companies I’ve worked with apply in this space. So, anyone who’s been working with agents realize there’s no problem running a hundred different agents on your codebase. The big problem is you get a ton of code showing up, and it has to get reviewed and checked in some way. Most of the organizations I talk to, their biggest issue is the code review. So, the Claude Code team just published how they review code now, and this is their key line. We didn’t remove review, but we did move most of the reading to

[01:04] machines optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes. AKA, the blast radius and the recoverability from that blast. So, I’m Rob from Switch Dimension. I’m going to walk you through Anthropic’s process layer by layer, and then I’m going to show you where Claude Code’s review product fits in. And it isn’t actually where you’d assume. And then I’m going to finish with a quick look at Seon. It’s their replacement for Git, which fits into this whole process. So, if you’re a practicing developer, I would definitely hang around. We’ll also talk about this one pull request that Anthropic had that went through 50

[01:37] rounds of AI review overnight. Is that overkill? Let’s take a look. Now, let’s bear in mind that Anthropic have a ton of inference to throw at all of these problems. They might not fit exactly how you like to build, but it is giving us indications of where things might be going. And let’s also bear in mind that Anthropic are, of course, selling inference and selling a big dream and vision of where this is all going. So, keep that in the back of your mind as we look through their process. That’s not to say there’s some gold in there for us developers to take away. So, across Anthropic’s mono repo changes landing

[02:09] per day went from something like 2,500 in May to more than 30,000 in September. That is a big leap. Claude Code has its own separate repo and that is under the same kind of pressure. So, you can imagine at that speed manual line by line review isn’t going to happen. In their words, it’s incredibly difficult if not impossible. So, the question they’re asking themselves is what is code review for? Well, it does two jobs. One is catch problems before they ship and then two is spread understanding of the code base

[02:39] across the team. Because when you’re reviewing other people’s code historically, you’re getting a sense for what’s going on and how other people are working. So, the guys went back to first principles on this one and with that the question kind of changed. So, instead of what it used to be, did a human review this code, they realized that was always a proxy for the real question was what could go wrong with this code that’s just been submitted? And then with that, which check is it going to be automated or human is the right one to catch it? And obviously, it’s great if we could reduce the bottleneck of humans as much

[03:10] as we can. Now, that really sounds like developers being replaced in the review process. I don’t think it is. It’s about moving us as developers to a better point in the process. Well, at least I hope it does or else I’m out of a job. The other thing that’s changed is where review happens. It’s at a different point now. It used to be one check we did at the end just before a merge. But now, because of agents, it can run all the way from the first prompt to the merge, constant checks as we move. So, it’s more like spell check as you write. So, next thing they did was they set a bold goal. So, most PR’s in Claude Code

[03:44] repos should merge with at most one human in the loop. And that one human can be the author. Now, that’s a change because usually review happened by somebody else. It was a second pair of eyes. So, they track human approvals by pull requests and also the comments that go with those pull requests and then how long that pull request waits on a person before it gets pushed through. These are the new metrics that are coming into play that might supplement or even replace traditional Dora metrics. And so, the guardrail that they’re applying here is the reversion and the incident rates because if those go up, we haven’t

[04:17] saved human time, we’ve only moved it somewhere else. So, basically, if we’re getting agents to do all of the coding and we’re getting these major amounts of commits and pull requests and merges, that’s fantastic, but are we seeing that the customer is really peeved off at the end? Are features breaking? Are things falling over more and more? Because that means we’re just fixing up the problems later on in the process. That’s what we want to avoid. So, they sum up the whole system as six layers of checks with rollbacks underneath them. I’ve been talking about rollbacks for a while. The great idea

[04:47] here is that you can let agents run loose with their level of constraint, but if something does go wrong, you have a rollback to pull them back before it actually goes live or it has any impact on the customer. So, few problems get through all six layers and then you’ve got rollbacks to handle the rest if they do get through. So, layer one is verification before anyone looks. It’s all that checking that we do, the browser tests, etc. So, most review now happens before that pull request actually exists. So, Claude gets something it can run, it can run tests, it can build, take screenshots, do some

[05:21] integration testing. So, instead of it just saying, “Yeah, it’s done.” it actually has to prove it’s done and show the output. So, then a sub agent jumps in and reviews the diff with a completely fresh context window. Bar Shirni, we all know him, he’s the creator of plug code. I’ve got several videos on him in the backlog if you want to take a look. He estimates that verification makes the final result two to three times better. So, when the same finding keeps coming up, they fix it at source. So, Claude at MD or agents.md is a short file that describes the project stack,

[05:52] conventions, and goals, and code owners write review.md, which tells the reviewer what matters in their code. You’ll see in a lot of code review tools, they can do a lot of nitpicking, kind of these false positives of things that are probably a bit off, but are not really affecting the code. It’s important that you put a cap on those so you’re not overwhelmed by these small changes. The other problem with nitpicking is it can actually call out issues with previous generations of code that were just pulled into the PR that are not actually part of the change that’s being made. This is something I’ve seen in my own production workflows and have limited the number of

[06:24] nitpicking because of this. So, layer two is an AI review on every PR before a person looks. It reads through the diff or the difference against the whole repository and then what the pull request stated intent is. So, this reviewer is checking each finding before a human even sees it. Several agents will hunt for bugs in parallel, then a separate group votes on each one of those findings. Then the reviewer only posts a finding if enough of them agree it’s real. Okay, so layer three is a separate security review. So, on

[06:55] Anthropic’s own repos, a pull request can’t merge while any finding from the bug review or the security review is still open. So, that’s a hard gate there and we’ll come back to that rule. Okay, so layer four covers the boring checks that still block a merge. So, this is lint, type checking, testing on every platform, and then of course a build test. The pull request template also asks how the author tested the change and then how to undo it. Okay, quick word from our sponsor because this one ties directly into what we’re building today. Specifically, it’s about controlling the blast radius of your

[07:28] agents. So, most of you know OpenRouter as one API that gets you hundreds of different models. You can swap between them, compare them, it’s all one bill, and I use it constantly. But they just launched something I’m genuinely excited about. It’s called Armor and it’s in beta. So, here’s the problem. Once your agent can call a tool, it can actually do things, run commands, hit APIs, touch your files, and any hook or regex filter that you set up just won’t catch these bad calls reliably. So, armor sits in between. Before your agent runs a tool call, armor checks it against your policy using Type safe’s Jev model.

[08:01] Remember those guys? And then it can block anything that’s out of bounds. Open router says it beats Claude code’s auto classifier at a fraction of the cost. And that’s thanks to the system one model. So, you get safer agents without slowing them down or building all these guardrails yourself. Check out Open Router and Armor at the link in the description down below. Okay, layer five is human approval scaled by risk. And this is where I think it gets interesting. Low-risk changes like docs, copy, or additive changes behind a flag, they don’t need any human approval once the automated and security checks are

[08:34] green. Ordinary product work needs one person. And then high-risk code needs two. You might remember some of my past videos on some of Addy Osmani’s work. He was originally from Google and now works on Anthropic. He talks a lot about this level of blast radius and how many approvers should be applied to levels of criticality. Basically, if it’s going to make a big mess if it goes wrong, have more people check it. So, there are five rules in this system. The first one is the change that’s being made sets the tier, not the author. A classifier reads the change and then picks the tier. A second classifier checks whether it

[09:07] needs a person anyway, and any kind of changes to a CI workflow file always will. Second rule, only trusted authors, and they’re mostly from the owning team, get the lighter paths. Third, an agent’s approval never counts as a person’s. Automated review can clear a low-risk change. It’s never going to fill the human slot. Nice to see we’re still required as part of the process, at least for the next little while anyway. Okay, the fourth rule, whoever prompted the change is on the hook. This is the responsibility level. On an agent-written PR, the person directing

[09:40] the changes counts as the reviewer. So, there is always accountability and someone to point the finger at. So, basically, whether you’re running hundreds of agents or not, you as a person for orchestrating this system is responsible for the pull request. Essentially, if an agent does a bad job, it’s your problem. It was either your software factory or your level of review that caused this. The fifth rule, an approval covers one specific commit. If an agent pushes a new commit, someone has to approve again. So, layer six is

[10:11] the merge queue. It reruns every check against the main branch with the changes applied. So, basically, if you’ve got two PRs that are happening at different times and they pass through together, they can’t combine in a way that’s going to break the main. This is a big deal when you’re running with lots of different agents running lots of different changes at the same time. After that, new behavior ships behind a flag. First of all, it goes to the internal team at Anthropic to have a play with it and see if anything’s broken. Then, it goes to a latest channel where wider group of people and customers, maybe about a thousand or more, test it and you’ll quickly figure

[10:44] out if something is broken or not and then you can roll back the change. If all of those changes go okay, then you move it to the stable channel. So, the backbone of these six layers is they rely on fast detection when things go wrong and fast rollback. Flags will switch off without a deploy. There’s weekly on-call rotation and then every incident review asks, “Which layer should we have caught the problem on?” This is kind of like a retrospective, so we can keep improving the workflow and the system. So, as usual in any of Anthropic’s writings, they also admit practically where the gaps are. So,

[11:17] they’re saying in this case they don’t have what they would call a circuit breaker. So, essentially, if you’re watching your system and then you’re seeing that lots of the code the agents are doing is beginning to be reverted, you want to crack down on your system pretty quick. That’s what they’re calling a circuit breaker. This is like a typical factory. If you have a bottling process for Coca-Cola and there’s a defect on level two of the entire process, you kind of want the whole system to shut down or slow down so it doesn’t affect a huge batch of work later on. In Anthropic’s words, the argument is that slowing down lowers your error rate, mostly because you’re

[11:50] doing less of everything. They’d rather get faster at noticing and fixing problems than have a ton of problems show up. Now, here’s the interesting story I promised. One Claude code CLI pull request went through more than 50 rounds of AI review and fixes overnight before its author stopped it. So, all those levels of review we’re talking about just went round and round and round because nobody was watching it overnight. So, when they ran the git blame on what the reviewer kept flagging, using git blame you can basically do a root cause and find out what the issue was. So, about 59% of

[12:21] these issues that kept showing up that they tried to fix over and over was code that had been there since the first pass. It wasn’t necessarily finding new bugs. It was finding a few more old ones every single round. Because what we’ve done here is created a system that checks and checks and checks. If it’s trying to be proactive, if it’s trying to do a good job, it’s probably going to keep finding those issues. And we get caught into these silly little loops. So, it really is about knowing how much and how little. And that really is the trap with agents. A person can wave off a nitpick to their code or a preferential change in a couple of seconds where an agent, being proactive,

[12:55] tries to fix it, which means another commit, another review, another round. And this is why software factories are a moving system. And I’ve talked about this loads. Developers are afraid of where they stand in all this. You are now designing and building and curating a moving and growing system that’s only going to get more ambitious as time goes on. We’re going to be able to do amazing things with these software factories if you start learning them and start hanging around and get invested. So, in this case, Anthropic’s fix was a number of review round caps. After three rounds, the reviewer asked the author to

[13:26] step back and rethink the whole approach. Are we going a little bit overboard here? On later passes, the reviewer only re-reviews the exact diff, flags the entire class of a bug instead of just that one line, because having the whole class together means we’re attacking the whole thing, it’s not going to surface later on, and then it never repeats the finding. And here’s where agent evals come in, or evaluations. They turned past incidents into an eval. So, how they do this is they took real pull requests that actually caused incidents in the flow. They had engineers who know that code

[13:58] confirm them, and now run the reviewer against that set every day. Is it improving or is it getting worse? This is their benchmark. So, where does the cloud code review product fit in? It just went generally available, at least at the enterprise level, hopefully coming soon to everyone else, and it’s their public version of their layer two, the AI review on every pull request. So, agents search the diff in parallel, and then a verification step filters out false positives. This happens quite a lot if you’ve used any other kind of code review tools, you know what I mean. Then it ranks the findings by severity

[14:29] and posts inline comments and a check run. So, Anthropic are claiming with this that most reviews are now about three times faster, and that’s from roughly about 20 minutes previously down to about six or 10. You can pick quick, standard, or deep per repository, and then of course the deeper costs more. So, remember we talked about that layer three rule, the product never approves or blocks a PR, and that matches their own internal rules that the agent’s approval never counts as a person. Locally in cloud code or cursor or anything else like that, the code review will give you a lighter pass before you

[15:01] do a PR, and then security review covers the security layer. As a developer, personally what I would do is just study how they’re doing this, and then build my own version or my own agent to do exactly the same thing based on how I or my company likes to work. Okay, so one last quick topic, something that might not affect everyone now but may affect us in the future. Anthropic went and replaced Git on its mono repo with an in-house system called Seon plus a review tool they’re calling antique. So, this is a unique problem that Anthropic had. The main branch has almost 100 GB of history and their CI checks this out

[15:36] 25 million times a day. A team of seven people have been building this at Anthropic and they finished the migration in about 5 months, which gives you an idea of the scale of this project. Nobody outside Anthropic has tested this as far as I know, but they report a footprint of 200 times smaller than their old Git mirroring. So, this is really interesting stuff, but what can a normal team copy right now? So, number one, give your agent checks it can run. Add a review.md. Put an AI reviewer on one repo and tune it for a

[16:08] couple of weeks. Set risk tiers by the change, not by the author. So, how big of a blast radius does this have? Never let an agent’s approval replace a human’s and measure the amount of reverts you’re getting or the amount of things that are going wrong inevitably. So, this is a subjective one. Tell me in the comments, would you let a low-risk pull request merge without any approval by you as a human if every check in your factory workflow was green? And that really depends on the type of code base that you do work in or what the blast

[16:39] radius is. So, let me know yes or no and then why. And I really want to know from the practicing developers here. I’m not talking about your vibe coded projects. If you want to learn how to build with agents like this, that’s what the switchdimension.com accelerator is for. Go check it out, the link is in the description. If this breakdown was useful, subscribe because there’s a lot more like this coming. And if you’re into the software development life cycle that Anthropic describes, check out this video from a couple of weeks ago about intent.