Simon Willison classificou 244 ferramentas feitas com vibe coding usando tree-sitter

Quando a IA escreve código em poucos minutos, o principal problema muda rapidamente. Em vez de «como fazer isso», surge a pergunta «onde já tenho algo parecido». Simon Willison se deparou com isso na própria coleção: em tools.simonwillison.net já há 244 pequenas ferramentas, quase todas escritas com ajuda de modelos. Uma lista simples com tantos itens deixou de funcionar.

O que ele fez

Willison decidiu não classificar as ferramentas manualmente. Ele tinha créditos do modelo Fable 5.2 até a renovação semanal dos limites e entregou a tarefa inteira a ele. O modelo usou o tree-sitter, um parser que constrói a árvore sintática do código, e analisou o JavaScript de cada ferramenta. Do código extraiu três coisas: quais APIs do navegador são usadas, quais bibliotecas são carregadas de CDNs e a quais hosts de APIs web a ferramenta recorre.

O resultado aparece na página inicial como nuvens de tags, em que o tamanho de cada tag depende do número de ferramentas. Ao clicar em uma tag, vê-se a lista de todas as ferramentas que a usam.

O que os números mostram

As estatísticas são curiosas por si só. ES modules são usados por 92 ferramentas, Clipboard API por 69, Canvas 2D por 44, Blob URLs por 38 e Drag and drop por 30. A câmera ou o microfone são usados por 9 ferramentas, e a IA integrada ao navegador (Built-in AI) aparece, por enquanto, exatamente uma vez.

Entre as bibliotecas, estão à frente Marked (12), Pyodide (11) e DOMPurify (7). Depois vêm Leaflet, markdown-it e jSquash para WebP, com 4 cada. Só entram na nuvem bibliotecas adotadas por pelo menos duas ferramentas, de modo que o ruído isolado é filtrado.

Uma interpretação cautelosa: os números altos de Clipboard API e Blob URLs provavelmente indicam o cenário típico de «colar dados, obter um resultado, copiar ou baixar». Essa é uma conclusão nossa a partir dos números; o autor não afirma isso.

Para que isso serve na prática

A ideia principal não é a nuvem de tags em si, mas a maneira de obtê-la. Se você acumulou muito código gerado — utilitários internos, protótipos, scripts —, pode construir a navegação a partir do próprio código. Descrições escritas à mão ficam desatualizadas e são esquecidas, enquanto a análise da árvore sintática sempre corresponde ao que realmente está no arquivo.

O que você pode repetir por conta própria:

• peça a um agente que escreva um script com tree-sitter que procure chamadas às APIs desejadas e imports;
• salve o resultado em um JSON simples e gere uma página a partir dele;
• defina um limite, como «no mínimo duas ferramentas», para que a nuvem não vire um depósito;
• execute novamente a classificação a cada nova ferramenta adicionada.

Um benefício adicional é que essa classificação responde a perguntas de auditoria. Por exemplo, quais das suas ferramentas puxam scripts de terceiros de CDNs, quais acessam hosts externos e quais trabalham com a câmera. Para uma equipe pequena que acumulou rapidamente aplicativos internos, é uma forma barata de enxergar a superfície de risco.

Limitações

Esta é uma nota curta sobre um projeto pessoal, não uma pesquisa. A coleção pertence a um único autor e não precisa refletir como é o código típico escrito por IA. A análise estática não pega tudo: APIs acessadas de forma dinâmica ou bibliotecas carregadas por um caminho fora do padrão podem passar despercebidas. A nota não traz dados sobre a precisão da classificação nem sobre se o autor a verificou manualmente. A captura de tela mostra as nuvens de bibliotecas e APIs do navegador; a terceira categoria, hosts de APIs web, não aparece nela.

Ainda assim, como técnica de trabalho ela é útil. Quando o código é escrito mais rápido do que se consegue lembrar dele, a classificação baseada no conteúdo real se torna uma parte tão obrigatória do processo quanto os testes. E a tarefa «analise meus arquivos e monte um catálogo» é justamente do tipo que um agente resolve em uma noite com o que sobrou do limite semanal.