Se você é desenvolvedor JavaScript e adotou o Bun nos últimos dois anos, provavelmente sentiu aquela empolgação rara — um runtime que finalmente entregava velocidade absurda, TypeScript nativo e um toolkit unificado que eliminava metade das dependências do seu projeto. Aí veio dezembro de 2025, e a Anthropic comprou o Bun. A promessa? “Nada muda, continua open source, MIT license, time intacto.” Quem já viu esse filme antes sabe como ele costuma terminar.

O Bun em 2026: Por Que Devs Se Apaixonaram

Antes de falar de aquisição, vale lembrar por que o Bun gerou tanto hype. Com mais de 82.000 estrelas no GitHub e 7 milhões de downloads mensais, o runtime criado por Jarred Sumner conquistou empresas como Midjourney e Lovable com argumentos difíceis de ignorar:

Esses números impressionam, mas o verdadeiro diferencial sempre foi a proposta “all-in-one”: runtime, bundler, test runner e package manager num único binário. Com o Bun 1.2 vieram o Bun.SQL (Postgres nativo), um client S3 embutido e lockfile em texto. O 1.3 trouxe MySQL, Redis nativo e um dev server com hot reload zero-config.

Para quem passava horas configurando Vite + Vitest + pnpm + tsx, o Bun era um alívio:

# Antes: 4 ferramentas, 4 configs, 4 atualizações
npm install -g pnpm
pnpm add -D vite vitest tsx typescript
# + vite.config.ts, vitest.config.ts, tsconfig.json...

# Depois: Bun
curl -fsSL https://bun.sh/install | bash
bun init
bun test
bun build ./src/index.ts --outdir ./dist

Um binário. Zero config. E rodando TypeScript nativamente — enums, decorators, namespaces, tudo sem transpilação prévia. Bun também passa mais de 90% da test suite do Node.js, o que significa que a maioria dos pacotes npm funciona sem modificação.

A Aquisição: O Que a Anthropic Quer com o Bun

Em dezembro de 2025, a Anthropic fez sua primeira aquisição de sempre: o Bun. O momento não foi coincidência — no mesmo comunicado, a empresa anunciou que o Claude Code atingiu US$ 1 bilhão em receita anualizada em apenas 6 meses. Clientes como Netflix, Spotify e Salesforce já usavam a ferramenta.

O Claude Code roda como um executável Bun. Literalmente — você baixa um arquivo e ele funciona. Essa é a razão estratégica: se o Bun quebra, o Claude Code quebra. A Anthropic tem incentivo direto em manter o runtime saudável.

A promessa oficial, repetida pelo time do Bun no blog de anúncio:

• Bun continua open source e MIT-licensed
• O time permanece focado no runtime
• A missão agora inclui “fazer do Bun o melhor lugar para construir, rodar e testar software movido a IA”

Tudo bonito no papel. Mas um post que viralizou no Hacker News na primeira semana de maio de 2026 levantou uma pergunta incômoda: e se a realidade for diferente da promessa?

“Eu Estou Preocupado com o Bun”

O artigo do desenvolvedor wwj atingiu 210 pontos no Hacker News e gerou mais de 100 comentários. O argumento central é simples: olhe o que aconteceu com o Claude Code depois que a Anthropic assumiu o controle total, e imagine o mesmo happening com o Bun.

O autor lista problemas concretos que surgiram no Claude Code durante abril de 2026:

• Redução do “reasoning effort” padrão — reconhecida pela própria Anthropic num postmortem de engenharia
• Bugs de sessão que faziam o agente perder contexto
• Mudanças de prompt que degradaram a qualidade de código
• Restrições de billing para harnesses de terceiros, com cobranças inesperadas
• Comportamento bizarro: ter certos termos no histórico do git podia fazer o Claude Code recusar requests — mesmo em repositórios vazios

Eu vi isso de perto. A comunidade de devs no X e no HN estava em chamas em abril. O postmortem da Anthropic, publicado em 23 de abril, foi a primeira vez que a empresa admitiu culpa publicamente. Como o autor do post colocou: “honestamente, foi possivelmente a primeira vez que a Anthropic mencionou que algo era culpa deles.”

A conclusão do dev? Se a Anthropic não conseguiu manter a qualidade do Claude Code — um produto que gera US$ 1 bilhão por ano — o que garante que o Bun não vai sofrer o mesmo destino?

O Fantasma da Enshittification

O termo “enshittification”, cunhado por Cory Doctorow, descreve um padrão que se repete com frequência perturbadora no mundo tech:

1. A plataforma é boa para os usuários (atrai adoção)
2. A empresa muda para ser boa para clientes empresariais (monetização)
3. A empresa extrai todo o valor para si mesma (enshittification completa)

O dev que escreveu o post sobre o Bun usou exatamente essa palavra. E ele tem precedentes de sobra.

Heroku: O Caso Mais Doloroso

A Salesforce comprou o Heroku em 2010, e por uns anos tudo parecia bem. Depois veio a estagnação. O Heroku congelou — literalmente. Nenhum produto novo significativo entre 2017 e 2024. Os preços subiram entre 300% e 400%. Para criar uma conta, você precisava de cartão de crédito antes mesmo de ver o dashboard. Nove telas de onboarding sem poder fazer nada.

O resultado? Uma geração inteira de devs migrou para Railway, Render e Fly.io. O Heroku virou sinônimo de “plataforma que a big tech matou”. Um estudo de 12 postmortems sobre o Heroku concluiu que o problema não foi técnico — foi cultural. A Salesforce simplesmente não entendia (nem se importava com) o público original.

GitHub: Erosão Lenta

A Microsoft comprou o GitHub em 2018 por US$ 7,5 bilhões. Diferente do Heroku, o GitHub não morreu — mas mudou. O Copilot se tornou o centro de tudo, com ads aparecendo em PRs (sim, isso aconteceu). A confiabilidade caiu, com outages cada vez mais frequentes. Tanto que Mitchell Hashimoto, criador do Terraform, abandonou o GitHub após 18 anos culpando os outages diários.

Nenhuma empresa sai comprando dev tools com a intenção de destruí-las. Mas o padrão se repete porque os incentivos mudam. Quando o Heroku era independente, o incentivo era agradar devs. Quando virou Salesforce, o incentivo era agradar enterprises.

O Que Pode Dar Errado com o Bun

Vamos ser honestos: o cenário não é necessariamente apocalíptico. A Anthropic precisa do Bun funcionando bem — o Claude Code depende disso. Mas “funcionando bem para o Claude Code” e “funcionando bem para a comunidade” nem sempre são a mesma coisa.

Riscos reais:

1. Prioridade Desalinhada

O Bun pode evoluir para otimizar cenários de uso do Claude Code (execução de agentes, sandboxing, integração com SDK) enquanto features que a comunidade quer (melhor compatibilidade com Node.js, performance de banco de dados, APIs web) ficam para trás.

2. Dependência de Uma Empresa

Antes, o Bun dependia de Jarred Sumner e uma equipe pequena mas apaixonada. Agora depende das prioridades estratégicas de uma empresa avaliada em dezenas de bilhões de dólares. Se o Claude Code pivotar para outra tecnologia (improvável, mas possível), o investimento no Bun pode secar da noite pro dia.

3. O Precedente do Claude Code

Abril de 2026 mostrou que a Anthropic é capaz de degradar a experiência de um produto de US$ 1 bilhão em receita. Se isso acontece com o carro-chefe, pode acontecer com qualquer coisa.

4. Integração Forçada

O que acontece quando a Anthropic começa a adicionar features exclusivas para Claude Code no Bun? Hooks internos, APIs privilegiadas, otimizações que só funcionam no contexto de agentes de IA? O Bun pode continuar open source na teoria, mas se tornar efetivamente um runtime otimizado para um caso de uso específico.

O Contra-argumento: Por Que Talvez Esteja Tudo Bem

Seria desonesto não apresentar o outro lado. Existem razões sólidas para acreditar que o Bun vai ficar bem:

Incentivo financeiro direto. O Claude Code é a galinha dos ovos de ouro da Anthropic. Ele roda em Bun. Se o Bun degradar, o Claude Code degrada. Nenhuma empresa sabota sua própria infraestrutura de propósito.

Mais recursos do que nunca. O Bun como startup independente tinha recursos limitados. Dentro da Anthropic, tem acesso a uma equipe de engenharia de classe mundial e investimento que Jarred Sumner nunca teria conseguido sozinho. O Bun 1.3 foi a prova — Windows ARM64, MySQL, Redis nativo, dev server. Tudo isso saiu depois da aquisição.

MIT license é real. Se a Anthropic fizer besteira, qualquer pessoa pode forkar o Bun. O código está lá, aberto. Isso é um seguro que o Heroku nunca teve. Na prática, forkar um projeto desse tamanho não é trivial — precisa de mantenedores dedicados e infraestrutura de build — mas a possibilidade jurídica existe e serve como pressão.

A comunidade está vigiando. O post que viralizou no HN é prova de que qualquer movimento errado será notado e amplificado. A pressão pública funciona — foi exatamente isso que forçou o postmortem de abril.

Alternativas: O Plano B dos Cautelosos

O autor do post original já migrou para o pnpm como package manager, embora reconheça que o pnpm não substitui o bundler, o test runner e o suporte nativo a TypeScript do Bun.

Se você quer reduzir a dependência do Bun sem abandonar tudo, aqui está um plano pragmático:

# Package management → pnpm
npm install -g pnpm
pnpm init

# Bundler → Vite (ou Rolldown quando estiver estável)
pnpm add -D vite

# Test runner → Vitest
pnpm add -D vitest

# TypeScript → tsx para execução direta
pnpm add -D tsx

A desvantagem? Você volta a gerenciar 4 ferramentas ao invés de 1. A vantagem? Nenhuma delas depende de uma única empresa.

Outro ponto que vale considerar: o Rolldown, bundler escrito em Rust pelo time do Vite, está chegando perto de uma release estável. Se ele entregar a performance prometida, a combinação pnpm + Vite/Rolldown + Vitest + tsx pode ser tão rápida quanto o Bun — sem a dependência corporativa.

Para quem quer ficar no ecossistema de runtimes alternativos, o Deno é a opção mais madura. Com 85.000 req/s em HTTP nativo e um modelo de segurança baseado em permissões, ele cobre boa parte do que o Bun oferece — com a diferença de ser mantido pela Deno Company, uma organização independente.

Minha Leitura: 12 Meses de Observação

Eu não acho que o Bun vai morrer. A Anthropic precisa dele funcionando, e os incentivos financeiros estão alinhados — por enquanto. Mas “por enquanto” é a parte que me incomoda.

O que eu recomendo é o mesmo que o autor do post original sugeriu: observe os próximos 12 meses. Preste atenção em sinais específicos:

• Frequência de releases — se o ritmo de atualizações cair, preocupe-se
• Node.js compatibility — se o Bun parar de se preocupar com compatibilidade, é sinal de que o foco virou exclusivamente Claude Code
• Issues abertas — se o tempo de resposta para bugs da comunidade aumentar, o time provavelmente está focado em demandas internas
• APIs exclusivas — se features aparecerem que só fazem sentido para agentes de IA, o desalinhamento começou

A real é que toda ferramenta que você adota carrega risco. O Node.js depende do OpenJS Foundation. O Deno depende da Deno Company. O Bun agora depende da Anthropic. A diferença é que a Anthropic tem mais capital — e mais motivos para mudar de direção — do que uma fundação ou uma startup focada.

Se em maio de 2027 o Bun continuar entregando releases consistentes, mantendo compatibilidade e respondendo à comunidade, essa preocupação toda vai ter sido paranoia saudável. Se não… bem, pelo menos você já sabe onde fica o pnpm init.

Fonte de inspiração: I am worried about Bun por wwj, publicado em 2 de maio de 2026.