Quando PRs deixam de ser bem-vindos: a fábrica de software com agentes

Por 18 anos o pull request foi o contrato social do open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →: qualquer pessoa abre um PR, um mantenedor revisa, discute, ensina e faz o merge. Uma reportagem de Richard MacManus no Latent Space documenta uma inversão desse contrato entre projetos AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →-native: Vercel (AI SDK), Astro, Flue e tldraw estão fechando PRs externos por padrão e delegando o trabalho a times de agentes. O motivo declarado é direto: boa parte das contribuições que chegam hoje é gerada por IA sem cuidado, e os mantenedores confiam mais nos próprios agentes calibrados do que em código de terceiros.

Para o dev brasileiro que mantém (ou sonha em manter) um projeto de IA open source, a pergunta não é ideológica. É operacional: como você escala revisão de código quando o volume de contribuições cresce mais rápido do que sua capacidade de ler diff.

O que é uma "software factory"

O termo que aparece na reportagem descreve um pipeline onde um time de agentes, e não um único copilot, cuida do ciclo de vida de uma contribuição. Cada agente tem uma função estreita:

• um agente triage classifica a issue (bug, feature, ruído);
• um agente reproduz o bug num sandbox isolado;
• um agente implementa a correção ou a feature;
• um agente revisa o que foi implementado;
• um humano faz o merge final.

A chave está na especialização. Lars Grammel, engenheiro da Vercel, explica na fonte por que a empresa prefere seus próprios agentes aos da comunidade:

Se temos um agente muito específico com um prompt muito específico que otimizamos, e sabemos que, ao longo do histórico, ele teve muito sucesso em corrigir uma certa categoria de bugs, então desenvolvemos confiança naquela configuração de agente.

Lars Grammel, engenheiro da Vercel

Esse é o argumento técnico central: confiança é uma propriedade de configuração, não de pessoa. Um agente com prompt versionado, histórico mensurável e escopo definido é auditável de um jeito que um PR anônimo de um contribuidor desconhecido nunca será. Grammel descreve a arquitetura do sistema do AI SDK como uma UI custom, um web app, uma API, um espaço de execução e sandboxes, tudo sincronizado com o GitHub, que dispara as ações seguintes automaticamente.

Os números da Vercel

O AI SDK passa de 20 milhões de downloads semanais no npm. No fim de junho, segundo a fonte, o backlog tinha ultrapassado mil issues abertas e quase 800 pull requests. Quatro semanas depois de implantar a fábrica, a Vercel afirma que ela:

Vale a régua de ceticismo: são números reportados pela própria Vercel, sem auditoria externa, e "fechar issue" não é sinônimo de "resolver problema" (fechar por duplicidade ou por ser irreproduzível também conta). Ainda assim, a ordem de grandeza mostra que o gargalo real do open source moderno não é escrever código, é triar e reproduzir o que chega.

A Astro, framework com 62 mil estrelas no GitHub, conta uma história parecida. O criador Fred Schott descreve cinco anos em que "issues chegavam mais rápido do que conseguíamos lidar". Com agentes cuidando de triagem, reprodução e até fazendo o usuário verificar o fix sugerido pelo bot antes de qualquer humano olhar, ele diz ter conseguido, pela primeira vez em mais de uma década de open source, tratar issues como algo priorizável semanalmente em vez de um backlog eterno.

O caso radical: PR vira issue automaticamente

Do sistema de auto-triagem da Astro nasceu o Flue, um framework de agentes do próprio Schott que leva a política ao extremo. No Flue, todo PR externo é fechado automaticamente e convertido: relatório de bug ou proposta de fix vira issue; pedido de feature vira discussão. O guia de contribuição do projeto usa o termo "drive-by AI slop PRs" para o que quer evitar.

A metáfora que Schott usa é interessante para quem pensa produto: tratar contribuições que chegam como leads, não como trabalho que o mantenedor se sente obrigado a revisar. A decisão do que construir a seguir sai da issue ou discussão, combinando a expertise do time com "os melhores LLMs SOTA a que temos acesso". Só depois de decidido é que os agentes entram para pesquisa, design, implementação e revisão inicial.

O tldraw (50 mil estrelas), ferramenta de desenho em React sob licença "source available", adotou o mesmo fechamento automático de PRs. O criador Steve Ruiz classificou a mudança como "uma decisão opinativa em resposta a mudanças em como estamos codando (mais discussão, mais agentes), às práticas sociais em torno de contribuição pública e ao cenário mutável de segurança de código". Mitchell Hashimoto, cofundador da HashiCorp e criador do Ghostty, vai além na fonte e aposta que "o futuro é que grandes projetos open source vão fechar contribuições completamente".

O que quebra: a esteira de novos mantenedores

Aqui está o trade-off que a própria reportagem não esconde. Historicamente, revisar um PR nunca foi só sobre o código. Era como um mantenedor ensinava um contribuidor e o avaliava como futuro mantenedor. Se os agentes fazem a revisão e a implementação, some o mecanismo natural de formação de gente.

O próprio Schott reconhece o risco: "ainda sobra aquele buraco de: bom, se você fica só estreitando o projeto, em algum momento você e eu vamos viajar, e aí o que acontece? Isso não resolve todos os problemas."

A pista de solução que a fonte sugere é que Flue e tldraw fecham PRs mas abrem issues e discussões. A ideia é que a comunidade se conheça e ganhe confiança conversando, e é aí que alguém prova que merece virar mantenedor, em vez de provar via diff. Ruiz resume que é melhor limitar a contribuição da comunidade aos lugares onde ela ainda importa: "relato, discussão, perspectiva e cuidado".

O que isso muda para quem constrói no Brasil

Para o mantenedor brasileiro, o modelo não exige a infra custom da Vercel para começar a valer. O que dá para extrair sem UI própria nem SOTA caro:

• Separe triagem de implementação. O maior ganho reportado (70% a 80% de issues fechadas) veio da triagem, não da escrita de código. Um workflow de GitHub Actions que roda um LLM para classificar e pedir reprodução mínima já ataca o gargalo principal.
• Force a reprodução antes do humano. A prática da Astro de fazer o autor da issue verificar o fix sugerido pelo bot antes de qualquer olhar humano é barata e filtra muito ruído.
• Versione e meça seus prompts de agente. A confiança de que Grammel fala não cai do céu: vem de histórico. Sem medir taxa de sucesso por categoria de bug, você não sabe em qual agente confiar.
• Não copie o fechamento total de PRs cedo demais. Projetos como Flue e tldraw têm base grande e time pago. Um projeto brasileiro pequeno que fecha PRs pode estar apenas espantando os poucos contribuidores que tem, sem ter agentes maduros para compensar. O fechamento faz sentido quando o volume de "slop" já custa mais do que a contribuição humana rende.

O ponto que fica em aberto, e que a fonte deixa honestamente sem resposta, é de sustentabilidade humana: um ecossistema onde código vem de agentes e novos mantenedores não têm mais o PR como porta de entrada precisa inventar outra porta. Discussão e issue são um começo, mas ainda não são um caminho comprovado de formação de gente. Para quem mantém projeto de IA no Brasil, vale acompanhar isso menos como tendência a copiar e mais como experimento em andamento, com números da própria casa antes de fechar qualquer porta.

Fonte: Latent Space