Bun e LLMs: por que a percepção de IA está tão dividida

Na mesma semana, dois devs que eu respeito me disseram coisas opostas. O primeiro contou que um agente escreveu uma feature inteira dele em Bun, com testes, e ele só revisou. O segundo jurou que IA "não serve nem pra CRUD", porque o modelo inventou um import que não existe. Os dois estavam falando a verdade. E é exatamente disso que o Andrej Karpathy reclamou num post recente no X: a distância entre o que as pessoas acham que os LLMs conseguem fazer está aumentando, e não diminuindo.

Esse texto é sobre essa distância, usando o Bun como termômetro. Faz sentido: é um runtime que muda rápido, que hoje pertence à Anthropic e que roda por baixo de uma das ferramentas de IA para código mais usadas.

O que o Karpathy está apontando

A ideia central é simples. Antes, quase todo mundo usava a mesma coisa: um chat, um modelo, um prompt. As opiniões variavam, mas a experiência de base era parecida.

Hoje não é mais assim. Tem gente usando modelo gratuito numa aba do navegador, colando trecho de código e copiando a resposta de volta. E tem gente rodando agente no terminal, com acesso ao repositório, rodando testes, lendo erro e corrigindo sozinho por meia hora. São produtos diferentes que levam o mesmo nome: "IA".

Quando essas duas pessoas discutem, cada uma descreve uma ferramenta diferente. Discussão de IA no grupo da firma virou debate de futebol: cada um assistiu a um jogo diferente e todo mundo tem certeza do placar.

Quem testou IA uma vez em 2024 está brigando com um produto que já não existe.

Por que a percepção sobre LLMs só se afasta

Não acho que seja uma questão de alguém ser burro ou deslumbrado. A distância cresce por motivos bem concretos:

• O modelo importa muito. A diferença entre o modelo de entrada e o de ponta, em tarefa de código com vários arquivos, é enorme. Quem só usou o gratuito tem uma amostra que não representa o resto.
• O ambiente importa mais ainda. Um modelo bom num chat sem contexto erra import. O mesmo modelo dentro de um agente que lê o package.json e roda bun test corrige o import sozinho na segunda tentativa.
• A opinião envelhece rápido. Muita gente formou opinião há um ano e meio e nunca mais testou. Nesse meio tempo, o produto mudou umas quatro vezes.
• O tipo de tarefa muda tudo. Gerar um endpoint é uma coisa. Debugar uma condição de corrida num worker é outra. Os dois lados generalizam a partir do próprio caso.

O resultado é que a conversa pública fica inútil. O hype diz que dev vai acabar ano que vem. O cético diz que é autocomplete metido. Nenhum dos dois te ajuda a decidir se vale usar isso amanhã às 9h no seu projeto.

Bun é um bom termômetro para isso

O Bun é um caso interessante por três motivos.

Primeiro, ele muda rápido. APIs como Bun.serve com routes, o bun:sqlite, o Bun.password e o cliente nativo de S3 e Postgres foram chegando ao longo das versões. Um modelo com conhecimento desatualizado, ou sem acesso à documentação, vai te sugerir Express com better-sqlite3. Funciona, mas joga fora o motivo de você ter escolhido Bun.

Segundo, a Anthropic comprou o Bun no fim de 2025, e o Claude Code é distribuído como executável Bun. Ou seja, o runtime virou peça de infraestrutura de ferramenta de IA. Isso não quer dizer que os modelos conhecem o Bun melhor por mágica. Quer dizer que tem gente com muito incentivo para o Bun funcionar bem dentro de fluxos de agente.

Terceiro, o Bun tem um loop de feedback muito curto. bun test sobe em milissegundos, sem configurar Jest, sem transpilar TypeScript à parte. Para um agente que precisa rodar teste, ler a falha e tentar de novo vinte vezes, isso faz uma diferença real no tempo total.

Veja a diferença na prática. Pedi a mesma coisa em dois cenários: "endpoint que busca usuário por id no SQLite". No chat sem contexto, veio Express, better-sqlite3 e um app.listen. No agente com acesso ao repositório, que já usava Bun, veio isso:

import { Database } from "bun:sqlite";

const db = new Database("app.db");
const findUser = db.query("SELECT id, name FROM users WHERE id = ?");

Bun.serve({
  routes: {
    "/api/users/:id": (req) => {
      const user = findUser.get(req.params.id);
      return user
        ? Response.json(user)
        : new Response("Not found", { status: 404 });
    },
  },
});

Zero dependência nova. Query preparada uma vez só. Esse é o tipo de diferença que faz um dev achar que IA é inútil e o outro achar que ela é ótima. O modelo pode até ter sido o mesmo. O contexto foi diferente.

Como medir a capacidade do LLM no seu próprio código

A saída para não cair em nenhum dos dois extremos é parar de opinar e começar a medir. E dá para fazer isso com o que você já tem.

Monte um eval caseiro. Não precisa de framework. Pegue de 5 a 10 tarefas reais que você já resolveu no seu repositório: um bug que te custou uma tarde, um endpoint novo, uma migração de schema. Para cada uma, escreva o teste que prova que está resolvido.

// evals/user-endpoint.test.ts
import { test, expect } from "bun:test";

test("retorna 404 para usuário inexistente", async () => {
  const res = await fetch("http://localhost:3000/api/users/999999");
  expect(res.status).toBe(404);
});

test("retorna o usuário com id e name", async () => {
  const res = await fetch("http://localhost:3000/api/users/1");
  const body = await res.json();
  expect(body).toMatchObject({ id: 1, name: expect.any(String) });
});

Depois, para cada tarefa, crie uma branch limpa, entregue a descrição ao modelo ou agente que você quer avaliar e rode:

bun test evals/

Anote três coisas: passou ou não, quantas intervenções suas foram necessárias e quanto tempo levou. Repita a cada troca de modelo ou de ferramenta. Em uma tarde você tem um dado que vale mais do que cem threads no X.

Duas dicas que aprendi errando:

1. Use tarefas que você já resolveu. Assim você sabe o que é uma boa solução e não se impressiona com código que só parece certo.
2. Inclua pelo menos uma tarefa difícil de verdade. Se todas forem CRUD, você vai concluir que a IA resolve tudo. Não resolve.

O que muda no seu fluxo de trabalho

Se a distância de percepção é real, a consequência prática é que você não pode terceirizar sua opinião sobre IA. Nem para o influenciador empolgado, nem para o colega cético. Os dois estão descrevendo a ferramenta deles, não a sua.

No dia a dia, isso vira algumas mudanças pequenas:

• Escreva código que se verifica. Teste bom virou insumo para o agente, e não só segurança para você. Com Bun, o custo de rodar teste é tão baixo que não tem desculpa.
• Dê contexto em vez de prompt esperto. Um CLAUDE.md ou AGENTS.md dizendo "este projeto usa Bun, bun:sqlite e Bun.serve, não instale Express" resolve metade dos erros bobos.
• Reavalie a cada poucos meses. Coloca no calendário. Sério. Sua opinião de março pode estar errada em outubro.
• Nas discussões do time, pergunte "qual ferramenta e qual tarefa?" antes de pensar em concordar ou discordar. Isso encerra muita briga inútil.

E uma coisa que não muda: revisão. O agente escreveu, você assina. Se o código for para produção com SQL concatenado porque "a IA fez", a culpa continua sendo sua no post-mortem.

Minha opinião

Acho que o Karpathy tem razão, e acho que a distância vai continuar crescendo por um tempo. As ferramentas de ponta melhoram mais rápido do que a percepção média consegue acompanhar. Quem usa o melhor setup todo dia vai ficando cada vez mais longe de quem testou uma vez e desistiu.

Mas a solução é chata e está ao alcance de qualquer um: medir no próprio código, com os próprios testes. O Bun facilita isso porque o loop é rápido e o ferramental já vem pronto. Você não precisa acreditar em mim nem em ninguém. Roda o bun test e olha o resultado.

É assim que eu venho testando IA nos meus projetos com Bun e React Native. Se quiser ver onde isso já está rodando de verdade, dá uma olhada nos meus projetos.

Na mesma semana, um dev me disse que a IA escreveu uma feature inteira em Bun e outro jurou que ela não serve nem pra CRUD.

Os dois estavam certos. Só estavam usando ferramentas completamente diferentes com o mesmo nome: "IA".

O Karpathy apontou isso: a distância entre o que as pessoas acham que os LLMs conseguem fazer só aumenta. Chat sem contexto erra import. Agente com acesso ao repo lê o erro e corrige sozinho.

Minha saída foi parar de opinar e começar a medir. Pego 5 a 10 tarefas reais que já resolvi, escrevo os testes e rodo `bun test` a cada troca de modelo.

Uma tarde de eval caseiro vale mais que cem threads no X. E a revisão continua sendo minha: o agente escreve, eu assino.

Escrevi o passo a passo completo no blog. Você já mediu a IA no seu próprio código?

#Bun #InteligenciaArtificial #LLM #DesenvolvimentoDeSoftware #TypeScript