3

Dev que usa IA pra revisar código cresce mais rápido do que quem não usa

Tem dois tipos de dev usando IA hoje. O primeiro usa pra gerar: pede a função, cola o que veio, segue a vida. O segundo usa pra revisar: escreve o código, depois manda a IA tentar achar o que está errado. O primeiro até entrega mais rápido no curto prazo. Mas o segundo está crescendo mais rápido.

O motivo é simples: crescer como dev depende de feedback. Quanto mais rápido você descobre o que o seu código tem de errado, mais rápido você aprende a não fazer de novo. Antes da IA, esse feedback vinha do sênior no review, o que significa que você esperava dias, levava os comentários, entendia (ou não), e seguia. Era lento.

Quem usa a IA pra revisar está comprimindo esse ciclo. Você escreve, pede um review crítico, recebe o feedback em segundos, entende o problema, corrige, e se pediu o "por quê" junto, sai sabendo mais do que entrou. Faz isso em cada PR durante um ano e a diferença de crescimento começa a aparecer.

Não é sobre entregar mais rápido

Esse ponto importa porque o uso errado também entrega rápido, só que sem aprender nada.

Dev que pede código pronto pra IA e cola também entrega. Às vezes entrega até mais rápido que os dois. Mas ele não está crescendo, está terceirizando o raciocínio. O dia que a ferramenta não estiver ali, ele trava. E o sênior que revisa o PR dele nota, cedo ou tarde, que o código funciona mas a pessoa não sabe explicar por que.

O que separa os dois usos não é a ferramenta. É o que você faz com ela. Pedir pra ela escrever te economiza tempo, mas ela pensa no lugar de você. Pedir pra ela revisar o que você escreveu acelera o seu aprendizado, mas você ainda pensa. No primeiro caso a IA te deixa mais dependente. No segundo, mais afiado.

O review da IA tem limite, e conhecer esse limite faz parte do crescimento

Tem uma armadilha em usar IA pra revisar: ela parece segura, então dá vontade de confiar demais. Mas ela inventa problema com o mesmo tom que usa quando está certa. Ela não conhece o contexto do seu sistema. Ela vai sugerir complexidade que o seu caso não precisa.

Saber filtrar o que ela aponta, aceitar o que faz sentido, descartar o que não faz, e entender a diferença, é em si uma habilidade de dev. E é uma habilidade que você só desenvolve se você decide, em vez de só obedecer.

Por isso eu acho que dev que usa IA pra revisar cresce mais rápido: não porque a ferramenta é mágica, mas porque o uso correto te força a pensar mais, não menos. Você escreve, revisa, filtra, decide. Cada ciclo te deixa um pouco melhor em reconhecer o problema antes de precisar perguntar pra alguém.

Dev que só gera código com IA está usando uma calculadora pra fazer as contas no lugar dele. Dev que usa pra revisar está usando a calculadora pra checar se o raciocínio dele está certo. Um para de pensar. O outro pensa mais rápido.


Ando escrevendo sobre utilização de IA pra estudar/programar. Se interessar:

Utilização de IA para estudo: https://hdfreitas.github.io/ia-como-professor/

Utilização de IA para revisão de código: https://hdfreitas.github.io/ia-como-revisor/

Carregando publicação patrocinada...
1

Mesmo a revisão por IA pode falhar quando não há diretrizes sobre o projeto.

Sem ADRs e PRDs bem consolidados e fazendo parte da base de código, tanto a IA quanto o dev podem escrever e revisar um código que está correto e funcional, mas que violam as definições do projeto.

E mesmo com isso as IA podem vacilar, eu tenho pegado vários problemas de duplicidade de código mesmo depois de revisão por IA e gates gerados por elas mesmos para evitar duplicidade, pois elas têm problemas de abstração e semântica. Mais de uma vez peguei o Claude considerando como diferentes duas funções semanticamente iguais, apenas por conta dos nomes de variáveis e parâmetros terem nomes diferentes.

A propósito, o DeepSeek é bom para encontrar duplicidades de código, não é perfeito, mas é melhor que o Codex e Claude nesse cenário.

Acho que em projetos complexos ainda não podemos deixar 100% da escrita e revisão nas mãos das IA, é grande a chance delas irem na direção errada e você não conseguir se encontrar mais no código. Para isso é importante dividir o desenvolvimento em partes ainda menores do que a gente costuma fazer no "modo tradicional", sempre revisando e corrigindo a direção.

2

Verdade, sem ADRs e convenções documentadas a IA revisa o que vê, não o que o projeto precisa ser. Duplicidade de código é exatamente esse problema, ela trata funções iguais como diferentes só por causa do nome das variáveis.
O ponto de dividir em partes menores faz todo sentido também, quanto menor o escopo por iteração mais fácil manter o controle.