Contexto Técnico
No veo a SpecKit y OpenSpec como "simplemente otras dos CLI", sino como un intento de estandarizar la conversación entre el humano, el repositorio y el asistente de código. En ambos enfoques el núcleo es el mismo: fijamos la intención en spec.md, mantenemos las reglas del juego en constitution.md (o análogos), y luego forzamos al asistente a trabajar dentro de estos límites, en lugar de improvisar.
Lo que me gusta de SpecKit (github/spec-kit) como arquitecto es que piensa en fases y disciplina al equipo. En un escenario típico, tiene un comando de nivel /specify que genera un paquete de artefactos bastante voluminoso (especificación, principios, descomposición de tareas, verificaciones). Sí, pueden ser cientos de líneas, pero es precisamente ese caso donde la "verbosidad" reduce el coste de errores en la arquitectura temprana, especialmente en monorepos *greenfield*.
OpenSpec tiene un enfoque diferente: lo veo como un mecanismo conveniente de propuestas de cambio iterativas para código ya vivo. La lógica de "proponer cambio → aplicar → archivar como fuente única de verdad" encaja bien en proyectos *brownfield* y en equipos que no están listos para pasar por una fase pesada de diseño previo cada vez. Técnicamente, esto se traduce en una estructura de carpetas de cambios y varios comandos de IA que ayudan a aplicar la especificación al código.
Pero coincido totalmente con el feedback práctico de la comunidad: ambos toolkits aún no son "nativos para agentes". No tienen una comprensión nativa de multi-repositorios, no hay un modelo integrado para pasar la misma funcionalidad por una cadena de subagentes, ni mecanismos integrados como modo de plan/subagentes. Son agnósticos al agente, y en eso radica su fuerza para flujos simples y su debilidad para los complejos.
- SpecKit se siente mejor en monorepos, donde se pueden autocrear ramas, mantener estándares estrictos y verificar dependencias de tareas.
- OpenSpec gana donde se necesita realizar una serie de cambios de manera rápida y ordenada, sin convertir cada uno en un "miniproyecto de una semana".
- Para sistemas avanzados de agentes de IA, ambos requieren orquestación externa: prompts separados, roles, comandos y reglas de traspaso (*handoff*).
Impacto en Negocio y Automatización
En mis proyectos, la implementación de SDD casi siempre se amortiza no por la "belleza de los documentos", sino por la reducción de reconstrucciones y conflictos en el equipo. Si desarrollas soluciones de IA para empresas, el principal dolor no es la velocidad de generación de código, sino la gobernabilidad de los cambios: quién tomó la decisión, dónde se fijaron las asunciones y cómo verificamos el resultado.
SpecKit y OpenSpec ayudan precisamente aquí: crean un contrato entre producto, arquitectura e implementación. En la práctica, veo tres efectos rápidos:
- Revisiones más estables: no discutimos sobre "por qué el asistente lo escribió así", sino sobre "qué pedimos en spec.md".
- Onboarding más sencillo: un nuevo desarrollador lee la constitución/spec y entra en contexto más rápido.
- Menos regresiones: cuando las verificaciones y los criterios de aceptación están en texto explícito, al asistente le cuesta más "tomar atajos".
¿Quién gana con SpecKit/OpenSpec ahora mismo? Equipos que construyen un producto nuevo en un solo repositorio, quieren disciplina y están dispuestos a invertir una o dos horas en una especificación normal antes de la implementación. Pierden aquellos que esperan un "piloto automático": instalar la CLI no hará que la fábrica de agentes distribuya mágicamente las funcionalidades por servicios, repositorios y entornos.
Si hablamos de automatización mediante IA dentro del desarrollo, estas herramientas son más sobre semiautomatización gestionada. En ellas, el humano sigue siendo el despachador. Y personalmente considero esto una ventaja para el negocio: la responsabilidad y el control permanecen en el equipo, no en la "magia" del agente.
En Nahornyi AI Lab, suelo implementar estos toolkits no "tal cual", sino como parte de la arquitectura del proceso: añado plantillas de dominio, reglas de nomenclatura, políticas de prueba, límites de migración y requisitos de registro/observabilidad. Sin esto, SpecKit/OpenSpec se convierten simplemente en otro formato markdown que dejan de actualizar al mes.
Visión Estratégica y Análisis Profundo
Mi conclusión principal para 2026: SpecKit y OpenSpec son una buena base para SDD, pero aún no resuelven el problema clave de los proyectos agénticos: la gestión del contexto y la transferencia de responsabilidad entre partes del sistema. En el desarrollo "normal", bastan las especificaciones y tareas. En sistemas agénticos, se necesita también un modelo operativo: roles de agentes, protocolos de traspaso, política de memoria, criterios de parada y perímetros de seguridad.
Por eso, cada vez construyo más híbridos: tomo sus artefactos como "esqueleto" (spec/constitution/tasks) y construyo encima una capa de comandos y habilidades para el proyecto concreto. En esencia, armo un "kit de comandos" interno para el equipo y el asistente: cómo planificamos, cómo descomponemos, cómo definimos interfaces, cómo realizamos migraciones y cómo validamos. Esta es la verdadera arquitectura de soluciones de IA a nivel de proceso, y no solo a nivel de microservicios.
Destaco aparte un cuello de botella que surge casi siempre: multi-repo e integraciones. El negocio rara vez vive en un monorepo ideal. Hay un ERP, hay 1–3 servicios, hay una aplicación móvil y hay un repositorio de infraestructura. Los toolkits SDD orientados a un solo repositorio empiezan a "perder fuerza": la especificación existe, pero la sincronización de cambios entre repositorios sigue siendo manual. En ese momento, o introduces orquestación (scripts, procesos CI, reglas de PR) o te pasas a frameworks más agénticos donde el multi-repo es ciudadano de primera clase.
Mi pronóstico es simple: no ganará el "agente más inteligente", sino el stack más práctico que se pueda actualizar cada semana sin dolor. Y aquí, el conjunto personalizado de prompts/comandos del que hablan los profesionales a menudo resulta más maduro que una herramienta en crudo. El *hype* termina rápido; la utilidad permanece donde hay disciplina de especificaciones y reglas claras de ejecución.
Si deseas elegir un enfoque SDD para tu producto y no perderte en un stack inmaduro, te invito a discutir el contexto de tu equipo y repositorios. Escribe a Nahornyi AI Lab; la consultoría la realizaré personalmente yo, Vadym Nahornyi, y propondré una arquitectura de proceso adaptada a tus objetivos, riesgos y plazos.