Contexto técnico
Observé este debate como un profesional en la materia y no como un espectador: el mercado claramente se dirige hacia el desarrollo basado en especificaciones (SDD). Sin embargo, aún no existe un stack maduro centrado en una sola herramienta, sino más bien en una combinación de enfoques. En el uso real, SpecKit, Claude Code con el comando /plan y el archivo CLAUDE.md suelen destacar como la capa fundamental para la gestión del contexto.
Noté un detalle crucial: openspec y get-shit-done aún parecen ser herramientas de nicho o inmaduras en este ámbito, mientras que SpecKit ya se ha convertido en el estándar de facto. La razón es simple: ofrece una estructura de SDD muy clara (constitución, especificación, desglose de tareas, validación) que puede integrarse en el proceso de ingeniería, y no solo mostrarse en una demo.
También le veo un lado negativo a las especificaciones. SpecKit consume muchos tokens porque hace pasar al modelo por varias fases: principios, especificación, descomposición, y luego código y pruebas. En características complejas, esto se convierte rápidamente en un embudo de contexto costoso, especialmente si se integran modelos potentes como Claude Opus o equivalentes con alta capacidad de razonamiento.
Por eso estoy muy de acuerdo con la idea expuesta en el debate de que "las especificaciones son pruebas". Cuando diseño arquitecturas de IA, casi siempre intento vincular la especificación a un artefacto verificable: pruebas, contratos de API, criterios de aceptación o esquemas de datos. De lo contrario, el equipo solo obtiene un documento bonito en lugar de una entrega controlable.
Impacto en el negocio y la automatización
Desde el punto de vista empresarial, no veo esto como un flujo de trabajo de moda, sino como un cambio en el modelo de gestión del desarrollo. El SDD es rentable allí donde el costo del error es alto: plataformas internas, productos B2B multimodulares, entornos de integración y procesos regulados. En estos casos, la integración de la IA funciona mejor cuando el modelo no "escribe código por inspiración", sino que sigue una especificación predefinida.
¿Quién gana? Los equipos con una sólida disciplina de ingeniería que ya tienen reglas arquitectónicas, CI/CD, una estrategia de pruebas y un responsable del producto. ¿Quién pierde? Aquellos que quieren implementar la automatización con IA sobre un código heredado caótico, sin límites claros en el sistema y sin una persona que mantenga la arquitectura.
Según mi experiencia en Nahornyi AI Lab, el principal error al integrar inteligencia artificial en el desarrollo es intentar automatizar la generación de código antes de definir los invariantes del sistema. Cuando esto ocurre, CLAUDE.md crece desproporcionadamente, /plan empieza a generar pasos demasiado genéricos y el gasto de tokens camufla la falta de soluciones. Por fuera parece que el agente trabaja, pero por dentro la deuda técnica se acumula.
Por lo tanto, yo no vendería el SDD como un sustituto universal del desarrollo tradicional. Lo vendería como una integración gestionada por IA dentro del ciclo de ingeniería: para proyectos greenfield, características de gran tamaño, módulos con contratos claros y equipos dispuestos a pagar por la previsibilidad.
Visión estratégica y análisis profundo
Creo que la siguiente fase del SDD no será "aún más especificaciones", sino una compresión de contexto mucho más estricta. El stack ganador no será el que escriba las especificaciones más largas, sino el que sepa dividir el sistema en límites de dominio pequeños, proporcionarle al agente solo las reglas necesarias y devolver el resultado a la arquitectura principal sin expandir el contexto.
Es precisamente aquí donde Claude Code con /plan y un CLAUDE.md bien organizado resulta a menudo más práctico que un framework pesado y universal. Ya he visto este patrón en proyectos de Nahornyi AI Lab: un manifiesto arquitectónico breve, paquetes de tareas muy delimitados, pruebas que actúan como especificaciones y subagentes separados para contextos limitados. Esto ofrece el mejor equilibrio entre calidad, velocidad y costo.
Mi predicción es sencilla: el SDD llegó para quedarse, pero en su forma madura se fusionará con la arquitectura de IA, donde la especificación ya no será un simple documento, sino un contrato ejecutable. Para las empresas, estas son excelentes noticias, ya que significa que el desarrollo de soluciones de IA pasará de una improvisación costosa a un enfoque de producción predecible y repetible.
Este análisis fue elaborado por mí, Vadym Nahornyi, experto principal en Nahornyi AI Lab especializado en arquitectura de IA, automatización y aplicación práctica de IA en empresas reales. Si desea saber si el SDD es adecuado para su producto, cómo reducir el consumo de tokens y cómo diseñar una arquitectura sin caos, lo invito a discutir su proyecto conmigo y con el equipo de Nahornyi AI Lab.