- Resultado de uma pesquisa que analisou as tendências de escolha de ferramentas do Claude Code em 2.430 repositórios open source reais
- Em 12 das 20 categorias no total, ele optou por implementação própria (Custom/DIY) em vez de ferramentas prontas, e esse foi o tipo de escolha mais frequente
- Por outro lado, ao escolher ferramentas, mostrou alta concentração em itens específicos, como GitHub Actions (94%), Stripe (91%) e shadcn/ui (90%)
- Os ambientes de deploy são fixos por linguagem: para JS, a escolha padrão é Vercel; para Python, Railway, enquanto AWS·GCP·Azure ficam fora da primeira escolha
- Quanto mais recente o modelo, mais clara é a tendência de substituição por ferramentas emergentes, como Drizzle e FastAPI BackgroundTasks, com consistência de escolha dentro do ecossistema em torno de 90%
Visão geral da pesquisa
- Usando o Claude Code v2.1.39, foram realizados 2.430 experimentos no total, observando a escolha de ferramentas em repositórios reais por meio de perguntas abertas
- 3 modelos (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 tipos de projeto, 20 categorias de ferramentas
- Taxa de extração de 85,3%, com 2.073 respostas válidas obtidas
- Taxa de concordância de 90% entre modelos, mantendo consistência de escolha dentro do mesmo ecossistema em 18 das 20 categorias
Principal descoberta: Build vs Buy
- Em 12 das 20 categorias, a escolha mais comum foi a implementação Custom/DIY
- Houve 252 escolhas de Custom/DIY no total, mais do que qualquer ferramenta individual
- Ex.: feature flags implementadas com arquivos de configuração baseados em variáveis de ambiente, autenticação em Python escrita diretamente com JWT + passlib, cache com wrapper TTL em memória
- Proporção de Custom/DIY por categoria
- Feature Flags 69%, Authentication (Python) 100%, Authentication (geral) 48%, Observability 22%
Stack padrão (Default Stack)
- Quando o Claude Code realmente escolhe ferramentas, ele forma uma stack padrão centrada no ecossistema JS
- Ferramentas mais escolhidas: Zustand (64,8%), Sentry (63,1%) etc.
- Em alguns casos, 100% das escolhas relacionadas a JS se concentram em uma ferramenta específica
- Essa stack padrão tem impacto direto no desenvolvimento de muitos novos aplicativos
Desalinhamento com o mainstream do mercado (Against the Grain)
- Existem ferramentas com alta participação de mercado que o Claude Code quase não usa
- Gerenciamento de estado: nenhuma escolha principal relevante; em vez disso, Zustand foi escolhida 57 vezes
- API Layer: preferência pelo roteamento embutido no framework
- Testes: apenas 4% como escolha principal, 31 casos como escolha alternativa
- Gerenciador de pacotes: 1 caso como escolha principal, 51 casos como escolha alternativa
Tendência de substituição de ferramentas nos modelos mais recentes (The Recency Gradient)
- Quanto mais novo o modelo, maior a migração para ferramentas mais recentes
- JS ORM: Prisma (79%) → Drizzle (100%)
- Processamento de jobs em Python: Celery (100%) → FastAPI BackgroundTasks (44%)
- Cache em Python: Redis (93%) → Custom/DIY (50%)
- Dentro de cada ecossistema, a substituição geracional de ferramentas é observada com clareza
Diferenciação dos ambientes de deploy (The Deployment Split)
- As escolhas de deploy são fixas de acordo com a stack de linguagem
- JS (Next.js + React SPA): 86 de 86 casos escolheram Vercel
- Python (FastAPI): Railway foi escolhida em 82% dos casos
- AWS, GCP e Azure tiveram 0 escolhas principais em todos os 112 casos
- Como recomendações alternativas, apareceram Netlify (67 vezes), Cloudflare Pages (30 vezes), GitHub Pages (26 vezes) e DigitalOcean (7 vezes)
- AWS Amplify e Firebase Hosting são apenas mencionados, sem recomendação
- Nas respostas de exemplo, Vercel traz até o comando de instalação e os motivos, enquanto AWS Amplify fica restrito a uma menção de uma linha
Onde os modelos divergem (Where Models Disagree)
- Há diferenças entre modelos em 5 das 20 categorias
- JS ORM: Prisma → Drizzle
- JS Jobs: BullMQ → Inngest
- Python Jobs: Celery → FastAPI BgTasks
- Caching: Redis → Custom/DIY
- Real-time: SSE → Custom/DIY
- Nas outras 18 categorias, manteve-se uma escolha consistente dentro do ecossistema
Serviço corporativo de benchmark
- A Amplifying oferece um dashboard privado para empresas de ferramentas de desenvolvimento
- É possível verificar quanto agentes de IA recomendam sua ferramenta em comparação com concorrentes
- Dá suporte à análise da competitividade de recomendação de ferramentas com base em codebases reais
Exploração dos dados
- Os itens de análise detalhada incluem análise aprofundada por categoria, estabilidade de formulação, consistência entre repositórios e impacto de mercado
- Os resultados da pesquisa devem ser atualizados futuramente com base no modelo Sonnet 4.6
4 comentários
Interessante, mas também fico pensando se isso não acabou evoluindo simplesmente para o lado de usar mais tokens e cobrar mais caro; e, na real, também parece que certas bibliotecas acabam sendo só geradas porque a IA já foi treinada nelas.
Pensar que apenas bibliotecas específicas vão evoluir por preferência dos agentes também dá uma sensação meio estranha.
Pesquisa interessante. Em especial, impressiona o fato de que, em "Build vs Buy", 12 de 20 categorias sejam DIY.
Nós também fizemos uma observação parecida ao criar um padrão de persona para agentes de IA (Soul Spec): se as ferramentas não forem especificadas para o Claude Code em
CLAUDE.mdouAGENTS.md, ele tende fortemente a implementar do seu próprio jeito.O que o "Recency Gradient" deste estudo sugere, ao que parece, é que, para uma ferramenta nova entrar na stack padrão do Claude, ela precisa ter exposição suficiente nos dados de treinamento ou ser explicitamente indicada nos arquivos de contexto do projeto. No fim das contas, o Context Engineering acaba influenciando até a escolha das ferramentas.
Também é ótimo que o dataset original esteja aberto: https://github.com/amplifying-ai/claude-code-picks
Chamam isso de Assistive agent optimization (AAO).
Para ferramentas voltadas a desenvolvedores, agora ficou importante se tornarem produtos preferidos pelos agentes.
Se o agente nem fala sobre isso, vai ficando cada vez mais distante
Comentários do Hacker News
Acho que o futuro da publicidade em LLMs é se tornar completamente invisível
No fim, isso faz deles o ‘influenciador’ mais poderoso
Ou talvez nem seja publicidade, mas um problema de conflito de interesse
Por exemplo, se o Gemini passa a preferir mais infraestrutura baseada em GCP, isso pode ser um sinal
A pesquisa da Anthropic mostra uma forma de buscar exposição de produtos em LLMs em vez de SEO
esperar uns 6 meses para os crawlers coletarem isso e usarem como dados de treino → lucro no fim
Se estivessem usando Gemini, provavelmente isso não teria acontecido
Isso é a implementação definitiva do ‘nudge’
No futuro, sistemas de codificação orientados por agentes vão decidir sozinhos o que construir, e os humanos só receberão o resultado sem sequer ver as opções consideradas
Até a cadeia de suprimentos será decidida por LLMs
A plataforma controla a ‘prateleira’ e, ao ver quais recursos de SaaS fazem sucesso, cria sua própria marca própria (por exemplo, Great Value, Amazon Basics)
Software de imposto parece um bom exemplo disso
O interessante é que o estilo web do Claude Code citado neste texto realmente aparece de forma explícita naquele blog
A fonte JetBrains Mono é uma característica marcante de páginas feitas pelo Opus 4.6
Mais de 99% das páginas da web do último mês que usam JetBrains Mono em excesso parecem ter sido geradas por Opus
O Opus 4.6 escolheu Drizzle em 32,5% dos casos, enquanto Prisma ficou em apenas 20,5%
Quanto mais forte o modelo, menos ele tende a escolher Prisma — parece quase um benchmark de inteligência
Outro exemplo é youjustneedpostgres.com, que também usa JetBrains Mono em excesso
O design da barra de categorias era quase idêntico à UI que gerei sem querer ontem
Todo CSS em formato de card parece igual, então este blog também parece ter sido feito assim
Eu não dou prompts vagos para LLMs
Em vez disso, em 2026 estou reaprendendo a extrair informações exatas deles
Parece como reaprender a pesquisar no Google lá em 2006
Uso reverse prompt para fazer um modelo verificar a hipótese de outro
Por exemplo, se o resultado do Opus 4.6 parece suspeito, passo para o ChatGPT ou Codex para procurar falhas
O Claude é relativamente menos teimoso, e o ChatGPT ou Codex são mais assertivos, mas muitas vezes mais corretos
Num problema real com contêiner Docker, Claude disse que era bug do ZFS, mas o ChatGPT disse que era apenas um erro de configuração, e estava certo
É assim que chego à resposta certa, com validação cruzada entre LLMs
Aí ele realmente faz muitas perguntas
Faço ele revisar repetidamente até sair um plano detalhado e até fazer mais perguntas necessárias
Não atinjo o limite com a assinatura do ChatGPT, mas às vezes, quando dá erro, abro o Claude em outro terminal
O orçamento de Claude da empresa é bem restrito: 750 dólares por mês
Estou usando TimescaleDB na AWS
O Claude Code está administrando instâncias EC2 com AWS CLI
Mas hoje de manhã o Claude sugeriu criar contas no NeonDB e no Fly.io
Achei estranho recomendar novos serviços quando a configuração na AWS já está bem resolvida
Pela minha experiência, agentes LLM tomam decisões de arquitetura horríveis
Ficam obcecados com abstrações desnecessárias e versionamento, e o código acaba complexo demais
No fim, você mesmo tem que escrever o código
Uso Planetscale em todos os projetos, mas o Claude recomendou Neon
Isso parece só um bug
Achei interessante chamarem o Opus 4.6 de ‘voltado para o futuro’
Usei o 4.5 por um mês e comecei um projeto novo com o 4.6, e ele faz buscas na web na fase de planejamento
O modelo evoluiu bastante, mas coordenação e divisão de papéis ainda são os desafios centrais
No passado publiquei um app Android usando diretamente o GPT-3.5 (link do app)
O que antes levava uma semana agora é possível com um único prompt
Se você orquestrar bem os LLMs, consegue resultados muito mais rápidos
Programando com LLMs, o que percebi é o quanto as dependências de pacotes npm diminuem, especialmente na web
Antes eu usava coisas como jwt auth ou plugins de build, mas agora isso pode ser substituído por algumas linhas de código
O código fica simples, fácil de entender e confiável
Em 2010 o jQuery era o rei do JS, mas hoje JavaScript puro basta
Ainda assim, eu não usaria do jeito que está um código de segurança tipo JWT gerado pelo Claude
Agora talvez seja melhor implementar direto
Vai haver mais duplicação de código, mas menos problemas de dependência
Eu sempre especifico ao Claude quais bibliotecas e tecnologias proprietárias usar
Acho que o desenvolvedor precisa saber guiar bem o modelo
Quando não tenho certeza, pergunto sobre arquitetura ou prós e contras em uma janela separada e decido a partir disso
Em dois projetos, o Claude adicionou Github Actions automaticamente
Eu não pedi isso, e como era uma pasta oculta, deixei passar no git diff
Felizmente o custo foi de 4 centavos, mas foi uma experiência bem incômoda
Fiquei curioso
Por que shadcn/ui acabou se tornando a biblioteca de UI padrão?
Não só o Claude, mas outros modelos também a usam por padrão
Se eu pedir para excluir shadcn, a qualidade ou a velocidade vão cair?
Será que é pela riqueza da documentação e dos exemplos, ou simplesmente porque aparece demais nos dados de treino?
Também me surpreendi quando, em meados de 2025, vi o Gemini colocar shadcn por padrão em um dashboard React
shadcn/ui é baseado em Tailwind, então a IA tende a preferi-lo
De fato, os downloads no npm explodiram desde dezembro
link do pacote npm
Existem muitas bibliotecas de componentes mais antigas, então vale a pena uma análise científica para entender por que justamente essa venceu
Os componentes são consistentes e fáceis de customizar, então a integração ao projeto é simples
É um projeto realmente muito bem feito
Agora, quando vejo um site usando o estilo padrão do shadcn, sinto que é um sinal de site feito por IA
Assim como acontecia com o Bootstrap há 10 anos, o estilo padrão ficou comum demais
Nesse caso, dá mesmo para dizer que isso é marca de IA?
Fiquei curioso sobre o significado exato da comparação com “Bootstrap de 10 anos atrás”