Minhas 4 camadas de defesa para supervisionar menos o código da IA

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: Minhas 4 camadas de defesa para supervisionar menos o código da IA · Canal: Cortes do Rafael Quintanilha · 06:40 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA

Resumo

Revisar vários pull requests exige carregar muitos contextos e consome a capacidade cognitiva, um desafio que cresce quando a IA aumenta o volume de código produzido. Para reduzir a supervisão humana, o vídeo propõe uma sequência de defesas: verificações estáticas, testes, code review automático e, por fim, uma revisão humana. O autor recomenda ajustar o nível de rigor das revisões automáticas para evitar perder tempo com nitpicks e casos improváveis. Com essas etapas, a revisão final pode se concentrar na abordagem geral, e o trabalho pode ser refeito se a solução estiver no caminho errado.

Pontos-chave

Revisar vários pull requests exige alternar entre contextos diferentes e pode causar cansaço e sobrecarga cognitiva.
O aumento da produção de código com IA torna necessário automatizar etapas de verificação antes da revisão humana.
As verificações estáticas incluem linter, formatação e type check, que são determinísticas.
Critérios de aceite podem ser transformados em testes unitários e end to end, que a IA também pode ajudar a escrever.
Ferramentas de code review automático podem revisar pull requests quando são abertos ou recebem novos pushes.
A revisão automática pode identificar problemas por severidade e permitir que um agent os corrija antes da análise humana.
Níveis de reasoning muito altos podem levar a nitpicks e a correções de cenários pouco prováveis.
A revisão humana final pode ser um spot check da abordagem, sem exigir a inspeção de cada detalhe.
Se a solução estiver fundamentalmente errada, pode ser melhor descartá-la e recomeçar com a abordagem correta.

Capítulos

Início	Capítulo	Resumo
00:00	O custo cognitivo de revisar código	Revisar vários pull requests exige compreender cada mudança e manter diversos contextos em mente.
01:32	Camadas de defesa antes da revisão humana	O objetivo é reduzir a supervisão humana automatizando verificações antes que o código chegue ao revisor.
02:03	Verificações, testes e code review automático	O código passa por static checks, testes baseados nos critérios de aceite e ferramentas automáticas de revisão.
04:36	Severidade, correções e nitpicks	A IA pode identificar e corrigir problemas, mas níveis altos de reasoning podem gerar nitpicks sobre casos improváveis.
06:09	Revisão final e recomeço quando necessário	A revisão humana verifica a abordagem geral, e uma solução inadequada pode ser descartada e refeita.

Citações

O objetivo é minimizar a supervisão humana. — 01:32

São aquelas verificações que o código pode fazer, elas são 100% determinísticas. — 02:03

A chance de você entrar aqui e ter que olhar cada detalhe é muito menor. — 05:39

Eu acho que beleza, a abordagem está correta. — 06:09

Conceitos e entidades

Code review (conceito): Processo de revisar mudanças no código para entender sua abordagem, implicações e possíveis problemas.
Static checks (conceito): Verificações determinísticas, como linter, formatação e type check, executadas antes da revisão humana.
Unit tests (conceito): Testes que verificam partes individuais do código e podem ser derivados dos critérios de aceite.
End-to-end tests (conceito): Testes que verificam fluxos completos do sistema em relação aos critérios de aceite.
Codex (modelo): Produto mencionado como opção para realizar code review automático e cujo limite pode ser usado pelo ChatGPT.
Claude Code (ferramenta): Produto citado como opção para code review automático, disponível nos planos Teams ou Enterprise conforme a transcrição.
ChatGPT (ferramenta): Produto que oferece uma opção de code review automático configurável para repositórios e pull requests.
Greptile (ferramenta): Serviço especializado em code review mencionado como alternativa.
CodeRabbit (ferramenta): Serviço de code review que o autor cita como uma de suas opções favoritas.
DHH (pessoa): Pessoa a quem o autor atribui o uso do termo spot check para a etapa de revisão final.
spot check (conceito): Revisão final breve, voltada a verificar se a abordagem geral parece correta.

Tradução completa (pt-BR)

00:00 Então, quando você está fazendo uma revisão de código, o que está fazendo na prática? Uma revisão de código exige que o revisor entenda o código. Primeiro, você precisa entender o que está mudando, como era antes, quais são as implicações e até os detalhes técnicos, certo? Agora

00:32 imagine fazer isso para quatro ou cinco pull requests por dia. Você basicamente está carregando o contexto, certo? Está carregando o contexto um, o contexto dois, o contexto três, o contexto quatro. Está carregando na memória o contexto de um monte de tarefas, às vezes não relacionadas, de modo que vai lentamente esgotando sua capacidade cognitiva, ficando cansado e sem conseguir mais produzir, certo? Então, isso é algo

01:02 extremamente difícil de lidar. Só que agora pense que a IA é um multiplicador. Sei lá, agora sua equipe entrega dez vezes mais pull requests, se quiser. Hoje você tem tokens para entregar dez vezes mais pull requests do que entregava antes. E agora, se aquilo já esgotava você, como vai resolver esse problema? Como vai fazer aquilo que fazia antigamente? Ou você descarta esse ganho potencial de entregar dez vezes mais pull requests, ou vai dar um jeito

01:32 de automatizar cada uma dessas etapas, de modo que não precise mais fazer isso. Então, voltando ao tema das linhas de defesa, você quer minimizar o tempo que precisa despender, certo? No fim das contas, o objetivo, o objetivo é minimizar a supervisão humana, por causa dos problemas que mencionamos. Então, para minimizar a supervisão humana, antes que chegue ao humano, certo?

02:03 Aqui, olha: você vai revisar o código, certo? Antes de chegar aqui, a gente tem o código. Ele foi gerado e precisa passar por um conjunto de etapas. Claro, há as etapas mais simples, que são as verificações estáticas. Então, entram aqui o linter, a formatação e a verificação de tipos. São verificações que o próprio código pode fazer; elas são 100% determinísticas. Depois, você passa pelos testes. E quais são esses testes? Podemos ter

02:33 testes unitários, certo? Também podemos ter testes de ponta a ponta. Então, beleza, aqui normalmente você vai mapear os critérios de aceite. Esses critérios de aceite vão virar testes, que a própria IA pode escrever. Ela vai escrever código até que esses testes passem. Depois dos testes, vamos entrar na revisão de código automática. Aqui estamos falando da revisão de código do Codex; estamos

03:04 falando da revisão de código do Cloud Code. Ambos vão ter suas próprias soluções, certo? Se você entrar no ChatGPT, acessar as configurações, vai ver que, no final, há a revisão de código. Gosto bastante; é a minha favorita. Posso selecionar um repositório, por exemplo, Rafael Quintanilha/barra/skills, e configurar a revisão automática aqui. Essa revisão, por exemplo, pode ser feita em todos os pull requests. Ela será acionada cada vez que um PR for aberto ou a cada push. Então, eu

03:34 posso, usando, por exemplo, a revisão de código do ChatGPT, fazer uma revisão de código automática. Você também pode fazer essa revisão de código com o Cloud Code. Essa funcionalidade está disponível agora para todo mundo que está no Cloud Teams ou no Enterprise, embora seja preciso pagar por créditos. No ChatGPT, a vantagem é que ele usa o seu limite do Codex. Então, é excelente. Além disso, há outras empresas que oferecem um serviço focado em revisão de código, como a Greptile ou a que eu mais gosto de usar, que é a

04:05 Code Rabbit, sobre a qual, inclusive, já fiz um vídeo aqui no canal. Vou deixar o link, se você quiser assistir à minha análise completa do Code Rabbit. E, se também quiser testar o Code Rabbit, há um link de afiliado. Ao se cadastrar pelo link que está na descrição, você ajuda o canal. Então, sinta-se à vontade para testar também o Code Rabbit como outra linha de defesa que você pode ter. Certo. Depois que você passar por todas essas linhas de defesa, aí sim pode enviar para o humano. Por quê? Porque, nesta etapa da revisão de código,

04:36 normalmente, a IA vai indicar um problema P1 ou P2. Esses são os graus de severidade, de urgência e de risco do erro que ela encontrar. Então, você pode, em um ciclo de verificação, colocar seu agent para revisar e corrigir tudo o que foi encontrado. Embora seja bom dizer que, muitas vezes, a IA, principalmente se estiver com o reasoning muito alto, o reasoning extra high ou o reasoning max,

05:08 tende a fazer muito nitpick, como a gente chama. Ou seja, elucubrar demais e inventar um caso muito mirabolante que tecnicamente pode acontecer, mas que, na prática, dificilmente vai acontecer. Ela inventa esses casos mirabolantes, e aí você passa um tempão corrigindo algo que dificilmente vai acontecer. É importante ajustar isso ao seu gosto pessoal, beleza? Depois que a IA passar por essa etapa de verificação, ou seja, passar pelo linter e pela verificação de tipos, sem nenhum problema de formatação, e todos os testes passarem, você fizer uma revisão de código e corrigir todos aqueles problemas, a chance de ter sobrado algo grotescamente errado neste ponto é muito menor. Não estou dizendo que é impossível, nem que nunca vai acontecer, mas a chance de você chegar aqui e ter que olhar cada detalhe é muito menor. Então, aqui você faz uma etapa de revisão final, que foi o que o DHH chamou de spot check. Você vai lá, entra

05:39 aqui e diz: “Olha, acho que está tudo certo; a abordagem está correta”. Ou, se entrar aqui e vir que algo foi feito incorretamente, não tem muito problema jogar tudo fora. Você pode riscar isso aqui. Por que pode riscar isso aqui? Porque a IA gerou isso e talvez tenha levado até meia hora. Não custa quase nada refazer agora, sabendo qual é a forma correta. Claro que ninguém quer jogar trabalho fora, mas, no pior dos casos, se a IA fizer um trabalho que, no fim das contas, adotou uma abordagem errada e

06:09 você não percebeu, porque não fez um planejamento adequado — um detalhe sobre o qual falo lá no curso do Programação a Gente —, se deixou passar, mas chegou a esta fase e não gostou, cara, jogue fora e recomece agora, sabendo como quer fazer. Então, você não precisa mais carregar tudo o que pode dar errado, porque essas diversas linhas de defesa estão protegendo você. Elas estão protegendo seu cérebro e sua carga cognitiva, certo?

06:40 Você não capturou, porque não fez um planejamento adequado — detalhe que eu falo lá no curso do Programação a Gente, se você deixou passar. Mas chegou nessa fase e não gostou? Cara, joga fora, recomeça agora sabendo como você quer fazer. Então, você não precisa mais carregar tudo que pode dar errado, porque essas diversas linhas de defesa estão te protegendo. Elas estão protegendo o seu cérebro, estão protegendo sua carga cognitiva, tá?

Transcrição original

[00:00] Então quando você tá fazendo um code review, o que que você tá fazendo na prática, tá? Então um code review, ele requer do revisor entender o código, você precisa entender primeiro o que que está mudando, né? Entender o que está mudando como era antes implicações e aí até detalhes técnicos, tá? Agora

[00:32] imagina você fazer isso aqui pra quatro, cinco pull request no dia, você basicamente tá carregando o contexto, né? Você tá carregando o contexto um, né? O contexto dois, o contexto três, o contexto quatro, você tá carregando o contexto de um monte de tarefa, às vezes não relacionadas dentro da sua memória, de modo que você vai ali lentamente deletando a sua capacidade cognitiva e vai ficando cansado e não consegue mais produzir, tá? Então isso aqui é algo

[01:02] extremamente difícil de lidar. Só que agora pensa que a IA é um multiplicador, sei lá, agora o seu time entrega 10 vezes mais pull request se você quiser, tá? Você tem tokens hoje pra entregar 10 vezes mais pull request do que você entregava antes. E agora, se aquilo ali já te deletava, como que você vai resolver esse problema, né? Como que você vai fazer aquilo que você fazia antigamente? Ou você descarta esse ganho potencial de 10 vezes mais pull request se entregues, ou você vai dar um jeito

[01:32] de automatizar cada uma dessas etapas aqui, de modo que aí você não precise mais fazer isso. Então voltando para o tema das linhas de defesa, você quer minimizar o tempo que você precisa despender, tá? Então no final das contas o objetivo o objetivo é minimizar a supervisão humana, por causa dos problemas que nós falamos. Então, para você minimizar a supervisão humana, antes que chegue no humano, então tá

[02:03] aqui, ó, você vai chegar para revisar, antes de chegar aqui, o seu código, né? Então, a gente tem aqui o código, foi gerado, ele tem que passar por um conjunto de etapas. Aí, claro, você tem as etapas mais simples, que são os static checks. Então, aqui vai entrar linter, vai entrar formatação, vai entrar type check, são aquelas verificações que o código pode fazer, elas são 100% determinísticas. Depois, você vai passar aqui pelos testes. E quais são esses testes? Nós podemos ter

[02:33] aqui unit tests, né? Nós podemos ter aqui end to end test também. Então, beleza, aqui normalmente você vai mapear o acceptance criteria, o critério de aceite, né? Esses critérios de aceite vão virar testes, que a própria IA pode escrever esses testes e ela vai escrever código até que esses testes estejam passando. Depois, depois dos testes, a gente vai entrar aqui no code review automático. Então, aqui nós estamos falando do code review do Codex, nós

[03:04] estamos falando do code review do Cloud Code, ambos vão ter as suas próprias soluções, tá? Se você entrar aqui no chat GPT, né, vier aqui em settings, você vai ver que aqui no final tem o code review. Eu gosto bastante, é o meu favorito. Posso selecionar um repositório, por exemplo, Rafael Quintanilha {barra} skills e configurar, ó, automatic review aqui. E aí esse review, né, vai ser, por exemplo, para todos os pull requests. E ele vai ser disparado, é, cada vez que o PR for aberto ou a cada push, né? Então, eu

[03:34] posso, né, utilizando, por exemplo, o code review do chat GPT, fazer um code review automático. Você também pode fazer esse code review com o Cloud Code, tá? Eles têm essa funcionalidade agora disponível para todo mundo que tá lá no Cloud Teams ou no Enterprise, embora que você tem que pagar por créditos, tá? No do chat GPT, a vantagem é que ele bebe do seu limite do Codex. Então, é excelente. Além de você ter outras empresas que oferecem um serviço focado em code review. Por exemplo, o Greptile ou o que eu mais gosto de usar, que é o

[04:05] Code Rabbit, que eu inclusive já fiz um vídeo aqui no canal. Eu vou deixar o link, se você quiser quiser assistir o meu review completo do Code Rabbit. E se você quiser testar o Code Rabbit também, tem o link de afiliado, né? Você, é, fazendo o seu cadastro através do link que tá na descrição, você ajuda aqui o canal. Então, é, sinta-se à vontade também para testar o Code Rabbit como uma outra linha de defesa que você pode ter. Então, tá. Então, depois que você passou por todas essas linhas de defesa, aí você sim pode enviar para o humano. Por quê? Porque aqui nessa etapa do code

[04:36] review, normalmente, né, a IA vai gerar aqui um problema P1 ou um problema P2, né? Isso aqui são os graus de severidade, né, de de de urgência, de risco daquele erro que ela encontrar. Então, você pode, num loop de verificação, colocar ali o seu agente, né, revisando e corrigindo tudo que foi encontrado, embora é bom que se diga que muitas vezes a IA, principalmente se ela tiver com o reasoning muito alto, né, o reasoning extra high, o reasoning max,

[05:08] ela tende a fazer muito nitpick, que a gente chama, né? Que é elucubrar muito e inventar um caso muito mirabolante que tecnicamente pode acontecer, mas na prática muito dificilmente vai acontecer. E ela inventa esses casos mirabolantes e aí você passa lá diversos tempo corrigindo algo que dificilmente vai acontecer, tá? Isso é importante que você ajuste para o seu gosto pessoal, beleza? E aí depois que a IA então passou por essa etapa de verificação, ou seja, ela passou pelo linter, ela passou pelo type check, não tem nenhum problema

[05:39] de formatação, passaram-se todos os testes, você fez um code review e corrigiu todos aqueles problemas, a chance de ter sobrado algo grotescamente errado aqui nesse ponto é muito menor. Não estou falando que é impossível, não estou falando que nunca vai acontecer, mas a chance de você entrar aqui e ter que olhar cada detalhe é muito menor. Então aqui você faz uma etapa de final review, que foi o que o DHH chamou de spot check, né? Você vai lá, você entra

[06:09] aqui e fala: “Olha, eu acho que beleza, a abordagem está correta”. Ou se você entrar aqui e ver que foi feito algo incorreto, não tem muito problema você jogar tudo fora. Você pode riscar isso aqui. Por que que você pode riscar isso aqui? Porque a IA gerou, talvez até demorado meia hora para fazer isso aqui. Não custa quase nada você refazer agora sabendo da forma correta. Claro que ninguém quer jogar trabalho fora, mas no pior dos casos, né? No pior dos casos, se a IA fizer um trabalho que no final das contas tomou uma abordagem errada e

[06:40] você não capturou, porque você não fez um planejamento adequado, detalhe que eu falo lá no curso do Programação a Gente, se você deixou passar, mas chegou nessa fase e você não gostou, cara, joga fora, recomeça agora sabendo como você quer fazer. Então você não precisa mais carregar tudo que pode dar errado, porque essas diversas linhas de defesa estão te protegendo. Elas estão protegendo o seu cérebro, estão protegendo sua carga cognitiva, tá?