- Na era em que a IA escreve código, o modelo de revisão por pull request (PR) precisa mudar de forma fundamental, e o processo atual de revisão não se encaixa no workflow de programação com IA
- Quando o revisor pergunta “por que isso foi feito assim?”, a estrutura atual faz o desenvolvedor perguntar novamente à IA e colar a resposta, gerando a ineficiência de manter o humano no papel de intermediário (middleman)
- O log de decisões (decision log) da IA deve ser incluído no controle de código-fonte junto com o código, para que o revisor possa verificar o contexto diretamente
- Já é possível criar um workflow em que a IA receba diretamente os comentários do revisor e gere patches e respostas automaticamente, com a combinação de webhooks do GitHub/GitLab e um servidor MCP
- Documentos de design e diagramas de arquitetura também devem ser incluídos no controle de código-fonte em formatos que o LLM consiga interpretar, como Markdown ou Mermaid, e “o contexto é rei”
Problemas da revisão de código na era da IA
- Ao fazer perguntas em uma revisão de PR, voltam respostas que parecem ter sido geradas por IA, porque quem realmente escreveu o código foi a IA
- Para a pergunta “por que essa biblioteca foi escolhida?”, o desenvolvedor humano não consegue responder e acaba perguntando novamente à IA e copiando a resposta para repassar
- Antes da IA, perguntávamos diretamente ao desenvolvedor (autor do código), não ao gerente dele, então é preciso eliminar o intermediário
- Todos os autores do código devem participar da revisão, e usar um agente de IA separado para inferir retroativamente as razões por trás das decisões é uma abordagem completamente equivocada
A necessidade de um log de decisões
- Quando se pergunta “por quê?” a um humano, está se perguntando sobre um processo interno de pensamento que não está incluído no PR
- O chain-of-thought da IA é auditável externamente (externally auditable), e o registro das interações com a IA também pode ser auditado, então esse contexto precisa entrar na revisão e no controle de código-fonte
- Não é necessário commitar todos os tokens gerados durante a criação do PR; inspirado no conceito de episodes da Random Labs, basta incluir a transcrição das chamadas de ferramenta bem-sucedidas e das conclusões
- Isso também pode escalar em ambientes de agent swarm, conectando os logs de decisão antes da etapa do PR e fazendo a formatação final
Limites dos comentários inline
- Alterações em arquivos-fonte exigem reexecução do pipeline de build (linting, compilação, testes) mesmo quando só se modifica um comentário
- As transcrições de decisão são muito maiores do que o volume normalmente permitido em comentários inline
- Os comentários existentes explicam como o código funciona no estado atual, não o processo que levou àquela decisão
Workflow de revisão integrado com IA
- Quando o revisor adiciona um comentário, a IA do desenvolvedor deve conseguir recebê-lo diretamente e gerar patches e respostas automaticamente
- Isso já pode ser implementado hoje com a combinação de webhooks do GitHub/GitLab e servidor MCP
- De forma semelhante ao Devin AI ou ao Claude Code via GitLab Duo
- Pode-se configurar para o desenvolvedor autorizar primeiro a IA, ou para que a IA avalie sozinha e aja imediatamente
- O desenvolvedor humano também pode continuar fazendo comentários e alterações por conta própria
- Isso pode reduzir bastante os problemas de comentários de revisão que só são tratados horas ou dias depois, ou que nunca chegam a ser tratados
Requisitos de ferramenta para revisores
- O revisor também deve conseguir analisar o PR fazendo perguntas diretamente à IA, como faz ao explorar a codebase
- Ter o log de decisões versionado junto com o código é essencial para esse objetivo
- A interface atual de PR deve continuar sendo usada, mas com uma janela ao lado para conversar com Codex ou Claude, integrada como em um ambiente de desenvolvimento IDE
- Ainda não existe uma ferramenta realmente elegante para isso, então seria ótimo se alguém construísse uma
- No diff, o revisor pode tirar dúvidas em particular com a IA sobre bibliotecas desconhecidas, linguagens pouco familiares ou melhores práticas, e depois decidir se é necessário deixar um comentário de revisão
- Se um comentário for necessário, isso é sinal de que há uma lacuna (gap) no log de decisões, e o log deve ser atualizado antes da aprovação do PR
A importância dos documentos de design e do contexto
- Em uma revisão integrada com IA, também fica muito mais fácil para o revisor sugerir patches diretamente
- Documentos de design, registros de decisão (decision records) e diagramas de arquitetura devem ser adicionados ao controle de código-fonte em formatos que o LLM consiga interpretar, como Markdown ou Mermaid
- “O contexto é rei (Context is king)”
10 comentários
Parece que o motivo da morte do PR não é tanto o PR em si, mas a comunicação displicente dos vibe coders.
Com qual fluxo foi implementado, que outras abordagens existiam e por que não foram adotadas, por que o
package.lockprecisa mudar. Não são todas coisas que deveriam ser explicadas antes?Se dá para escrever isso na descrição do PR, parece melhor que morram os coders que fazem os outros terem que perguntar isso à força.
Concordo. No passado, um PR passava a sensação de que eu assumia a responsabilidade pelo resultado que criei,
mas o PR de um vibe coder parece mais algo como: "nem sei direito o que eu fiz, mas de qualquer forma tem um resultado aí, então você que avalie e encontre os problemas".
Concordo.
Estamos indo para uma forma em que o que deveria ser conversado antes acaba ficando para depois, sem que ninguém assuma responsabilidade.
Concordo. Chega a dar nos nervos.
Concordo.
Em um único PR, mudam 500 arquivos, e a pessoa que enviou ainda reclama porque não revisaram em 30 minutos. Na descrição, escreve só umas cinco ou seis linhas e pronto, então é para simplesmente confiar nisso e aprovar...?
Testou tudo, né?
Sim
Beleza, vamos fazer direito
Por que vivem dizendo que morreu?
Todo mundo vai morrer assim!
Parece que estão ficando numerosos demais os textos com título dizendo que algo morreu por qualquer coisa,
o que dá uma certa fadiga.
Eu também acho que já seria bom pararem de matar tudo.
"Morreu; vida longa"
Esse tipo de texto está ficando comum demais. Mas admito que a IA está mudando tudo.