Estou preocupado com o Bun

(wwj.dev)

4 pontos por GN⁺ 7 시간 전 | 3 comentários | Compartilhar no WhatsApp

Bun é um runtime JavaScript rápido e uma ferramenta que facilita o trabalho com TypeScript, mas cresce a preocupação de que ele possa ser afetado por políticas de produto e pela forma de operação após a aquisição pela Anthropic em dezembro de 2025
No anúncio da aquisição, foi dito que o Bun continuaria open source e sob licença MIT, que a mesma equipe seguiria desenvolvendo o projeto e que, como o Claude Code é distribuído como um executável do Bun, a Anthropic teria um incentivo direto para manter o Bun estável
Desde abril de 2026, foram levantados problemas no Claude Code envolvendo queda de qualidade, comportamento restritivo, limitação de harnesses de terceiros, cobrança confusa e comunicação lenta, e o postmortem de engenharia da Anthropic apontou problemas da camada de produto, como redução do esforço de raciocínio padrão e mudanças de prompt, como causa
Segundo reportagens da TechCrunch e da Gigazine, o Claude Code pode exigir custo extra para suporte a harnesses de terceiros como o OpenClaw, ou acionar recusas de solicitação e cobranças extras apenas por haver menção a OpenClaw no histórico do git, revelando um comportamento inesperado
A ansiedade não vem de problemas de qualidade do Bun em si nem da equipe do Bun, mas da possibilidade de as políticas da Anthropic contaminarem o Bun; por isso, alguns projetos estão migrando para pnpm para gerenciamento de pacotes e passaram a recomendá-lo também para novos projetos JavaScript e TypeScript

Contexto do aumento da preocupação com o Bun

Bun é um runtime JavaScript rápido e prático, que torna mais confortável trabalhar com TypeScript em scripts pequenos, apps, testes e ferramentas
Por causa da instalação rápida, testes rápidos, melhor bundling e menor peso na cadeia de ferramentas, ele era visto como uma ferramenta com potencial para se tornar uma alternativa ao Node.js
O centro da preocupação não é a qualidade do Bun em si, mas o fato de que, depois de entrar para a Anthropic, ele pode passar a sofrer influência das políticas de produto e do modo de operação da empresa

A aquisição pela Anthropic e a expectativa inicial

A Anthropic adquiriu o Bun em dezembro de 2025
Segundo o anúncio da aquisição, o Bun continuaria open source e com licença MIT, a mesma equipe seguiria no desenvolvimento, e o roadmap continuaria focado em ferramentas JavaScript de alto desempenho e compatibilidade com Node.js
O anúncio incluía a frase: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
Na época, fazia sentido entender que, como o Claude Code roda sobre o Bun, a Anthropic teria um incentivo direto para mantê-lo rápido e estável
Essa lógica ainda faz sentido, mas começou a surgir a preocupação de que existam rachaduras na forma como a Anthropic opera seus produtos de software

Mudança na avaliação do Claude Code

A principal preocupação não é exatamente a qualidade dos modelos da Anthropic
A família de modelos estimada como Claude Opus 4.6 ainda é avaliada como muito boa para programação, escrita, raciocínio e tarefas gerais de desenvolvimento
O problema está na camada de produto ao redor do modelo, e a avaliação central é que a usabilidade atual do Claude Code piorou bastante
Cerca de um ano atrás, o Claude Code parecia uma ferramenta capaz de ler projetos, fazer alterações focadas, executar comandos, corrigir erros e seguir em frente
Naquele momento, o Claude Code foi uma das primeiras ferramentas de codificação com IA a transmitir a convicção de que o fluxo de trabalho do desenvolvedor poderia migrar de um modelo centrado em autocomplete para um modelo centrado em agentes
Em dezembro de 2025, o Claude Code já estava piorando, mas ainda era utilizável, e a aquisição do Bun também parecia plausível do ponto de vista de que a Anthropic estava construindo o futuro das ferramentas de programação

Problemas do Claude Code desde abril de 2026

Em abril de 2026, desenvolvedores começaram a apontar problemas no Claude Code relacionados à qualidade, comportamento restritivo, limitação de harnesses de terceiros, cobrança confusa e comunicação lenta
A Anthropic publicou um postmortem de engenharia e atribuiu a causa a problemas da camada de produto, como redução do esforço de raciocínio padrão, bugs em sessões antigas e mudanças de prompt que prejudicaram a qualidade de programação
Essa análise posterior foi vista como melhor do que agir como se nada tivesse acontecido e como um raro caso em que a Anthropic reconheceu a própria responsabilidade
Segundo reportagem da TechCrunch, a Anthropic informou aos assinantes do Claude Code que seria necessário pagar a mais para suporte ao OpenClaw e a outros harnesses de terceiros
Segundo reportagem da Gigazine, apenas a presença de OpenClaw no histórico do git já pode fazer o Claude Code recusar solicitações ou disparar cobrança extra
A reportagem cita uma fala de Theo segundo a qual a simples menção ao OpenClaw em um commit recente dentro de um blob JSON já podia acionar esse comportamento ao chamar diretamente claude -p "hi" em um repositório vazio
A cena relacionada também pode ser conferida em um clipe de vídeo
Esse tipo de comportamento faz o produto parecer algo cujas mudanças foram lançadas sem uso interno suficiente em experiências reais no nível do código
Visto de fora, o Claude Code parece estar indo na direção errada, com mais restrições, cobrança estranha e comportamentos inesperados que variam conforme o texto dos commits
Esse movimento é descrito como enshittification

A ansiedade que se estende ao Bun

O Bun está profundamente embutido no Claude Code e, como o Claude Code parece estar piorando, surge o receio de que o Bun possa seguir na mesma direção
Isso não significa que o Bun seja ruim nem que a equipe do Bun tenha perdido o interesse
O problema é que, quanto mais o Bun e sua equipe se integrarem à Anthropic, mais as políticas da Anthropic também podem entrar junto
Se as políticas que aparentemente prejudicaram o Claude Code também afetarem o Bun, podem surgir no Bun problemas que façam parecer que a equipe não usa o próprio produto na prática
Só essa possibilidade já torna difícil ter confiança em continuar usando o Bun em alguns projetos

Migração para pnpm por enquanto

O Bun oferece mais recursos dentro de uma única ferramenta do que o pnpm
O Bun oferece suporte a TypeScript sem etapa de build separada, fornece um bundler no lugar do Vite e oferece funcionalidades de teste no lugar do vitest
O fato de reunir tudo isso em uma única cadeia de ferramentas é, de fato, uma grande vantagem
O pnpm não é substituto do Node.js nem do Bun; ele é apenas um gerenciador de pacotes
Ainda assim, se a parte do Bun que você mais usa no trabalho diário é o gerenciamento de pacotes, tanto o Bun quanto o pnpm oferecem instalação rápida, bom suporte a monorepos e uso razoável de disco
Em parte dos projetos que hoje usam Bun, a escolha está sendo sair do Bun e migrar para o pnpm
No momento, quando perguntam o que recomendar para projetos JavaScript ou TypeScript, a resposta passa a ser pnpm

Isso não é uma recomendação para abandonar o Bun

Embora alguns projetos estejam sendo migrados para fora do Bun, isso não precisa ser tomado como resposta universal
Para projetos novos, o pnpm faz sentido
Em projetos existentes, também é possível optar por manter o Bun até que surja um motivo suficientemente forte para sair

Possibilidades restantes e conclusão

A esperança é que o Bun continue excelente, que a equipe do Bun siga entregando um bom trabalho e que a Anthropic dê autonomia para decisões adequadas ao ecossistema JavaScript
A Anthropic tem dinheiro, capacidade de distribuição e razões concretas para se preocupar com o desempenho e a estabilidade do Bun
O Bun ainda pode sair dessa situação ainda mais forte
Ainda assim, a confiança na situação atual é menor do que era em dezembro de 2025
O Claude Code de antes parecia ser prova de que a Anthropic entendia ferramentas para desenvolvedores, mas agora parece mais um alerta de que talvez ela não saiba o que é necessário para manter e melhorar um produto no longo prazo
O Bun continua excelente, mas é difícil saber para onde ele vai daqui para frente
Como a situação pode mudar completamente em um ano, a intenção é revisitar essa previsão para ver se ela estava correta

3 comentários

click 3 시간 전

Reconheço que até o Node mudou bastante graças ao Bun, mas quando vejo AIs fazendo um baita alarde entre si com PRs no repositório, fico com medo de pisar numa mina de regressão daquelas em que algo que funcionava deixa de funcionar.
Antes da aquisição pela Anthropic, eu usava o Bun como principal, mas agora voltei para o Node.
Ainda acho que o recurso sfx é um killer feature, mas, se você não precisa disso, não vejo muito motivo para usar Bun agora mesmo.

GN⁺ 7 시간 전

Comentários no Hacker News

Não concordo com toda a premissa: mesmo antes da aquisição, o Bun precisaria encontrar uma forma de monetização em algum momento
Só porque a controladora mostra práticas ruins em outro software, o Claude Code, é exagero concluir que isso necessariamente vai tornar o Bun pior. Entendo a preocupação, mas ainda estou otimista com o Bun
O Claude Code é o produto principal da Anthropic e está crescendo de forma extremamente rápida, então até pequenas mudanças podem virar um problema de cobrança. Já o Bun é um runtime JavaScript, então pode se concentrar em ser o melhor runtime possível e, como não afeta diretamente a receita ou o lucro da Anthropic, é menos provável que precise de patches urgentes por abuso como o Claude Code
Ainda é incerto como isso vai evoluir nos próximos anos, mas neste momento, logo após a aquisição, não estou muito preocupado
- É interessante como as pessoas aceitam rápido demais a explicação de abuso. Já faz muito tempo que se sabe que os grandes laboratórios de IA não conseguem lucrar com usuários pesados de assinatura, independentemente de qual agente ou ferramenta de execução eles usem. O preço justo que dá lucro é cobrança por tokens com base no uso
  Esses laboratórios querem matar a concorrência porque ferramentas de execução de terceiros ameaçam transformar os modelos de base em commodity, e ao mesmo tempo estão jogando uma partida de chicken para ver quem consegue aguentar o prejuízo por mais tempo
  No fim, eles vão ter de precificar o produto corretamente, e até lá só podem torcer para já terem eliminado toda a concorrência. Mas parece que já estão perdendo esse jogo. Modelos úteis ficam menores a cada ano e o custo de execução cai, então já passamos do ponto em que o desenvolvimento de ferramentas de execução de terceiros continua existindo mesmo sem uma base de usuários por assinatura
  A aposta central de que “IA útil exige hardware extremamente caro” já fracassou, e a segunda aposta, de prender os usuários no ecossistema para monetizar depois, também vai fracassar. No fim, vão ter de competir apenas pela qualidade real do produto, e isso é bem menos lucrativo
- Acho que a própria ideia de que “mesmo antes da aquisição, o Bun precisaria encontrar uma forma de monetização em algum momento” não faz sentido. Já é estranho que as pessoas tenham passado a depender de um runtime JavaScript que um dia precisaria se monetizar, e é ainda mais esquisito continuar esperançoso depois que ele foi adquirido por uma das empresas mais deficitárias de uma das áreas mais deficitárias da indústria
- Parece que você está subestimando o impacto que as políticas e a cultura de uma empresa têm sobre o produto
  Algumas equipes agora estão apostando tudo em IA e se movendo na linha de “nem vamos mais olhar o código diretamente”. Eu já vi isso na prática e o resultado é o previsível. Até certo ponto funciona, mas, especialmente quando cada equipe tem termos técnicos e entendimentos diferentes, a complexidade vai se acumulando, os erros também, e no fim não sobra nenhuma pessoa ou equipe que realmente saiba como o software funciona
  Também existe uma tendência de deixar a IA controlar o navegador ou outras ferramentas, além de testes unitários e de integração, sem teste ou garantia de qualidade feitos por humanos. A cultura da Anthropic pode mudar a forma de operar e de pensar da equipe do Bun
  Se essa cultura e essa mentalidade virarem padrão, ou os modelos vão melhorar muito, ou a qualidade do software vai cair
  Há uma boa apresentação do Matt Pocock: https://youtu.be/v4F1gFy-hqg
  “Código não é barato. Código ruim está mais caro do que nunca, porque se você tem uma base de código difícil de mudar, não consegue aproveitar a abundância que a IA pode oferecer. Em uma boa base de código, a IA vai muito, muito bem.”
  Quando código ruim começa a se acumular por conta própria, é muito difícil sair disso
- Pela mesma lógica, antes da aquisição o GitHub também precisaria encontrar uma forma de monetização em algum momento. Dizer que, só porque a controladora Microsoft mostrou práticas ruins com Embrace, Extend, Extinguish ou no MS Windows, isso não significa que o GitHub vai piorar, então você entende a preocupação mas continua otimista com o GitHub, não é diferente desse argumento
- A Anthropic comprou o Bun não pelo bem da comunidade JavaScript como um todo, mas para proteger e ampliar seu investimento no Claude Code. Parece óbvio, mas vale registrar. No longo prazo, o resultado vai seguir os incentivos
Não entendo por que as pessoas usam Deno ou Bun em vez de Node. É bom haver concorrentes para o runtime JavaScript, mas não vejo muito bem quais vantagens se ganha ao sair do Node
O Bun não tem REPL e o motor JavaScript é pior, o Deno me parece um Node com sistema de permissões limitado e irritante, e eu tinha visto que nem sqlite tinha. Dizem que ambos têm bom desempenho, mas parece ser só em benchmarks escolhidos a dedo, e nas cargas de trabalho que eu mesmo testei há cerca de um ano, os dois foram mais lentos que o Node
Dito isso, lembro de ter usado Bun ao entregar uma pequena ferramenta de ERP, porque as ferramentas dele para empacotar o projeto em *.exe eram as mais sólidas. O projeto inteiro era em JavaScript sem dependências, então desenvolvemos tudo em Node e só usamos Bun na distribuição, e essa experiência foi claramente melhor que no Node
- O Deno tem sqlite sim: https://docs.deno.com/examples/sqlite/
- A experiência de desenvolvedor no Bun é muito melhor que no Node, especialmente em projetos TypeScript
- O bom do Deno é que o usuário pode simplesmente executar, sem uma etapa de instalação separada
O Bun nunca foi exatamente bem administrado. Havia muitos bugs e lacunas em cada recurso, e a cada release consertavam algumas coisas e quebravam outras
Em uma única patch release recente, colocaram tantas funcionalidades importantes e mudanças incompatíveis quanto a maioria dos softwares passa em duas versões major
Basicamente eu só o uso como executor de scripts e gerenciador de pacotes npm, e mesmo assim a quantidade de trabalho para encontrar uma versão “boa” é surpreendente. Já tive várias patch versions travando do nada durante a instalação, e por causa disso fiquei um bom tempo sem conseguir atualizar
Umas duas versões minor atrás, eles parecem ter quebrado completamente os scripts de postinstall junto com trustedDependencies. Não havia uma palavra sobre isso nas notas de release e ninguém parecia ter reportado no GitHub Issues. Por volta do 1.1, dava para fazer o Bun executar builds de trustedDependency no postinstall, mas depois disso parou de funcionar e está quebrado há meses
- Existe uma issue no GitHub sobre o travamento durante a instalação. O scanner de segurança passa a lista inteira de dependências como argumento de linha de comando e, em monorepos grandes no Linux, isso estoura o ARG_MAX
  O spawn trava em silêncio, sem erro, e como o scanner é separado do postinstall, --ignore-scripts também não ajuda. Está quebrado pelo menos desde a 1.3.5
Trabalho no Bun, e este texto está meio confuso. Tanto eu quanto a equipe do Bun usamos o próprio Bun todos os dias para melhorá-lo, e o ritmo de desenvolvimento na verdade acelerou. A estabilidade do Bun também melhorou bastante desde a entrada na Anthropic
Entre as coisas da próxima versão do Bun estão redução de 17 MB no binário Windows x64 [0], redução de 8 MB no binário Linux [1], a flag de CLI --no-orphans para encerrar recursivamente processos filhos remanescentes [3], cache de contexto SSL para sockets TCP e Unix do cliente, reduzindo bastante o uso de memória em clientes de banco de dados como Mongoose/MongoDB [4], cliente experimental HTTP/3 e HTTP/2 no fetch [5], suporte experimental a HTTP/3 em Bun.serve() [6] e a biblioteca embutida de processamento de imagens Bun.Image [7]
Além disso, também entram melhorias de confiabilidade em node:fs, Worker, BroadcastChannel e MessagePort
Graças à aquisição pela Anthropic, o Bun não precisa mais ser um negócio que gere receita. O Claude Code depende do Bun, e muitos engenheiros de software dependem do Claude Code para trabalhar, então existe um forte incentivo para tornar o Bun melhor
[0]: https://github.com/oven-sh/bun/pull/30219
[1]: https://github.com/oven-sh/bun/pull/30098
[2]: https://github.com/oven-sh/WebKit/pull/211
[3]: https://github.com/oven-sh/bun/pull/29930
[4]: https://github.com/oven-sh/bun/pull/29932
[5]: https://github.com/oven-sh/bun/pull/29863
[6]: https://github.com/oven-sh/bun/pull/30032
- Aquisições nesta indústria normalmente acabam de um jeito meio inevitável. O software adquirido piora quando o time original recebe sua recompensa e vai embora, e a cultura existente é substituída pela cultura do novo dono
  O Bun pode até ser uma exceção, mas não dá para dizer que a preocupação não tem fundamento
  O CEO da Anthropic frequentemente faz previsões exageradas como se a IA fosse quase substituir programadores humanos, e a Anthropic está aplicando essa crença ao Claude Code, transformando-o em um espaguete impossível de manter
- O melhor recurso que o Bun entregou recentemente foi o binário portável. Muita gente usa distribuições Linux antigas, então portabilidade é extremamente importante. Node e Deno exigem Linux mais recente, mais especificamente glibc mais nova
- Dizer “trabalho no Bun” é um eufemismo gigantesco. Tenho preocupações com a Anthropic, mas se o Jarred estiver no comando, não acho que o Bun vá sair dos trilhos. Imagino que ele esteja aproveitando bem a estabilidade e o dinheiro de uma organização maior
Passei algumas horas migrando o backend do site de amolar facas de Bun para Node, e fiquei feliz por evitar o efeito lock-in. No começo eu era bastante entusiasta do Bun, mas fui perdendo a convicção aos poucos
Os recursos de que vou sentir falta são consultas sqlite com tagged template literal, Bun.password.verify usando argon2 por padrão, importação de HTML, transformação de JSX e carregamento automático de arquivos .env
https://burlyburr.com chama https://backend.burlyburr.com
- O Node também suporta consultas sqlite com tagged template literal
  https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
- Acho que bastaria usar uma pequena biblioteca auxiliar para recuperar os recursos de que sente falta. O Node já tem pelo menos SQLite e Argon2 embutidos, então se o problema for a interface, isso é fácil de resolver
- O Node também oferece carregamento automático de .env e sqlite
Eu já não achava que o Bun funcionava tão bem antes da aquisição. Continuei usando para scripts pequenos, mas não teria colocado um serviço em produção com Bun no trabalho
Por causa de problemas de memória e incompatibilidades que não eram corrigidas, eu o via mais como um brinquedo interessante que mostrava bem onde o Node.js ainda pode melhorar
Por exemplo, continuei acompanhando https://github.com/oven-sh/bun/issues/14102, e no fim as bibliotecas passaram a adicionar ramificações do tipo “se for Bun, faça x”, o que é o oposto de compatibilidade
- Tentei usá-lo em produção em alguns projetos, mas nos dois casos tivemos de voltar de Bun para Node. Em um deles havia um grande vazamento de memória, como foi mencionado, e no outro houve erros por diferenças de API em coisas como TextDecoderStream. Decidi não tentar de novo antes do Bun v2
A direção do Claude Code e da Anthropic parece caminhar para esconder coisas do usuário à força. Algumas pessoas devem se lembrar da confusão quando ler xxx.yy passou a contar como ler 1 arquivo ou 2 arquivos
Vieram mais mudanças desse tipo, impossíveis ou muito difíceis de configurar. Entendo a intenção de negócio: fazer você usar o máximo possível de IA, tirar humanos do loop e obter mais dados de treinamento e mais consumo de tokens
Mas, como resultado, acho que o Claude Code ficou muito pior e muito menos confiável. Parece uma tentativa de tirar secretamente o volante da mão do usuário. Seguindo essa lógica, cada vez mais coisas passam a ser justificadas
No momento, o que cresceu muito foi principalmente a desconfiança
Concordo com o post original, e também entendo que para algumas pessoas isso ainda possa soar como reação precoce
Vivemos em um mundo muito diferente de antes, e as pessoas estão mais atentas a preocupações éticas e mais dispostas a resistir para não repetir os erros do passado
Pelos critérios técnicos isso pode ser cedo demais, mas pelos critérios de preocupação ética faz sentido. Má conduta não é tão fácil de reverter quanto antes, e medidas preventivas são necessárias para evitar o grande impacto que esse tipo de decisão produz
- Gostaria de saber em que se baseia a afirmação de que as pessoas estão mais atentas a preocupações éticas do que antes. Não me parece que estejam mais conscientes eticamente. Por exemplo, vejo um pequeno aumento de gente do lado do BDS, mas fora isso não noto muita coisa
- Dadas as reclamações de que Firefox e Safari não adotam as APIs de plataforma do Chrome OS e a realidade de o Chrome estar sendo distribuído por toda parte, não acho que dê para dizer que as pessoas estejam resistindo por considerações éticas
No fim do texto, o autor lista coisas de que gosta no Bun mas que o pnpm não tem. A lista é basicamente suporte nativo a TS, bundler estilo Vite e executor de testes estilo Vitest/Jest
Tirando o bundler, o Node já tem tudo isso. A sintaxe do executor de testes pode ser diferente, mas o TypeScript já “simplesmente funciona” por padrão e o executor de testes embutido é perfeitamente utilizável. Não sei se faz tanto sentido lamentar o Bun desse jeito
- Para ser justo, o Node não tinha essas coisas até ser desafiado por Deno e Bun. Só o Deno, por algum motivo, não conseguiu provocar grandes mudanças, mas a existência do Bun teve impacto real no Comitê Diretivo Técnico do Node
  Também dá para argumentar que o marketing esperto de Jarred Sumner nas redes sociais criou boa parte do impulso atual. Ele fez as pessoas falarem do assunto, e isso também melhorou o Node
  Além disso, como o Bun forçou compatibilidade com o máximo possível da API do Node, o Deno também passou a caminhar para o mesmo nível de compatibilidade, e agora a maior parte do código na prática está menos presa ao runtime. Talvez eu nunca use Bun em produção de verdade, mas só o fato de ele ter existido já melhorou bastante o ecossistema JavaScript, então fico feliz por isso
- Quando o Node adicionou TypeScript nativo? Dá para executar node main.ts diretamente, sem dependências?
- Considerando até a reescrita do compilador TypeScript, a relevância do Bun diminui ainda mais
Sinceramente, nunca usei muito o Bun além de testar módulos de vez em quando. No dia a dia uso principalmente Deno, e nos últimos anos também escrevi muitos scripts de shell em Deno
Gostei bastante da usabilidade recente, e a forma de referenciar módulos diretamente de repositórios é especialmente boa para scripts de shell
Ainda assim, preocupa se eles conseguirão monetizar o suficiente mantendo os recursos abertos, ou pelo menos permitir que outras pessoas os reproduzam. Então entendo parte da preocupação

jjpark78 3 시간 전

https://github.com/oven-sh/bun/issues/17723

Se corrigissem só isso, acho que eu até testaria no backend...