O Bun Já É Escrito Quase Todo por IA e a Pergunta de Governança do Mantenedor Ficou Real
Mais de 80% dos commits do Bun hoje são escritos por IA. Jarred Sumner, criador do projeto, disse sem rodeios: “Não escrevemos código com as próprias mãos há muitos meses.” Estamos falando do runtime JavaScript que vive dentro de cerca de 7,3 milhões de instalações npm por mês, e as pessoas que escrevem seu código se afastaram em boa parte do teclado.
Esse número vem do analista Stephen O’Grady, da RedMonk, que publicou uma análise sobre o Bun em junho de 2026. Os dados aqui são a leitura dele dos dados públicos do repositório mais as declarações do próprio Sumner, não números oficiais da Anthropic. Lido com essa ressalva, o quadro continua chamando atenção.
Os Números
A Anthropic adquiriu a Oven, empresa por trás do Bun, em dezembro de 2025. Em cerca de 30 meses, os downloads npm do Bun saltaram de aproximadamente 445 mil por mês para 7,3 milhões. Perto de um aumento de 16X. A distribuição explodiu.
A autoria mudou no mesmo período. Em agosto de 2025, mais da metade dos commits do Bun já era gerada por bots. Depois da aquisição, esse número passou de 80%. A frase de Sumner sobre não digitar código descreve com precisão como o projeto funciona agora.
O terceiro número é o que a maioria ignora. Os contribuidores humanos do Bun caíram cerca de metade. As contribuições externas despencaram de forma significativa, mesmo com o Bun mantendo uma licença MIT que convida juridicamente qualquer pessoa a participar. A licença continuou aberta. A participação, não.
Falha Um: Quem Governa a Correção
Quando a IA escreve a infraestrutura e os revisores humanos rareiam, a correção deixa de ser problema de programação e passa a ser problema de governança.
Um runtime é software de base. Bugs nele se propagam para toda aplicação que depende dele. A defesa tradicional eram vários mantenedores lendo o trabalho uns dos outros, discutindo casos extremos e pegando os erros sutis que compilam limpos mas se comportam errado sob carga. Essa defesa enfraquece quando quem faz a leitura é em menor número e o volume de mudança gerada por máquina é maior.
A preocupação não é a IA escrever código ruim. Ela costuma escrever código competente. A preocupação é a camada de revisão. Um pull request gerado em segundos ainda precisa de um humano que entenda as implicações de segurança, os tradeoffs de desempenho e o custo de manutenção de longo prazo. Quando esse grupo humano encolhe enquanto a produção acelera, a razão entre escrutínio e mudança colapsa. Cada linha recebe menos atenção justamente quando mais linhas estão chegando.
Continuidade é a versão mais difícil do mesmo problema. O open source sempre dependeu de pessoas que se importam o bastante para continuar aparecendo. Se o trabalho diário do projeto passa pela IA de um fornecedor e pelo roadmap de um fornecedor, o bus factor deixa de ser sobre indivíduos e vira sobre as prioridades de uma única empresa. Quem revisa no ano que vem? Quem dá continuidade se o fornecedor repriorizar? Não são perguntas hipotéticas para uma dependência da qual 7,3 milhões de instalações mensais dependem.
Falha Dois: Concentração Inibe a Participação
A licença MIT diz que qualquer um pode contribuir. Os dados dizem que menos gente contribui.
Esse é o problema da concentração, e é fácil confundi-lo com uma história de qualidade quando na verdade é estrutural. Quando um único fornecedor mais sua IA detêm o desenvolvimento de um projeto, o sinal para contribuidores de fora muda. Por que investir noites revisando e enviando patches para um codebase onde o mantenedor afirmou que o código é majoritariamente escrito por máquina e a direção é definida dentro de uma empresa? O incentivo para participar se desfaz mesmo com a porta jurídica aberta.
O’Grady traça um contraste útil com o próprio Model Context Protocol da Anthropic. O MCP levou mais de dez meses para chegar a uma fundação neutra em que múltiplos fornecedores pudessem confiar e construir. Esse atraso não foi acidente de burocracia. A concentração de fornecedor desacelera a colaboração entre múltiplos fornecedores porque os outros participantes esperam para ver se a governança será genuinamente compartilhada antes de comprometer recursos. O Bun mostra a mesma dinâmica pelo lado do mantenedor. Controle de fornecedor único, mesmo sob licença permissiva, suprime a participação ampla da qual o open source depende.
O resultado é um projeto que parece mais saudável do que nunca pela métrica de downloads e mais magro do que nunca pela métrica de contribuidores. Distribuição e participação caminharam em direções opostas.
O Espelho do Lado do Mantenedor
O risco de cadeia de suprimentos costuma ser enquadrado como injeção: um ator malicioso enfia código ruim numa dependência em que você confia. O Bun aponta para outro modo de falha na mesma superfície.
Aqui a governança não é atacada. Ela evapora. A automação elimina a necessidade de muitas mãos, e a concentração elimina o incentivo para as mãos de fora aparecerem. Nenhum vilão é necessário. A combinação de autoria por IA e propriedade de fornecedor único esvazia em silêncio a revisão, a continuidade e a participação que tornavam a dependência confiável em primeiro lugar. A licença ainda diz “aberto.” A realidade de governança diz “concentrado e automatizado.”
Para quem roda o Bun em produção, ou qualquer dependência mantida por IA, as perguntas agora são operacionais. Quantos humanos independentes revisam mudanças neste pacote? O que acontece com ele se o fornecedor patrocinador mudar de foco? A base de contribuidores é ampla o suficiente para sobreviver à decisão de uma única empresa de despriorizar? São perguntas respondíveis, e pertencem à sua avaliação de risco de dependências ao lado dos scans de CVE.
Faça Isso Agora
Audite suas dependências críticas por concentração de mantenedor, e vá além do tipo de licença. Uma licença permissiva diz o que você tem permissão de fazer. Não diz nada sobre quem de fato revisa, governa e dá continuidade ao código. Para qualquer dependência onde a autoria por IA é alta e a contribuição humana está concentrada em um fornecedor, documente o risco de continuidade de forma explícita e decida se você precisa de um plano B. A contagem de downloads mede popularidade, e popularidade nada garante sobre quem sustenta o código. O Bun mostra que as duas curvas podem subir e descer em direções opostas.
Fontes
- RedMonk. “What Bun can tell us about AI, open source, and Anthropic.” Junho de 2026.
A Victorino ajuda times a governar código mantido por IA e o risco de dependências: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa