Voltar para as novidades

Por que projetos estão desabilitando pull request para código gerado por IA?

Resposta curta: dois motivos diferentes estão fechando essa porta, e eles pedem respostas opostas de você. O primeiro é custo de revisão: o repositório denoland/celld desabilitou pull request por completo, e o README dele diz que agente de código torna barato demais mandar uma mudança grande e de baixo contexto, que custa mais tempo ao mantenedor do que economiza. O segundo é procedência legal: o projeto QEMU recusa contribuição que se acredite conter ou derivar de conteúdo gerado por IA, porque a situação de direito autoral dessa saída não está resolvida. O primeiro você resolve mandando um patch menor e focado. O segundo você não resolve escrevendo código melhor.

O que o repositório celld desabilitou, exatamente?

O repositório celld, publicado sob a organização denoland no GitHub, tinha 3.166 estrelas e 101 forks quando lemos, em 12 de agosto de 2026. O README dele traz uma seção chamada Contributions com este texto, citado literalmente:

Pull requests are disabled. Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves. Thoughtful contributions are welcome; please understand the code, keep the patch focused, and respect the review time you are asking for.

Duas coisas fazem disso mais que um desabafo num arquivo de texto. Primeiro, o comportamento bate com a declaração: a API REST do GitHub informa pull request como indisponível naquele repositório e devolve 404 no endpoint de pull requests dele, enquanto um repositório com o recurso ligado responde normalmente. Segundo, o texto não é reação a uma semana ruim. Ele já estava no README da primeira versão publicada, em 2 de agosto de 2026, e continuava lá em 12 de agosto de 2026.

Leia a redação com atenção, porque ela é mais estreita do que a manchete sugere. O README do celld não bane IA, e não bane você. Ele diz que contribuição pensada é bem-vinda, e pede outro formato de entrega: um anexo de git format-patch mandado para o endereço de contato do projeto. O que foi recusado é a economia do botão de pull request, em que mandar custa um clique e revisar custa uma tarde.

O banimento do QEMU é a mesma coisa?

O QEMU fechou outra porta, e confundir as duas manda você atrás da correção errada. A página de procedência de código na documentação de desenvolvimento do QEMU, lida em 12 de agosto de 2026, declara a política em letras maiúsculas:

Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

O motivo que o QEMU dá não tem nada a ver com tamanho de patch. É o Developer's Certificate of Origin: quem contribui precisa atestar que entende a situação de direito autoral e de licença do que está enviando, e com gerador de conteúdo por IA essa situação é, nas palavras do próprio projeto, "ill-defined with no generally accepted, settled legal foundation". A mesma página abre uma exceção fácil de perder, e ela merece ser citada em vez de resumida: "This policy does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not included in contributions."

Então a diferença prática para você é total. No celld, um patch menor e mais bem explicado é bem-vindo. No QEMU, nenhuma disciplina de patch ajuda, porque a objeção é de onde o texto veio, não de quanto texto tem. Descobrir qual dos dois casos você tem pela frente custa um minuto lendo os documentos do próprio projeto, e é isso que decide se você melhora o patch ou não manda nada.

Qual o tamanho de uma mudança que um agente de IA de programação realmente produz?

Medimos o nosso próprio repositório, que é uma amostra útil justamente por ser extrema: este site é escrito por agentes de IA de programação trabalhando em git worktrees paralelas. Lendo o histórico completo em 12 de agosto de 2026, são 251 commits sem merge feitos entre 18 de julho e 10 de agosto de 2026. O commit mediano muda 86 linhas. O percentil 90 muda 987. O maior muda 17.718 linhas.

Esse maior commit não é trabalho de agente, e o segundo maior também não. "Set up a fresh Laravel app" (17.718 linhas) e "Install Laravel Boost" (6.275 linhas) foram feitos com 45 segundos de diferença no primeiro dia, e os dois são instalador de pacote escrevendo arquivo, não alguém resolvendo um problema. Dá para separar as duas categorias com mais que um palpite, porque todo commit feito dentro de uma sessão de agente neste repositório carrega um trailer Claude-Session na mensagem. 214 dos 251 commits, 85%, carregam ele, e nenhum dos dois maiores carrega. Contando por linha em vez de por commit a fatia cai para 70%, e a maior parte da diferença vem desses dois commits de instalação.

Restringir a medição a esses 214 commits de sessão de agente mexe menos nos números do que se esperaria, e é esse o achado. A mediana passa a 91 linhas, o percentil 90 a 920, e a maior entrega individual de agente na história do projeto tem 4.007 linhas. A fatia de entregas grandes demais quase não se move: 21,1% de todos os commits mudam mais de 500 linhas (53 de 251), contra 21,0% dos de agente (45 de 214). São duas frações próximas, e não um número só, mas próximas o bastante para dizer que tirar o bootstrap humano da conta não salva a cauda, porque a cauda não é o bootstrap.

No histórico completo, a concentração é severa: os dez maiores commits carregam 43% de todas as linhas já alteradas no projeto, enquanto a metade menor de todos os commits carrega 3%. Ou seja: a entrega típica de um agente de IA é perfeitamente revisável, e é na cauda que vai embora a tarde do mantenedor. Uma política escrita contra essa cauda também acerta os seus patches razoáveis, que é exatamente o que aconteceu no celld.

Rode a mesma medição no seu repositório com um comando:

git log --no-merges --pretty=tformat:'@' --numstat \
| awk '/^@/{if(n)print s; s=0; n=1; next} {s+=$1+$2} END{if(n)print s}' \
| sort -n \
| awk '{v[NR]=$1; t+=$1; if($1>500) big++} END{
    for(i=1;i<=int(NR/2);i++) half+=v[i]
    for(i=NR-9;i<=NR;i++) top+=v[i]
    printf "commits: %d\nmediana: %d\np90: %d\nmaior: %d\nacima de 500 linhas: %d (%d%%)\n10 maiores = %d%% das linhas\nmetade menor = %d%% das linhas\n", NR, v[int(NR/2)], v[int(NR*0.9)], v[NR], big, big*100/NR, top*100/t, half*100/t}'

Os números acima são a saída exata desse comando no nosso repositório, e o recorte só de agente é a mesma sequência com --grep='Claude-Session' acrescentado ao git log. Ele conta linhas adicionadas mais removidas por commit, ignora commit de merge e trata arquivo binário como zero, então um repositório cheio de imagem vai parecer menor do que é. Num repositório com exatamente um commit, a mediana e o p90 saem os dois como zero, porque o índice que o script usa não tem uma segunda posição para apontar e o awk lê valor não inicializado como zero; a partir de dois commits ele já imprime número real, e deixa de ser um chute grosseiro na casa das dezenas.

Como mandar um patch quando pull request está desabilitado?

A resposta é git format-patch, e ele é mais velho que o pull request. Ele transforma cada commit da sua branch num arquivo que carrega o diff, a mensagem do commit, o autor e a data, que é tudo que um mantenedor precisa para aplicar o seu trabalho com a atribuição intacta. A sequência, testada num repositório descartável antes de publicar:

git switch -c minha-mudanca
# trabalhe, depois faça commit normalmente
git format-patch main

Isso escreve um arquivo por commit, com nome 0001-assunto-do-seu-commit.patch, no diretório atual. Anexe no endereço que o projeto pede, na ordem. Se o projeto usa lista de e-mail, git send-email 0001-*.patch faz o envio sem o seu cliente de e-mail estragar o espaçamento, que é o jeito clássico de um patch chegar inutilizável. Do outro lado, o mantenedor roda git am 0001-assunto-do-seu-commit.patch e os seus commits entram no histórico dele com o seu nome.

Um hábito que vale levar daqui mesmo quando o pull request está aberto: antes de pedir revisão a alguém, rode git diff --stat main...HEAD. Isso imprime o tamanho do favor que você está prestes a pedir. Ver "47 files changed" antes do mantenedor ver é a revisão mais barata que você vai conseguir.

Como manter a mudança de um agente pequena o bastante para alguém revisar?

A expressão para levar do README do celld é low-context change, mudança de baixo contexto, e não mudança grande. Um patch de 900 linhas que faz uma coisa só e se explica é mais fácil de revisar que um de 200 linhas que toca nove arquivos sem relação entre si, e agente de IA de programação é muito bom em produzir o segundo por acidente. Quatro hábitos que mantêm a entrega revisável:

  • Diga o que não tocar. Nomear no prompt os arquivos e diretórios fora do escopo remove a maior parte do volume acidental, porque senão o agente arruma o que encontra pelo caminho.
  • Separe o mecânico do significativo. Renomear ou reformatar vai em patch próprio, para o revisor passar o olho nele e gastar atenção no commit que muda comportamento.
  • Peça uma frente por vez. Tarefa grande gera entrega grande, demorada de conferir e difícil de recusar, o que deixa o revisor escolhendo entre aceitar um bloco que ele não leu e pedir tudo de novo.
  • Escreva a mensagem você mesmo, ou confira linha a linha. A mensagem do commit é o contexto que falta ao mantenedor, e é a parte que o agente tem menos evidência para escrever, porque ele não viu a discussão que motivou o trabalho.

Escrevemos separadamente sobre o outro lado dessa mesa, como revisar código escrito por agentes de IA quando você é quem recebe, e sobre integrar o trabalho de vários agentes dentro do seu próprio repositório. Este artigo é sobre o terceiro caso, o de entregar dentro do repositório de outra pessoa.

Você deve avisar que um agente de IA escreveu o patch?

Onde o projeto declara uma política, a resposta já está decidida para você, e o QEMU é o caso claro: mandar código escrito por agente lá sem dizer significa atestar, sob o Developer's Certificate of Origin, algo que você não tem como atestar. Onde não existe política, avisar continua sendo o erro mais barato. O mantenedor que descobre depois lê aquilo como um contribuidor que desperdiçou o tempo de revisão dele de propósito, e esse julgamento gruda no seu nome, não na ferramenta.

Existe um argumento prático em cima do ético. Dizer ao mantenedor que um agente produziu o patch e que você verificou partes específicas dele mostra onde ele deve olhar, o que torna a revisão mais rápida e o seu patch mais provável de entrar. O aviso que ajuda é específico: o que você testou, o que leu com atenção e onde você está menos seguro.

O que este artigo não resolve

Dois projetos são dois projetos, não uma tendência. Chegamos ao celld e ao QEMU seguindo uma discussão no Hacker News e depois lendo os documentos de cada projeto, o que basta para provar que a prática existe e para mostrar que a mesma porta fechada tem duas causas sem relação entre si, mas não é levantamento, e não temos contagem de quantos repositórios fizeram o mesmo.

Os nossos números carregam uma limitação que vale declarar com precisão. O trailer Claude-Session marca a sessão em que o commit foi feito, não a autoria de cada linha, e uma pessoa pode digitar dentro de uma sessão de agente. Então os 214 commits são saída de sessão de agente, e não prova de que um agente escreveu cada linha deles, e nenhuma medição nossa vai além disso. A contagem de linhas também é um substituto para esforço de revisão, não o esforço em si. Uma mudança de 40 linhas num caminho de pagamento merece mais atenção que uma de 900 linhas num catálogo de tradução, e nenhum percentil sabe disso.