Code review com IA: como ganhar produtividade sem perder qualidade

Ver no idioma original →

Autoria: Rafael Quintanilha – QuantBrasil · 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: Code review com IA: como ganhar produtividade sem perder qualidade · Canal: Rafael Quintanilha – QuantBrasil · 42:05 · Assistir no YouTube

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

Resumo

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.

Pontos-chave

• 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.

Capítulos

Início	Capítulo	Resumo
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.

Citações

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

Conceitos e entidades

• Claude Code (ferramenta): Produto de codificação com IA cujo time é apresentado como exemplo de fluxo de revisão automatizada.
• Codex (ferramenta): Ferramenta citada para code review e para executar verificações de QA com computer use.
• ChatGPT (ferramenta): Produto mencionado como opção para executar code review automático em pull requests.
• CodeRabbit (ferramenta): Serviço de code review automático recomendado pelo apresentador como alternativa.
• TestSprite (ferramenta): Ferramenta citada como apoio à execução de testes automatizados.
• Uncle Bob Martin (pessoa): Autor de Clean Code, citado ao discutir a programação como meio para alcançar resultados.
• DHH (pessoa): Criador do Ruby on Rails, citado por defender revisões feitas por agentes e testes automáticos em vez da inspeção humana de cada linha.
• Rafael Quintanilha (pessoa): Apresentador do vídeo e profissional de engenharia de software que relata sua experiência com code review.
• linhas de defesa (conceito): Conjunto de verificações em sequência que busca detectar problemas antes de exigir a revisão humana.
• revisão baseada em risco (conceito): Abordagem que direciona a intervenção humana conforme o risco e o impacto provável de uma mudança.

Tradução completa (pt-BR)

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

00:31 fazer para aproveitar ao máximo a produtividade que a IA nos proporciona sem negligenciar a qualidade do código? 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. Quero dar a minha própria opinião pessoal, como alguém que já revisou milhares de pull requests na vida, e responder à 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 em 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? Foi por isso que eu disse que esse é o elefante na sala quando a gente conversa com pessoas que trabalham com software. Então, este vídeo é um pouco diferente: quero fazer essa reflexão com você, como alguém que é engenheiro de software por formação, tá?

01:35 Sou formado em engenharia de computação e trabalho com isso a minha vida toda. Claro, hoje tenho um canal aqui falando sobre inteligência artificial, mas isso me afeta diretamente também. Além disso, passei grande parte da minha carreira revisando o código dos outros, então posso dizer que esse é um trabalho que fiz muito e entendo perfeitamente as implicações do que vamos discutir aqui. Só que, né, é necessário que a gente entenda que houve uma mudança. Inicialmente, a IA ia lá e 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 é muito menor; é um review muito mais minucioso. Só que, além disso, tem outro problema, que é o seguinte: temos uma superoferta de token. Você pode, por exemplo, assinar um plano como 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, poderíamos dizer que, pelo preço de metade ou de um terço de um estagiário, você consegue ter, né, uma IA trabalhando em paralelo em diversas tarefas ao mesmo tempo e, naturalmente, fica interessado em maximizar aquele poder. Só que, se você está revisando minuciosamente tudo aquilo que é escrito pela IA, todas as linhas, não vai conseguir; vai se tornar o gargalo, o bottleneck. Não estou dizendo que você deve aceitar cegamente tudo o que foi escrito, nem que deve revisar toda

03:09 a linha de código. Estou apresentando o problema para que juntos conversemos de forma madura sobre isso, tá? Inclusive, convido você a deixar sua opinião aqui ao longo do vídeo sobre o que formos tratar. Claro, este é um vídeo opinativo: estou trazendo opiniões de outras pessoas e vou dar a minha também. Estou interessado em saber a sua. Então, já aproveito e peço para você curtir este vídeo, participar da discussão com a gente e se inscrever no canal também, porque aqui 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 o time do Cloud Code lida com a revisão de código. E aí fica a dúvida, né? Como você revisa código no volume que os agents produzem? Imagino que isso seja particularmente, né, relevante para quem trabalha numa empresa de IA, né? Uma empresa que tem tokens infinitos. Mas você nem precisa se colocar na realidade deles. Vou dar o exemplo da empresa em que trabalho. Trabalho numa

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

04:41 você vai ter ali bastante token para usar. Então, 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 minimiza o número de intervenções humanas, certo? De reviews feitos por humanos, sem aumentar, né, as reversões e os incidentes. Então, basicamente, o dilema que precisamos resolver é o seguinte, né? Qual é o dilema? Precisamos aumentar a

05:12 produção de código, aumentar a quantidade de código produzido. E aqui estou falando de código; não entenda isso como linhas de código. Obviamente, essa é uma medida que não faz sentido. O que faz sentido é aumentar a quantidade de funcionalidades, de coisas que você coloca ali no seu app, né? Então, aumentar a produtividade no geral, certo? Ao mesmo tempo que você aumenta a produtividade, quer diminuir o human in the loop, ou seja, a intervenção humana. É a 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 bugs, beleza? Então, isso é perfeito, né? Não é isso que todo mundo quer? Hoje sou VP of Engineering, já fui Engineering Manager, e é basicamente isso que você quer alcançar quando tem um time de engenharia. Você quer maximizar a produtividade, diminuindo, né, o tempo que precisa dedicar a alguma intervenção e diminuindo o número de bugs. Por exemplo, você pode medir isso no seu time. Você tem uma sprint, né, um cycle; trabalha com linha, é um período de tempo em que as pessoas

06:13 vão trabalhar, e você vai lá e soma a quantidade de pontos, né, usando, por exemplo, Fibonacci para estimar quantos pontos custa uma determinada tarefa. E aí você soma os pontos entregues numa sprint. Para dar uma definição completa do 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 nesse período normalmente se reúne com o seu time e vocês concordam sobre o que será entregue naquela semana, naquela sprint.

06:46 Então, pega o desenvolvedor X: olha, você vai trabalhar nisso, nisso e nisso. Desenvolvedor Y, você vai trabalhar aqui, aqui e ali. Então, cada pessoa, né, se compromete a entregar um determinado ticket. Aí você faz uma estimativa, né? Olha, quanto tempo você acha que vai levar para fazer esse ticket? Normalmente, traduzimos esse tempo, né, esse nível de esforço necessário, em pontos. É uma forma de mensurar 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, e tem ali o que chamamos de velocity, ou seja, a velocidade do seu time, tá? Quantos pontos o seu time costuma entregar em uma sprint? Por que isso é interessante? Porque todo manager quer saber quantos pontos você consegue entregar. Porque, quando surgir uma nova funcionalidade para ser feita, você vai ver: bom, o meu time consegue entregar 100 pontos em uma semana. Pegando aqui tudo o que precisa ser feito para essa funcionalidade e somando os pontos estimados, cheguei à conclusão de que

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

08:20 qualidade. Isso aqui muitas vezes vai passar por uma intervenção humana. Podemos ter aqui o QA manual, ou seja, alguém que vai lá e clica, sai clicando para ver se está funcionando, né? Também temos o QA automatizado. Aí você tem testes automatizados, né? Testes de ponta a ponta, muitas vezes. Uma das funcionalidades que 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 a revisão de código. A revisão de código é basicamente

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

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

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

10:24 Ou seja, se você está trabalhando em um time com várias pessoas e está acostumado a trabalhar em uma determinada área, sei lá, você trabalha no app mobile do seu time. E aí alguém faz uma mudança no app em que você não trabalhou, mas você sabe que 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, porque, a partir de agora, a gente vai passar a fazer assim”. Então, muitas vezes você marca uma pessoa em um pull request, por exemplo, para que

10:55 ela veja: “Olha, presta atenção nisso aqui, tá?”. Então, o compartilhamento de conhecimento sempre foi algo feito durante a revisão de código 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 mais entrar lá e escrever à mão; se precisar trabalhar nisso, vou usar uma IA para trabalhar com aquilo, e a IA vai dar um jeito de entender. Ela pode puxar o pull request, pode puxar as decisões tomadas; ela consegue fazer isso muito mais facilmente do

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

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

12:27 peguei um tweet dele aqui. Até disse que não sabia quem ele era, e aí as pessoas vieram reclamar de mim aqui, falar que eu nem era engenheiro de software de verdade por não saber quem era Bob Martin. E, de fato, nunca li os livros dele, embora, depois de saber o que ele fez, já tenha ouvido muitas coisas, principalmente sobre o Manifesto Ágil. O ponto não é esse, tá? O ponto é que muita gente segue Bob Martin por causa de livros como Clean Code, né, em que ele descrevia uma forma de arquitetar seu software. E o próprio Bob disse aqui, no início deste mês, que

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

13:31 ela passa a ser uma ferramenta que você usa para desenvolver alguma coisa que vai ter um efeito prático: desenvolver um app, melhorar a vida das pessoas, melhorar sua própria vida, sua produtividade etc. Ou você pode encarar a programação como um fim em si mesma. Por exemplo, quase como se fosse uma arte, um ofício. Quero trabalhar com programação de uma forma mais manual, mais artesanal, porque 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 queira abrir uma empresa de marcenaria ou competir com uma fábrica de móveis de madeira. Não, você quer fazer aquilo de forma lenta, né, para uso pessoal e também para espairecer um pouco. Tudo isso é legítimo, mas, no ambiente corporativo, no ambiente produtivo, a programação é um meio para 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 cada linha de código, tanto faz, desde que você chegue ao resultado. Então, outra opinião que eu queria trazer é a do DHH. Eu sempre trago ele aqui, né? É o criador do Ruby on Rails, hoje em dia do Omar aqui, né, CTO da 37signals etc.; um cara extremamente conhecido e famoso, que também ficou famoso por, no início, ser cético em relação à IA e depois ter mudado de ideia quando percebeu que a IA tinha melhorado bastante. Então, ele demorou para entrar no hype, demorou para apostar tudo na IA, porque foi bem criterioso, e hoje em dia fala coisas como esta aqui, ó.

15:06 Olha o tweet do DHH, do dia 28 de setembro. “Demora para você ganhar confiança, mas não existe um futuro em que você revisa manualmente cada linha de código gerado por um agent. Não há muita aceleração nisso. Você precisa de revisões feitas por agents adversários, né? Um contradizendo o outro, tentando derrubar o outro. Você precisa de testes automáticos, né? E talvez você vá lá e

15:38 Dá uma olhada para ver se está tudo certo. E é basicamente isso. Do prompt à produção, beleza? Então aqui é o DHH falando: “Cara, não vai ter um futuro em que você vai ficar revisando manualmente cada linha de código”. Ele não está dizendo que você nunca vai olhar, né? Ele já está dizendo aqui, ó: “Eventualmente, você vai lá para ver se está tudo certo”. Mas revisar cada linha de código é muito difícil se você quiser maximizar a produtividade de um agent, 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 colaborador 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 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 venho de uma trajetória em gestão, eu sempre tinha que ficar ali pensando nesse aumento de produtividade. Então, para mim

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

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

17:45 depois. E isso mudou, pessoal. Isso mudou, porque hoje é o próprio agent 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 base de código. 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 naquele código, hoje em dia isso já não é mais tão necessário. Estou trazendo esse artigo

18:16 que eu mesmo escrevi há 7 anos para mostrar para você que não estou falando isso porque estou aqui na onda da IA, não é por isso. Estou falando isso porque percebi como as coisas funcionam hoje em dia e que não era assim no passado. Tanto é que já escrevi sobre isso. Agora, já que provei para você que venho de uma trajetória muito anterior à IA e que percebi como a IA ajuda no trabalho hoje em dia, quero fazer um convite para você que quer aprender a usar agents de IA na prática para construir software. Isso porque 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, vai encontrar hoje a trilha do engenheiro de IA, que tem três cursos que ajudam você a construir esse aprendizado em engenharia de IA. O que é engenharia de IA? É resolver problemas utilizando a inteligência artificial. Dividi essa trilha em três cursos: o curso de fundamentos da engenharia de IA, para que você aprenda a base do que vai usar para construir seus apps. O curso de

19:19 Programação Agêntica, para que você aprenda a usar agents de IA no desenvolvimento de software. E é aqui que vamos entrar em detalhes para aprender inclusive a fazer as verificações automáticas com IA que vamos ver no artigo descrito pelo pessoal do Cloud Code. Então, no curso de Programação Agêntica, falamos com muito mais detalhe sobre a técnica, essa nova forma de trabalhar com engenharia de software, que é utilizando agents de IA. E, por fim, também tem o curso de Harness Engineering, para aquelas pessoas que querem aprender a

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

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

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

21:22 código hoje em dia? E, se algo quebrar, quem percebe isso, né? Quem monitora isso? Quem vai ver que quebrou e corrigir? Este é um artigo deles que descreve o fluxo de revisão de código dentro do time do Cloudcode e como ele evoluiu. De junho a setembro, o número de pull requests integrados à base de código do Cloudcode mais que dobrou, enquanto a taxa de reversões caiu mais de 40%, tá? Ou

21:53 seja, se voltarmos aqui à nossa equação, eles alcançaram isso: aumentaram a produtividade e diminuíram o número de regressões. Sei que você pode estar tentado a desconsiderar o que eles estão dizendo aqui, mas confesso que observei isso também no time em que sou gerente, tá? Aumentamos o número de pontos entregues por sprint e o número de regressões que tivemos se manteve igual ou até diminuiu, tá? Então

22:25 isso é algo que você consegue medir facilmente usando qualquer rastreador de issues. E, de fato, notei, principalmente nesses últimos meses, esse aumento de velocidade, sem prejuízo da qualidade. Então, de fato, os modelos mais recentes, assim como o maior conhecimento do time como um todo, à medida que a IA vai ficando cada vez mais popular, sem dúvida têm ajudado nisso. Bom, tá? Então o pessoal do Cloud diz que não removeu a revisão, mas transferiu para as máquinas a maior parte do que ela analisa, otimizando o tempo gasto por humanos e investindo pesadamente em tornar essa revisão tão rápida quanto fácil de desfazer possíveis erros, beleza? E aí tem aqui a seção “Repensando o propósito da revisão de código”, e a gente já conversou bastante sobre isso, né? Então eles também dizem aqui, ó: “A revisão de código faz dois trabalhos, né? O primeiro é encontrar e corrigir problemas antes que você coloque esses problemas no ar e também construir um contexto comum entre o time, né? Então a

22:56 ∅

23:26 A gente falou basicamente isso, e o artigo é basicamente sobre a etapa número um: como encontrar e corrigir os bugs. E aqui tem uma passagem muito interessante, em que 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 um humano correta para detectar isso?”, tá? Ou seja, o que eles querem dizer? Você precisa pensar no que pode dar errado e em como 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: “Ah, não, porque um humano olhou aqui, eu fico mais tranquilo”, mas isso nem sempre é verdade. E aí eles dizem aqui: “Hoje em dia, o review é executado continuamente, quase como se fosse um corretor ortográfico, né? Quase como uma correção de texto enquanto você escreve, e a maior parte das mudanças tem sido revisada e corrigida pelo Claude pelo menos uma vez antes de um humano ter que intervir para olhar,”

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

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

25:31 atenção, que é basicamente o fato de que, quando você troca muito de assunto, aquilo ali sempre deixa um resíduo na sua mente. Esse resíduo vai aumentando com o tempo, se acumulando, de modo que, se você fica toda hora trocando de assunto, no final do dia não tem mais energia para nada. É quase como se você tivesse esgotado a RAM do seu computador; você precisa dar um reboot, que é basicamente dormir, né? Parar de trabalhar, descansar. Então, quando você está fazendo um code review, o que está fazendo na prática, tá? Então, um code review requer que o revisor

26:03 entenda o código. Você precisa entender primeiro o que está mudando, né? Entender o que está mudando, como era antes, as implicações e até os detalhes técnicos, tá? Agora, imagina fazer isso para quatro, cinco pull requests por dia. Você basicamente está carregando o contexto,

26:35 né? Está carregando o contexto um, né? O contexto dois, o contexto três, o contexto quatro. Está carregando o contexto de um monte de tarefas, às vezes não relacionadas, na sua memória, de modo que vai lentamente esgotando a sua capacidade cognitiva, vai ficando cansado e não consegue mais produzir, tá? Então, isso aqui é algo extremamente difícil de lidar. Só que agora pense que a IA é um multiplicador. Sei lá, agora o seu time entrega 10 vezes mais pull requests,

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

27:37 minimizar o tempo que precisa despender, tá? Então, no final das contas, o objetivo — o objetivo — é minimizar a supervisão humana, por causa dos problemas de que falamos. Então, para minimizar a supervisão humana, antes que chegue ao humano… Então, está aqui, ó: você vai revisar o seu código antes de ele chegar aqui, né? Então, a gente tem aqui o código gerado, que tem que passar por um

28:08 conjunto de etapas. Aí, claro, você tem as etapas mais simples, que são as verificações estáticas. Então, aqui entram linter, formatação e type check: são aquelas verificações que o código pode fazer, e elas são 100% determinísticas. Depois, você vai passar pelos testes. E quais são esses testes? Podemos ter aqui unit tests, né? Também podemos ter end-to-end tests. Então, beleza, aqui normalmente você vai mapear os acceptance criteria, os

28:39 critérios de aceite, né? Esses critérios de aceite vão virar testes, que a própria IA pode escrever, e ela vai escrever código até que esses testes estejam passando. Depois, depois dos testes, a gente entra aqui num code review automático. Então, aqui estamos falando do code review do Codex e do code review do Claude Code. Ambos vão ter as suas próprias soluções, tá? Se você entrar aqui no ChatGPT, né, vier aqui em Settings, vai ver que, no final, tem o

29:09 code review. Eu gosto bastante, é o meu favorito. Posso selecionar um repositório, por exemplo, Rafael Tanilha/Skills, e configurar, ó, o automatic review aqui. E aí esse review, né, vai ser, por exemplo, para todos os pull requests e vai ser disparado, é, cada vez que o PR for aberto ou a cada push, né? Então, posso, né, utilizando, por exemplo, o code review do ChatGPT, fazer um code review automático. Você também pode fazer esse code review com o Claude Code, tá? Eles

29:39 têm essa funcionalidade agora disponível para todo mundo que está no Claude Teams ou no Enterprise, embora aqui você tenha que pagar por créditos, tá? No do ChatGPT, a vantagem é que ele consome do seu limite do Codex. Então, é excelente. Além disso, há outras empresas que oferecem serviços focados em code review. Por exemplo, o Graphtile ou o que eu mais gosto de usar, que é o Code Rabbit, sobre o qual, inclusive, já fiz um vídeo aqui no canal. Vou deixar o link, se você quiser assistir ao 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 pelo link que está na descrição, ajuda aqui o canal. Então, é, sinta-se à vontade também para testar o Code Rabbit como outra linha de defesa que você pode ter. Então, tá. Depois que você passou por todas essas linhas de defesa, aí sim pode enviar para o humano. Por quê? Porque, nesta etapa do code review, normalmente, né, a IA vai apontar aqui um problema P1 ou um problema P2, né? Isso aqui são os graus de

30:40 severidade, né, 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 o que foi encontrado. Embora seja bom dizer que, muitas vezes, a IA, principalmente se estiver com o reasoning muito alto, né, um reasoning extra high, um reasoning max, tende a fazer muito nitpick, como a gente chama, né? A elucubrar muito e inventar um caso muito

31:11 mirabolante, que tecnicamente pode acontecer, mas que, na prática, muito dificilmente vai acontecer. E ela inventa esses casos mirabolantes, e aí você passa diversos momentos corrigindo algo que dificilmente vai acontecer, tá? É importante que você ajuste isso ao seu gosto pessoal, beleza? E aí, depois que a IA passou por essa etapa de verificação — ou seja, passou pelo linter e pelo type check, não tem nenhum problema de formatação, todos os testes passaram, 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 dizendo que é impossível, não estou dizendo 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 revisão final, que foi o que o DHH chamou de verificação pontual, né? Você vai lá, entra aqui e fala: “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,

32:14 você pode riscar isso aqui. Por que pode riscar isso aqui? Porque a IA gerou. Talvez tenha demorado até meia hora para fazer isso aqui, mas 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, né, no pior dos casos, se a IA fizer um trabalho em que, no fim das contas, adotou uma abordagem errada e você não percebeu, porque não fez um planejamento adequado — detalhe que eu comento lá no curso de Programação Agente —, se deixou passar, mas chegou nessa

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

33:17 E aí você tem ambientes de pré-visualização, então cada vez mais as empresas estão levando você para a nuvem. Ok, você vai lá, trabalha em paralelo, gera um ambiente de pré-visualização e, no fim das contas, se o código está passando, porque passou pelas suas linhas de defesa, você tem ali um artefato para verificar visualmente: “É isso mesmo que eu queria?” Ou não, a experiência não está tão legal, né? Porque a questão de UX, né, e o famoso gosto, isso é você que vai ter que avaliar também. Outra coisa: já que você tem um ambiente de pré-visualização, pode usar um computer user ali, e aí o Codex é o

33:50 principal para isso. Você vai lá e coloca um computer user para fazer todo o QA. Aqui ele vai fazer todo o QA para você, um QA manual, né? Claro que é operado pelo computador, pela IA, mas você fala assim: “Olha, Codex, está aqui o meu ambiente de pré-visualização. Vai lá, você sabe qual é o ticket, gera os casos de teste e verifica cada um deles para garantir que está funcionando. Sai clicando, verifica no banco de dados, cria uma conta com as condições adequadas”. Pessoal, isso aqui

34:21 leva muito tempo para fazer à mão. No time em que trabalho, um dos maiores gargalos que temos é justamente o QA, porque a configuração do QA, gerar condições para testar manualmente e fazer iterações com o dev, tudo isso demora. Se você consegue — não substituir completamente, mas dar mais ferramentas para seu time de QA —, por exemplo, dar muito mais tranquilidade sobre o que vão testar, eles podem se preocupar só em testar casos mais específicos, sabendo que a IA está ajudando a verificar aqueles outros

34:52 casos que não são tão óbvios e cuja verificação levaria muito mais tempo e trabalho para garantir a funcionalidade, tá? Então, veja, tudo isso aqui se encaixa, beleza? Tudo isso aqui se conecta. Nós queremos aumentar a capacidade, queremos aumentar a eficiência, temos que diminuir o tempo gasto por humanos, porque assim conseguimos colocar a máquina, colocar a IA para trabalhar muito mais, e nós entramos pontualmente. Não entramos mais olhando cada linha

35:23 de código. Quer olhar cada linha de código? Fique à 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, prefiro ter um controle maior do código. Sem problema nenhum, tá? Essa é uma opção que você vai tomar dentro do seu time, da sua empresa, do seu projeto. Mas, se quiser ir sempre um pouquinho mais além, né, ganhando mais confiança, é o que o DHH disse, né? Leva um tempo para ganhar confiança, mas, depois que você ganha, consegue maximizar o resultado que

35:53 você tem com a IA. E, para finalizar este vídeo, quero mostrar como o pessoal lá do Cloud 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. E aí, depois, outro agent vai lá e revisa o diff, né, ou seja, as modificações em outro contexto. É justamente isso: esse code review é automático, ou, como disse o DHH, revisões adversariais por agents, ou seja,

36:25 outro contexto olhando para aquilo com um par de olhos novos, digamos assim, né? Então, isso acontece antes do pull request. E aí, em cada pull request, o que acontece? Bom, lá no CI, na integração contínua, de novo: lint, tipos, 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 rodarem no pull request têm que estar verdinhos antes de algum humano dar uma olhada. Se não estiver

36:57 verdinho, nem adianta chamar 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 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. A segunda opção, uma alternativa, seria algo como o Code Rabbit, de que também falei, mas são agents que vão rodar diretamente no pull request.

37:29 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 intervenção humana. Isso é 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

38:00 mudança 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, mudança de texto, né? Mudança de texto ou pequenas mudanças de UI, né? Ou aquele código muito autocontido, cujo blast radius, né, cujo raio de destruição ali seja pequeno. Então, isso é algo interessante. Inclusive, se quiser aprender mais sobre o Gerrit, o vídeo mais assistido deste canal acabou sendo aquele em que digo que Gerrit não é hype. Vou deixar o link para você assistir depois. Ok, então passou

38:31 por tudo, vai para a fila para fazer o merge e, depois do release, eles colocam atrás de uma flag, né? Protegido por uma flag, usado internamente primeiro, e 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, o Cloud Code é usado por milhões de pessoas; eles têm que ter um pouco mais de cuidado com os releases, tá? Então, essa também é uma estratégia que você pode usar. E aqui eles continuam falando de todas as camadas de proteção, tá? Eu não

39:01 vou ler isso aqui porque é bem longo, são sete camadas que eles colocaram, mas quis trazer isso para que você entenda que é exatamente o que venho falando aqui sobre as linhas de defesa. Eu chamo de linhas de defesa; eles chamam de layers, tanto faz. A ideia é: são camadas, são linhas pelas quais você tem que passar, né? O código tem que passar por aquelas etapas até que, no final, chegue ao human in the loop, 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 pode, no

39:32 No final de todas essas linhas de defesa, falar: “Olha, já que passou por tudo isso aqui e analisou qual é a mudança, nem precisa de revisão humana, pode passar 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 de a gente colocar 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

40:03 tentar melhorar a etapa de revisão de código, sabe? Eu sei que ninguém gosta de fazer revisão de código; é 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 você 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

40:33 canal eu vou trazer para você sempre que houver alguma mudança, alguma alternativa, algo que possa ajudar nessa difícil missão que é revisar código, principalmente hoje em dia, quando 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 sou vendedor de curso? Agora você pode falar isso, porque, de fato, eu vendo curso. Até três semanas atrás eu tinha esse álibi; não tenho mais. Perdi esse álibi agora que tenho o programa

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

41:35 gentileza, inscreva-se. Se estiver no celular, não deixe de dar hype. Faço também um convite: se você quiser que eu fale mais desses princípios de revisão de código na sua empresa, tenho minha própria empresa de consultoria, chamada Quintanilha IA. Acesse quintanilha.com; o link vai estar aqui na descrição. Preencha o formulário, e nosso time entrará em contato para ajudar você a extrair o máximo da IA com segurança. Repito também o convite para que você conheça nossa formação individual lá no programa

42:05 IA. O curso de programação agêntica fala bastante disso em particular, porque é muito importante que nós, programadores, saibamos como operar com a IA e garantir a qualidade do que 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 até agora neste longo vídeo. Até a próxima.

Transcrição original

[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.