Si trabajas con Claude Code, Gemini CLI o cualquier agente de IA para programar, sabes lo que pasa: empiezas bien, el agente entiende el contexto, genera algo razonable. Pero a medida que la conversación crece, el contexto se degrada. Lo que el agente “sabía” al principio empieza a difuminarse. Cada sesión nueva es casi empezar de cero.
GSD — Get Shit Done — es un intento open-source de atacar ese problema. No con más contexto, sino con más estructura.
¿Qué es GSD exactamente?
GSD es un framework ligero de meta-prompting e ingeniería de contexto diseñado para equipos pequeños y founders que desarrollan productos con IA. El principio central: antes de ejecutar cualquier funcionalidad, defines una especificación (SPEC) clara. El sistema divide entonces el trabajo entre agentes especializados — un Researcher que investiga, un Planner que organiza, un Executor que implementa — y mantiene el estado del proyecto en archivos estructurados.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El estado vive en una carpeta .planning/ con archivos como PROJECT.md, REQUIREMENTS.md y planes en formato XML. Los comandos principales son /gsd:new-project para arrancar y /gsd:plan-phase para avanzar entre fases, con verificaciones automáticas (comandos Bash) en cada entregable.
El proyecto es open-source, disponible en GitHub, con forks activos para OpenCode, Claude Code y otras plataformas, y una comunidad de Discord donde founders comparten implementaciones.
¿Qué problema resuelve de verdad?
Para entender el valor real, vale la pena ser específico sobre el problema. Los agentes de IA para código tienen una limitación estructural: la ventana de contexto es finita y la degradación del contexto es real. A medida que el proyecto crece, el agente “olvida” decisiones de arquitectura, convenciones adoptadas, restricciones del cliente. Cada sesión nueva requiere re-inyectar contexto manualmente.
Soluciones existentes para eso: un archivo CLAUDE.md en la raíz del proyecto, Cursor Rules, un .cursorrules bien escrito. Todas funcionan para equipos de una persona con proyectos simples. Donde fallan: múltiples agentes en paralelo, proyectos multi-fase, o equipos donde más de una persona interactúa con el mismo agente.
GSD apunta a ese caso más complejo: proyectos con muchas fases donde necesitas trazabilidad y estado replicable entre sesiones. Si tu proyecto es más complejo que “un dev usando Claude Code para construir una feature”, GSD empieza a tener sentido.
¿Qué tan maduro está?
Aquí conviene ser honesto. GSD es un proyecto de comunidad, no un producto con respaldo institucional. Hay varios forks, lo que habla de interés real, pero también de que no hay una versión canónica estabilizada. La documentación asume familiaridad con CLI, Git y los agentes de IA que soporta.
Los “casos reales” que circulan en la comunidad — OpenCode, Antigravity — son referencias de peers, no estudios de caso verificados. Y el impacto real depende casi por completo de qué tan bien construyas las specs iniciales. Si entras con specs vagas, la estructura de GSD no va a salvar el resultado. Es un amplificador del proceso, no un sustituto del pensamiento.
¿Cuándo usarlo y cuándo no?
Vale la pena compararlo con otras apuestas en el mismo espacio. Cursor Automations, por ejemplo, ofrece agentes de código integrados en el IDE, mantenidos por un equipo con recursos y con soporte activo. GSD es más flexible y más portable, pero mucho más manual.
Tiene sentido si:
- Tu proyecto tiene múltiples fases con dependencias claras entre ellas
- Trabajas con más de un agente de IA o más de una persona interactuando con el mismo agente
- Necesitas que las decisiones de arquitectura persistan entre sesiones sin reinyectar contexto manualmente
- Tienes disposición de invertir tiempo en definir specs bien antes de ejecutar
No tiene sentido si:
- Eres un dev solo en un proyecto de pocas semanas — un CLAUDE.md bien escrito es suficiente
- Buscas una solución lista para usar sin curva de aprendizaje inicial
- Tu herramienta de desarrollo ya tiene memoria de proyecto nativa
Por qué importa
GSD refleja algo que el ecosistema todavía está resolviendo: el perfil de quien construye software está cambiando, pero los workflows para hacerlo de forma confiable y trazable todavía no están estandarizados. La pregunta de cómo mantener contexto y estado en proyectos desarrollados con agentes de IA es genuinamente importante y no está resuelta.
Hay un debate real sobre si la solución correcta son frameworks de prompting como GSD, o si las propias herramientas van a absorber ese problema. Claude Code ya incorpora memoria de proyecto de formas que hace un año no existían. Si esa tendencia continúa, frameworks externos como GSD podrían volverse innecesarios para la mayoría de casos de uso.
Por ahora, GSD es una solución práctica para un problema real en el extremo más complejo del espacio. Si reconoces el problema que describe, vale la pena explorar el repositorio. Si tu contexto es más simple, hay opciones más ligeras que probablemente cubren el 80% del valor con el 20% del esfuerzo.
