Code review com IA: como ganhar produtividade sem perder qualidade

Author: Rafael Quintanilha – QuantBrasil · 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: Code review com IA: como ganhar produtividade sem perder qualidade · Channel: Rafael Quintanilha – QuantBrasil · 42:05 · Watch on YouTube

Topics: AI agents, Software engineering with AI

Summary

O vídeo discute como aproveitar o aumento de produtividade trazido por agentes de IA sem comprometer a qualidade do software. A proposta é substituir a revisão humana linha por linha por camadas de verificações automáticas, como linters, testes e code review feito por IA, reservando a intervenção humana para mudanças de maior risco e uma checagem final. O apresentador relaciona essa abordagem à redução da carga cognitiva e ao aumento da capacidade de entrega, sem ignorar os riscos de regressões. No fim, apresenta o fluxo de revisão usado pelo time do Claude Code e reforça que a responsabilidade pelo código continua sendo humana.

Key points

A revisão humana de cada linha pode se tornar um gargalo quando agentes produzem grandes volumes de código.
O objetivo é aumentar a entrega de funcionalidades e reduzir regressões, não simplesmente aumentar linhas de código.
Code review também servia para compartilhar conhecimento, mas esse papel pode mudar quando agentes consultam o histórico e o contexto do projeto.
A revisão automática deve integrar várias linhas de defesa: verificações estáticas, testes, revisão por IA e checagem humana final.
Revisar muitos pull requests aumenta a carga cognitiva e o resíduo de atenção.
Testes e verificações automáticas devem passar antes que um humano seja chamado para revisar um pull request.
Agentes distintos podem revisar mudanças em contextos separados, ajudando a identificar problemas antes do pull request.
A revisão humana pode ser direcionada conforme o risco e o impacto da mudança, com classificadores ajudando a decidir quando ela é necessária.
Preview environments e computer use podem apoiar verificações de QA e avaliações visuais da experiência.
Mesmo quando a IA escreve o código, a responsabilidade pelo resultado continua sendo das pessoas.

Chapters

Start	Chapter	Summary
00:00	O desafio de revisar código escrito por IA	O apresentador introduz o descompasso entre a velocidade de geração de código por IA e a capacidade humana de revisá-lo.
03:40	Produtividade, intervenção humana e regressões	O vídeo apresenta o dilema de aumentar a entrega de funcionalidades, reduzir a supervisão humana e evitar bugs.
09:53	Os propósitos tradicionais do code review	Além de validar o código, a revisão costumava compartilhar conhecimento, papel que pode mudar com o uso de agentes.
11:56	Opiniões sobre revisar cada linha	O apresentador traz as perspectivas de Uncle Bob Martin e DHH sobre o valor da revisão manual e da programação como meio ou fim.
18:16	Engenharia de IA e programação agêntica	O apresentador descreve seus cursos sobre fundamentos de IA, programação agêntica e construção de harnesses.
20:51	O fluxo de code review do Claude Code	O artigo do time do Claude Code é apresentado, incluindo dados sobre pull requests e reversões.
23:26	Revisão contínua e carga cognitiva	O vídeo discute por que revisões repetidas consomem atenção e como automações podem reduzir esse custo.
27:37	Camadas de verificação antes da revisão humana	São detalhadas verificações estáticas, testes automatizados, code review por IA e uma checagem humana final.
33:17	QA com preview environments e computer use	O apresentador explica como ambientes de preview e agentes podem apoiar testes manuais e avaliações de UX.
35:53	Ciclo de vida da mudança e revisão baseada em risco	O fluxo passa por checks, revisão automática, verificações de segurança, aprovação conforme o risco e releases graduais.
40:03	Conclusões e responsabilidade humana	O apresentador encerra defendendo a automação progressiva do code review e lembra que as pessoas seguem responsáveis pelo código.

Quotes

Não existe um futuro em que você revise manualmente cada linha de código gerada por um agente. — 15:06

O que poderia dar errado com essa mudança e qual verificação é a correta para detectar isso? — 23:26

O objetivo é minimizar a supervisão humana. — 27:37

Por mais que a IA seja quem escreva o código, os responsáveis sempre seremos nós. — 42:05

Concepts and entities

Claude Code, Codex, ChatGPT, CodeRabbit, TestSprite, Uncle Bob Martin, DHH, Rafael Quintanilha, linhas de defesa, revisão baseada em risco

Full transcript (original language)

00:00 Com a inteligência artificial escrevendo a maioria, se não a totalidade de todo código, muita coisa mudou na área de desenvolvimento de software. Em particular, a etapa de code review, que comumente servia para capturar bugs ou compartilhar conhecimento dentro de um time, sofreu mudanças drásticas. Isso porque a capacidade da inteligência artificial gerar código é muito maior do que a nossa própria de revisá-lo. Por isso, no vídeo de hoje, eu quero endereçar o elefante na sala para todos aqueles que trabalham com software. Como

00:31 fazer para aproveitar o máximo de produtividade que a IA nos dá sem negligenciar a qualidade do código? Eu quero fazer isso a partir de um artigo escrito pelo time de desenvolvedores do Cloud Code. Vou trazer a opinião de programadores famosos e da velha guarda. Eu quero dar a minha própria opinião pessoal, como alguém que já revisou milhares de pull requests na vida, e responder a pergunta: será que hoje em dia ainda é necessário revisar cada linha de código? Pessoal, esse é um tema bastante sensível, sempre que você conversa com

01:03 alguém que tem uma carreira na programação, pelo simples motivo, né? Se a sua carreira consistia em escrever e revisar código, se a IA consegue hoje escrever código muito mais rápido e talvez até melhor do que você, e além disso, você não precisa nem mais revisar o trabalho que a IA faz, qual seria a sua função? O que é que você está fazendo? Por isso que eu disse que esse é o elefante na sala quando a gente conversa com pessoas que trabalham com software. Então, esse vídeo aqui é um pouco diferente, eu quero fazer essa reflexão com você, como alguém que é engenheiro de software de formação, tá?

01:35 Eu sou formado em engenharia de computação, trabalho com isso a minha vida toda. Claro, hoje eu tenho um canal aqui falando sobre inteligência artificial, mas isso me afeta diretamente também. Além disso, eu passei grande parte da minha carreira revisando o código dos outros, então eu posso dizer que esse é um trabalho que eu fiz muito e eu entendo perfeitamente as implicações do que nós vamos discutir aqui. Só que, né, é necessário que a gente entenda que houve uma mudança. Inicialmente, a IA ia lá, ela escrevia o código para você, talvez o código não

02:06 fosse tão perfeito, então ela precisava que você fizesse uma camada de review muito mais completa. Hoje em dia, as IAs estão escrevendo código cada vez melhor, então a necessidade desse review, ele é é muito menor, é um review muito mais minucioso. Só que além disso tem um outro problema, que é o seguinte, nós temos uma super oferta de token, você pode, por exemplo, assinar um plano tipo o Cloud Max, pagar 100 dólares, né, 500, 600 reais e basicamente não conseguir estourar o seu

02:37 limite com o melhor modelo para engenharia de software hoje em dia. Então a gente poderia dizer que pelo preço de metade, um terço de um estagiário, você consegue ter, né, uma IA trabalhando em paralelo em diversas tarefas ao mesmo tempo e naturalmente você fica interessado em maximizar aquele poder. Só que se você está revisando tudo aquilo que é escrito pela IA minuciosamente, todas as linhas, você não vai conseguir, você vai se tornar o gargalo, você vai se tornar o bottleneck. Eu não estou falando que você deve aceitar cegamente tudo que foi escrito, nem que você deve revisar toda

03:09 a linha de código. Eu estou te apresentando o problema para que juntos nós conversemos de forma madura sobre isso, tá? Inclusive, eu te convido a deixar a sua opinião aqui ao longo do vídeo no que nós formos tratar, claro, isso aqui é um é um vídeo opinativo, eu estou trazendo opiniões de outras pessoas, vou dar a minha também. Tô interessado em saber a sua. Então já aproveito e peço para você curtir esse vídeo, para você participar aqui da discussão com a gente e se inscreve aqui no canal também, porque aqui nós falamos de inteligência artificial com seriedade. Muito bem, pessoal, a motivação para o vídeo de hoje veio

03:40 desse artigo publicado pelo time de desenvolvedores do Cloud Code chamado “How the Cloud Code Team Does Code Review”, ou seja, como que o time do Cloud Code é lida com a revisão de código. E aí tá aqui a dúvida, né? Como que você revisa código no volume que os agentes produzem? Imagino que isso aqui é particularmente, né, relevante para quem trabalha numa empresa de IA, né? Uma empresa que tem tokens infinitos, mas você nem precisa ir para a realidade deles. Eu vou dar a realidade da empresa que eu trabalho. Eu trabalho numa

04:11 empresa nos Estados Unidos, temos um time de 11 engenheiros e cada pessoa no time tem um orçamento de até 500 dólares para gastar com IA. A minha empresa tem uma mentalidade muito pró IA, então a gente quer que as pessoas tenham acesso a esses recursos porque a gente acredita no ganho de produtividade. Nós temos mensurado isso com bastante sucesso, né, nos últimos meses, tá? Então, 500 dólares, cara, você poderia ter o plano máximo do Cloud Code, o plano pró do ChatGPT, botar o Grok mais o sei o quê e

04:41 você vai ter ali bastante token para usar. Então, volume de código produzido não é um problema. O problema é como você valida isso, tá? Então, eles vão contar aqui a estratégia por trás do time do Cloud Code que minimize o número de intervenção humana, certo? De review feito por humanos e que não aumente, né, reversões e incidentes. Então, basicamente, o dilema que nós precisamos resolver é o seguinte, né? Qual que é o dilema? Nós precisamos aumentar a

05:12 produção de código, aumentar o código produzido. E aqui eu tô falando código, não entenda a linha de código. Obviamente, essa é uma medida que não faz sentido. O que faz sentido é aumentar a quantidade de funcionalidade, de coisas que você coloca ali no seu app, né? Então, aumentar produtividade no geral, certo? Então, aqui você tá aumentando a produtividade ao mesmo tempo que você quer diminuir o human in the loop, ou seja, a intervenção humana. É IA trabalhando ali na maior parte do processo e você intervindo pontualmente. E você também quer diminuir as

05:43 regressões, né? Os os bugs, beleza? Então, isso aqui é perfeito, né? Não é isso que todo mundo quer? Eu hoje sou VP of Engineering, já fui Engineering Manager e é basicamente isso que você quer alcançar quando você tem um time de engenharia. Você quer maximizar a sua produtividade, diminuindo, né, o tempo que você precisa fazer alguma intervenção, diminuindo o número de bugs. Por exemplo, você pode medir isso no seu time, você tem ali uma sprint, né, um cycle, você trabalha com linha, é um um período de tempo onde as pessoas

06:13 vão trabalhar e você vai lá e soma a quantidade de pontos, né, usando ali, por exemplo, Fibonacci para estimar, né, quantos pontos uma determinada tarefa custa, né, e você vai lá e vai somar ali a sua quantidade de pontos entregue numa sprint para dar toda a definição para você o que que seria uma sprint num time de desenvolvimento de software, né? Você separa um período de tempo, sei lá, uma semana, duas semanas e ali você normalmente se junta com aquele seu time e vocês concordam no que vai ser entregue naquela semana, naquela sprint.

06:46 Então, pega o desenvolvedor X, ó, você vai trabalhar nisso, nisso, nisso. Desenvolvedor Y, você vai trabalhar aqui, aqui e ali. Então, cada pessoa, né, se compromete com entregar um determinado ticket e aí você vai lá e faz uma estimativa, né? Olha, quanto tempo você acha que você vai gastar para fazer esse ticket? Normalmente a gente traduz esse tempo, né, esse nível de esforço necessário em pontos, né? É uma forma de você metrificar mais ou menos a complexidade de um determinado trabalho, tá? E aí, no final das contas, você tem N desenvolvedores trabalhando num

07:17 período de tempo, você tem ali o que nós chamamos de velocity, ou seja, é a velocidade do seu time, tá? Quantos pontos o seu time costuma entregar em uma sprint? Por que que isso é interessante? Porque todo manager quer saber quantos pontos você consegue entregar. Porque quando tiver uma nova funcionalidade para ser feita, você vai ver, bom, o meu time consegue entregar 100 pontos em uma semana. Pegando aqui tudo que precisa ser feito para essa funcionalidade e somando os pontos estimados, eu cheguei à conclusão de que

07:48 nós temos 250 pontos. Ora, então eu vou precisar pelo menos de duas semanas e meia para terminar isso aqui. Então eu passo a ter previsibilidade no meu desenvolvimento, tá? Então isso é algo que sempre aconteceu. Então naturalmente você quer aumentar essa quantidade de pontos produzida. E isso aqui vai ser bastante influenciado por esses dois fatores. Por quê? Porque o Human in the Loop, normalmente que vai ser a etapa de QA, né? Ou seja, a Quality Assurance, certo? A garantia da

08:20 qualidade. Isso aqui muitas vezes vai passar por uma intervenção humana. Nós podemos ter aqui o Manual QA, ou seja, alguém que vai lá e clica, sai clicando para ver se está funcionando, né? Nós temos também o Automatic QA. Aí você tem testes automatizados, né? Testes end to end, muitas vezes. Né? Uma das funcionalidades que te permite fazer isso é o Test Sprite, que eu sempre trago aqui no canal como um parceiro nosso, né? E você também pode ter ali o Code Review. O Code Review é basicamente

08:51 uma etapa onde alguém entra para revisar aquele código, para ver se aquele código tá dentro dos conformes, se tá usando os padrões do projeto, se não tá colocando nenhum bug, se, enfim, está fazendo o que foi proposto, o que foi pedido, né? Tudo isso é medido aqui na etapa do Code Review também. E claro, então, na questão das regressões, se você tem um número maior de bugs, né? Se você aumenta os bugs, então o que acaba acontecendo? Os bugs eles vão entrar no lugar

09:21 do que você tem para fazer. Então você tem aqui, ó, sei lá, você tinha ali, é, ticket um, ticket dois, ticket três e aí agora entrou o bug, né? Ele entrou no lugar, por exemplo, do ticket quatro. Então ticket quatro agora teve que ficar para próxima sprint porque você teve que trabalhar no bug um e no bug dois. Então, você quer acabar atrapalhando a sua capacidade de melhorar o software, você tá toda hora tendo que apagar fogo que você mesmo criou. Então, pessoal, isso aqui não tem nenhuma novidade, beleza? Isso aqui faz parte da dinâmica de quem trabalha com software. Então,

09:53 aqui no vídeo de hoje, a gente tá especificamente, né, focando na etapa de code review. Só que tem uma coisa interessante aqui, tá? Que code review, tradicionalmente, ele servia a alguns propósitos, tá? O propósito número um, como eu disse, é você validar ali o código, né? Você quer validar o código de diversas formas, né? Você quer validar ali se ele tá funcionando, como eu disse, se ele se adequa aos padrões e tudo mais. Mas tem uma outra coisa que o code review sempre serviu também, que é o compartilhamento de conhecimento.

10:24 Ou seja, se você tá trabalhando num time com múltiplas pessoas e você tá acostumado a trabalhar em uma determinada área, sei lá, você trabalha no app mobile do seu time. E aí, alguém vai aí e faz uma mudança no app que você não trabalhou, mas você sabe que você vai precisar mexer daqui a um tempo, é importante que haja esse compartilhamento de conhecimento. Olha, mudei por causa disso ou presta atenção nessa mudança, que a partir de agora a gente vai passar a fazer assim. Então, muitas vezes você marca ali uma pessoa num pull request, por exemplo, para que

10:55 ela veja, olha, presta atenção nisso aqui, tá? Então, compartilhamento de conhecimento sempre foi algo feito durante o code review também. Só que, se hoje em dia a IA escreve o código e é a IA que vai ler o código, por que você precisaria compartilhar esse conhecimento necessariamente com um humano? É uma pergunta legítima de se fazer. Olha, eu não vou entrar mais ali e escrever na mão, se eu precisar trabalhar ali, eu vou usar uma IA para trabalhar com aquilo e a IA vai dar um jeito de entender, ela pode puxar o pull request, ela pode puxar as decisões feitas, ela tem isso muito mais fácil do

11:25 que eu. Ela consegue carregar isso no contexto. Então, essa etapa de compartilhar o conhecimento meio que deixou de ser relevante hoje em dia. Então, a gente fica com a parte de validar o código, mas se a gente conseguir validar o código de forma automática, onde então que entra a intervenção humana? E essa é a discussão que eu quero ter com vocês nesse vídeo. E antes da gente começar aqui a ler o artigo, de fato, do Cloud Code, eu quero trazer outras opiniões para você. Eu sei que muita gente vai assistir esse vídeo e vai ter um certo cinismo, no sentido

11:56 de: “Ah, é claro que o Cloud Code vai dizer que você precisa usar IA >> para revisar código, afinal de contas eles vendem IA”. E OK, esse pode até ser um argumento legítimo, mas eu não acredito que se resuma só a isso, tá? Então, para não ficar apenas no argumento, né, do barbeiro querendo te vender um corte de cabelo, né, eu quero trazer algumas opiniões para você. Primeira opinião que eu quero trazer é aqui do Uncle Bob Martin, que eu fui achincalhado aqui nesse canal quando eu disse no meu vídeo de por que você deveria aprender Harness in Denali. Eu

12:27 eh peguei um tweet dele aqui, até disse que eu não conhecia quem era e aí as pessoas vieram aqui reclamar de mim aqui, falar que eu nem era engenheiro de software de real por não conhecer quem é o Bob Martin. E de fato, eu nunca li os livros dele, apesar de depois, sabendo o que ele fez, já ter ouvido [roncando] muitas coisas, principalmente do Manifesto Ágil. O ponto não é esse, tá? O ponto é que muita gente segue o Bob Martin por causa de livros como o Clean Code, né, onde ele ia lá e descrevia uma forma de você arquitetar o seu software. E o próprio Bob disse aqui, no início desse mês, que

13:00 “As pessoas parecem estar chocadas com o fato que o autor do Clean Code, ou seja, ele, não lê o código mais, mas isso não deveria ser surpresa. Por que que eu escrevi o Clean Code? Qual é o objetivo de se manter o código limpo, né? Para tirar do caminho aquelas coisas que estão te atrapalhando a fazer o trabalho de verdade, que no caso aqui ele diz que é pensar, tá? Então, veja, pessoal, você pode olhar a programação de duas formas. Você pode pensar nela como um meio para o fim e aí nesse caso

13:31 ela passa a ser uma ferramenta, onde você usa a ferramenta para desenvolver alguma coisa que vai ter algum efeito prático, desenvolvimento de um app, melhorar a vida das pessoas, melhorar sua própria vida, sua produtividade, etc, etc. Ou você pode olhar para programação como um fim em si mesmo. Por exemplo, quase como se fosse uma arte, um craft. Eu quero trabalhar com a programação de uma forma mais manual, mais artesanal, porque eu tenho prazer em fazer isso. E não tem nada, absolutamente nada de errado em fazer isso. Muita gente, por exemplo, gosta de

14:01 trabalhar com marcenaria como hobby, não porque quer abrir uma empresa de marcenaria, não vai competir com uma com uma fábrica, né, de móveis de madeira. Não, você que tá ali querendo fazer aquilo de forma lenta, né, para uso pessoal, também para espairecer um pouco. Tudo isso é legítimo, mas no ambiente corporativo, no ambiente produtivo, a programação é um meio para um outro fim, tá? Se você pensar dessa forma. Então, de fato, se você consegue atingir aquele fim sem necessariamente usar a técnica do clean code ou sem

14:33 necessariamente analisar toda a linha de código, tanto faz, desde que você esteja chegando no resultado. Então, uma outra opinião que eu queria trazer é o do DHH, eu sempre trago ele aqui, né, criador do Ruby on Rails, hoje em dia do Omar aqui, né, CTO do 37signals, etc, um cara extremamente conhecido e famoso e que também ficou famoso por, no início, ser cético em relação a IA e ter pivotado depois que ele percebeu que a IA tinha melhorado bastante. Então, ele demorou até para entrar no hype train, ele demorou para, né, ir all in na IA,

15:06 porque ele foi bem criterioso e hoje em dia ele fala coisas tipo essa aqui, ó. Olha o tweet do DHH do dia 28 de setembro. Demora para que você ganhe a confiança, mas não existe um futuro onde você está manualmente revisando cada linha de código gerado por um agente. Não tem muita aceleração nisso. Você precisa de reviews de agentes que sejam adversários, né? Que sejam um contradizendo o outro, tentando de eh desbancar o outro. Você precisa de teste automático, né? E talvez você vai lá e

15:38 dá uma olhada para ver se está tudo certo. E é basicamente isso. Do prompt para produção, beleza? Então aqui é o DHH falando: “Cara, não vai ter um futuro onde você vai ficar manual mente revisando cada linha de código”. Ele não está dizendo que você não vai olhar nunca, né? Ele já está está dizendo aqui, ó: “Eventualmente você vai lá para ver se está tudo certo”. Mas revisar cada linha de código, isso é muito difícil se você quiser maximizar a produtividade de um agente, né? Ele diz: “Não tem muita aceleração nisso aqui”. E aqui em outro tweet ele até diz, ó: “Eu entendo que é uma transição difícil para

16:11 quem era um contribuidor individual, né? Um programador normal, um IC, como a gente chama, que talvez nunca tenha tido que liderar ou comandar um time muito grande. Existe uma uma satisfação muito grande em revisar cada linha de código”. E aí ele fala: “Eu fiz isso por décadas, mas isso também limita a sua ambição”. E eu também fiz isso por muitos anos, tá, pessoal? Eu também fiz isso por muitos anos e como eu disse, como eu venho de um background de management, eu sempre tinha que ficar ali pensando nesse aumento de produtividade. Então para mim

16:41 foi muito natural adotar IA porque eu percebi a vantagem que ela ia me dar muito rápido, tá? E eu entendo que a maior parte das pessoas às vezes pode não ter tido essa experiência. E até para provar isso para você, eu queria trazer um artigo que eu escrevi em 3 de julho de 2019. Lá se vão mais de 7 anos que eu escrevi isso aqui na internet. Esse artigo é é o meu artigo que mais fez sucesso, se é que a gente pode dizer assim, né? Que eu já tenha escrito, né? Ele já foi página topo de de Hacker News, já viralizou no Reddit várias vezes. E basicamente aqui era uma lista de coisas que eu escrevi de como

17:13 você se torna um desenvolvedor ruim, né? Então, né? Fazendo uma inversão aqui, com normalmente você quer pensar como você se torna bom naquela sua profissão e aí eu inverti o pensamento, falei: “Cara, como que você se tornaria ruim, né? O que que você precisa fazer para ser um profissional ruim nessa área, tá?” E aí, o último ponto desse artigo, que eu repito, eu escrevi há 7 anos atrás, era o seguinte: “Escreva para máquinas, não para humanos”. Ou seja, se você, naquela época, queria se tornar um desenvolvedor ruim, você escreveria sem se preocupar que o humano vai ler aquilo

17:45 depois. E isso mudou, pessoal. Isso mudou, porque hoje é o próprio agente que está lendo o código, se não tudo, repito, 90%, 80%, que seja 70%, 60%, 50%, ou seja quanto você permite que a IA leia o código dentro da sua codebase. É uma grande parte, uma parte relevante do código é lida pela IA. Então, se antes a gente otimizava para a leitura humana, para a intervenção humana daquele código, hoje em dia isso já não é mais tão necessário. Eu tô trazendo esse artigo

18:16 que eu mesmo escrevi há 7 anos atrás para mostrar para você que eu não tô falando isso porque eu tô aqui no hype train da IA, não é por isso. Tô falando isso porque eu percebi como as coisas funcionam hoje em dia e não era assim no passado. Tanto é que eu já escrevi sobre isso. Agora, já que eu provei para você que eu venho de um background muito antes de ter IA e que eu percebi como que a IA ajuda no trabalho hoje em dia, eu quero fazer um convite para você que quer aprender a usar agentes de IA na prática para construir software. Isso porque eu tenho um curso chamado

18:48 programação agêntica dentro do meu site o programe.ai, tá? Então, se você entrar em programe.ai, você vai encontrar, né, hoje a trilha do engenheiro de IA, que tem três cursos que te ajudam a formar esse aprendizado em engenharia de IA. O que que é engenharia de IA? É você resolver problemas utilizando a inteligência artificial. Eu dividi essa trilha em três cursos, o curso de fundamentos da engenharia de IA, para que você aprenda a base daquilo que você vai usar para construir os seus apps. O curso de

19:19 programação agêntica, para que você entenda a usar agentes de IA no desenvolvimento de software. E aqui é onde a gente vai lá no detalhe para aprender inclusive a fazer as verificações automáticas com a IA que nós vamos ver no artigo descrito pelo pessoal do Cloud Code. Então no curso de programação agêntica é onde nós falamos com muito mais detalhe na da técnica, dessa nova forma de você trabalhar com engenharia de software, que é utilizando agentes de IA. E por fim, tem também o curso de Harness Engineering, para aquelas pessoas que querem aprender a

19:51 construir o seu próprio Harness, seja para maximizar o seu desenvolvimento pessoal, por exemplo, criar um Harness próprio que melhore a sua capacidade de gerar software, como também criar um Harness para uma empresa, para um time, seja você um líder, seja você um empreendedor, seja você alguém que quer utilizar a IA no seu trabalho. Beleza? Você pode adquirir tanto a trilha completa do engenheiro de IA, contendo os três cursos e aí você tem um desconto, quanto você pode também escolher aquele curso que mais se adequa ao seu momento e comprar ele

20:21 separadamente também, beleza? Se você quiser conhecer mais sobre a trilha do engenheiro de IA, em particular sobre o curso de programação agêntica, eu vou deixar um link tanto na descrição quanto no comentário fixado. Então tá, pessoal, então fizemos esse grande preâmbulo aqui para que você entendesse o problema e para que você entendesse que isso é algo que lá fora, mesmo grandes players, mesmo dinossauros da programação, entenderam o problema. Então vamos agora olhar praticamente o que o pessoal do Cloud Code tem feito e

20:51 como nós podemos aprender com eles, descontando o fato, claro, que eles têm o interesse em maximizar o uso de IA com todo o mundo, já que é isso que eles vendem. Uma coisa curiosa aqui que eles falam nesse artigo é que eles dizem que o Cloud escreve 90% do código do Cloud Code, né? E as pessoas estavam perguntando na internet: “Quem escreve os últimos 10%?”, né? Maldosos dirão que é o Codex. Mas o fato é que se você escreve tanto código assim com a IA, como que você revisa o código nesse volume produzido? Alguém ainda lê o

21:22 código hoje em dia? E se algo quebrar, quem que captura isso, né? Quem que observa isso? Quem é que vai ver que quebrou e corrige? Esse é um artigo deles descrevendo o fluxo de code review dentro do time do Cloudcode e como que isso evoluiu. De junho a setembro, o número de pull requests que foram mergeados, né, foram, né, feito o merge lá na codebase do Cloudcode, mais do que dobrou, enquanto a taxa do que foi revertido caiu por mais de 40%, tá? Ou

21:53 seja, se a gente voltar aqui para a nossa equação, eles alcançaram isso, eles aumentaram aqui a produtividade e diminuíram o número de regressões. Eu sei que você você pode estar tentado a descontar o que eles estão falando aqui, mas eu confesso que eu observei isso no time que eu sou manager também, tá? Nós aumentamos o número de pontos que a gente tem entregue por sprint e o número de regressões que nós temos tido se manteve ou mesmo ou menor, tá? Então

22:25 isso é algo que você consegue medir facilmente utilizando qualquer, eh, issue tracker. E eu de fato notei, principalmente nesses últimos meses, né, esse aumento de velocidade, né, sem detrimento da qualidade. Então de fato os modelos mais recentes, assim como o maior conhecimento de um time como um todo, à medida que a IA vai ficando cada vez mais popular, sem dúvida tem ajudado isso. Bom, tá, então o pessoal do Cloud diz que eles não removeram a revisão, mas eles moveram a maior parte do que ela lê para as máquinas, otimizando para

22:56 o tempo gasto por humanos e investindo pesadamente em tornar, né, esse review tão rápido, quanto fácil de, né, desfazer possíveis erros, beleza? E aí tem aqui a seção repensando o propósito de code review e aí a gente já conversou bastante sobre isso, né? Então eles também dizem aqui, ó: “O code review faz dois trabalhos, né? Então o primeiro é encontrar e corrigir problemas antes que você coloque aqueles problemas no ar e que você também construa um contexto comum, né, entre o time, né? Então a

23:26 gente falou basicamente isso e o artigo é basicamente na etapa número um, que, ou seja, como que você faz para encontrar e corrigir os bugs. E aqui tem uma passagem muito interessante, onde eles dizem que a frase: “Algum humano leu esse código?” é um proxy impreciso da frase: “O que poderia dar errado com essa mudança e qual a verificação automática ou feita por humano é a verificação correta para capturar isso, tá?” Ou seja, o que que eles querem dizer? Você precisa pensar o que que pode dar errado e como você pode

23:57 verificar se aquilo deu errado, tá? Isso não necessariamente precisa ser feito por um humano, tá? Então a gente tende a achar que, ah, não, porque um humano olhou aqui, eu tenho mais tranquilidade, mas isso nem sempre é o fato. E aí eles dizem aqui, ó: “Hoje em dia o review executa continuamente, quase como se fosse um spell check, né? Quase como se fosse uma correção de texto enquanto você escreve e a maior parte das mudanças tem sido revisadas e corrigidas pelo cloud pelo menos uma vez antes que um humano tenha que intervir para olhar,

24:27 tá?” E eu queria voltar aqui para vocês, porque isso é algo que eu tenho falado bastante, inclusive no curso de programação a gente é onde eu bato bastante na tecla das linhas de defesa. Por quê, pessoal? Porque essa questão de você revisar código toda hora é um dos maiores detratores de atenção que você pode ter. Então, quanto mais código você revisa, maior a sua carga cognitiva e menor a sua produtividade. Eu posso falar isso aqui sem medo nenhum

24:59 de, né, de exagerar, porque como eu disse, por muito tempo na minha carreira eu revisei múltiplos pull requests por dia, né? E era sem dúvida uma das piores tarefas que eu podia fazer, porque aquilo ali depletava completamente a minha energia, tá? Por quê, pessoal? Existe um conceito lá no livro Deep Work, se vocês forem lá e e verem o o livro Deep Work, né? Acho que em português se chama trabalho focado, do Cal Newport, onde ele trata de uma coisa chamado attention residue, ou resíduo de

25:31 atenção, que é basicamente o fato que quando você troca de muito assunto, aquilo ali sempre deixa um resíduo na sua mente, aquilo ali vai aumentando com o tempo, se acumulando, de modo que se você fica toda hora trocando de assunto, no final do dia você não tem mais energia para nada, é quase como se você tivesse depletado a RAM do seu computador, você tem que dar um reboot, que é basicamente dormir, né? Parar de trabalhar, descansar. 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

26:03 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 imagina você fazer isso aqui para quatro, cinco pull requests no dia, você basicamente tá carregando o contexto,

26:35 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 tarefas, às vezes não relacionadas dentro da sua memória, de modo que você vai ali lentamente depletando a sua capacidade cognitiva e vai ficando cansado e não consegue mais produzir, tá? Então, isso aqui é algo 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

27:06 você quiser, tá? Você tem tokens hoje para entregar 10 vezes mais pull request do que você entregava antes. E agora, se aquilo ali já te depletava, como que você vai resolver esse problema? É como que você vai fazer aquilo que você fazia antigamente? Ou você descarta esse ganho potencial de 10 vezes mais pull requests entregues, ou você vai dar um jeito 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

27:37 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á 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

28:08 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 aqui unit tests, né? Nós podemos ter aqui end-to-end tests também. Então, beleza, aqui normalmente você vai mapear o acceptance criteria, o

28:39 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 num code review automático. Então, aqui nós estamos falando do code review do Codex, nós 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

29:09 code review. Eu gosto bastante, é o meu favorito. Posso selecionar um repositório, por exemplo, Rafael Tanilha {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 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

29:39 têm essa funcionalidade agora disponível para todo mundo que tá lá no Cloud Teams ou no Enterprise, embora aqui 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 serviço focado em code review. Por exemplo, o Graphtile ou o que eu mais gosto de usar, que é o Code Rabbit, que eu inclusive já fiz um vídeo aqui no canal. Eu vou deixar o link, se você quiser assistir o meu review completo do Code Rabbit. E se você quiser testar o Code Rabbit também, tem o link de

30:09 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 review, normalmente, né, a IA vai gerar aqui um problema P1 ou um problema P2, né? Isso aqui são os graus de

30:40 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é, um reasoning extra high, um reasoning max, ela tende a fazer muito nitpick, que a gente chama, né? Que é elucubrar muito e inventar um caso muito

31:11 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 de formatação, passaram-se todos os testes, você fez um code review e corrigiu todos aqueles problemas, a chance de ter sobrado algo

31:43 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 the spot check, né? Você vai lá, você entra aqui e fala: “Olha, eu acho que beleza, a abordagem tá correta”. Ou se você entrar aqui e ver que foi feito algo incorreto, não tem muito problema você jogar tudo fora,

32:14 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 ela tomou uma abordagem errada e você não capturou, porque você não fez um planejamento adequado, detalhe que eu falo lá no curso do Programação Agente, se você deixou passar, mas chegou nessa

32:45 fase você não gostou, cara, joga fora e 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 a sua carga cognitiva, tá? E claro que existem outras técnicas que você pode colocar aqui também, por exemplo, técnicas mais avançadas, vamos botar assim, né? Você pode estar trabalhando com agentes na nuvem.

33:17 E aí você tem preview environments, então cada vez mais as empresas estão te jogando para a nuvem. Ok, você vai lá, trabalha em paralelo, gera um preview environment, no final das contas, se o código tá passando, porque ele passou nas suas linhas de defesa, você tem ali um artefato para você verificar visualmente mesmo, não gostei, é assim que eu queria que tivesse mesmo, ou não, a experiência não tá tão legal, né? porque a questão de UX, né, e o famoso taste, isso você que vai ter que dar também. Uma outra coisa, já que você tem um preview environment, você pode usar ali um computer user, e aí o Codex é o

33:50 principal para isso, você vai lá e coloca um computer user fazendo todo o QA. Aqui ele vai fazer todo o QA para você, um um QA manual, né? Claro que é que é operado pelo computador, pela IA, mas você fala assim, olha, Codex, tá aqui o meu preview environment, vai lá, você sabe qual que é o ticket, você sabe ali, você gera os casos de teste e verifica cada caso de teste ali para garantir que tá funcionando, sai clicando, verifica no banco de dados, cria uma conta com as condições adequadas. Pessoal, isso aqui

34:21 toma muito tempo para você fazer na mão. No time que eu trabalho, um dos maiores gargalos que a gente tem é justamente o QA, porque a setup do QA, gerar condição para testar manualmente e fazer iteração com deve, isso demora. Se você consegue, não substitui completamente, mas dar mais armas para o seu time de QA, por exemplo, ter muito mais tranquilidade no que eles vão testar, eles podem se preocupar só em testar casos mais específicos sabendo que a IA está ajudando eles a verificar aqueles outros

34:52 casos que não sejam tão óbvios e que daria muito mais tempo e trabalho para garantir a funcionalidade, tá? Então, veja, tudo isso aqui orna junto, beleza? Tudo isso aqui conversa entre si. Nós queremos aumentar a capacidade, nós queremos aumentar a eficiência, nós temos que diminuir o tempo envolvido por humanos, porque assim nós conseguimos colocar a máquina, colocar a IA para trabalhar muito mais e nós entramos pontualmente. Nós não entramos mais olhando cada linha

35:23 de código. Você quer olhar cada linha de código? Sinta-se à vontade, mas você não vai conseguir extrair o máximo de eficiência. Rafael, mas eu não quero extrair o máximo de eficiência, eu quero, eu prefiro ter um controle maior do código. Sem problema nenhum, tá? Isso é uma opção que você vai tomar dentro do seu time, dentro da sua empresa, dentro do seu projeto. Mas se você quiser ir sempre um pouquinho mais além, né, ganhando mais confiança, é o que disse o DHH, né? Demora um tempo para ganhar confiança, mas depois que você ganha, você consegue maximizar o resultado que

35:53 você tem com a IA. E para finalizar esse vídeo, então, eu quero passar como o pessoal lá do Cloud Code faz com as mudanças de dele, 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, as modificações e um outro contexto, é justa, justamente esse code review é automático ou aqui o que o DHH disse, né? Adversarial agent reviews, ou seja,

36:25 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, 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 rodarem no pull request, tem que estar verdinho antes de algum humano botar o olho. Se não tiver

36:57 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

37:29 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 Jev, 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

38:00 mudança de código, desse ali a 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. Inclusive, se você quiser aprender mais sobre o Gerrit, é o vídeo mais assistido desse canal se tornou o vídeo onde eu falo que Gerrit não é hype. Eu vou deixar o link para você assistir aqui depois. Ok, então passou

38:31 por tudo, ele vai ali para a 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, o 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

39:01 vou ler isso aqui porque é bem grande, 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

39:32 final de todas essas linhas de defesa, 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

40:03 carinho especial nesse trabalho de 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

40:33 canal eu vou trazer para você sempre que tiver alguma 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. Mas agora eu quero saber de você, você concorda comigo? Você acha que eu estou só aqui vendendo um sonho? Que é só porque eu sou um vendedor de curso? Agora você pode falar isso, porque de fato eu vendo curso. Até três semanas atrás eu tinha esse álibi, eu não tenho mais, perdi esse álibi agora que eu tenho o programa

41:03 IA. Então, me conta aqui nos comentários o que que você acha, como que você faz no seu time, na sua empresa, como que você gostaria que fosse, comenta aqui livremente, eu quero saber a sua opinião. Aproveito para pedir que você curta esse vídeo, que você compartilhe ali com o seu companheiro de trabalho, com o seu amigo, sua amiga que usa IA no dia a dia e que sabe que está tendo dificuldades para revisar, para garantir a qualidade ou que nota que não está conseguindo extrair o máximo da inteligência artificial. Tenho certeza que você vai gostar bastante desse canal, se você não é inscrito aqui, por

41:35 gentileza, se inscreve, se tiver no celular, não deixe de hypa. Eu faço um convite também, se você quiser que eu fale mais desses princípios de code review na sua empresa, eu tenho a minha própria empresa de consultoria chamada Quintanilha IA. Entra em quintanilha.com, o link vai estar aqui na descrição, para encher lá o formulário que o nosso time entra em contato para ajudar você a extrair o máximo da IA com segurança. Repito o convite também para que você conheça nossa formação individual lá no programa

42:05 IA. O curso de programação agente que em particular fala bastante disso, porque é muito importante que nós programadores saibamos como operar com a IA e garantir a qualidade do que nós estamos fazendo, porque afinal de contas, por mais que a IA seja quem escreva o código, os responsáveis sempre seremos nós, beleza? Agradeço imensamente a você por estar comigo aqui até agora nesse longo vídeo e até a próxima.