- Resultados de un estudio que analizó las tendencias de selección de herramientas de Claude Code en 2,430 repositorios reales de código abierto
- En 12 de 20 categorías totales, eligió con mayor frecuencia el enfoque de implementación propia (Custom/DIY) en lugar de herramientas existentes, convirtiéndose en el tipo de elección más común
- En cambio, al elegir herramientas mostró una alta concentración en elementos específicos como GitHub Actions (94%), Stripe (91%) y shadcn/ui (90%)
- Los entornos de despliegue son fijos según el lenguaje: para JS la opción predeterminada es Vercel y para Python Railway, mientras que AWS·GCP·Azure quedan fuera de la primera opción
- En los modelos más recientes se observa claramente una tendencia a reemplazar por herramientas emergentes como Drizzle y FastAPI BackgroundTasks, y la consistencia de elección dentro del ecosistema ronda el 90%
Resumen del estudio
- Se realizaron 2,430 experimentos en total con Claude Code v2.1.39 para observar la selección de herramientas mediante preguntas abiertas sobre repositorios reales
- 3 modelos (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 tipos de proyecto y 20 categorías de herramientas
- 85.3% de tasa de extracción, con 2,073 respuestas válidas obtenidas
- 90% de coincidencia entre modelos, manteniendo consistencia de elección dentro del mismo ecosistema en 18 de 20 categorías
Hallazgo principal: Build vs Buy
- En 12 de 20 categorías, la elección más común fue la implementación Custom/DIY
- Se registraron 252 elecciones Custom/DIY en total, más que cualquier herramienta individual
- Ejemplos: feature flags implementados con archivos de configuración basados en variables de entorno, autenticación en Python escrita directamente con JWT + passlib, caché con un wrapper TTL en memoria
- Proporción de Custom/DIY por categoría
- Feature Flags 69%, Authentication (Python) 100%, Authentication (total) 48%, Observability 22%
Stack predeterminado (Default Stack)
- Cuando Claude Code realmente elige herramientas, forma un stack predeterminado centrado en el ecosistema JS
- Herramientas más elegidas: Zustand (64.8%), Sentry (63.1%), entre otras
- En algunos casos, el 100% de las elecciones relacionadas con JS se concentran en una herramienta específica
- Este stack predeterminado tiene un impacto directo en el desarrollo de muchas aplicaciones nuevas
Distancia frente a la corriente principal del mercado (Against the Grain)
- Hay herramientas con alta cuota de mercado que Claude Code casi no usa
- Gestión de estado: sin una opción principal relevante; en su lugar, Zustand fue elegida 57 veces
- API Layer: preferencia por el enrutamiento integrado del framework
- Testing: solo 4% como elección principal, con 31 elecciones alternativas
- Gestor de paquetes: 1 elección principal, 51 elecciones alternativas
Tendencia de reemplazo de herramientas en los modelos más recientes (The Recency Gradient)
- Mientras más nuevo es el modelo, más cambia hacia herramientas recientes
- JS ORM: Prisma (79%) → Drizzle (100%)
- Procesamiento de tareas en Python: Celery (100%) → FastAPI BackgroundTasks (44%)
- Caché en Python: Redis (93%) → Custom/DIY (50%)
- Dentro de cada ecosistema, se observa claramente un relevo generacional de herramientas
Diferenciación de entornos de despliegue (The Deployment Split)
- Las elecciones de despliegue son fijas según el stack de lenguaje
- JS (Next.js + React SPA): 86 de 86 eligieron Vercel
- Python (FastAPI): Railway fue elegida en el 82% de los casos
- AWS, GCP y Azure tuvieron 0 elecciones principales en los 112 casos
- Como recomendaciones alternativas aparecieron Netlify (67 veces), Cloudflare Pages (30), GitHub Pages (26) y DigitalOcean (7)
- AWS Amplify y Firebase Hosting solo se mencionan, pero no se recomiendan
- En las respuestas de ejemplo, Vercel incluso incluye el comando de instalación y las razones, mientras que AWS Amplify se queda en una mención de una sola línea
Zonas de desacuerdo entre modelos (Where Models Disagree)
- Hay diferencias entre modelos en 5 de 20 categorías
- JS ORM: Prisma → Drizzle
- JS Jobs: BullMQ → Inngest
- Python Jobs: Celery → FastAPI BgTasks
- Caching: Redis → Custom/DIY
- Real-time: SSE → Custom/DIY
- Las otras 18 categorías mantuvieron elecciones consistentes dentro del ecosistema
Servicio de benchmark para empresas
- Amplifying ofrece un dashboard privado para empresas de herramientas de desarrollo individuales
- Permite ver cuánto recomiendan los agentes de IA su herramienta frente a la competencia
- Ayuda a analizar la competitividad de recomendación de herramientas con base en codebases reales
Exploración de datos
- Entre los análisis detallados se incluyen análisis profundo por categoría, estabilidad del lenguaje, consistencia entre repositorios e impacto de mercado
- Está previsto que los resultados del estudio se actualicen en el futuro con base en el modelo Sonnet 4.6
4 comentarios
Es interesante, pero también da la impresión de que simplemente evolucionó hacia el lado de usar muchos de sus propios tokens y cobrar más, y también pienso que, en realidad, hasta cierto punto hay bibliotecas que la IA ya aprendió y por eso simplemente las genera.
Pensar que solo ciertas bibliotecas van a desarrollarse por preferencia de los agentes también se siente un poco extraño.
Es una investigación interesante. En particular, me impresiona que en “Build vs Buy”, 12 de 20 categorías sean DIY.
Nosotros también hicimos una observación similar mientras creábamos el estándar de persona para agentes de IA (Soul Spec): si no se especifican herramientas para Claude Code en
CLAUDE.mdoAGENTS.md, tiene una fuerte tendencia a implementarlo a su manera.Lo que sugiere el “Recency Gradient” de este estudio es que, para que una herramienta nueva entre al stack base de Claude, necesita suficiente exposición en los datos de entrenamiento o debe indicarse explícitamente en los archivos de contexto del proyecto. Al final, Context Engineering termina influyendo incluso en la selección de herramientas.
También está bueno que el dataset original esté publicado: https://github.com/amplifying-ai/claude-code-picks
Eso le llaman Assistive agent optimization (AAO).
Para las herramientas para desarrolladores, ahora se ha vuelto importante convertirse en productos preferidos por los agentes.
Si el agente ni siquiera las menciona, cada vez se irán quedando más atrás.
Comentarios en Hacker News
Creo que el futuro de la publicidad en los LLM será volverse completamente invisible
Al final, eso los convertiría en el ‘influencer’ más poderoso
O quizá ni siquiera sea publicidad, sino un problema de conflicto de interés
Por ejemplo, si Gemini prefiere más las implementaciones sobre GCP, eso podría ser una señal
Según la investigación de Anthropic, hay formas de apuntar a la visibilidad de productos en LLM en lugar de al SEO
Si esperas unos 6 meses, los crawlers lo recopilan y lo usan como datos de entrenamiento → ganancia al final
Si hubieran estado usando Gemini, no creo que eso hubiera pasado
Esto es la implementación definitiva del ‘nudge’
En el futuro, los sistemas de programación tipo agente decidirán por sí mismos qué construir, y los humanos ni siquiera veremos las opciones antes de recibir el resultado
Incluso la cadena de suministro será decidida por los LLM
La plataforma controla el ‘anaquel’, ve qué funciones de SaaS se vuelven populares y luego crea su propia marca blanca (por ejemplo, Great Value, Amazon Basics)
El software de impuestos parece un buen ejemplo de eso
Lo interesante es que el estilo web de Claude Code mencionado en el artículo realmente se nota tal cual en ese blog
La fuente JetBrains Mono es una característica muy representativa de las webs hechas por Opus 4.6
En el último mes, más del 99% de las páginas que usan JetBrains Mono en exceso parecen haber sido generadas por Opus
Opus 4.6 eligió Drizzle el 32.5% de las veces, mientras que Prisma apenas llegó al 20.5%
Cuanto más potente es el modelo, menos tiende a elegir Prisma — casi se siente como una especie de benchmark de inteligencia
Otro ejemplo es youjustneedpostgres.com, que también usa JetBrains Mono en exceso
El diseño de la barra de categorías era casi idéntico al de una UI que generé sin pensarlo mucho ayer
Todo ese CSS de tarjetas se siente igual, así que parece que este blog también fue hecho de esa manera
Yo no le doy prompts ambiguos a un LLM
Más bien, en 2026 estoy aprendiendo de nuevo cómo sacarle información precisa a un LLM
Se siente como volver a aprender a usar Google Search en 2006
Uso ‘reverse prompt’ para que un modelo verifique la hipótesis de otro
Por ejemplo, si el resultado de Opus 4.6 me parece sospechoso, se lo paso a ChatGPT o a Codex para que encuentren los huecos
Claude es relativamente menos terco, mientras que ChatGPT o Codex son más tajantes pero a menudo más precisos
De hecho, en un problema con un contenedor Docker, Claude dijo que era un bug de ZFS, pero ChatGPT dijo que era solo un error de configuración, y tenía razón
Así es como obtengo la respuesta correcta mediante validación cruzada entre LLM
Entonces sí te hará muchísimas
Lo hago seguir revisándolo hasta que salga un plan detallado, y así también hace más preguntas necesarias
Con la suscripción a ChatGPT no llego al límite, pero a veces, cuando falla, abro Claude en otra terminal
El presupuesto de Claude en la empresa está muy limitado a 750 dólares al mes
Estoy usando TimescaleDB en AWS
Claude Code está administrando instancias EC2 con AWS CLI
Pero esta mañana Claude me propuso crear cuentas en NeonDB y Fly.io
Me pareció raro que recomendara servicios nuevos cuando ya tengo bien montada la configuración en AWS
En mi experiencia, los agentes LLM toman decisiones de arquitectura terribles
Se obsesionan con abstracciones innecesarias y con el versionado, y el código se vuelve excesivamente complejo
Al final terminas escribiendo el código tú mismo
Uso Planetscale en todos mis proyectos, pero Claude me recomendó Neon
Esto parece simplemente un bug
Me pareció interesante que llamaran a Opus 4.6 ‘futurista’
Después de usar 4.5 durante un mes, empecé un proyecto nuevo con 4.6 y vi que hacía búsquedas web en la etapa de planificación
El modelo ya avanzó mucho, pero la coordinación y el reparto de roles siguen siendo el reto principal
Antes lancé por mi cuenta una app de Android con GPT-3.5 (link de la app)
Lo que en ese entonces me tomaba una semana, ahora se puede hacer con un solo prompt
Si orquestas bien los LLM, puedes sacar resultados mucho más rápido
Algo que he notado al programar con LLM es cuánto se reducen las dependencias de paquetes npm, sobre todo en web
Antes usaba cosas como jwt auth o plugins de build, pero ahora muchas veces se pueden reemplazar con unas cuantas líneas de código
El código queda simple, fácil de entender y por eso da más confianza
En 2010 jQuery era el rey de JS, pero ahora con JavaScript puro basta
Aun así, no usaría tal cual código de seguridad como JWT hecho por Claude
Ahora tal vez sea mejor implementarlo uno mismo
Habrá más código duplicado, pero menos problemas de dependencias
Siempre le indico a Claude qué librerías y tecnologías patentadas usar
Creo que un desarrollador debe saber guiar bien al modelo
Si no estoy seguro, pregunto en otra ventana sobre arquitectura o ventajas y desventajas antes de decidir
En dos proyectos, Claude agregó Github Actions automáticamente
Yo no se lo pedí, y como estaba en una carpeta oculta, no lo vi en
git diffPor suerte el costo fue de 4 centavos, pero fue una experiencia bastante inquietante
Tengo una duda
¿Por qué shadcn/ui se volvió tanto la librería de UI por defecto?
No solo Claude: otros modelos también la usan por defecto
Si excluyes shadcn, ¿bajará la calidad o la velocidad?
¿Será por la riqueza de la documentación y los ejemplos, o simplemente porque aparece demasiado en los datos de entrenamiento?
A mí también me sorprendió ver que Gemini ya lo metía por defecto en dashboards de React hacia mediados de 2025
shadcn/ui está basado en Tailwind, así que a la IA le gusta
De hecho, las descargas en npm se dispararon desde diciembre
link del paquete npm
Hay muchas librerías de componentes más antiguas, así que valdría la pena analizar científicamente por qué esta ganó
Los componentes son consistentes y fáciles de personalizar, así que integrarlo en proyectos es sencillo
Es un proyecto realmente bien hecho
Ahora, cuando veo sitios que usan shadcn con el estilo por defecto, lo siento como una señal de sitio web hecho por IA
Igual que pasaba con Bootstrap hace 10 años, el estilo por defecto ya es demasiado común
Entonces, ¿realmente eso se puede ver como una huella de IA?
Me da curiosidad qué significa exactamente la comparación con “Bootstrap hace 10 años”