Flujos de trabajo de SDD: GitHub Spec Kit vs. Kiro vs. Claude Code

Los desarrolladores que comparan configuraciones de Desarrollo Guiado por Especificaciones (SDD) en 2026 generalmente no preguntan qué modelo es el más inteligente. Preguntan qué flujo de trabajo mantendrá alineado a un agente de IA sin sumergirlos en una burocracia innecesaria.

GitHub Spec Kit, AWS Kiro y los flujos de trabajo personalizados de Claude Code implementan la misma idea general: requisitos, diseño, tareas, implementación y validación, pero intercambian portabilidad, profundidad de integración y cuánto proceso imponen.

Si necesitas los conceptos primero, lee ¿Qué es el Desarrollo Guiado por Especificaciones? y la guía neutral en cuanto a herramientas Flujo de Trabajo de Desarrollo Guiado por Especificaciones en el clúster de documentación de Arquitectura de Aplicaciones. Esta comparación se sitúa en el hub de Herramientas para Desarrolladores de IA junto con reseñas de asistentes y guías de flujo de trabajo. Cubre las tres configuraciones sobre las que los desarrolladores más debaten en Hacker News y foros estilo Reddit, además de las alternativas más ligeras y más pesadas que las rodean.

El SDD se está convirtiendo en una categoría de herramientas

El Desarrollo Guiado por Especificaciones dejó de ser un ejercicio teórico a finales de 2025. Cada principal proveedor de codificación con IA ahora ofrece alguna versión del ciclo especificar-planificar-implementar, y una lista creciente de herramientas independientes compite por la cantidad de estructura que añaden alrededor de ese ciclo.

La comparación que importa no es “qué herramienta gana”. Es profundidad del proceso versus portabilidad. Kiro está integrado. Spec Kit es portable. Los flujos de trabajo de Claude Code son adaptables. Las malas especificaciones hacen que cada agente sea peor, independientemente del envoltorio que elijas. Las buenas especificaciones viajan entre herramientas.

Cómo comparar configuraciones de SDD

Antes de elegir una herramienta, define para qué estás optimizando. La misma funcionalidad puede parecer sencilla en una configuración y burocrática en otra, dependiendo del tamaño del equipo, la antigüedad de la base de código y cuánta revisión necesites.

Portabilidad – ¿Pueden vivir las especificaciones como markdown plano en tu repositorio y funcionar con el agente que prefieras el próximo trimestre? ¿O están atadas a un IDE, una nube o un formato propietario?

Fricción de configuración – ¿Cuánto tiempo toma desde “quiero probar SDD” hasta tener un ciclo funcional de especificar-planificar-tareas? El andamiaje CLI, la instalación del IDE o crear tus propios comandos de barra inclinada tienen diferentes energías de activación.

Calidad de la especificación – ¿La herramienta te ayuda a escribir requisitos y criterios de aceptación precisos, o simplemente genera documentos largos? La estructura es útil. El volumen, no tanto.

Ejecución de tareas – ¿Cómo divide la herramienta el trabajo en fragmentos revisables? ¿Pueden ejecutarse las tareas en paralelo? ¿Resiste a explosiones de listas de tareas con cincuenta ítems?

Puntos de control de revisión – ¿Hay puertas humanas naturales entre especificar, planificar, tareas e implementar? El SDD sin revisión es solo codificación por “vibe” (intuición) más lenta.

Anclaje al repositorio – ¿El flujo de trabajo lee las convenciones del proyecto, registros de decisiones, ADRs, AGENTS.md y el código existente antes de planificar? Los agentes sin anclaje reinventan la arquitectura porque nunca ven la intención revisada detrás de las decisiones anteriores.

Colaboración en equipo – ¿Pueden varias personas revisar los mismos artefactos de especificación en solicitudes de extracción (pull requests)? ¿Puedes mezclar agentes sin reescribir el proceso?

Dependencia (Lock-in) – ¿Qué pierdes si cambias de editor, modelo o proveedor de nube en seis meses?

GitHub Spec Kit

GitHub Spec Kit es un kit de herramientas CLI de código abierto que crea un ciclo guiado por especificaciones en tu repositorio y delega la ejecución al agente de codificación que ya uses. El CLI specify despliega plantillas, comandos de barra inclinada y una estructura de carpetas convencional. Los comandos típicos siguen una secuencia de constitución-especificar-clarificar-planificar-tareas-implementar, con un paso explícito de clarificación para resolver ambigüedades antes de que comience el trabajo de arquitectura.

La ventaja definitoria de Spec Kit es la independencia del agente. La documentación oficial lo posiciona como una herramienta que funciona con Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex y docenas de otros agentes. Escribes especificaciones una vez en markdown, las confirmas como código y cambias el ejecutor sin reescribir el proceso. Esto hace de Spec Kit la recomendación predeterminada para equipos que quieren SDD sin apostar por un solo proveedor.

Los contrapesos son reales. Spec Kit puede producir un árbol de artefactos grande: constitución, especificación, plan, tareas, contratos, lo que compensa en funcionalidades multi-sesión pero se siente pesado para un pequeño ajuste de CLI. Los hilos de Hacker News comparan regularmente esa sobrecarga con la ceremonia de cascada. Spec Kit también es más débil si buscas un IDE completamente integrado donde las especificaciones, tareas e implementación vivan en una superficie guiada. Capa el proceso sobre tu editor existente en lugar de reemplazarlo.

Spec Kit encaja en equipos que ya tienen un asistente de codificación con IA preferido y quieren un andamiaje SDD estandarizado encima. Es especialmente fuerte para funcionalidades desde cero (greenfield), equipos multi-agente y cualquiera que se niegue a atarse a un editor.

AWS Kiro

Kiro es el IDE guiado por especificaciones de AWS, construido sobre un fork de VS Code / Code OSS. Mientras Spec Kit trae el SDD a tu stack existente, Kiro asume que el SDD merece un entorno construido a medida. Un prompt genera artefactos estructurados: típicamente requirements.md en notación estilo EARS, design.md y un tasks.md secuenciado por dependencias, antes de que los agentes escriban código de producción.

La experiencia guiada es el principal punto de venta de Kiro. Los requisitos, el diseño y las tareas son objetos de interfaz de usuario de primera clase junto a tu código, no archivos que gestionas a través de un CLI separado. Kiro también incluye Agent Hooks, automatizaciones impulsadas por eventos que pueden actualizar pruebas, documentación o artefactos relacionados cuando la implementación cambia. Ese ciclo bidireccional es algo que Spec Kit no proporciona de forma nativa: las especificaciones de Spec Kit permanecen estáticas hasta que un humano las actualiza.

Los costos son la profundidad de la integración a cambio de la portabilidad. Kiro se ejecuta dentro de su editor, usa modelos respaldados por AWS Bedrock y factura a través de un modelo de precios basado en créditos con planes escalonados. Los equipos empresariales que ya usan infraestructura de AWS a menudo encuentran esto aceptable. Los desarrolladores solitarios y los equipos con múltiples editores quizás no. Kiro también tiene asperezas típicas de un IDE nuevo: compatibilidad de extensiones, sorpresas en el flujo de trabajo y la habitual pregunta de “¿realmente necesito otro editor?”.

Kiro encaja en desarrolladores que quieren la experiencia SDD más guiada y se sienten cómodos adoptando un IDE nativo de especificaciones. Es una opción sólida para equipos empresariales, entornos pesados en AWS y cualquiera que migre de Amazon Q Developer y quiera disciplina de especificaciones sin ensamblar la cadena de herramientas manualmente. Si hoy vives en VS Code estándar y te encanta tu configuración actual, Kiro pide un cambio mayor que Spec Kit.

Comandos Personalizados y Habilidades de Claude Code

Claude Code no lanza un único producto SDD oficial como lo hacen Spec Kit o Kiro. Si eres nuevo en la herramienta en sí, comienza con la guía de instalación y configuración de Claude Code para la configuración, permisos y backends locales. El patrón SDD en sí vive en comandos personalizados, habilidades y plantillas de markdown locales al repositorio que los desarrolladores mantienen. Anthropic incorporó los antiguos archivos .claude/commands/*.md en el mecanismo de Habilidades, por lo que el patrón duradero es un SKILL.md (o equivalente) que define tu lista de verificación de especificar-planificar-implementar, cargada bajo demanda.

Este enfoque es el más ligero y el más adaptable. Puedes portar una estructura de tres archivos estilo Kiro, reflejar las fases de Spec Kit con comandos de barra inclinada o inventar un flujo de trabajo mínimo que se ajuste a un solo repositorio. Claude Code lee CLAUDE.md para el contexto del proyecto siempre activo y extrae habilidades cuando la tarea coincide. Esa divulgación progresiva mantiene las sesiones enfocadas sin cargar una constitución completa en cada prompt.

El lado negativo es la disciplina. Nada te obliga a pasar por puertas de clarificación o revisión a menos que construyas esas puertas tú mismo. Los hilos de Reddit y Hacker News sobre “desarrollo guiado por especificaciones dentro de Claude Code” están llenos de desarrolladores que copiaron la habilidad de alguien más, la ejecutaron una vez y volvieron a la generación de prompts no estructurados cuando la habilidad se sintió lenta. El SDD de Claude Code funciona cuando tratas las habilidades como código: versionadas, revisadas y mantenidas, no como una descarga de prompt de un solo uso.

Para una implementación seria, lee Habilidades de Claude y SKILL.md para Desarrolladores y codifica tus fases como habilidades con puntos de control de revisión explícitos. El SDD de Claude Code es la elección correcta cuando ya vives en Claude Code, quieres máxima flexibilidad y mantendrás el flujo de trabajo tú mismo.

BMAD, OpenSpec y Otros Flujos de Trabajo

No todos los equipos quieren el árbol de artefactos de Spec Kit o el IDE de Kiro. Dos alternativas aparecen constantemente en las comparaciones de 2026.

OpenSpec (Fission AI) adopta un enfoque centrado en los cambios con menos archivos generados que Spec Kit. Los benchmarks de la comunidad reportan un uso de tokens materialmente menor para tareas comparables, a costa de tener menos estructura preliminar. OpenSpec tiende a ganar cuando estás modificando una base de código existente y quieres especificaciones revisables sin una fase de planificación de 800 líneas. Compite con Spec Kit en portabilidad más que con Kiro en integración de IDE.

BMAD-METHOD (comunidad) empuja en la dirección opuesta: flujos de trabajo multi-agente basados en roles que simulan personas de propietario del producto, arquitecto, desarrollador y revisor. BMAD puede ser poderoso en esfuerzos grandes desde cero donde la separación explícita de roles ayuda. También es pesado. Los equipos reportan frecuentemente que la ceremonia solo compensa cuando el dolor de coordinación ya es agudo.

Tessl trata la especificación como la fuente literal del código generado, marcando la salida como derivada y desaconsejando ediciones manuales. Esa es la postura más fuerte de “especificación-como-fuente” entre las herramientas principales, pero Tessl permanece en beta y conlleva la mayor dependencia del producto del grupo.

Spec Kitty y otros andamiajes de la comunidad se sitúan entre OpenSpec y Spec Kit en peso. Vale la pena observarlos si quieres plantillas sin adoptar toda la cadena de herramientas de GitHub.

El patrón a través de todos ellos es el mismo. Más proceso ayuda cuando la ambigüedad es costosa. Más proceso perjudica cuando la velocidad de retroalimentación importa más que la alineación. Adapta el peso de la herramienta al tamaño de la tarea, no al hype.

¿Qué Configuración de SDD Deberías Usar?

No hay un ganador universal. La configuración correcta depende de quién eres, qué estás construyendo y cuánta estructura realmente mantendrás.

Desarrollador solitario, base de código existente, funcionalidades pequeñas. Comienza con habilidades de Claude Code o OpenSpec. Escribe un bloque de requisitos corto, una lista de tareas mínima y un punto de control de revisión. No instales un árbol completo de Spec Kit para un cambio de cincuenta líneas.

Desarrollador solitario, funcionalidad desde cero, múltiples sesiones. Spec Kit o una habilidad SDD de Claude Code bien mantenida. Necesitas artefactos duraderos más que asistencia manual del IDE.

Equipo pequeño, editores mixtos. Spec Kit. Especificaciones de markdown plano en Git, revisadas en solicitudes de extracción, ejecutadas por el agente que prefiera cada desarrollador.

Equipo empresarial, nativo de AWS, presión de cumplimiento. Kiro. Artefactos guiados, trazabilidad de requisitos y hooks que mantienen la documentación y las pruebas más cerca de la implementación.

Entorno regulado. Kiro o Spec Kit más tu propia lista de verificación de validación: no solo habilidades de Claude Code a menos que codifiques puertas de cumplimiento explícitamente. Las herramientas no reemplazan las trazabilidades de auditoría. Solo las hacen más fáciles de producir.

Base de código existente, cambio en entorno existente (brownfield). OpenSpec o un flujo de trabajo ligero de Claude Code. La ceremonia completa de Spec Kit en cada corrección de errores se sentirá como cascada. Reserva estructuras más pesadas para funcionalidades transversales.

Producto desde cero, muchos agentes. Spec Kit. La portabilidad importa más que el pulido del IDE cuando Copilot, Claude Code y Cursor pueden tocar el mismo repositorio.

Los equipos que experimentan con orquestación multi-agente también deberían mirar Oh My OpenCode Agents para patrones sobre cómo dividir roles entre agentes: complementario a los artefactos SDD, no un reemplazo para ellos.

Tabla de Decisiones Prácticas

Qué Determina Realmente el Éxito

La elección de la herramienta importa menos que la calidad del artefacto. Un archivo de requisitos de Kiro con criterios de aceptación vagos producirá la misma desviación que un prompt de Claude Code descuidado. Un plan de Spec Kit que liste cincuenta tareas redundantes se sentirá como cascada, independientemente de qué agente lo implemente.

Las prácticas que viajan a través de cada configuración son aburridas y efectivas. Mantén las especificaciones lo suficientemente pequeñas para revisarlas en una sola sesión. Escribe los objetivos no deseados (non-goals) explícitamente. Divide las tareas en diferencias que un humano pueda leer. Valida contra los criterios de aceptación antes de fusionar. Actualiza la especificación cuando la implementación descubra un mejor camino.

Si aún estás eligiendo entre SDD y la generación de prompts no estructurada para una funcionalidad dada, lee Desarrollo Guiado por Especificaciones vs Codificación por Vibe. La comparación de herramientas en este artículo solo importa una vez que has decidido que la funcionalidad merece una especificación en absoluto.

Las malas especificaciones hacen que cada agente sea peor. Las buenas especificaciones viajan entre herramientas.

Conclusión

GitHub Spec Kit, Kiro y los flujos de trabajo de Claude Code son tres respuestas a la misma pregunta: ¿cómo mantienes alineados a los agentes de IA a través de las sesiones? Con diferentes apuestas sobre portabilidad versus integración. Spec Kit optimiza para markdown agnóstico al agente en tu repositorio. Kiro optimiza para un IDE nativo de especificaciones guiado con agentes respaldados por AWS. Las habilidades de Claude Code optimizan para flujos de trabajo adaptables y ligeros que solo tienen éxito cuando los mantienes tú.

Elige la configuración más superficial que aún elimine la ambigüedad para la funcionalidad en cuestión. Añade estructura cuando aparezca el dolor de coordinación, no cuando una entrada de blog te lo diga. Los desarrolladores que obtienen valor del SDD en 2026 no son aquellos con la cadena de herramientas más elaborada. Son aquellos que escriben especificaciones dignas de implementar y luego dejan que la herramienta que eligieron ejecute contra ellas.

Enlaces Útiles

• Documentación de GitHub Spec Kit – referencia oficial del flujo de trabajo de Spec Kit
• Martin Fowler sobre herramientas SDD – análisis de Kiro, Spec Kit y Tessl