Serie: Openspec (2/6)
Por Qué el Desarrollo con IA Sin Especificaciones Siempre Termina Costando Más
Le pides a la IA que agregue una funcionalidad. Empieza a escribir. Se ve bien. Pero cuando lo ejecutas, algo no está bien. Dos revisiones después sigue estando mal. Para la tercera apenas lo tienes bien — y para entonces has quemado toda una tarde. Esto no es culpa del modelo, y no es que tu prompt no haya sido suficientemente bueno. El problema es que nadie se sentó antes de empezar el trabajo y escribió "qué construir, qué no construir, y cómo se ve cuando está terminado."
La IA Trabaja Duro — Pero No Tiene una Pista de Despegue
Los agentes son incansables — ese no es el problema. El problema es que su razonamiento solo puede trabajar con lo que proporcionas en la conversación. Dices "agrega modo oscuro," y lo implementa según lo que entiende. Pero no sabe si quieres un simple intercambio de variables CSS o un sistema de temas completo, si localStorage debería persistir la preferencia, o si tu biblioteca de componentes ya tiene un mecanismo de temas incorporado.
Sin claridad, adivina. Y cuando adivina, terminas mirando lo que construyó y diciendo: "No, no, eso no era lo que quería."
Luego empiezas de nuevo.
Los Requisitos que Solo Viven en el Chat Tienen una Vida Útil Corta
Hay otro escenario doloroso — una decisión de diseño que alineaste con la IA la semana pasada ha desaparecido completamente cuando abres una nueva conversación esta semana. Todo el entendimiento compartido que construiste en esa sesión anterior se ha esfumado. Tienes que explicarlo de nuevo desde cero, o esperar que lo recuerdes y lo pegues tú mismo.
Este es el efecto secundario de tener los requisitos solo en el chat. Las conversaciones se evaporan; las especificaciones persisten. Sin especificaciones, cada conversación está reconstruyendo una base cognitiva que desaparecerá.
Qué Resuelve OpenSpec
OpenSpec no es otro formato de documento de requisitos. Es más bien un mecanismo para darle a los agentes una pista de despegue por donde correr:
- Alinear primero, luego construir — Tú y la IA llegan a un acuerdo sobre "qué construir" antes de que se escriba cualquier código
- Cada cambio tiene su propia carpeta — propuesta, especificación, diseño y tareas viven juntos, no dispersos en el historial del chat
- Fluido, no rígido — Los artefactos se pueden actualizar en cualquier momento; sin bloqueo rígido de fases
- Funciona con las herramientas que ya usas — Compatible con más de 20 asistentes de codificación con IA y se ejecuta mediante slash commands
Comparado con las herramientas tradicionales de gestión de especificaciones, es más ligero. Comparado con no escribir nada, aporta estabilidad — no una garantía, pero una reducción significativa en la probabilidad de "construimos lo incorrecto y solo lo descubrimos al final."
Sus Cuatro Filosofías Fundamentales
Vale la pena tenerlas en mente, porque estos cuatro principios explican por qué OpenSpec está diseñado de la manera en que lo está:
Fluido, no rígido
Sin bloqueo de fases. Una propuesta puede ser revisada después de ser escrita; un diseño puede ser reexaminado durante la implementación; una especificación puede ser actualizada cuando se descubren problemas durante la codificación. Esto no es una invitación al caos — es reconocer la realidad. Solo comprendes verdaderamente los requisitos cuando los implementas.
Iterativo, no en cascada
No requiere que descubras cada detalle antes de empezar. Te permite ir llenando los vacíos sobre la marcha. El objetivo es "un punto de partida compartido," no "planificación perfecta desde el principio."
Simple, no complejo
Un comando para inicializar, tres slash commands para el flujo de trabajo principal. No hay nueva sintaxis ni toolchain que aprender.
Brownfield primero
No es solo para proyectos nuevos. La mayor parte del tiempo estás haciendo cambios a una base de código existente — el diseño de delta spec de OpenSpec fue construido exactamente para eso.
Entonces, ¿Cuándo Es el Momento Correcto para Empezar?
No necesitas esperar un proyecto grande. Pruébalo la próxima vez que estés agregando una funcionalidad a un proyecto personal. Los diez minutos que pasas en /opsx:propose casi con certeza ahorrarán más tiempo que corregir una implementación incorrecta después. Cuanto mayor sea la escala y más personas involucradas, más claro será el beneficio — pero incluso trabajando solo, eliminar un ciclo de "construí en la dirección incorrecta y tuve que rehacerlo" lo hace valer.