OpenSpec vs Spec Kit: Cómo Elegir un Framework Basado en Especificaciones para el Desarrollo con Agentes de IA

Los agentes de IA de codificación escriben código más rápido que cualquier humano. El cuello de botella ha cambiado: la especificación es ahora el producto. Si su agente no tiene una especificación clara y estructurada desde la cual trabajar, alucina arquitectura, inventa requisitos y produce código que pasa pruebas que nadie pidió.

Han surgido dos frameworks para resolver esto: OpenSpec (~28k estrellas en GitHub) y GitHub Spec Kit (~75k estrellas). Ambos tienen licencia MIT. Ambos generan comandos slash que los agentes de IA consumen directamente. Pero hacen compensaciones fundamentalmente diferentes entre velocidad y gobierno — y elegir el equivocado le cuesta a su equipo semanas de retrabajo.

Aquí le mostramos cómo elegir.

La División Fundamental: Iteración Fluida vs. Gobierno Estructurado

OpenSpec es un CLI de Node.js (@fission-ai/openspec) que trata las especificaciones como artefactos ligeros nativos del repositorio. Organiza el trabajo en carpetas de cambio que contienen archivos de propuesta, especificaciones, diseño y tareas. La filosofía es ceremonia mínima — poner una especificación frente al agente rápido, iterar, archivar cuando termine.

Spec Kit (el framework de GitHub, centrado en el CLI specify y los comandos /speckit.*) ancla todo a una constitución — un documento a nivel de proyecto que codifica restricciones, estándares de codificación, requisitos de TDD y reglas de cumplimiento. Cada funcionalidad fluye a través de un pipeline de fases estructurado con plantillas y listas de verificación en cada puerta.

La diferencia no es cosmética. Determina cuánta sobrecarga absorbe su equipo por funcionalidad, cuánto contexto consumen sus agentes por indicación y si su pista de auditoría satisface a los revisores de cumplimiento.

Comparación de Flujos de Trabajo

OpenSpec: Cuatro Comandos, Mínima Fricción

El flujo de trabajo de OpenSpec es intencionalmente corto:

graph LR
    A["/opsx:propose"] --> B["/opsx:explore"]
    B --> C["/opsx:apply"]
    C --> D["/opsx:archive"]

1. /opsx:propose — Crear una carpeta de cambio con un documento de propuesta
2. /opsx:explore — Iterar sobre especificaciones y diseño dentro de esa carpeta
3. /opsx:apply — Ejecutar la implementación basada en las especificaciones finalizadas
4. /opsx:archive — Mover el trabajo completado al archivo

Eso es todo. Sin constitución. Sin fase de aclaración obligatoria. Sin puerta de desglose de tareas. Propone, explora, aplica, archiva. Si necesita volver de aplicar a explorar, simplemente lo hace — no hay una puerta de fase que se lo impida.

OpenSpec impone un límite de contexto de 50KB para evitar la hinchazón de indicaciones. Esta es una decisión de diseño deliberada: los agentes que trabajan con especificaciones de OpenSpec no se ahogarán en ventanas de contexto sobredimensionadas, lo que importa cuando ejecuta múltiples agentes en un monorepositorio.

Spec Kit: Seis Fases, Anclado a la Constitución

El pipeline de Spec Kit es más extenso:

graph LR
    A["/speckit.constitution"] --> B["/speckit.specify"]
    B --> C["/speckit.clarify"]
    C --> D["/speckit.plan"]
    D --> E["/speckit.tasks"]
    E --> F["/speckit.implement"]
    G["/speckit.analyze"] -.-> B

1. /speckit.constitution — Definir reglas, restricciones y estándares de todo el proyecto
2. /speckit.specify — Crear una especificación detallada de funcionalidad
3. /speckit.clarify — Resolver ambigüedades y preguntas abiertas
4. /speckit.plan — Generar un plan de implementación
5. /speckit.tasks — Dividir el plan en tareas discretas y asignables
6. /speckit.implement — Ejecutar tareas con puertas TDD y validación de listas de verificación
7. /speckit.analyze (opcional) — Analizar código existente antes de especificar cambios

La constitución es el diferenciador clave. Es un documento vivo que todos los comandos posteriores respetan. Si su constitución dice “todos los cambios de base de datos requieren scripts de migración” o “sin llamadas directas a API sin lógica de reintento”, el agente aplica esas reglas en cada fase. Para industrias reguladas — salud, finanzas, gobierno — este es exactamente el mecanismo que necesita para codificar requisitos de cumplimiento en el propio flujo de trabajo de desarrollo.

Comparación Directa

El Problema del Impuesto de Contexto

El poder de Spec Kit tiene un costo. Cada comando slash instalado, cada plantilla, cada regla constitucional añade tokens a la ventana de contexto del agente. Los equipos que ejecutan Spec Kit con múltiples extensiones reportan un impuesto de contexto significativo — el agente gasta tokens analizando instrucciones del framework en lugar de razonar sobre su código.

Esto importa a escala. Si está ejecutando Claude Code o Codex contra una base de código grande con el conjunto completo de comandos de Spec Kit cargado, está quemando contexto en sobrecarga del framework. Algunos equipos han reportado la necesidad de podar extensiones o dividir constituciones para mantenerse dentro de presupuestos de tokens prácticos.

OpenSpec evita esto con su límite de contexto de 50KB. Es un instrumento contundente — no puede codificar la misma profundidad de gobierno — pero mantiene a los agentes enfocados en la especificación real en lugar de metadatos del framework.

Conclusión empresarial: Si sus agentes ya están restringidos en contexto (bases de código grandes, indicaciones de sistema complejas, cambios de múltiples archivos), mida el costo en tokens del conjunto de comandos de Spec Kit antes de comprometerse. El techo de OpenSpec es más bajo pero predecible.

Cuándo Usar OpenSpec

Elija OpenSpec cuando:

• Esté haciendo prototipado rápido o trabajo de prueba de concepto donde la velocidad importa más que el proceso
• Su equipo use múltiples herramientas de agentes de IA y quiera una capa de especificación única y ligera que funcione con todas ellas
• Necesite iterar sobre la marcha — cambiar especificaciones después de que la implementación haya comenzado sin luchar contra puertas de fase
• Su base de código sea lo suficientemente grande como para que el presupuesto de contexto sea una restricción real
• Quiera desarrollo basado en especificaciones sin adoptar un marco de gobierno completo

El perfil “core” de OpenSpec es el punto de entrada de menor fricción al desarrollo de IA basado en especificaciones. Instale el CLI, cree una carpeta de cambio y su agente tendrá especificaciones estructuradas desde las cuales trabajar. Sin constitución que escribir, sin catálogo de extensiones que curar.

Cuándo Usar Spec Kit

Elija Spec Kit cuando:

• Esté construyendo sistemas de producción donde el gobierno y la repetibilidad justifiquen la sobrecarga
• Su organización opere en un dominio regulado (salud, finanzas, gobierno) y necesite reglas de cumplimiento codificadas en el flujo de trabajo de desarrollo
• Quiera la aplicación de TDD incorporada en el framework, no añadida después
• Su equipo se beneficie de puertas de fase estructuradas — aclaración antes de la planificación, planificación antes de la implementación
• Necesite extensibilidad mediante hooks y catálogos de extensiones curados para flujos de trabajo específicos de la organización

El modelo de constitución de Spec Kit es genuinamente poderoso para contextos empresariales. Codificar “cada endpoint de API requiere documentación OpenAPI” o “todas las mutaciones de estado requieren event sourcing” como reglas constitucionales significa que el agente las aplica automáticamente, cada vez. Eso no es teatro de gobierno — es gobierno que realmente se ejecuta.

Enfoque Híbrido: Empiece Ligero, Añada Estructura

Estos frameworks no son mutuamente excluyentes en filosofía. Un camino práctico para muchos equipos empresariales:

1. Empiece con OpenSpec para exploración inicial y prototipado. Establezca el hábito de las especificaciones sin la sobrecarga.
2. Pase a Spec Kit cuando el proyecto avance a producción y necesite gobierno, codificación de cumplimiento y flujos de trabajo de fases repetibles.
3. Mantenga OpenSpec para proyectos secundarios, herramientas internas y experimentos rápidos donde la ceremonia de Spec Kit lo ralentizaría.

El peor resultado es ningún framework de especificaciones en absoluto — agentes trabajando a partir de indicaciones vagas, produciendo código que nadie revisó contra requisitos que nadie documentó.

Conclusiones Accionables

1. El desarrollo basado en especificaciones ya no es opcional. Si sus agentes de IA no tienen especificaciones estructuradas, está depurando requisitos alucinados. Elija un framework.

2. Mida su presupuesto de contexto primero. Ejecute su agente con el conjunto completo de comandos de Spec Kit cargado y verifique cuántos tokens van a la sobrecarga del framework. Si es más del 15-20% de su ventana de contexto, considere OpenSpec o una configuración recortada de Spec Kit.

3. Para industrias reguladas, la constitución de Spec Kit se paga sola. Codificar reglas de cumplimiento que los agentes apliquen automáticamente vale la sobrecarga adicional de artefactos. La alternativa es la revisión manual de cada cambio generado por el agente para el cumplimiento normativo.

4. Para prototipado rápido, OpenSpec gana en velocidad. Cuatro comandos, límite de contexto de 50KB, sin constitución que mantener. Ponga especificaciones frente a los agentes rápido.

5. No omita el paso de archivo/limpieza. Ambos frameworks soportan el archivo de trabajo completado. Las especificaciones obsoletas en su repositorio confunden a los agentes en ejecuciones futuras. Archive agresivamente.

6. Evalúe ambos contra su stack real. Clone el repositorio de ejemplo de cada framework, ejecútelo contra su base de código con su agente de IA preferido y compare la calidad de salida y los costos en tokens. La elección correcta depende de las necesidades de gobierno de su equipo, no del conteo de estrellas en GitHub.