Resumo geral
- O texto não decreta a “morte do sistema de PR” em si, mas aborda a realidade de que, na era da IA, o PR já não funciona mais como um “mecanismo de transmissão de entendimento”.
- O problema central, antes mesmo da qualidade do código, é o crescimento de uma situação em que o contexto, a intenção e o julgamento que deveriam acompanhar o código não são transmitidos pelo PR.
- Em conclusão, a essência do PR continua válida, mas, se a forma de operá-lo (as condições do gate) não mudar, ele deixará de cumprir o papel de linha de defesa.
1. A formulação do problema: por que o PR está balançando?
- Enxergar a causa do fracasso do PR como “os reviewers ficaram preguiçosos” é diagnosticar o problema de forma errada.
- A causa real é o acúmulo do fenômeno em que o PR Review já não transmite entendimento. Ou seja, o reviewer (desenvolvedor) não consegue compreender a intenção e o contexto do PR.
- A IA reduz drasticamente o custo de gerar PRs, mas amplia a assimetria existente (gerar é rápido, revisar é lento).
2. O papel original do PR: não um processo de aprovação de código, mas um contrato de transferência de responsabilidade
- O PR nunca foi apenas um processo para verificar sintaxe de código ou se os testes passam.
- Havia uma promessa implícita de que o autor seria capaz de explicar “por que isso foi feito assim”.
- O reviewer tinha o papel de avaliar não só o código em si, mas também o julgamento e a intenção de design por trás dele.
- Em outras palavras, o botão de merge não era apenas um botão de aprovação de código, mas uma decisão de consenso social de que o time aceitaria junto a responsabilidade por aquela mudança.
3. O gate já era frágil antes
- O open source sempre foi o ambiente que mais expôs as fragilidades da estrutura de PR.
- Pelo cansaço mental e físico dos mantenedores, a lacuna de contexto e a diversidade de contribuidores, o PR tendia facilmente a se transformar em aprovação meramente formal.
- O caso do backdoor no xz Utils mostrou, mais do que uma falha de automação, como um gate humano esgotado pode se tornar superfície de ataque.
Ou seja, mesmo antes da IA, o gate de PR já era fragile (frágil), e os sinais de seus limites já vinham se acumulando.
- Caso do backdoor no xz Utils: um ataque à cadeia de suprimentos de open source em que um contribuidor, após construir confiança por mais de dois anos, inseriu um backdoor por meio de PRs.
4. A mudança trazida pela IA: enxurrada de PRs e explosão da assimetria na revisão
- Com as ferramentas de coding com IA, a velocidade e o volume de geração de PRs cresceram drasticamente.
- Já a revisão continua dependendo do tempo, da concentração e da compreensão de contexto humanos.
- Como resultado, surge um padrão de mais código, PRs maiores, revisões mais longas e mais incidentes.
- Isso não nega a “ganho de produtividade” em si, mas alerta que aceleração sem governança pode se tornar venenosa.
5. O problema mais profundo: código que funciona, mas ninguém consegue explicar
- O risco do código gerado por IA não é apenas “código que quebra imediatamente”.
- Mesmo depois de passar em testes e compilar com sucesso, o problema maior é o acúmulo de código sem explicação sobre por que foi escrito daquela forma.
- Quando ocorre uma falha com o tempo, o time não corrige; ele passa a interpretar um código sem intenção, tentando adivinhar seu significado.
- Diferentemente de um bug comum, isso é mais perigoso porque não há rastros de julgamento de design nem um responsável claro.
6. O conceito central oculto: a IA preenche lacunas de informação de forma plausível
- A IA tende, em vez de revelar o que não sabe, a preencher os espaços em branco com código plausível.
- O problema é que essas lacunas (suposições ocultas, restrições não confirmadas) não aparecem com clareza na etapa de PR.
- Por isso, “o código roda / a documentação parece plausível / os checks passaram” já não basta para garantir segurança.
- No fim, o que o gate do PR precisa verificar não é se compila, mas se existe reasoning (por quê / o quê / sob quais restrições) para essa mudança.
7. O que o caso OpenClaw mostrou: escala e velocidade que o PR não consegue suportar
- O texto cita o OpenClaw como um caso representativo em que o colapso do PR apareceu de forma condensada.
- O OpenClaw (nome inicial: Clawdbot) era um projeto experimental/playground de caráter pessoal iniciado por Peter Steinberger por volta de novembro de 2025.
- Em um curto período (cerca de 10 semanas), cresceu de forma explosiva e atraiu grande volume de usuários, contribuições e atenção externa.
- Nesse processo, questões de segurança, skills/contribuições maliciosas e aumento da carga de revisão se somaram, levando o projeto a uma situação difícil de sustentar por um mantenedor individual ou uma estrutura pequena.
- Depois, em fevereiro de 2026, ele publicou uma retrospectiva sobre o projeto, mencionando que, para torná-lo mais seguro, seriam necessárias mais estrutura, recursos e acesso à pesquisa mais recente.
- Em seguida, repassou o projeto e entrou na OpenAI.
- O texto interpreta esse ponto não como crítica pessoal, mas como uma cena que mostra o abismo entre “o sucesso de um protótipo brilhante” e “a operação segura de uma infraestrutura de uso geral”.
- Além disso, o ponto central não é um único erro de implementação, mas a estrutura em que a escala, a velocidade e a diversidade de intenções das contribuições ultrapassaram a capacidade de revisão humana.
- Mesmo que o mantenedor continuasse melhorando a segurança, a velocidade de exposição e a velocidade de contenção não faziam parte da mesma corrida.
- Em outras palavras, a causa do fracasso não foi “não saber construir”, mas o fato de um gate concebido originalmente para um modelo pessoal/local de confiança não ter suportado a escala global.
8. O significado da mudança de configuração no GitHub: não um recurso novo, mas um sinal de alerta
- O GitHub anunciou oficialmente, em 13 de fevereiro de 2026, a adição de uma opção para desativar PRs.
- Porém, o autor interpreta isso não apenas como a inclusão de uma funcionalidade de conveniência, mas como um reconhecimento silencioso de que, em alguns repositórios, o próprio PR virou um risco operacional.
- Ou seja, ele enfatiza que isso deve ser lido como um sinal de que até a plataforma já tem dificuldade em sustentar a premissa de que “PR é sempre bom”.
9. A conclusão prática do texto: não abandonar o PR, mas redefinir o gate
- Não se trata de defender a interrupção do desenvolvimento de ferramentas de código com IA.
- Pelo contrário, a pergunta não é “usar IA ou não”, mas se vamos usá-la sem um gate que realmente funcione.
- O que é necessário, mais do que uma lista de regras, são princípios operacionais como explicabilidade, design prévio, explicitação do que ainda não foi confirmado, direito de recusa do mantenedor e garantia de rastreabilidade.
- Um PR cujo motivo não pode ser rastreado não é um ativo intelectual que o time possui, mas uma dívida que acabará dominando o time.
10. Resumo em uma linha
- O objetivo do PR não é apenas fazer o código passar, mas transferir junto entendimento e responsabilidade.
- A pergunta central da era da IA: mais do que “o código roda?”, é “dá para explicar este código?”
- Essa pergunta não é um obstáculo à produtividade, mas a condição mínima para preservar a última linha de defesa do software.
2 comentários
Quem pede a revisão só clica, enquanto quem revisa é que quebra a cabeça; virou uma forma não só de transferir responsabilidade, mas de empurrar o trabalho inteiro para outra pessoa.
Concordo muito com este texto.
Nos últimos meses, ver códigos gerados por IA sendo enviados em PRs pelos membros do time tem sido muito sofrido para mim, e venho testando várias formas de melhorar isso.
Além de limitar o escopo dos PRs, como o texto principal aborda, também estou pensando no que exatamente devemos revisar.
Em vez de revisar o código, estou refletindo sobre uma revisão de código que revise a intenção