Como o time do Claude Code revisa código antes de colocá-lo em produção

Autoria: Cortes do Rafael Quintanilha · 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: português

Vídeo original: Como o time do Claude Code revisa código antes de colocar em produção · Canal: Cortes do Rafael Quintanilha · 04:41 · Assistir no YouTube

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

Resumo

O vídeo apresenta as etapas usadas pelo time do Claude Code para revisar e liberar mudanças: verificações automáticas antes do pull request, checks no CI e revisão por agentes. O apresentador recomenda automatizar verificações e bloquear o merge enquanto houver checks com falha. Também explica como um classificador pode avaliar o risco de uma mudança e decidir se é necessária uma revisão humana. Após a aprovação, as mudanças podem ser protegidas por uma flag e liberadas gradualmente, com diferentes camadas de defesa.

Pontos-chave

Antes de abrir um pull request, mudanças podem passar por testes, build, linter e revisão de diff por outro agente.
No CI, checks como lint, types, testes e builds precisam passar antes do merge.
O apresentador recomenda o code review do ChatGPT e cita CodeRabbit como alternativa.
Uma verificação de segurança pode ser incluída conforme o escopo e as necessidades do projeto.
Um classificador pode avaliar o risco de uma mudança e indicar se ela precisa de revisão humana.
Mudanças de baixo risco, como ajustes de texto ou pequenas alterações de UI, podem ser candidatas a uma aprovação automatizada.
Após o merge, a mudança pode ser liberada atrás de uma flag, primeiro para uso interno e depois gradualmente.
As camadas de defesa conduzem o código até uma revisão humana, quando necessária.
O objetivo é aumentar a confiança na automação do code review, especialmente para código escrito por IA.

Capítulos

Início	Capítulo	Resumo
00:00	Verificações antes e durante o pull request	O apresentador descreve testes, builds, lint e revisão do diff antes do pull request, além dos checks exigidos no CI.
01:02	Revisão automatizada e análise de risco	São apresentados recursos de code review, verificação de segurança e a possibilidade de um classificador avaliar a necessidade de intervenção humana.
02:37	Merge, flags e releases graduais	Depois das verificações, as mudanças podem ser protegidas por uma flag, testadas internamente e liberadas gradualmente.
03:08	Camadas de defesa e revisão humana	O código passa por camadas de proteção, e um classificador pode indicar se a mudança precisa ser verificada por uma pessoa.
04:10	Automatizar o code review	O apresentador comenta a dificuldade da revisão de código e o interesse em aumentar a confiança na automação, especialmente para código escrito por IA.

Citações

Um outro contexto olhando ali com um par de olhos frescos. — 00:30

Se não tiver verdinho, nem adianta chamar um outro humano para olhar. — 01:02

O código tem que ir passando aquelas etapas até que no final chegue ali para o human in the loop. — 03:08

Conseguir automatizar isso até que você tenha um nível maior de confiança nessa automatização é algo que me agrada bastante. — 04:10

Conceitos e entidades

Claude Code (ferramenta): Produto citado como exemplo do processo de revisão e liberação de mudanças.
ChatGPT (ferramenta): Ferramenta cujo recurso de code review é recomendado pelo apresentador.
CodeRabbit (ferramenta): Alternativa mencionada para realizar revisão automatizada em pull requests.
CI (conceito): Integração contínua em que são executados checks como lint, testes e builds.
risk-based approval (conceito): Abordagem que considera o risco de uma mudança para decidir se ela requer aprovação humana.
human-in-the-loop (conceito): Participação de uma pessoa na verificação de uma mudança antes que ela siga adiante.
feature flag (conceito): Mecanismo usado para proteger uma mudança e controlar sua liberação gradual.
classificador (conceito): Componente que pode avaliar uma mudança e recomendar se é necessária uma revisão humana.

Tradução completa (pt-BR)

00:00 E, para finalizar este vídeo, quero mostrar como o pessoal da Claude Code faz com as mudanças deles, né? Então, está aqui, ó: o ciclo de vida de uma mudança. Antes do pull request, o trabalho é verificado. Ou seja, olha aí: testes, build, linter, lembra? São os checks. Depois, outro agent vai lá e revisa o diff, né? Ou seja, as modificações em outro contexto. É justamente esse code review automático, ou, como disse o DHH, “revisões adversariais por agent”, ou

00:30 seja, outro contexto olhando com um par de olhos frescos, digamos assim, né? Então, isso aqui acontece antes do pull request. E, em cada pull request, o que acontece? Bom, lá no CI, na integração contínua, de novo, tem lint, types, testes em diversas plataformas, builds etc. Qualquer coisa que esteja vermelha, qualquer check que não esteja passando, bloqueia o merge. Isso é algo que implementei na minha empresa também. Olha, todas as actions aqui, todos os jobs que rodaram no pull request têm que estar verdinhos antes de algum humano dar uma olhada. Se não estiverem

01:02 verdinhos, nem adianta chamar outro humano para olhar. Deixe tudo bonitinho, tudo redondinho até alguém olhar. Então, isso tem que acontecer. E aí entra o Claude Code Review, né, que é justamente aquela funcionalidade deles que mencionei. Minha recomendação aqui para a maior parte das pessoas, principalmente se você tem acesso ao ChatGPT, é usar o code review do ChatGPT, que vai consumir do seu limite, não consome muito e é muito bom, tá? Gosto bastante. Como segunda opção, uma alternativa seria algo como o Code Rabbit, que também mencionei, mas são agents que vão rodar direto no pull request.

01:34 Depois, tem a revisão de segurança, né, alguma verificação de segurança. Aqui, claro, vai depender do escopo do seu projeto; nem todos os projetos vão precisar disso. E aí eles passam por uma aprovação baseada em risco, né? Então, um classificador. Interessante. Olha, um caso de uso interessante para o Jev, né? Você pode usar um classificador para ver se precisa de uma intervenção humana. Isso aqui é algo que quero fazer, tá? Até me conta aqui nos comentários se você gostaria que eu trouxesse isso para o canal. Já pensei em fazer um classificador que, com base em um diff, com base na mudança

02:06 de código, desse uma recomendação. Ó, será que isso aqui pode passar de ponta a ponta sem que necessariamente um humano olhe? Por exemplo, uma mudança de copy, né? Mudança de texto ou pequenas mudanças de UI, né? Ou aquele código muito autocontido cujo raio de impacto, né, o raio de destruição, seja pequeno. Então, isso aqui é algo interessante. Ah, inclusive, se você quiser aprender mais sobre o Jev, o vídeo mais assistido deste canal acabou sendo o vídeo em que digo que o Jev não é hype. Vou deixar o link para você assistir depois. OK, então, depois de passar por tudo, ele vai para

02:37 a fila para fazer o merge e, depois do release, eles colocam atrás de uma flag, né, protegido por uma flag, e usam internamente primeiro. Aí vão fazendo os releases graduais, tá? Isso também vai depender da quantidade de pessoas que usam seu app e da gravidade de um possível problema no seu app. Claro, a Claude Code é usada por milhões de pessoas; eles têm que ter um pouquinho mais de cuidado com os releases, tá? Então, essa é uma estratégia que você também pode adotar. E aqui eles continuam falando de todas as camadas de proteção, tá? Não vou ler isso aqui porque é bem grande,

03:08 são sete camadas que eles colocaram, mas quis trazer isso para que você entenda que isso é exatamente o que venho chamando aqui de linhas de defesa. Eu chamo de linhas de defesa; eles estão chamando aqui de camadas, tanto faz. A ideia é que são camadas, são linhas pelas quais você tem que ir passando, né? O código tem que passar por essas etapas até que, no final, chegue ao humano no ciclo, para que o humano verifique. E, dependendo do nível de sofisticação que você colocar no seu serviço, pode até ter um classificador que, no final de todas essas linhas de defesa,

03:39 diga: “Olha, já que passou por tudo isso aqui e, analisando qual é a mudança, nem precisa de humano; pode passar direto”. Ou, se for algo, claro, mais complexo ou que tenha um impacto maior no seu projeto, ele classifica e diz: “Não, é melhor que alguém aqui pelo menos verifique antes de colocarmos em produção”. Muito bem, pessoal, vou parar por aqui; já falei bastante. Esse é um assunto que me interessa muito porque, como eu disse, isso fez parte do meu dia a dia por muitos anos. Então, tenho um carinho especial por esse trabalho de

04:10 tentar melhorar a etapa de code review, sabe? Eu sei que ninguém gosta de fazer code review; é um trabalho meio chato. Desenvolvedor gosta de criar coisas novas, ninguém gosta de ficar apontando defeitos no código dos outros; nunca foi algo agradável. Então, conseguir automatizar isso até que se tenha um nível maior de confiança nessa automatização é algo que me agrada bastante. É um trabalho em andamento, né? São coisas que estão evoluindo e, aqui no canal, vou trazer para você sempre que houver alguma

04:41 mudança, sempre que houver alguma alternativa, sempre que houver algo que possa ajudar você nessa difícil missão que é revisar código, principalmente hoje em dia, em que os códigos são escritos pela IA.

Transcrição original

[00:00] E para finalizar esse vídeo, então quero passar como o pessoal lá do Cloud Code faz com as mudanças deles, né? Então tá aqui, ó, a vida, né, o ciclo de vida de uma mudança. Então, antes do pull request, o trabalho é verificado, ou seja, olha aí, testes, build, linter, lembra? São os checks. E aí depois um outro agente vai lá e revisa o diff, né, ou seja, de modificações em um outro contexto, é justa justamente esse code review é automático ou aqui o que o DHH disse, né? Adversarial agent reviews, ou

[00:30] seja, um outro contexto olhando ali com um par de olhos frescos, digamos assim, né? Então isso aqui acontece antes do pull request. E aí em cada pull request, o que acontece? Bom, lá no CI, né, lá no continuous integration, de novo, tem lint, types, testes em diversas plataformas, builds, etc. Qualquer coisa que esteja vermelha, qualquer check que não esteja passando, bloqueia o merge. Isso é algo que eu implementei na minha empresa também. Olha, todas as actions aqui, todos os jobs que rodaram no pull request tem que estar verdinho antes de algum humano botar o olho. Se não tiver

[01:02] verdinho, nem adianta chamar um outro humano para olhar. Deixa tudo bonitinho, tudo redondinho até alguém olhar. Então isso tem que acontecer. E aí entra aqui o Cloud Code Review, né, que é justamente aquela funcionalidade deles que eu mencionei. É a minha recomendação aqui para a maior parte das pessoas, principalmente se você tem acesso ao ChatGPT, é usar o code review do ChatGPT, que vai beber do seu limite, não consome muito e é muito bom, tá? Eu gosto bastante. Segunda opção aqui alternativa seria algo como o Code Rabbit, que eu falei também, mas são ali

[01:34] agentes que vão rodar direto no pull request. Depois tem ali o security review, né, alguma verificação de segurança. Aqui, claro, vai depender do escopo do seu projeto, nem todos os projetos vão precisar disso. E aí eles passam por um risk based approval, né? Então um classificador, interessante. Olha um caso de uso interessante para o Jeff, né? Você pode usar ali um classificador para ver se você precisa de uma intervenção humana. Isso aqui é algo que eu quero fazer, tá? É, até me conta aqui nos comentários se você gostaria que eu trouxesse isso no canal. Eu já pensei em fazer um classificador que baseado num diff, baseado na mudança

[02:06] de código, desse ali uma recomendação. Ó, será que isso aqui pode passar end to end sem que necessariamente um humano olhe? Por exemplo, é mudança de copy, né? Mudança de texto ou mudança, pequenas mudanças de UI, né? Ou aquele código muito autocontido cujo blast radius, né, quanto raio de de de destruição ali seja pequeno. Então, isso aqui é algo interessante. A, inclusive, se você quiser aprender mais sobre o Jeff, é, o vídeo mais assistido desse canal se tornou o vídeo onde eu falo que Jeff não é hype. Eu vou deixar o link para você assistir aqui depois. OK, então passou por tudo, ele vai ali para

[02:37] fila para fazer o merge e depois do release, eles colocam ali atrás de uma flag, né, protegido por uma flag, utilizado internamente primeiro e aí vão fazendo os releases graduais, tá? Isso aqui também vai depender da quantidade de pessoas que usam o seu app, da seriedade que seria ter algum problema no seu app. Claro, Cloud Code é usado por milhões de pessoas, eles têm que ter um pouquinho mais de cuidado com os releases, tá? Então, isso é uma estratégia que você pode fazer aqui também. E aqui eles seguem falando de todas as camadas de proteção, tá? Eu não vou ler isso aqui porque é bem grande,

[03:08] são sete camadas que eles colocaram, mas eu quis trazer isso para que você entenda que isso é exatamente o que eu venho falando aqui das linhas de defesa. Eu chamo de linhas de defesa, eles estão chamando aqui de layers, tanto faz. A ideia é, são camadas, são linhas onde você tem que ir passando, né, o código tem que ir passando aquelas etapas até que no final chegue ali para o human in the loop, para que o humano verifique. E dependendo do nível de sofisticação que você colocar no seu serviço, você pode ter até um classificador que pode, no final de todas essas linhas de defesa,

[03:39] falar, “Olha, já que passou por tudo isso aqui e analisando qual é a mudança, nem precisa de human, passa direto”. Ou se for algo, claro, mais complexo ou que tenha um impacto maior no seu projeto, aí ele classifica e fala, “Não, é melhor que alguém aqui pelo menos verifique antes que a gente coloque em produção”. Muito bem, pessoal, vou parar por aqui, já falei bastante. Esse é um assunto que me interessa muito, porque como eu disse, isso foi muito do meu dia a dia por muitos anos, então eu tenho todo um carinho especial nesse trabalho de

[04:10] tentar melhorar a etapa de code review, sabe? Eu sei que, né, ninguém gosta de fazer code review, é um trabalho meio chato, desenvolvedor gosta de criar coisas novas, ninguém gosta de ficar colocando defeito no código dos outros, nunca foi algo agradável. Então, conseguir automatizar isso até que você tenha um nível maior de confiança nessa automatização é algo que me agrada bastante, é um trabalho é em andamento, né, um working progress, são coisas que estão evoluindo e aqui no canal eu vou trazer para você sempre que tiver alguma

[04:41] mudança, sempre que tiver alguma alternativa, sempre que tiver algo que possa te ajudar nessa difícil missão que é revisar código, principalmente hoje em dia que os códigos são escritos pela IA.