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

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

Topics: AI agents, Software engineering with AI

Summary

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.

Key points

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.

Chapters

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

Quotes

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

Concepts and entities

Code review, Static checks, Unit tests, End-to-end tests, Codex, Claude Code, ChatGPT, Greptile, CodeRabbit, DHH, spot check

Full transcript (original language)

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á?