GSD (Get Shit Done) Análisis en Profundidad

Introducción

En el Análisis en Profundidad de Ralph Wiggum, exploramos un problema fundamental: Context Rot — a medida que las conversaciones se alargan, la ventana de contexto de Claude se llena de código fallido, discusiones obsoletas e información irrelevante, provocando que la calidad de las respuestas se degrade progresivamente.

La solución de Ralph fue "reiniciar todo": usar un bucle infinito de bash para iniciar una instancia nueva de Claude cada vez, pasando el estado a través del sistema de archivos. Simple, efectivo, pero con limitaciones evidentes — es solo una metodología sin comprensión del proyecto, sin planificación por fases ni verificación de calidad. Usted necesita escribir las especificaciones, orquestar las tareas y juzgar "¿está terminado?" por su cuenta.

Como Chase AI resumió con precisión en su video: El Ralph Loop es un arma increíblemente poderosa, pero la mayoría de las personas no necesitan un arma — necesitan un arsenal completo. El bucle de Ralph depende enteramente de la preparación previa: ¿Su PRD es suficientemente bueno? ¿Las definiciones de funcionalidades son lo bastante precisas? ¿Sabe cómo se ve "terminado"? Si las respuestas a estas preguntas no son precisas, sin importar cuántas veces se ejecute el bucle, será simplemente basura entra, basura sale.

¿Y si usted quiere un sistema que no solo ejecute Claude en un bucle, sino que realmente comprenda su proyecto y entregue código de manera confiable?

Eso es exactamente lo que GSD (Get Shit Done) está diseñado para hacer.

¿Qué es GSD?

GSD fue creado por TÂCHES (GitHub: glittercowboy), un desarrollador independiente. Su motivación fue directa:

"No soy una empresa de software de 50 personas. No quiero jugar al teatro empresarial. Soy simplemente una persona creativa que quiere hacer cosas geniales."

En su transmisión en vivo, TÂCHES demostró un hecho impactante: nunca escribe código a mano. Usando GSD, construyó una aplicación nativa de macOS para generación de música con IA (Sample Digger) desde cero en 4 horas — cero código escrito a mano. Se posiciona no como programador, sino como "gerente de proyecto de alto nivel" — describiendo la visión, tomando decisiones clave y validando resultados. GSD hace posible esta forma de trabajar.

"This has like 100x'd my ability to make cool shit with Claude Code because it's just created this systematization."

—— TÂCHES

Otras herramientas de desarrollo dirigido por especificaciones — BMAD, SpecKit — tienen su propio valor, pero tienden a introducir flujos de trabajo empresariales complejos: ceremonias de sprint, story points, sincronizaciones con stakeholders. Para desarrolladores independientes o equipos pequeños, estos procesos son una carga en sí mismos. Como dijo Chase AI: "It's not enterprise theater. We understand that you're just one person, you just want some sort of scaffolding around Claude Code to make sure it executes the tasks it says it's going to execute in an effective way."

La filosofía de diseño de GSD es ocultar la complejidad dentro del sistema. Los usuarios solo necesitan unos pocos comandos simples mientras el sistema se encarga de toda la gestión de contexto, la orquestación de tareas y la verificación de calidad tras bambalinas. En el primer mes desde su lanzamiento, el proyecto obtuvo cerca de 3,000 estrellas en GitHub y 14,000 instalaciones de npm, con TÂCHES publicando actualizaciones 15-20 veces casi todos los días.

Posición de GSD en el ecosistema de herramientas

Esta tabla revela una compensación clave: Ralph intercambia complejidad mínima del sistema por máxima autonomía de ejecución — inícielo y váyase a dormir; mientras que GSD intercambia alta complejidad del sistema por calidad de planificación y supervisión humana — usted tiene la oportunidad de intervenir en cada etapa. SpecKit y BMAD se ubican en un punto intermedio, ofreciendo capacidades de planificación pero sin la ingeniería de contexto de GSD ni la ejecución autónoma de Ralph.

GSD y Ralph no son contradictorios. GSD hereda los principios fundamentales de Ralph — contexto fresco, archivos como fuente de verdad — pero construye un marco completo de comprensión y ejecución de proyectos sobre esa base. Si Ralph es "darle una tarea a la IA y dejar que siga intentando", GSD es "entender lo que usted quiere, investigar cómo hacerlo, planificar los pasos, ejecutar y verificar".

El resumen de Chase AI lo captura perfectamente: El bucle de Ralph asume que usted llega con un plano completo — GSD le ayuda a construir ese plano. GSD toma su idea a medio formar, hace preguntas profundas, investiga en su nombre, genera un PRD completo, lo descompone en tareas atómicas y entrega el proyecto de principio a fin. Y al ejecutar código, utiliza exactamente los mismos principios fundamentales que hacen poderoso al bucle de Ralph: contexto fresco para los subagentes y tareas lo más pequeñas y precisas posible.

Flujo de trabajo principal

El flujo de trabajo de GSD es un ciclo de discusión → planificación → ejecución → verificación, donde cada etapa tiene entradas y salidas claramente definidas.

1. Inicializar el proyecto

/gsd:new-project

Un solo comando inicia todo el proceso. El sistema hará lo siguiente:

1. Hacer preguntas — Seguirá indagando hasta comprender completamente su idea (objetivos, restricciones, preferencias tecnológicas, casos límite)
2. Investigar — Enviar agentes en paralelo para investigar los dominios relevantes (opcional pero recomendado)
3. Extraer requisitos — Distinguir entre elementos de v1, v2 y fuera de alcance
4. Hoja de ruta — Crear un plan por fases alineado con los requisitos

Usted aprueba la hoja de ruta y luego comienza a construir. La experiencia de TÂCHES indica: cuanto más detallada sea la descripción inicial que proporcione, menos preguntas de seguimiento hará el sistema; cuanto más vaga sea, más preguntará. Recomienda preparar un documento de visión aproximado antes de comenzar — no necesita conocer el stack tecnológico ni los detalles de implementación, solo describir lo que quiere.

Archivos de salida: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md

¿Ya tiene una base de código? Ejecute /gsd:map-codebase primero — el sistema enviará agentes en paralelo para analizar su stack tecnológico, arquitectura, convenciones y problemas potenciales. Luego /gsd:new-project podrá planificar basándose en su código existente.

2. Fase de discusión

/gsd:discuss-phase 1

Cada fase en la hoja de ruta tiene solo una o dos oraciones de descripción — eso no es suficiente para construir lo que usted quiere. La fase de discusión existe para capturar sus preferencias de implementación antes de la investigación y planificación.

El sistema analiza la fase actual e identifica "zonas grises" — puntos de decisión donde existen múltiples enfoques razonables de implementación:

• Funcionalidades visuales → diseño, interacciones, manejo de estados vacíos
• API/CLI → formato de respuesta, manejo de errores, nivel de detalle
• Sistemas de contenido → estructura, tono, profundidad, flujo

Cada decisión que tome aquí afecta directamente la calidad de la investigación y planificación posteriores. Omitir este paso es válido (el sistema usará valores predeterminados razonables), pero una discusión más profunda permite al sistema construir algo más cercano a sus expectativas.

Archivos de salida: {phase}-CONTEXT.md

3. Fase de planificación

/gsd:plan-phase 1

El sistema hará lo siguiente:

1. Investigar — Examinar cómo implementar la fase actual, guiado por las decisiones de la fase de discusión
2. Planificar — Crear 2-3 planes de tareas atómicas usando formato estructurado XML
3. Verificar — Comprobar si el plan satisface los requisitos, iterando hasta que pase

Un principio de diseño clave es el Goal-Backward Planning (planificación retroactiva desde el objetivo). En lugar de partir de "¿qué deberíamos construir?", pregunta "¿qué condiciones deben cumplirse para lograr el objetivo?" — y luego trabaja hacia atrás para derivar el plan y las tareas. TÂCHES afirma que este enfoque "mejoró masivamente la calidad de los resultados" porque cada tarea entiende su relación con las demás, en lugar de ser simplemente un elemento en una lista de pendientes.

Cada plan es lo suficientemente pequeño para ejecutarse dentro de una única ventana de contexto nueva. Esto es crucial — no habrá degradación de calidad.

Archivos de salida: {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. Fase de ejecución

/gsd:execute-phase 1

El sistema hará lo siguiente:

1. Ejecución por oleadas — Las tareas independientes se ejecutan en paralelo; las dependientes se ejecutan secuencialmente
2. Contexto fresco — Cada plan se ejecuta en un contexto completamente nuevo de 200k tokens, sin basura acumulada
3. Commits atómicos — Cada tarea obtiene un commit de git independiente
4. Verificación de objetivos — Comprobar si la base de código entrega la funcionalidad prometida por la fase

En la demostración en vivo de TÂCHES, completó 3 fases completas de desarrollo con su ventana de contexto principal manteniéndose en apenas el 24%. El subagente GSD Executor necesita cargar menos de 1,000 líneas de contexto para completar una fase entera — puede ejecutar 10 planes seguidos y el contexto aún se mantiene por debajo del 50%. Esta es una experiencia completamente diferente a trabajar directamente en Claude Code: ya no es "jugar a la ruleta rusa, apostando a cuándo chocarás contra el muro de la ventana de contexto".

Archivos de salida: {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

5. Fase de verificación

/gsd:verify-work 1

La verificación automatizada puede comprobar si el código existe y si las pruebas pasan. Pero, ¿la funcionalidad trabaja como usted espera? Eso requiere su confirmación.

El sistema hará lo siguiente:

1. Extraer entregables verificables — Listar las cosas que ahora debería poder hacer
2. Guiar la verificación una por una — "¿Puede iniciar sesión con correo electrónico?" Sí/no, o describa el problema
3. Diagnosticar fallos automáticamente — Enviar un agente de depuración para encontrar la causa raíz
4. Crear un plan de corrección — Una corrección directamente ejecutable

Si todo pasa, continúe a la siguiente fase. Si hay problemas, ejecute /gsd:execute-phase nuevamente para ejecutar el plan de corrección.

Esta es la mayor diferencia filosófica entre GSD y el bucle de Ralph: Ralph es de manos libres — inícielo y déjelo correr; GSD tiene un paso de verificación humana después de cada fase. Chase AI señala que el bucle de Ralph es estilo "ir a conquistar" — funciona por su cuenta sin mirar atrás; GSD asegura que usted pueda corregir el rumbo en cada punto de control crítico, evitando que los errores se acumulen sin supervisión.

Además, GSD proporciona un flujo de trabajo dedicado para depuración. Cuando la verificación encuentra problemas, /gsd:debug lanza un subagente de depuración aislado con su propio flujo de trabajo de hipótesis-evidencia-resolución, creando documentación de depuración independiente para rastrear todo el proceso de investigación sin contaminar el contexto principal.

Archivos de salida: {phase}-UAT.md

Repetir el ciclo

/gsd:discuss-phase 2 → /gsd:plan-phase 2 → /gsd:execute-phase 2 → /gsd:verify-work 2
...
/gsd:complete-milestone → /gsd:new-milestone

Cada fase pasa por el ciclo completo de discusión → planificación → ejecución → verificación. El contexto se mantiene fresco, la calidad se mantiene consistente.

Cuando todas las fases se completan, /gsd:complete-milestone archiva el hito y etiqueta la versión. Luego /gsd:new-milestone inicia la construcción de la siguiente versión.

Por qué funciona: principios técnicos

La confiabilidad de GSD no es accidental — cuatro pilares técnicos clave la sustentan.

Context Engineering

Claude Code es extremadamente poderoso cuando recibe el contexto adecuado. La mayoría de las personas no saben cómo darle el contexto adecuado. GSD se encarga de esto por usted.

Cada archivo tiene límites de tamaño basados en los umbrales de degradación de calidad de Claude. Mantenerse dentro de los límites garantiza resultados consistentemente de alta calidad. La ventana de contexto principal se mantiene en 30-40%, mientras que el trabajo real ocurre en los contextos frescos de 200k de los subagentes.

Chase AI tiene una explicación intuitiva del context rot: Sin importar cuán grande sea la ventana de contexto — Sonnet, Opus, incluso ventanas de un millón de tokens — los tokens en la primera mitad son más efectivos que los de la segunda mitad. Esto no es un error; es una propiedad inherente de los LLM. El autocompact integrado de Claude Code solo puede mitigar esto parcialmente. El enfoque de GSD es más exhaustivo: cada tarea atómica se ejecuta en un subagente nuevo, asegurando que cada tarea obtenga el mejor rendimiento de Claude.

Los propios datos de TÂCHES lo confirman: con el plan Max de $200/mes, consume aproximadamente $30,000 en tokens de Opus al mes. Eso suena como mucho, pero dado que cada tarea se ejecuta en contexto fresco, el retrabajo es mínimo — la eficiencia real es muy superior a reparar cosas repetidamente en un contexto degradado.

XML Prompt Formatting

Cada plan es XML estructurado optimizado para Claude:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Instrucciones precisas, sin adivinanzas, verificación integrada en cada tarea.

Orquestación multiagente

Cada etapa utiliza el mismo patrón: un orquestador ligero envía agentes especializados, recopila resultados y encamina al siguiente paso.

El orquestador nunca hace el trabajo pesado. Envía agentes, espera e integra resultados. El resultado: puede ejecutar una fase completa — investigación profunda, creación y validación de múltiples planes, miles de líneas de código escritas en paralelo, verificación automatizada — mientras su ventana de contexto principal se mantiene en 30-40%.

Commits atómicos de Git

Cada tarea se registra de forma independiente inmediatamente después de completarse:

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

Beneficios: git bisect puede localizar la tarea exacta que falló, cada tarea se puede revertir de forma independiente, y un historial limpio ayuda a Claude a entender la evolución del código en sesiones futuras.

Limitaciones de GSD

GSD es poderoso, pero entender lo que no puede hacer es igualmente importante.

GSD es un flujo de trabajo guiado por humanos, no un agente autónomo

GSD no puede ejecutarse de manera persistente. Cada frontera entre etapas — de discuss a plan a execute a verify — requiere que usted ingrese un comando manualmente. No puede decir "constrúyame una aplicación" e irse a dormir.

Esto contrasta marcadamente con el modo AFK de Ralph. Ralph está diseñado para "iniciarlo e irse a dormir" — el bucle infinito de bash sigue ejecutándose hasta que la tarea se complete o falle. GSD requiere que usted esté presente en cada punto de control crítico: aprobando la hoja de ruta, respondiendo preguntas de discusión, activando la planificación, lanzando la ejecución, confirmando los resultados de verificación.

Durante su transmisión en vivo de 4 horas, TÂCHES estuvo continuamente escribiendo comandos: new-project, discuss-phase 1, plan-phase 1, execute-phase 1, verify-work 1, discuss-phase 2... Cada transición requería que presionara Enter. Esto no es accidental — es una decisión de diseño deliberada.

Una compensación de diseño deliberada

Ralph sacrificó capacidad de planificación por autonomía de ejecución; GSD sacrificó autonomía de ejecución por calidad de planificación y supervisión humana. Esta es una compensación de diseño, no una deficiencia.

• Ventaja de Ralph: Puede dejarlo ejecutar una funcionalidad completa mientras duerme. Pero si la especificación no es suficientemente buena, avanzará a toda velocidad en la dirección equivocada.
• Ventaja de GSD: Puede corregir el rumbo después de cada fase. Pero debe estar presente en todo momento — no puede alejarse.

¿Cómo sería lo ideal? Si las fases de discusión, planificación, ejecución y verificación de GSD pudieran encadenarse en un ciclo automatizado — como el bucle bash de Ralph pero con la planificación estructurada y la verificación de calidad de GSD — eso sería lo mejor de ambos mundos. Pero aún no existe tal herramienta. Quizás esa sea la próxima dirección que vale la pena explorar.

Recursos en video

Los siguientes videos pueden ayudarle a comprender de manera más intuitiva cómo se usa GSD y qué puede lograr.

I Created GSD For Claude Code. This Is How I Use It.

Transmisión en vivo de 4 horas de TÂCHES (creador de GSD). Construye desde cero una aplicación nativa de macOS para generación de música con IA (Sample Digger) sin escribir código a mano. Demuestra el subagente GSD Executor, la planificación retroactiva desde el objetivo, el flujo de depuración, el cambio entre múltiples modelos, y cómo el contexto principal se mantiene en 24% después de 10 fases.YouTube

The New Claude Code Meta

Chase AI analiza por qué GSD es el nuevo meta para desarrolladores independientes. Análisis profundo de la mecánica del context rot, cómo la ejecución con subagentes asegura la calidad del resultado, los tres documentos centrales de GSD (Project/Roadmap/State), y su experiencia real construyendo un clon de My Fitness Pal con GSD.YouTube

Stop Using Ralph Loops (Use This Instead)

Chase AI evalúa GSD desde la perspectiva de un usuario del bucle de Ralph. Argumento central: el bucle de Ralph es un arma poderosa, pero GSD es el arsenal completo. Compara el modo de manos libres de Ralph vs la verificación human-in-the-loop de GSD, demuestra el flujo completo de instalación y ejecución, y discute la compensación en costo de tokens.YouTube

Reflexiones finales

GSD representa una dirección en la evolución de las herramientas de programación con IA: de "dejar que la IA escriba código" a "dejar que la IA entregue proyectos de manera confiable".

Ralph Wiggum demostró una perspectiva clave — el contexto fresco es más valioso que el contexto acumulado. GSD construye sobre esta base agregando comprensión del proyecto (new-project), captura de decisiones (discuss), planificación estructurada (plan), ejecución en paralelo (execute) y verificación de calidad (verify), formando un ciclo cerrado completo.

Para desarrolladores independientes y equipos pequeños, el valor de GSD radica en empaquetar prácticas complejas de ingeniería en unos pocos comandos simples. No necesita entender la orquestación de subagentes ni la ingeniería de prompts XML — solo necesita describir lo que quiere y dejar que el sistema se encargue.

Chase AI lo expresó bien: GSD es para personas que "no vienen de un trasfondo técnico pero aún quieren construir proyectos de principio a fin en Claude Code de manera sostenible y repetible". Y la transmisión en vivo de TÂCHES lo demostró — alguien que se describe a sí mismo como "probablemente solo capaz de escribir una página HTML de Hello World por mi cuenta" usó GSD para construir una aplicación de escritorio nativa completa.

Esto no es magia. Es poner la complejidad correcta en el lugar correcto — el sistema maneja la complejidad de la orquestación mientras los humanos se concentran en la creatividad y las decisiones. Y sus limitaciones también merecen respeto: la decisión de GSD de mantener a los humanos presentes en todo momento es tanto su restricción como la fuente de su confiabilidad.

¿Listo para ponerse manos a la obra? Continúe con la Guía Práctica de GSD — que cubre la referencia completa de comandos, detalles de configuración, demostraciones de flujos de trabajo y preguntas frecuentes.

Lecturas relacionadas:

• Análisis en Profundidad de Ralph Wiggum — Análisis completo del problema de Context Rot y la metodología Ralph
• ¿Qué es el Desarrollo Dirigido por Especificaciones? — El cambio de paradigma de Vibe Coding al desarrollo dirigido por especificaciones
• Guía Completa de Claude Subagent — Otro enfoque para mantener limpio el contexto
• Arquitectura del Sistema Claude — La arquitectura general de Hooks, Subagents y otros componentes
• Mis Mejores Prácticas con Claude Code — Consejos prácticos para el uso diario de Claude Code