Demissão voluntária na Microsoft: o que o Bun ensina

A Microsoft ofereceu um programa de demissão voluntária para mais ou menos um quarto da empresa. A notícia saiu no Seattle Times. E não foi numa empresa em crise: foi na dona do VS Code, do TypeScript, do GitHub e do npm. Ao mesmo tempo, o Bun, um runtime JavaScript feito por um time que cabe numa sala de reunião, continua lançando versão atrás de versão. Este texto não fala de fofoca corporativa. A pergunta é outra: o que a Microsoft e o Bun, lado a lado, dizem sobre como você deveria trabalhar e escolher ferramentas.

O que a Microsoft anunciou

Demissão voluntária é diferente de demissão em massa. A empresa não manda ninguém embora de cara. Ela coloca um pacote na mesa e deixa a pessoa decidir se aceita. Na prática, o efeito é parecido: menos gente na folha de pagamento, só que com menos manchete negativa.

O tamanho chama atenção. Um quarto de uma empresa com mais de 200 mil funcionários são dezenas de milhares de pessoas recebendo a mesma proposta. Nem todo mundo vai aceitar. Mas ninguém oferece isso para tanta gente se não quer, de fato, encolher.

O motivo de fundo não é segredo para quem acompanha o setor. As big techs estão colocando bilhões em data center e IA. Esse dinheiro sai de algum lugar. E a aposta é que uma equipe menor, com ferramentas melhores, entrega o mesmo ou mais.

Por que o Bun entra nessa conversa

O Bun é a prova viva da tese que a Microsoft está tentando comprar com cortes.

Pensa no que ele entrega:

• runtime JavaScript e TypeScript
• gerenciador de pacotes
• bundler
• test runner
• APIs nativas para SQLite, Postgres, S3 e servidor HTTP

No ecossistema Node, cada item dessa lista é um projeto separado, mantido por gente diferente, com config diferente. No Bun, é um binário só. E quem fez isso nunca foi um time de milhares. Foi um grupo pequeno, liderado pelo Jarred Sumner, que no fim de 2025 acabou comprado pela Anthropic justamente porque esse tipo de alavancagem vale ouro.

Tamanho de time nunca foi métrica de entrega. Alavancagem é.

A Microsoft tem gente para manter dez produtos que fazem a mesma coisa. O Bun não tem. Então ele foi obrigado a ser opinativo, a cortar camada, a escrever em Zig com foco brutal em performance. Restrição virou estratégia.

O que muda no seu projeto na prática

Vamos sair da tese e ir para o código. Um projeto Node típico de 2023 tinha um package.json assim:

{
  "scripts": {
    "dev": "tsx watch src/index.ts",
    "build": "tsup src/index.ts",
    "test": "vitest run"
  },
  "devDependencies": {
    "tsx": "^4.0.0",
    "tsup": "^8.0.0",
    "vitest": "^2.0.0",
    "typescript": "^5.0.0"
  }
}

Quatro dependências só para rodar, empacotar e testar. Cada uma com seus próprios mantenedores, seu próprio ciclo de release e suas próprias issues abertas.

No Bun, o mesmo fluxo fica assim:

{
  "scripts": {
    "dev": "bun --watch src/index.ts",
    "build": "bun build src/index.ts --outdir dist --target bun",
    "test": "bun test"
  }
}

Menos coisa para atualizar. Menos node_modules. Menos superfície para um ataque de supply chain, o que em 2026 já deixou de ser papo de paranoico.

Não estou dizendo para migrar tudo amanhã. Estou dizendo que a pergunta "quantas ferramentas eu preciso para fazer isso?" ficou mais importante do que "qual é a ferramenta mais popular?".

E o risco de depender de time pequeno?

Essa é a objeção honesta, e ela merece resposta.

Projeto pequeno tem bus factor baixo. Se o mantenedor principal some, o projeto pode morrer. Isso é real. Muita gente torceu o nariz para o Bun por esse motivo, e não estava errada.

Só que a notícia da Microsoft mostra o outro lado: empresa grande também não é garantia. Quando uma big tech oferece saída para um quarto da equipe, times inteiros mudam de dono. Produto que tinha cinco pessoas dedicadas passa a ter uma, dividida com outras três prioridades. Você não fica sabendo pelo blog oficial. Você fica sabendo quando a issue que você abriu fica seis meses sem resposta.

Já vi isso acontecer com ferramenta de empresa grande que todo mundo achava eterna. Lembra do Atom? Era do GitHub, que era da Microsoft. Foi arquivado em 2022. O argumento "é de empresa grande, então é seguro" nunca foi tão forte quanto parecia.

O critério que uso hoje é mais simples:

1. O projeto tem licença aberta e código que alguém consegue forkar?
2. Ele segue padrões da web (Fetch, Request, Response, Web Streams) ou inventa API própria?
3. Se ele morrer amanhã, quanto do meu código precisa mudar?

O Bun vai bem no item 2. Boa parte do que você escreve nele roda em Node, Deno ou num Worker com pouca adaptação. Esse é o seguro de verdade. O CNPJ do mantenedor não é.

O recado para quem escreve código

Tem um lado dessa notícia que incomoda, e não adianta fingir que não. Se a Microsoft acha que consegue funcionar com bem menos gente, outras empresas vão copiar. Algumas vão copiar sem ter as ferramentas para isso, e aí o resultado é time sobrecarregado e produto pior. Mas a direção está dada.

O dev que se dá bem nesse cenário é o que gera alavancagem. Não é quem digita mais rápido. É quem:

• elimina ferramenta que não precisa existir
• automatiza o que é repetitivo, com ou sem IA
• entende o sistema inteiro, do banco ao front, em vez de só uma camada
• consegue colocar algo no ar sozinho quando precisa

O Bun é um ótimo exemplo justamente porque ninguém ali tentou ser enorme. Eles tentaram ser eficientes. A diferença parece pequena, mas muda tudo na hora de decidir o que construir.

E vale o lembrete: produtividade não é desculpa para empresa cortar gente e jogar o trabalho de três no colo de um. Uma coisa é ferramenta melhor liberando tempo. Outra é planilha decidindo que agora você faz o trabalho do colega que saiu. A primeira é progresso. A segunda é só corte com nome bonito.

Minha opinião

A Microsoft não está errada em apostar que times menores podem render mais. O Bun prova isso todo dia. O erro seria achar que basta tirar gente e pronto. O Bun não ficou rápido porque tinha pouca gente. Ficou rápido porque essa pouca gente escolheu muito bem o que não fazer.

Para você, o recado prático é parecido. Olhe seu package.json hoje. Conte quantas ferramentas existem ali só porque "sempre foi assim". Provavelmente dá para cortar umas duas. E se quiser ver como eu tenho aplicado essa ideia em projetos reais, dá uma olhada nos meus projetos.

---

Não consegui abrir a matéria do Seattle Times (a permissão do WebFetch foi negada). Então o texto usa só o que diz o título: a oferta para cerca de um quarto da equipe. Não inclui prazos, valores do pacote nem citações. "Mais de 200 mil funcionários", Atom arquivado em 2022 e a compra do Bun pela Anthropic saíram da minha memória. Vale conferir esses dados antes de publicar.

A Microsoft ofereceu demissão voluntária para cerca de um quarto da empresa. E não está em crise.

Enquanto isso, o Bun segue lançando versão atrás de versão com um time que cabe numa sala de reunião.

A lição que eu tiro disso: o que define entrega é alavancagem, e não o tamanho do time.

Ser de empresa grande também não garante nada. O Atom era do GitHub e foi arquivado do mesmo jeito.

Hoje eu me pergunto: quantas ferramentas existem no meu package.json só porque "sempre foi assim"?

Escrevi sobre isso no blog. Se quiser trocar ideia, me chama.

#JavaScript #Bun #DesenvolvimentoDeSoftware #Produtividade #Tecnologia