Como o time do Claude Code revisa código antes de colocar em produção

Author: Cortes do Rafael Quintanilha · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: Como o time do Claude Code revisa código antes de colocar em produção · Channel: Cortes do Rafael Quintanilha · 04:41 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Claude Code, Software engineering with AI, AI developer tools

Summary

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.

Key points

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.

Chapters

Start	Chapter	Summary
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.

Quotes

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

Concepts and entities

Claude Code, ChatGPT, CodeRabbit, CI, risk-based approval, human-in-the-loop, feature flag, classificador

Full transcript (original language)

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.