Como a Anthropic realmente revisa código de IA (30 mil mudanças por dia)

Autoria: Hyperautomation Labs · 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: How Anthropic ACTUALLY Reviews AI Code (30,000 Changes a Day) · Canal: Hyperautomation Labs · 12:22 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Claude Code, Engenharia de software com IA

Resumo

A equipe do Claude Code, da Anthropic, ampliou o volume de mudanças sem depender da leitura humana de cada linha: os pull requests mais que dobraram, enquanto os rollbacks caíram mais de 40%. O processo combina sete camadas de revisão, desde testes e análises feitas por agentes até verificações de segurança, níveis de risco, fila de merge e monitoramento após o lançamento. Para evitar ciclos intermináveis entre agentes, a equipe limitou as rodadas e ajustou o sistema para priorizar novas mudanças e não repetir achados. O papel das pessoas passa a se concentrar em decisões de arquitetura, áreas de alto risco e responsabilidade pelo que é enviado.

Pontos-chave

A equipe substituiu a leitura de cada linha por uma pergunta mais útil: o que pode dar errado e qual verificação é adequada para detectar o problema?
Antes de abrir um pull request, o agente deve executar verificações e apresentar evidências, como resultados de testes ou capturas de tela.
Uma segunda análise é feita em contexto separado, e vários agentes podem avaliar possíveis problemas cujos achados são filtrados por votação.
Regras de lint, arquivos de instruções do projeto e orientações de revisão ajudam a corrigir padrões recorrentes na origem.
Os pull requests passam por revisões automatizadas, análises de segurança e verificações de lint, tipos, testes e build.
O nível de risco determina quantas aprovações humanas são necessárias; a aprovação de uma IA não conta como aprovação humana.
A fila de merge reexecuta as verificações sobre o código atualizado, e novos comportamentos podem ser lançados gradualmente atrás de flags.
Para reduzir ciclos excessivos entre agentes, a equipe limita as rodadas, concentra novas revisões nas mudanças recentes e evita repetir achados.
Incidentes e rollbacks confirmados por engenheiros são transformados em casos de teste para avaliar o reviewer.
Pessoas continuam responsáveis por decisões de produto e arquitetura, mudanças de alto risco e pelo resultado de cada alteração enviada.

Capítulos

Início	Capítulo	Resumo
00:01	O desafio de revisar mais código	A Anthropic aumentou o volume de mudanças e trocou a leitura linha a linha por verificações orientadas ao risco.
02:35	As primeiras camadas de revisão	O agente testa a mudança, outro agente a revisa em contexto separado e vários reviewers automatizados filtram achados.
05:08	Segurança, verificações e níveis de risco	Revisões de segurança, testes automatizados e regras de risco definem quais mudanças exigem aprovação humana.
07:43	Como limitar ciclos de revisão entre agentes	A equipe reduziu rodadas repetitivas e criou um conjunto de testes para medir a qualidade e o ruído do reviewer.
10:19	Responsabilidade humana e como começar	O vídeo explica as decisões que continuam a cargo das pessoas e apresenta passos práticos para adotar o processo.

Citações

A pergunta melhor é: o que pode dar errado com esta mudança? — 01:34

Boris Cherny chama isso provavelmente de a coisa mais importante. — 03:05

A aprovação de uma IA nunca conta como aprovação humana. — 06:40

Você envia a mudança, você é responsável por ela. — 10:50

Conceitos e entidades

Anthropic (empresa): Empresa responsável pelo Claude Code e pelo processo de revisão de código descrito no vídeo.
Claude Code (ferramenta): Produto da Anthropic cuja equipe aplica as práticas de revisão apresentadas.
Boris Cherny (pessoa): Criador do Claude Code, citado ao destacar a importância da revisão em contexto separado.
Revisão adversarial por agentes (conceito): Método em que agentes examinam possíveis bugs de perspectivas diferentes e um grupo separado filtra os achados.
Níveis de risco (conceito): Classificação das mudanças que determina quantas aprovações humanas são exigidas.
Fila de merge (conceito): Etapa que reexecuta as verificações sobre o código atualizado antes de combinar uma mudança.
Conjunto de testes do reviewer (conceito): Coleção de incidentes e rollbacks confirmados por engenheiros usada para avaliar diariamente o reviewer.
Flags (conceito): Mecanismo que permite desativar funcionalidades sem um novo deploy e liberar mudanças gradualmente.

Tradução completa (pt-BR)

00:01 A equipe do Claude Code, da Anthropic, parou de ler cada linha de código >> [música] >> e os rollbacks caíram 40%. Veja qual problema eles resolveram. É segunda-feira de manhã. Há 14 pull requests esperando por você. Metade foi escrita por um agent enquanto você dormia. Você abre a primeira. Deixa três comentários pequenos, renomeia isto, adiciona um espaço para parecer que leu. E clica em aprovar. Os próprios engenheiros da Anthropic conhecem essa jogada. >> Alguém ia lá revisar o

00:32 código e escolhia, sabe, três pequenas implicâncias para comentar. Era mais ou menos como dizer: estou sinalizando que li este código. >> É. >> Veja por que isso importa. Dentro da Anthropic, as alterações de código feitas por dia passaram de cerca de 2,5 mil em maio para mais de 30 mil em setembro. Doze vezes mais código. Nenhum ser humano consegue ler tudo isso. E, mesmo assim, na equipe do Claude Code, o número de pull requests mesclados mais que dobrou, enquanto a parcela que

01:03 precisou ser revertida caiu mais de 40%. Mais código, menos erros. Nesta semana, eles publicaram exatamente como fazem isso. São sete camadas, mais um problema que eles mesmos criaram e que passou por 50 rodadas durante a noite. Ao final deste vídeo, você vai poder copiar cada parte. Primeiro, descartaram a pergunta que todo mundo faz: um ser humano leu o código? Eles chamam isso de indicador impreciso. A pergunta melhor é: o que pode dar errado com esta

01:34 alteração? E qual verificação, automatizada ou humana, é a mais adequada para detectar isso? Essa única pergunta muda o momento em que a revisão acontece. Antes, ela era um portão no fim do caminho. Escreva o código, abra o pull request, espere por um colega. Agora, a revisão acontece o tempo todo, como a correção ortográfica enquanto você digita. A maioria das alterações já foi revisada e corrigida pelo Claude pelo menos uma vez antes mesmo de pedirem para um ser humano dar uma olhada. E eles deixam claro o que estão protegendo: a atenção humana. A revisão custa tempo duas vezes.

02:04 O tempo que as pessoas passam lendo e o tempo que passam consertando o que o código ruim estraga. Se você reduz o primeiro, mas o segundo aumenta, não economizou nada. Só transferiu o tempo de lugar. Então, o objetivo é que a maioria dos pull requests seja mesclada com no máximo uma pessoa no processo, que pode ser o autor, >> [música] >> sem aumento de reversões ou incidentes. Esse número de reversões é a proteção. Fique de olho nele. Então, vamos acompanhar uma alteração pelo sistema inteiro. Digamos que um engenheiro peça

02:35 ao Claude que corrija um bug no atualizador automático, o código que atualiza o Claude Code na sua máquina. Imagine o sistema como fatias de queijo suíço. >> [música] >> Cada camada tem buracos. Cada uma detecta alguns problemas e deixa outros passarem, mas pouquíssimos bugs atravessam todas elas, e os que conseguem são revertidos rapidamente. A primeira camada acontece antes mesmo de existir um pull request. Claude recebe algo que pode executar, como testes, uma compilação ou uma captura de tela para comparar com o design. E precisa

03:05 mostrar o resultado em vez de apenas dizer que terminou. Depois, um segundo agent revisa a alteração em um contexto novo, sem nenhuma das suposições do primeiro agent. Boris Cherny, que criou o Claude Code, diz que isso provavelmente é o mais importante e estima que melhora o resultado de duas a três vezes. >> Quando o Claude cria um PR para mim no Claude Code, >> Sim. >> ele testa, me envia capturas de tela de como ficaria, e aí você ganha confiança. >> E aqui está a parte inteligente. Quando o revisor continua apontando o

03:36 mesmo erro, eles não continuam corrigindo à mão. Corrigem na origem, com uma regra de lint, uma skill ou dois arquivos pequenos. Claude.md diz ao Claude o que é o projeto. Review.md, escrito pelas pessoas responsáveis por aquele código, diz ao revisor o que importa ali. Os bons arquivos explicam como é uma falha naquele repo. Na documentação, a falha é ela mentir. Na configuração, é ela encaminhar algo para o lugar errado. Eles limitam as implicâncias, listam os caminhos a ignorar e exigem um arquivo e um número de linha como

04:07 evidência, não um palpite. Camada dois. Cada pull request recebe uma revisão na nuvem antes de uma pessoa olhar. Ela analisa a alteração em relação ao repo inteiro e faz três perguntas: resolve o problema? Se encaixa no sistema? Quebra outra coisa? Aqui está o que me surpreendeu. Não é um único revisor de IA. Vários agents procuram bugs ao mesmo tempo. Depois, um grupo separado vota em cada descoberta. E uma descoberta só é publicada se houver concordância suficiente de que é real.

04:38 >> Para cada bug, você pode fazer uma revisão adversarial, pedindo que ele examine o bug sob três opiniões ou perspectivas diferentes e veja se o bug realmente existe. Isso filtra todos esses bugs e entrega apenas os mais importantes, que exigem ou precisam da sua atenção. >> Descobertas que tratam apenas de estilo são descartadas. O que sobra aparece como comentários ordenados por gravidade. Cada um é marcado como importante, implicância ou preexistente. Assim, [música] um bug

05:08 que o autor não introduziu não parece culpa dele. Quando lançaram isso internamente, a parcela de pull requests que recebiam comentários de revisão de verdade saltou de 16% para 54%. E é preciso responder a cada descoberta. Corrija ou encerre com uma justificativa. Muitas vezes, um agent assume a correção durante a noite. Assim, você acorda com um pull request que já passou por mais uma rodada. A camada três é uma revisão de segurança separada e pode bloquear a mesclagem. Um pull request não pode ser mesclado enquanto houver qualquer

05:38 descoberta de bug ou segurança ainda em aberto. A camada quatro é a parte menos empolgante, mas ainda importante. Lint, verificações de tipos, testes em todas as plataformas e uma compilação. Uma alteração típica passa por dezenas de verificações antes de alguém olhar. E o modelo de pull request deles faz duas perguntas que toda equipe deveria copiar: Como isso foi testado? E como podemos desfazer a alteração? A camada cinco determina quanto do seu tempo uma alteração recebe. >> [música] >> Uma correção de erro de digitação na documentação e uma alteração no atualizador automático não têm o mesmo risco,

06:09 então não recebem a mesma revisão. Alterações de baixo risco, como documentação, texto ou coisas ocultas atrás de um sinalizador, não precisam de aprovação humana quando as revisões automatizadas são aprovadas. Risco médio, ou seja, alterações comuns no produto e áreas sensíveis como cache, o atualizador automático e system prompts, precisa de uma pessoa. Alto risco precisa de duas. Quatro regras mantêm isso seguro. Primeiro, é a alteração que define o nível, não o autor. Um classificador lê a alteração e escolhe o nível.

06:40 E um segundo classificador pergunta se, mesmo assim, esta alteração precisa de uma pessoa. Segundo, apenas autores confiáveis, principalmente a equipe responsável pelo código, têm acesso aos caminhos mais leves. Terceiro, a aprovação de uma IA nunca conta como aprovação humana. E quarto, minha regra favorita: quem pediu a alteração é responsável por ela. Se você orientou o agent, conta como revisor, como se tivesse escrito o código você mesmo. Mais um detalhe: uma aprovação vale para um commit específico. Se novos commits forem adicionados, você precisa aprovar de novo.

07:12 Camada seis: a fila de mesclagem executa novamente todas as verificações sobre o código mais recente, já com a alteração aplicada. Assim, duas alterações que passam nos testes separadamente não podem se combinar e criar algo quebrado. O novo comportamento é lançado primeiro para os funcionários da Anthropic, por trás de um sinalizador; depois, chega ao canal mais recente, enquanto a versão estável fica atrás. A camada sete parte do princípio de que algo ainda vai passar. Os sinalizadores podem ser desligados sem um deploy. Há um rodízio semanal de plantão, e toda análise de incidente faz uma pergunta: qual camada deveria ter detectado isso? Um engenheiro resumiu bem.

07:43 Ir mais devagar reduz a taxa de erros, mas principalmente porque você faz menos de tudo. Eles preferem ficar mais rápidos em perceber e corrigir os problemas. Se este vídeo for útil, inscreva-se, porque é grátis. E, se quiser apoiar o trabalho, clique em “Join” aqui ou no botão de apoiador no Facebook. Agora, é aqui que a história muda. Quando o autor é uma IA e o revisor também é uma IA, eles podem manter um ao outro ocupado para sempre. Um pull request passou por mais de 50 rodadas de revisão e correções durante a noite, até que o autor o interrompeu.

08:14 50. Então, eles executaram o git blame no que o revisor continuava apontando. Cerca de 59% disso era código que já estava lá desde a primeira revisão do revisor. Ele não estava encontrando bugs novos. A cada rodada, encontrava mais alguns antigos. E eles admitem que pioraram a situação ao executar várias rodadas por padrão em cada alteração. O ruído também custa mais quando o autor é um agent. Uma pessoa descarta uma implicância em dois segundos. Um agent a corrige, e isso significa mais um commit e mais uma rodada. Então, fizeram quatro alterações. Depois de três rodadas, o revisor diz

08:45 para que o autor dê um passo atrás e repense a abordagem. Depois das primeiras rodadas, ele reanalisa apenas as novas alterações. Sinaliza toda a categoria do bug, para que você corrija todas as ocorrências, e não apenas uma linha. E nunca repete uma descoberta. Como resultado, a taxa de aprovação após uma rodada passou de 65% para 78%. A proporção de casos que precisaram de cinco ou mais rodadas caiu de quase 9% para 1,5%. A média de revisões até a aprovação passou de 2,08 para 1,32.

09:16 Eles mantêm o revisor honesto com um ciclo que você pode reproduzir. Cada incidente anterior e cada reversão são confirmados por um engenheiro que conhece aquele código e entram em um conjunto de testes. O revisor é testado com esse conjunto todos os dias. Se mudarem o prompt, as ferramentas ou o modelo e a pontuação aumentar, mantêm a mudança. Caso contrário, descartam. Também acompanham o que as pessoas fazem com cada comentário: corrigem, dizem que está errado, dizem que foi intencional ou decidem que não importa.

09:46 É assim que medem o ruído. Então, o que sobra para os humanos? Esta parte importa para a sua carreira. Tirar um engenheiro sênior do trabalho concentrado para encontrar um erro de digitação custa muito mais do que uma revisão automatizada. Por isso, as pessoas passaram a se concentrar em cinco decisões para as quais as máquinas não são boas. Devemos mesmo desenvolver isso? Código de alto risco, como faturamento, atualizações automáticas e workflows de CI. Arquitetura que define um padrão que outras pessoas vão copiar. Analisar as evidências, a saída dos testes, a captura de tela, as descobertas e assumir a responsabilidade pelo

10:19 resultado. Uma pessoa é responsável por cada alteração que vai para produção, não importa quem a escreveu. >> O importante é entender, talvez, o panorama geral. É como se o Claude talvez não entendesse completamente por que esta API foi estruturada dessa maneira ou, sabe, por que os limites entre os serviços foram definidos em determinado ponto por algum motivo que talvez o Claude não tenha assimilado totalmente ao escrever o PR. >> E, se as máquinas fazem a leitura, como alguém aprende o código? Eles pedem ao Claude que escreva uma explicação exatamente sobre

10:50 a parte que estão prestes a alterar. Uma mudança de cópia de uma linha não ensina nada. Uma explicação do módulo que você está prestes a modificar ensina bastante. A regra deles para o restante é simples: se você faz o merge, a responsabilidade é sua. Isso não é para culpar ninguém. É porque você tem mais contexto para corrigir o problema. Veja como começar esta semana, nesta ordem. Um: dê ao seu agent verificações que ele possa executar, listadas em um arquivo CLAUDE.md curto. Dois: execute /code review e /security review nas suas próprias alterações

11:22 antes de abrir o pull request. Três: adicione um review.md e, sempre que escrever o mesmo comentário de revisão pela segunda vez, coloque-o nesse arquivo. Quatro: adicione testes, riscos e instruções para reverter ao modelo do seu pull request. Cinco: anote os níveis de risco. Comece com critérios rigorosos e só flexibilize com base em evidências. >> [música] >> Seis: limite a três rodadas de revisão. E sete: transforme cada reversão em um caso de teste para o seu revisor. Reuni tudo isso em um kit gratuito, >> [música]

11:52 >> um review.md inicial, o modelo de pull request, uma folha de uma página com os níveis de risco e a lista de verificação em sete etapas. Comente “nitpick” e meu bot vai enviar o kit para você. Falando sério, 90% de vocês que estão assistindo ainda não se inscreveram. No Facebook, o botão de inscrição é o botão de apoio. É isso que mantém as luzes acesas por aqui. No YouTube, é de graça e diz ao algoritmo para recomendar mais conteúdo nosso. Inscreva-se para nos apoiar. Acompanhe a gente no Instagram e no Facebook para ver dicas rápidas de IA; e os guias aprofundados

12:22 ficam aqui no YouTube. Inscreva-se para não perder nenhum. Então, na próxima segunda-feira, quando estiver prestes a deixar três pequenos comentários sobre detalhes irrelevantes para provar que leu o código, faça uma pergunta melhor: o que pode dar errado aqui e qual é a verificação certa para detectar isso? Vejo você no próximo vídeo.

Transcrição original

[00:01] Anthropic’s Claude code team stopped reading every line of code >> [music] >> and their rollbacks fell by 40%. Here’s the problem they solved. It’s Monday morning. 14 pull requests are waiting for you. Half of them were written by an AI agent while you slept. You open the first one. You leave three little comments, rename this, add a space so it looks like you read it. And you click approve. Anthropic’s own engineers know this move. >> You would have someone go and review the

[00:32] the code and they would like pick out like, you know, three little nitpicks to post. And it was kind of just like, I’m signaling to you that I read this code. >> Yeah. >> Here’s why that matters. Inside Anthropic, code changes landing every day went from about 2 and 1/2 thousand in May to more than 30,000 in September. 12 times more code. No human can read that. And yet, on the Claude code team, merged pull requests more than doubled while the share that

[01:03] had to be rolled back fell by more than 40%. More code, fewer mistakes. This week, they published exactly how they do it. It’s seven layers plus one problem they created themselves that ran 50 rounds overnight. By the end of this video, you can copy every piece of it. First, they threw out the question everyone asks, did a human read the code? They call it an imprecise proxy. The better question is this, what could go wrong with this

[01:34] change? And which check, automated or human, is the right one to catch it? That one question changes when review happens. It used to be a gate at the end of the road. Write the code, open the pull request, wait for a colleague. Now, review runs all the time, like spellcheck while you type. Most changes have been reviewed and fixed by Claude at least once before a human is even asked to look. And they’re clear about what they’re protecting. Human attention. Review costs time twice.

[02:04] The time people spend reading, and the time they spend fixing what bad code breaks. If you cut the first, and the second goes up, you saved nothing. You just moved the time. So, the goal is that most pull requests merge with at most one human in the loop, who can be the author, >> [music] >> with no rise in reverts or incidents. That revert number is the guardrail. Keep your eye on it. So, let’s follow one change through the whole system. Say an engineer asks

[02:35] Claude to fix a bug in the auto updater, the code that updates Claude code on your machine. Picture the system as slices of Swiss cheese. >> [music] >> Every layer has holes. Each one catches some problems and misses others, but very few bugs make it through all of them, and the ones that do get rolled back fast. Layer one happens before a pull request even exists. Claude gets something it can run, like tests, a build, or a screenshot to compare against the design. And it has

[03:05] to show the output instead of just saying it’s done. Then a second agent reviews the change in a fresh context with none of the first agent’s assumptions. Boris Cherny, who created Claude code, calls this probably the most important thing, and estimates it makes the result two to three times better. >> When Claude creates a PR for me for Claude code, >> Yes. >> uh it tests it, it sends me screenshots for what it would look like, uh and then you kind of get confidence. >> And here’s the clever part. When the reviewer keeps flagging the

[03:36] same mistake, they don’t keep fixing it by hand. They fix it at the source with a lint rule, a skill, or two small files. Claude.md tells Claude what the project is. Review.md, written by the people who own that code, tells the reviewer what matters there. The good ones say what failure looks like in that repo. For docs, failure is it lies. For config, it’s it misroutes. They cap the nitpicks, list paths to skip, and demand a file and line number as

[04:07] evidence, not a guess. Layer two. Every pull request gets a cloud review before a person looks. It reads the change against the whole repo and asks three things. Does it solve the problem? Does it fit the system? Does it break something else? Here’s the part that surprised me. It isn’t one AI reviewer. Several agents hunt for bugs at the same time. Then a separate group votes on every finding. And a finding only gets posted if enough of them agree it’s real.

[04:38] >> For each bug, you might do an adversarial review where you ask it look at the bug from three different, you know, opinions or perspectives and see if the bug is actually real. What that does is like it filters out all these bugs for you and gives you just the the most important ones that require or need your attention. >> Findings that are only about style get thrown out. What’s left shows up as comments sorted by severity. Each tagged important, knit, or pre-existing. So [music] a bug

[05:08] the author didn’t create doesn’t look like their fault. When they launched it internally, the share of pull requests getting real review comments jumped from 16% to 54. And every finding has to be answered. Fix it or close it with a reason. Often an agent picks up the fix overnight. So you wake up to a pull request that’s already been through another round. Layer three is a separate security review and it can block. A pull request can’t merge while any

[05:38] finding, bug, or security is still open. Layer four is the boring part that still matters. Lint, type checks, tests on every platform, and a build. A typical change runs dozens of checks before anyone looks at it. And their pull request template asks two questions every team should steal. How was this tested? And how do we undo it? Layer five decides how much of your time a change gets. >> [music] >> A typo fix in the docs and a change to the auto updater are not the same risk,

[06:09] so they don’t get the same review. Low risk, like docs, copy, or things hidden behind a flag, needs zero human approvals once the automated reviews are green. Medium, meaning ordinary product changes plus sensitive areas like caching, the auto updater, and system prompts, needs one person. High risk needs two. Four rules keep this safe. One, the change sets the tier, not the author. A classifier reads the change and picks the tier.

[06:40] And a second one asks whether this change needs a person anyway. Two, only trusted authors, mostly the team that owns the code, get the lighter paths. Three, an AI’s approval never counts as a human’s. And four, my favorite, whoever prompted the change is on the hook for it. If you directed the agent, you count as a reviewer, the same as if you type the code yourself. One more detail, an approval covers one exact commit. If new commits land, you approve again.

[07:12] Layer six, the merge queue reruns every check against the latest code with the change applied. So, two changes that pass alone can’t combine into something broken. New behavior ships behind a flag to Anthropic employees first, then to the latest channel with stable trailing behind. Layer seven assumes something still gets through. Flags switch off without a deploy. There’s a weekly on-call rotation, and every incident review asks one question, which layer should have caught this? One engineer put it well.

[07:43] Slowing down does lower your error rate, but mostly because you’re doing less of everything. They’d rather get faster at noticing and fixing. If this video is useful, hit subscribe because it’s free. And if you want to back the work, hit join here or the supporter button on Facebook. Now, here’s where the story turns. When the author is an AI and the reviewer is an AI, they can keep each other busy forever. One pull request went through more than 50 rounds of review and fixes overnight before its author stopped it.

[08:14] 50. So, they ran get blame on what the reviewer kept flagging. About 59% of it was code that had been there since the reviewer’s very first pass. It wasn’t finding new bugs. It was finding a few more old ones every round. And they admit they made it worse themselves by running several rounds by default on every change. Noise also costs more when the author is an agent. A person waves off a nitpick in 2 seconds. An agent fixes it, and that’s another commit and another round. So, they made four changes. After three rounds, the reviewer tells

[08:45] the author to step back and rethink the approach. After the first few passes, it only re-reviews the new changes. It flags the whole class of bug, so you fix every copy of it, not just one line. And it never repeats a finding. The result, passing after one round went from 65% to 78%. Needing five or more rounds dropped from almost 9% to 1 and 1/2. Average reviews to pass went from 2.08 to 1.32.

[09:16] They keep the reviewer honest with a loop you can copy. Every past incident and every revert gets confirmed by an engineer who knows that code, and it goes into a test set. The reviewer runs against that set every day. If they change its prompt, its tools, or its model, and the score goes up, they keep the change. If not, they drop it. They also track what people do with each comment. Fixed it, said it was wrong, said it was on purpose, or decided it didn’t matter.

[09:46] That’s how they measure noise. So, what’s left for humans? This part matters for your career. Pulling a senior engineer out of deep work to catch a typo costs far more than an automated review. So, people moved to five decisions machines are bad at. Should we build this at all? Risky code like billing, the auto up data, and CI workflows. Architecture that sets a pattern others will copy. Reading the evidence, the test output, the screenshot, the findings, and owning the

[10:19] outcome. A person is accountable for every change that ships, whoever typed it. >> What is important is understanding maybe the bigger picture. It’s like maybe Claude doesn’t have a full understanding of why is this API structured the way it is or you know the service boundaries are drawn in a particular spot for a for a reason that maybe Claude hasn’t fully internalized when it was writing the PR. >> And if machines do the reading, how does anyone learn the code? They ask Claude to write an explainer for exactly

[10:50] the part they’re about to change. A one-line copy change teaches you [music] nothing. An explainer of the module you’re about to touch teaches you a lot. Their rule for the rest is simple. You land it, you own it. That’s not blame. It’s because you have the most context to fix it. Here’s how you start this week in this order. One, give your agent checks it can run listed in a short Claude.md. Two, run {slash} code review and {slash} security review on your own changes

[11:22] before you open the pull request. Three, add a review.md and every time you write the same review comment twice, move it into that file. Four, add testing, risk, and how to revert to your pull request template. Five, write down your risk tiers. Start strict and loosen only with evidence. >> [music] >> Six, cap review rounds at three. And seven, turn every revert into a test case for your reviewer. I put all of it into a free kit, >> [music]

[11:52] >> a starter review.md, the pull request template, a one-page risk tier sheet, and the seven-step checklist. Comment nitpick, and my bot sends it to you. Real talk, 90% of you watching haven’t subscribed. On Facebook, subscribe is the supporter button. That is what keeps the lights on here. On YouTube, it’s free, and it tells the algorithm to send you more. Subscribe to support us. Follow along on Instagram and Facebook for bite-size AI, and the deep dive

[12:22] playbooks live here on YouTube. Subscribe, so you don’t miss one. So, next Monday, when you’re about to leave three little nitpicks to prove you read the code, ask the better question instead. What could go wrong here, and what’s the right check to catch it? I’ll see you in the next one.