- A questão sobre se faz sentido a IA revisar código escrito por IA é bastante interessante
- Bots como o Devin AI já estão abrindo a maior quantidade de PRs, e os casos em que a revisão também é feita por IA estão aumentando
- Também existe o argumento de que LLMs são sem estado (stateless) e, como a estrutura interna ao revisar e ao escrever é diferente, é possível separar os papéis
- Código gerado por IA tende a causar tipos de bugs diferentes dos humanos, e a IA é mais eficaz para encontrar esses bugs
- Em resumo, a revisão por IA tende a ser mais vantajosa para detectar erros concretos do que a revisão humana, embora o julgamento arquitetural e os guias de estilo continuem importantes
A IA pode revisar o próprio código?
- A maioria das empresas segue o princípio de autor ≠ revisor
- Porém, a IA baseada em LLM é sem estado e julga cada solicitação como algo novo
- Ou seja, mesmo usando o mesmo motor, escrever e revisar podem ser vistos como “carros” diferentes
Scaffolding: a estrutura da revisão por IA
- A IA voltada para revisão executa o seguinte workflow específico:
- análise de diff de código
- detecção de bugs
- redação de comentários e avaliação de gravidade
- consulta à documentação do codebase e a arquivos relacionados
- Já a IA de geração de código opera em um contexto completamente diferente, então revisão e geração são funcionalmente distintas
No fundo, humanos também são o "mesmo motor"
- Mesmo quando o autor do PR e o revisor são diferentes, ambos vêm da mesma inteligência humana
- Compartilham conhecimentos e experiências parecidos, da mesma empresa e com treinamento semelhante
- No fim, tanto IA quanto humanos se parecem nesse ponto de “mesmo motor, casos diferentes”
Código de IA exige uma revisão mais precisa
-
A qualidade do código de IA é um pouco inferior
- A IA é rápida, mas, por causa das limitações do prompt, a transmissão dos requisitos pode ser imprecisa
- Mesmo bons desenvolvedores não revisam código de IA com o mesmo cuidado que revisam o próprio código
- Como resultado, a qualidade geral tende a nivelar por baixo, convergindo para um nível mediano
-
Bugs de IA são difíceis para humanos encontrarem
- Os bugs produzidos por IA são de tipos que humanos normalmente não criam
- Ex.: alterações inesperadas de linha, erros sutis em condicionais etc.
- Segundo testes internos da Greptile:
- IA (Sonnet) encontrou 32 de 209 bugs “Hard”
- Desenvolvedores humanos encontraram em média apenas 5 a 7
Conclusão
- Faz sentido, do ponto de vista técnico, a IA revisar o próprio código
- A IA é melhor do que humanos em detectar bugs e, na prática, é útil para revisão
- Porém, a interpretação de intenção, decisões de design e avaliação de estilo de código ainda continuam importantes como papel humano
- O critério tradicional de autor ≠ revisor talvez precise ser reinterpretado para a IA
3 comentários
Acho que seria interessante revisar alternando os modelos de LLM. Por exemplo, revisar um código escrito com o modelo A usando os modelos B, C e D.
Ah, aqui na nossa empresa fazemos assim: quando abrimos um PR com código escrito no Cursor (Claude), fazemos a revisão com o ChatGPT. A ideia é basicamente “agora briguem entre si”. Desde o
o4-mini, isso tem deixado o pessoal impressionado. Também dá para testar isso direto no Cursor, trocando o modelo e fazendo a solicitação por lá mesmo.Opinião do Hacker News
Quero destacar este ponto: os engenheiros não revisam código gerado por IA com o mesmo cuidado com que revisam código escrito por eles mesmos. Isso acontece porque o LLM gera código muito mais rápido do que a velocidade de digitação. Então, quando você escreve o código por conta própria, a revisão acontece naturalmente, mas quando a IA gera, esse processo acaba sendo pulado. Curiosamente, para um engenheiro mediano, a IA pode até melhorar a qualidade do código. Quanto mais a IA for usada, mais engenheiros bons e ruins vão acabar produzindo código em níveis parecidos. É sempre interessante como o modo de pensar muda em cada etapa: revisão de código, design e escrita
Cada pessoa interage de um jeito, então existe um método que combina melhor com cada um. Para mim, revisar é mais fácil do que escrever código. Quando estou escrevendo, preciso pensar em muito contexto além da base de código, mas ao revisar consigo concentrar esse contexto só na base e fazer correspondência de padrões mais rapidamente. Infelizmente, como o nível dos LLMs ainda é de engenheiro júnior, revisar PRs deles exige mais esforço e energia
Muitas vezes um bom engenheiro não é necessariamente um bom programador
Se você usar bots e prompts diferentes para revisar código e para escrever código com IA, é possível encontrar muito mais erros. Mesmo repetindo várias vezes com a mesma ferramenta, às vezes surgem problemas novos. Nem humanos nem IAs conseguem produzir código perfeito de primeira. As ferramentas de IA estão evoluindo a ponto de já testarem o próprio código e fazerem uma revisão prévia, mas continuo acreditando que tanto pessoas quanto IA revisarem o código de um PR nunca faz mal. Mesmo com uma ferramenta que eu mesmo criei, chamada Kamara, já encontrei problemas em código que ela própria escreveu. Também houve problemas como no exemplo do greptile, fazendo sugestões com localização de código completamente errada, mas isso está sendo controlado aos poucos. Ainda não existe ferramenta 100% perfeita, e sinto que ainda falta um pouco de tempo até a IA tomar conta de tudo
Quando começamos o OpenHands (antes chamado OpenDevin), PRs criados por IA eram enviados com o nome da conta da própria IA. Isso gerava dois problemas sérios: 1) a pessoa que chamou a IA podia fazer merge direto sem revisão de código, então código não verificado podia ir para produção; 2) não havia um responsável claro pelo PR, então, mesmo que ele não fosse mergeado ou desse problema, ficava indefinido de quem cobrar a responsabilidade. Por isso mudamos a estratégia para que todo PR tenha um humano como dono, deixando apenas os commits com o nome da IA. O PR em si é inteiramente responsabilidade humana
Achei interessante a parte sobre LLMs encontrarem bugs com facilidade. Fico curioso sobre quantos falsos positivos aconteceram para atingir uma taxa real alta de detecção de bugs. Pela minha experiência, LLMs muitas vezes dizem que existe bug mesmo quando não existe
Concordo totalmente. Quando pergunto algo ao ChatGPT e não gosto da sugestão, se eu digo "não tenho tanta certeza dessa parte", ele muda a resposta na hora. Na prática, a resposta inicial talvez até estivesse certa, mas, se o usuário não demonstra confiança, ele se deixa influenciar com facilidade. Por isso não é simples validar essas ferramentas corretamente
Neste caso, havia apenas um bug por arquivo e o bot foi instruído a encontrar exatamente um. Todos os casos foram falsos positivos; ele inventou bugs em lugares onde não havia problema algum
A diferença entre as várias ferramentas de revisão de código com IA no mercado está justamente no ajuste da relação sinal/ruído. Algumas ferramentas são muito mais precisas e geram menos falsos positivos
Como programador, a responsabilidade mais importante é produzir código em que você confia e que funcione corretamente. Não importa se você usou LLM. O que importa é a postura de dizer, ao abrir um PR: "tenho confiança de que esta mudança resolve o problema e posso colocar minha reputação em jogo". Portanto, seja humano ou IA, um PR sempre precisa de um segundo revisor
Acho que reputação é o ponto central. Isso não vale só para código, mas também para texto em linguagem natural. Estamos entrando numa era em que a responsabilidade será de quem publica, não necessariamente de quem escreveu. Se 5% ou 95% do texto veio de chatbot, quando houver problema a culpa deve cair sobre mim, que publiquei. A desculpa de "foi o chatbot" não cola
O exemplo era apenas sobre engenheiros totalmente automatizados, como o Devin, então é uma situação um pouco diferente da de engenheiros comuns
Hoje em dia muitos engenheiros estão empurrando código ruim gerado por IA de forma irresponsável, esperando que outros colegas encontrem os problemas. Antes isso acontecia menos, porque gerar o código em si já exigia mais esforço
Concordo profundamente com a ideia de que sua responsabilidade é produzir código confiável. Mas isso já não era bem preservado antes da IA. Passamos a tratar programação apenas como meio ou fonte de renda. Antes havia a alegria de resolver problemas e mudar o mundo. Agora o foco virou ganhar dinheiro rápido ou construir barreiras. O importante não é se o código é bonito, mas se resolveu o problema de forma elegante. A IA pode piorar essa cultura, mas no fim tudo depende de como ela é usada
Tenho uma dúvida. Se um PR resolve todos os problemas, mas inclui apenas bugs pequenos, queria ver um exemplo de quando esse PR ainda seria considerado perda de tempo
Revisão de código é a etapa mais lenta da engenharia. Eu também consigo escrever código rápido sem IA, mas a revisão não fica mais rápida. Por isso, antes da revisão, faço uma pré-revisão com IA para poupar o tempo dos colegas e encontrar bugs antes, reduzindo em dias o tempo até o deploy. A IA já pegou bugs óbvios e erros escondidos, e em alguns casos encontrou bugs realmente profundos. Uso um fluxo em que copio o diff com git cli e xclip e colo em um modelo de raciocínio como o o3 para receber revisão
Uma das vantagens da IA é que ela consegue escrever muito mais testes unitários, muito mais rápido do que humanos. E também consegue corrigir sozinha os problemas que encontra. O fluxo ideal não seria só revisão de código: a IA também executaria testes automaticamente e verificaria se tudo atende a uma especificação definida. Testes demais podem dificultar refatorações depois (por exemplo, testes que dependem de detalhes de implementação) e, quando for conveniente, você pode simplesmente descartar os testes que a IA escreveu
Eu adoro poder regenerar testes unitários sempre que preciso. Quando abro uma revisão, fico satisfeito com o tamanho do diff e economizo o tempo chato de escrever testes, o que me permite fazer mais coisas
Ainda hoje a programação tem tarefas tediosas, mas o ideal com IA seria reduzir essas ineficiências e deixar humanos focarem em áreas criativas. Só que, na prática, a IA está avançando cada vez mais justamente sobre tarefas criativas de nível mais alto
Na verdade, mesmo sem IA, já dá para usar frameworks de testes baseados em propriedades para gerar automaticamente testes com uma enorme variedade de entradas
Tenho uma regra ao revisar código: se eu não me sentir confiante de que conseguiria manter aquilo depois, não aprovo. Se você usa LLM tanto para escrever quanto para revisar, dá para dizer que está aplicando o mesmo princípio de responsabilidade também às ferramentas. Mas eu mesmo não me vejo permanecendo muito tempo numa situação dessas
Tenho curiosidade se alguém já usou um pipeline em que um LLM gera scripts Gherkin a partir dos requisitos, outro LLM gera código a partir desses scripts, e depois o Cucumber valida o resultado. De qualquer forma, tanto os scripts Gherkin quanto o código precisariam de revisão, mas eu gostaria de entender que tipos de código não poderiam ser produzidos dessa maneira. Estou enxergando a IA como se fosse um desenvolvedor, e imagino que, assim como desenvolvedores humanos, ela também tenha áreas em que não vai bem
No fim, quem abre o PR precisa assumir responsabilidade pelo impacto e pelas consequências do próprio código. Com o coding por IA se tornando comum e com muitos engenheiros juniores, essa responsabilidade ficou ainda mais importante. Faz sentido deixar a IA fazer a primeira passada da revisão, mas o revisor humano ainda precisa trazer uma perspectiva externa, aumentar a compreensão da base de código e identificar problemas de nível mais alto. Em resumo, o ideal é IA na revisão inicial, outro engenheiro revisando contexto e colaboração, e, no fim, o autor assumindo responsabilidade por todos os resultados