Pare de me mandar PRs gigantes; um desabafo
PRs grandes gerados por IA estão sobrecarregando revisores humanos de código e expondo limites nos fluxos de trabalho de desenvolvimento atuais. Os comentaristas debatem se devem impor limites rígidos de tamanho de PR, confiar mais em revisão automatizada e assistida por IA, ou repensar o planejamento de funcionalidades para que as mudanças sejam introduzidas em blocos menores e narrativos, mais fáceis de entender e testar. Por trás da discussão sobre ferramentas está uma preocupação mais profunda com responsabilização, qualidade de software e quanto pode ser delegado com segurança a modelos de linguagem grandes.
PRs grandes gerados por IA e gargalo de revisão
- Muitos mantenedores relatam cansaço com PRs de 1.000–4.000 linhas “de uma tacada só” por agentes; a revisão humana vira o gargalo.
- Alguns dizem que, se um PR é grande demais para humanos revisarem, as equipes podem se sentir tentadas a abandonar aprovações e confiar apenas no CI, o que outros consideram perigoso.
- Há preocupação de que, se ninguém consegue revisar totalmente o código, ninguém mais entende de fato o sistema, enfraquecendo o “moat” de uma empresa.
Limites, ferramentas e estratégias de fluxo de trabalho
- Mitigações propostas: verificações de CI ou git hooks que rejeitem PRs acima de N linhas com uma mensagem educada; outros argumentam que isso só fragmenta trabalho incompreensível.
- Os PRs empilhados do GitHub, ferramentas de revisão de PRs “em capítulos” e extensões de navegador são citados como formas de tornar mudanças grandes mais digeríveis.
- Alguns descrevem “skills” ou fluxos de trabalho personalizados que impõem commits atômicos ou separam branches; outros acham que os LLMs são teimosamente ruins em boa higiene de git sem muito prompting.
Filosofia de PRs pequenos vs. grandes
- Uma corrente insiste em PRs pequenos e narrativos: introduza as bases, depois a cola, depois a funcionalidade; despejos grandes ou vários PRs grandes ao mesmo tempo são rejeitados.
- Outra corrente argumenta que alguns recursos “não podem estar meio grávidos”; dividir é trabalho extra e inútil, especialmente quando tudo precisa ser entregue junto.
- Contraponto: a maioria dos recursos grandes pode ser feita em etapas usando feature flags ou refatorações preparatórias; “se houver vontade, há um jeito”.
Papel dos testes e da qualidade do código
- Vários comentaristas enfatizam que testes escritos por LLM podem ser vazios ou codificar comportamento incorreto como especificação; os testes muitas vezes devem ser escritos ou, no mínimo, revisados com cuidado por humanos.
- Histórico de commits limpo e mudanças pequenas e focadas são apresentados como essenciais para uma boa revisão, não como polimento opcional.
Humanos vs IA na revisão e na responsabilização
- Alguns defendem revisões por IA como o único caminho escalável; críticos perguntam quem audita a IA e alertam que “slop gera slop”.
- Uma visão contrastante: reduzir ou remover revisores humanos e aumentar a responsabilização pessoal do “prompter”.
- Outros sustentam que a revisão humana genuína é crítica, especialmente em contextos regulados ou de segurança crítica.
Dinâmicas organizacionais e de OSS
- Em OSS, mantenedores podem simplesmente fechar PRs gigantes/de IA e muitas vezes consideram bloquear completamente contribuições anônimas de IA.
- Em empresas, conformidade, prazos, atitudes da liderança e dinâmicas de poder entre revisor e autor tornam o “basta dizer não” muito mais difícil.