Garry Tan publica su Claude Code: 23 herramientas-rol y 139.000 estrellas

Una escena conocida: le pide a un agente de IA que "haga una función" y, en un solo flujo, inventa el producto, dibuja la interfaz, escribe el código, se felicita a sí mismo y se olvida de la documentación. El resultado suele ser mediocre en todos los apartados. El repositorio garrytan/gstack intenta curar precisamente esto y hoy vuelve a estar en el top diario de GitHub Trending: 139.039 estrellas en total y 285 en el último día.

Qué es este conjunto

Garry Tan presenta gstack como su ajuste fino de Claude Code. La descripción del proyecto dice que son 23 herramientas "con opinión propia" (opinionated) que funcionan como CEO, diseñador, gerente de ingeniería, responsable de lanzamientos, ingeniero de documentación y QA. El lenguaje del proyecto es TypeScript.

Una salvedad importante: nos basamos en la descripción del repositorio y sus métricas. Aquí no se ofrece un análisis línea por línea de cada una de las 23 herramientas, y conviene hacerlo por cuenta propia antes de adoptarlo.

Por qué los roles funcionan mejor que un prompt general

La lógica es sencilla y familiar para cualquiera que haya formado un equipo. Cuando una misma persona se encarga tanto de la decisión de producto como del control de calidad, tiende a darse la razón. Con un modelo de lenguaje ocurre lo mismo: si en un mismo contexto escribe el código y lo evalúa, la crítica resulta blanda.

Imagine un día típico. Quiere añadir una pantalla de ajustes a un servicio. En un esquema por roles, el orden podría ser este:

• el "CEO" comprueba si la función es realmente necesaria y qué es lo esencial en ella;
• el "diseñador" describe los estados de la pantalla y los casos límite;
• el "gerente de ingeniería" divide la tarea en pasos;
• "QA" intenta romper el resultado por separado;
• el "responsable de lanzamientos" y el "editor de documentación" cierran los cabos sueltos: la versión, la lista de cambios, el README.

Cada rol recibe sus propias instrucciones y sus propios criterios de éxito. No es magia, sino disciplina de proceso integrada en las herramientas, para no tenerla en la cabeza ni reescribir el prompt cada vez.

Por qué se habla de ello

La primera razón es obvia: el nombre del autor. Cuando el responsable de una gran aceleradora de startups muestra cómo trabaja exactamente con un agente, resulta interesante como artefacto de trabajo, no como teoría. La segunda razón es más profunda: la comunidad está cansada de las charlas abstractas sobre agentes y quiere ver configuraciones concretas que se puedan copiar y ejecutar.

Sin embargo, las estrellas hay que leerlas con cuidado. 139 mil indican atención y curiosidad, pero no una productividad demostrada. La popularidad de un repositorio no sustituye las mediciones en su propia base de código.

Limitaciones

La descripción dice con honestidad que las herramientas son "con opinión propia". Eso significa que llevan integrados gustos ajenos: cómo debe ser un buen lanzamiento, qué se considera documentación suficiente, cuán estricto debe ser el QA. Para un equipo con otro stack, otras convenciones o requisitos regulatorios, habrá que reescribir parte de las reglas.

Hay además un coste oculto: más roles significan más llamadas al modelo, más tokens y más puntos donde algo puede fallar. Si su proyecto es pequeño, 23 herramientas pueden ser excesivas y bastarán dos o tres.

Qué hacer en la práctica

No instale el conjunto completo en un repositorio de trabajo el primer día. Es mejor así:

• clone el proyecto y lea las instrucciones de los roles: es un manual gratuito sobre cómo estructurar el trabajo de un agente;
• pruebe dos roles con el beneficio más claro, por ejemplo QA y documentación;
• ejecútelos en una tarea pequeña y compare el resultado con su método habitual;
• conserve lo que funcionó y descarte el resto.

Los responsables de producto y los fundadores deberían mirar gstack desde otro ángulo: como una plantilla de proceso. Incluso si no usa el código en sí, la pregunta "qué roles de mi desarrollo con agentes no interpreta nadie todavía" es útil. Lo más frecuente es que sean precisamente el control de calidad y la higiene de los lanzamientos.

La conclusión principal: el valor de gstack no está en ser la "mejor configuración", sino en mostrar cómo es un trabajo maduro con un agente de código: roles, reglas y separación de responsabilidades en lugar de un único prompt largo.