Simon Willison cataloga 244 herramientas de vibe coding

¿Qué construyó Simon Willison y cómo funciona el navegador por etiquetas?

244 herramientas construidas con vibe coding y ninguna forma razonable de encontrar la que hacía falta. Ese fue el problema que Simon Willison decidió resolver con un navegador por etiquetas para su colección personal de aplicaciones generadas con IA, que publicó en su blog el 11 de noviembre de 2026.

Para cualquier founder que ya acumuló prototipos internos hechos con IA, el caso funciona como espejo: el inventario crece más rápido que la memoria del equipo sobre qué hace cada pieza, qué librería usa y qué dependencia arrastra.

La solución no fue escribir documentación a mano. Willison usó los créditos que le quedaban de Fable 5.2 antes de su reinicio semanal y puso al modelo a analizar el código de cada herramienta con tree-sitter, el parser que genera árboles de sintaxis y permite inspeccionar el código como estructura, no como texto. El objetivo: extraer automáticamente qué APIs de JavaScript, qué librerías y qué APIs del navegador consume cada aplicación.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El resultado es una portada con nubes de etiquetas. Cada etiqueta aparece dimensionada según cuántas herramientas la usan, y al seleccionarla se despliega la lista de herramientas que la comparten. Es, en la práctica, un índice invertido de un catálogo que nadie iba a mantener a mano.

¿Qué revelan las etiquetas sobre cómo se construyen las herramientas de vibe coding?

Los datos del propio catálogo son la parte más interesante para un equipo técnico. De las librerías cargadas desde CDN por dos o más herramientas, la más repetida es Marked (12), seguida de Pyodide (11) y DOMPurify (7). Más abajo aparecen Leaflet (4), JSZip (3), PDF.js (3), three.js (3), React (3) y D3 (2).

La lectura es clara: el stack real del vibe coding no es el de las aplicaciones empresariales. React aparece en apenas 3 de 244 herramientas, y three.js y D3 en 3 y 2 respectivamente. Lo que domina son utilidades puntuales —sanitizar HTML, parsear markdown, comprimir archivos, renderizar un PDF— que resuelven una tarea concreta sin arrastrar un framework completo.

El segundo bloque, las APIs del navegador que usa el código de cada herramienta, refuerza esa idea. ES modules (92), Clipboard API (69), Canvas 2D (44), Blob URLs (38) y Drag and drop (30) están en el top. Son capacidades nativas del navegador, disponibles sin instalar nada. La etiqueta Built-in AI aparece en una sola herramienta, un dato que sugiere que la IA embebida en el navegador todavía no es el camino que eligen los desarrolladores.

Para un founder, esto tiene una consecuencia práctica: si tu equipo está construyendo herramientas internas con IA, probablemente no necesita un framework pesado. Necesita entender qué APIs nativas ya resuelven el problema.

¿Cuál es el riesgo real de acumular herramientas hechas con IA?

El catálogo de Willison es un caso de éxito, pero conviene mirar el otro lado. El medio especializado TechTarget documenta en su análisis sobre el fenómeno del «vibe slop» que el 81% de los líderes técnicos empresariales reportó más incidentes en producción vinculados a código generado por IA, según el informe State of Code Abundance 2026 de CloudBees, aunque el 92% se sentía confiado al desplegarlo.

La misma nota cita un análisis de GitClear de enero de 2026 según el cual los peores resultados de calidad de código son nueve veces más probables entre los usuarios más intensivos de IA. Y el AI Trust Index de Secure Code Warrior, elaborado con la Universidad RMIT, evaluó 1.760 bases de código generadas por IA en 16 modelos y encontró un promedio de 15 vulnerabilidades por base, concentradas en fallos de registro, inyección, diseño inseguro y control de acceso roto.

El problema no es que el código falle: es que funciona. Como resume Joshua Copeland, profesor de la Universidad de Tulane, en ese mismo artículo, «el código se ejecuta con éxito pero resuelve un problema distinto del que la organización pretendía», y esos defectos persisten sin detectarse en producción.

Hay una respuesta de plataforma a ese riesgo. Cloudflare liberó como código abierto su plataforma Cloudflare OS, un espacio interno donde empleados no técnicos describen flujos en lenguaje natural y un agente los convierte en aplicaciones. Según Ars Technica, el modelo de seguridad se basa en «isolates» —instancias del motor V8— que arrancan en milisegundos y consumen entre 10 y 100 veces menos memoria que un contenedor estándar, lo que permite aislar cada aplicación sin frenar al usuario.

¿Qué significa esto para tu startup?

El caso de Willison no es una anécdota de un desarrollador prolífico: es el manual de mantenimiento de un activo que tu equipo probablemente ya tiene y no sabe que tiene.

Inventaría antes de documentar. Si ya hay decenas de prototipos internos hechos con IA, el primer paso no es escribir un manual: es extraer automáticamente qué usa cada uno. Un análisis estático del código, como el que hizo Willison con tree-sitter, te da el mapa en horas en lugar de semanas.
Etiqueta por capacidad, no por equipo. Las categorías que funcionaron en ese catálogo son las que responden a qué necesita cada herramienta para funcionar: librería, API del navegador, host externo. Ese criterio sobrevive a las reorganizaciones; el nombre del equipo que la creó, no.
Pon un dueño humano por cada línea generada. El análisis de TechTarget es explícito: el código de IA debe tratarse como entrada no confiable de un tercero, con un responsable designado que pueda explicar, defender y mantener cada implementación.
Aísla antes de abrir la puerta. Si vas a permitir que perfiles no técnicos construyan herramientas, el aislamiento no es opcional. El enfoque de sandbox de Cloudflare OS existe justamente para que un equipo de seguridad pueda dar permiso sin perder el sueño.
Mide la confianza, no solo la adopción. Una encuesta informal de SD Times a 103 desarrolladores encontró que el 87% ya usa o planea adoptar herramientas de IA para programar, pero solo el 31% confía en la exactitud del código generado y apenas el 4% declara confianza alta. Esa brecha es tu verdadero indicador de riesgo.

Conclusión

Willison resolvió un problema de escala personal con una idea que escala bien: si el código se genera automáticamente, el inventario también puede generarse automáticamente. La etiqueta vibe-coding acumula 104 entradas en su blog, frente a las 2.319 de IA o las 772 de JavaScript, lo que da una pista de hacia dónde se mueve la conversación técnica.

Para un founder hispanohablante, la lección es de gestión más que de tecnología. La velocidad para generar herramientas ya no es el cuello de botella; saber qué tienes, quién responde por ello y qué tan seguro es, sí lo es. El catálogo de 244 herramientas es la prueba de que se puede construir rápido. El informe de CloudBees es la prueba de que construir rápido sin inventario ni dueños tiene un costo que aparece más tarde, en producción.