Review de OpenSpec: mi nuevo daily driver para AI coding

Review de OpenSpec: mi nuevo daily driver para AI coding

La primera vez que ejecuté openspec apply en un proyecto real, me alejé para volver a llenar mi café y lo olvidé. Dos horas y diecisiete minutos más tarde, volví a un panel de control en funcionamiento, un conjunto de pruebas aprobadas y una carpeta changes/ llena de rebajas que explicaban, con un nivel de detalle que nunca habría escrito a mano, exactamente lo que se acababa de crear y por qué.

Esa no es la parte impresionante. Lo impresionante es lo que sucedió a la mañana siguiente cuando necesitaba agregar una segunda función. No abrí el código. Abrí la carpeta de especificaciones. Leí tres archivos breves de rebajas. Y supe, con un tipo de claridad que normalmente solo obtengo después de una semana de carga de contexto, exactamente dónde debería conectarse la nueva función y qué tocaría.

En ese momento comprendí lo que realmente está haciendo OpenSpec AI coding framework y por qué creo que es la primera herramienta spec-driven que sobrevive al contacto con mi flujo de trabajo real.

Lo he estado ejecutando como mi daily driver durante dos semanas en tres proyectos: una herramienta de administración de Laravel que estoy refactorizando para un cliente, un proyecto paralelo de Next.js que comencé desde cero y una base de código Python existente que heredé y que tiene aproximadamente la higiene de la documentación de una nota de rehén. OpenSpec se ganó su lugar en los tres. Pero no por las razones que enumeran las páginas de marketing.

Este es el desglose completo: qué es OpenSpec, dónde se ubica en el panorama de AI coding framework, los comandos exactos que ejecuto y los lugares honestos donde no ayuda. Si ya ha pasado horas viendo una sesión Claude Code generar código según una especificación que era incorrecta desde el principio, las próximas 4000 palabras le resultarán personales.

Las tres categorías de marcos de AI coding (y por qué son importantes)

Antes de que OpenSpec tenga sentido, necesitas el mapa del territorio en el que vive. Cometí este error la primera vez que lo evalué: lo comparé con herramientas que nunca intentó superar y casi lo descarto por razones equivocadas.

Hay tres categorías distintas de envíos de AI coding framework en 2026 y resuelven diferentes problemas:

Estas categorías no compiten cara a cara. Se apilan.

Una pila de producción real se parece más a: OpenSpec escribe la especificación, Obra Superpowers aplica TDD durante la compilación, BMAD organiza la canalización multi-agent que envía PR mientras duermes. El mismo problema desde tres ángulos. Diferentes capas de una misma máquina.

Donde la mayoría de los artículos "spec-driven vs autónomo" salen mal es al tratarlos como alternativas. No lo son. Son niveles. Y OpenSpec es el nivel inferior, el que decide en qué trabajarán los otros dos niveles.

Es por eso que conseguir esta capa correctamente es más importante que las capas superiores. Una habilidad de aplicación de TDD perfecta no le salvará si la especificación que está aplicando fue incorrecta desde el primer día. Un canal autónomo que envía 40 RP en un sprint simplemente enviará 40 RP incorrectos. La calidad de las especificaciones es el punto de estrangulamiento ascendente. Todo lo demás amplifica cualquier decisión que se haya tomado allí, para bien o para mal.

Entonces la pregunta no es "¿OpenSpec o BMAD?" La pregunta es "¿OpenSpec es lo suficientemente bueno como para ser la fuente de verdad en la que todo el mundo confía?" Eso es lo que fui a probar.

Qué es realmente OpenSpec

OpenSpec es un marco de desarrollo spec-driven de código abierto, enviado como el paquete npm @fission-ai/openspec y mantenido por Fission-AI. Se ejecuta en cualquier proyecto como una capa delgada sobre su asistente de AI coding: Claude Code, Cursor, Codex, Windsurf, Continuar, GitHub Copilot, Amazon Q y alrededor de veinte otros según el documento de herramientas compatibles.

La idea central es brutal en su simplicidad. La especificación es el artefacto. El código es el destino de la compilación. Cada característica reside en un archivo de rebajas en su repositorio antes de que se escriba una sola línea de código, y ese archivo se convierte en el contrato que ejecutan los asistentes AI.

Tres cosas acerca de esa idea importan más que la idea misma.

Primero, las especificaciones se encuentran en su repositorio. No en un panel SaaS. No en un documento Notion que cambia en el momento en que alguien presiona "enviarlo". En una carpeta openspec/, en git, con diferencias que puedes revisar en PR como cualquier otro cambio de código. Esta es la parte que la mayoría de los equipos subestiman hasta que necesitan reconstruir lo que se suponía que debía hacer una característica seis meses después. Con OpenSpec, usted git log cumple con las especificaciones.

En segundo lugar, las especificaciones son deltas. OpenSpec inventó algo que no he visto bien hecho en ningún otro marco: la propuesta no es un documento nuevo, es un cambio respecto de la especificación existente. Cada propuesta etiqueta explícitamente adiciones, modificaciones y eliminaciones. Cuando se envía el cambio, los deltas se fusionan en la especificación maestra. Esta es la magia del brownfield: así es como OpenSpec permanece utilizable en bases de código heredadas en lugar de obligarte a crear una aplicación de 200,000 líneas para usarlo.

En tercer lugar, el flujo de trabajo es fluido, no en cascada. El marco oficial de Fission-AI es "fluido, no rígido, iterativo, no en cascada", y después de dos semanas puedo confirmar que eso no es marketing. Puede ingresar al flujo de trabajo en cualquier fase, puede retroceder cuando la implementación revela algo que la especificación omitió y puede ejecutar archive para confirmar un cambio parcial y comenzar uno nuevo. Se siente menos como un proceso y más como un cuaderno que refuerza la estructura.

La comparación más clara es el [Kit de especificaciones] de GitHub (https://github.com/github/spec-kit). Probé ambos. Spec Kit es más pesado: sus especificaciones tienen alrededor de 800 líneas por función según el trabajo de comparación publicado por Hashrocket, frente a las aproximadamente 250 de OpenSpec. Spec Kit trata cada función como su propio archivo independiente. OpenSpec se consolida en una única fuente viva de verdad que muta con el tiempo. Para una función empresarial totalmente nueva y limpia con puertas de revisión formales, el mayor rendimiento del Spec Kit está justificado. Para todo lo demás que hago (refactorizaciones, proyectos paralelos, trabajo con clientes de agencias), la huella más ligera de OpenSpec gana porque la especificación es algo que realmente volveré a leer.

Ésa es la capa filosófica. Así es como se ve ejecutarlo en la práctica.

Instalación de OpenSpec y la experiencia de primera ejecución

La configuración es un comando. No "un comando después de instalar tres dependencias". Un comando.

npm install -g @fission-ai/openspec
cd your-project
openspec init

Se requiere el nodo 20.19.0 o superior. El comando init le pregunta qué asistente AI está utilizando (elegí Claude Code en el proyecto Laravel, Cursor en Next.js, Codex en el código base de Python) y escribe los enlaces de comando de barra apropiados en la configuración de su proyecto para que el asistente sepa cómo invocar OpenSpec.

Aquí es donde noté lo primero que me hizo confiar en la herramienta. En un inicio nuevo, OpenSpec no lo deja frente a un documento en blanco y le dice "buena suerte". Ejecuta una habilidad de incorporación que lo guía a través de su primera propuesta de manera interactiva. Te pregunta qué estás construyendo. Pregunta quién es el usuario. Pregunta cuáles son los criterios de éxito. Hace esto en rebajas que se encuentran en su repositorio, por lo que el primer artefacto que tiene no es un tutorial, es el comienzo de una especificación real para una característica real.

Compare eso con mi experiencia comenzando con Spec Kit. La incorporación del kit de especificaciones supone que ya conoce el modelo de cuatro fases (/specify, /plan, /tasks, /implement) y lo lleva directamente al paso /specify. Si no ha utilizado el desarrollo spec-driven antes, escribe una especificación que tiene una forma incorrecta y descubre tres comandos más tarde cuando /tasks produce tonterías.

La incorporación de OpenSpec marca la diferencia entre aprender leyendo y aprender haciendo lo correcto la primera vez. Es un pequeño detalle. Es también la razón por la que ahora recomendé OpenSpec a dos amigos que nunca antes habían tocado el desarrollo de spec-driven.

La Referencia de Comandos: Qué Hace Cada Uno y Cuándo Lo Uso

OpenSpec se entrega con un conjunto de comandos básico y un conjunto de comandos ampliado llamado opsx al que puede optar a través de openspec config profile. He estado ejecutando el perfil ampliado porque quiero todas las herramientas que ofrece el marco. Aquí está la tabla completa, con el uso real de cada uno en producción:

| /openspec:apply | Implementar las tareas definidas en la propuesta | La fase de construcción: se ejecuta ~2 horas de forma autónoma, de 3 a 4 horas con mis interrupciones | | /opsx:verify | Validar la implementación según las especificaciones, incluidas comprobaciones visuales de la interfaz de usuario mediante la integración de Chrome | Migraciones de sistemas de diseño, funciones de interfaz de usuario pesadas | | /openspec:archive | Fusionar los deltas de cambio en la especificación maestra, comprometer la fuente viva de la verdad | Todas las funciones enviadas, sin excepciones | | /opsx:bulk-archive | Archive varios cambios completados en una sola pasada | Fin de un sprint cuando envié de 3 a 5 funciones | | /opsx:sync | Sincronice la carpeta de especificaciones maestras con lo que realmente hay en el código base | Cuando sospecho que hay una deriva entre el código y las especificaciones | | /opsx:onboard | Vuelva a ejecutar la habilidad de incorporación interactiva | Incorporar un compañero de equipo o un nuevo proyecto al flujo de trabajo OpenSpec |

La lista completa de comandos se encuentra en el [documento de comandos OpenSpec] oficial (https://github.com/Fission-AI/OpenSpec/blob/main/docs/commands.md), y la referencia de perfil ampliada se encuentra en el doc. opsx. Lo que no está en los documentos es el orden en que los ejecuto o cuáles me salto, y esa es la siguiente sección.

El flujo de trabajo que realmente ejecuto

Esta es la secuencia exacta que seguí al incluir una función de "cronología de actividad del usuario" en la herramienta de administración de Laravel la semana pasada. Todo esto tomó aproximadamente cuatro horas de reloj de pared, de las cuales tal vez cuarenta minutos fui yo y el resto fue OpenSpec trabajando en segundo plano.

Paso 1: Explora antes de proponer

El primer comando que ejecuto en cualquier cambio superior a "trivial" es /opsx:explore. Esta es la característica más subestimada del marco, y es lo único que hace OpenSpec que el kit de especificaciones GitHub se niega explícitamente a hacer.

El diseño del kit de especificaciones supone que ingresas a /specify sabiendo lo que quieres construir. Según mi experiencia, esa suposición es errónea aproximadamente el 70% de las veces. Lo que normalmente tengo es una idea confusa, tres limitaciones que recuerdo a medias y el presentimiento de que hay una complicación que todavía no he descubierto. Si escribo una especificación desde ese estado, la especificación será incorrecta y lo descubriré cuatro pasos más tarde.

/opsx:explore me da una fase para equivocarme en voz alta. El agente me hace preguntas aclaratorias. Investiga el código base. Saca a la luz ambigüedades que no sabía que existían. En la función de línea de tiempo de actividad, la exploración captó tres cosas que habría pasado por alto si hubiera saltado directamente a una propuesta: la tabla de registro de auditoría existente tenía una ambigüedad de columna que habría causado colisiones de consultas, dos de mis "acciones de usuario" eran en realidad dos eventos diferentes que había estado colapsando mentalmente, y el requisito de la interfaz de usuario implicaba un componente en tiempo real que no había presupuestado.

Son aproximadamente dos días de reelaboración que la exploración evitó en quince minutos.

Si soy honesto, casi nunca usé /opsx:explore durante los primeros tres días. Se sentía como si estuviera encima. Luego lo probé en una refactorización que resultó tener una dependencia oculta en una capa de caché obsoleta y no lo he omitido desde entonces. El patrón que he internalizado: si no puedo explicar el cambio en una oración sin reservas, primero ejecuto explore.

Paso 2: proponer, continuar o avanzar rápidamente

Una vez que la exploración ha despejado la niebla, ejecuto uno de tres comandos según el tamaño del cambio:

• /openspec:propose para cambios pequeños y con un alcance bien definido donde quiero que todo se genere en una sola pasada.
• /opsx:continue para cambios más importantes, quiero dividirlos en secciones verticales: primero la propuesta, luego las especificaciones y luego las tareas, con una puerta de revisión entre cada una.
• /opsx:ff cuando la exploración fue exhaustiva y quiero que OpenSpec avance rápidamente por los pasos restantes de la propuesta/spec/tasks sin tener que hacer clic en cada puerta.

El resultado de cualquiera de estos es el mismo: una carpeta changes/[change-name]/ que contiene proposal.md (el por qué y el qué), design.md (el cómo, incluido el diseño del sistema), uno o más archivos en specs/ (los escenarios funcionales que actúan como contrato) y tasks.md (el desglose del trabajo que ejecutará el asistente).

Este es el momento en el flujo de trabajo donde la especificación deja de ser mía y pasa a ser del equipo. Incluso si el equipo soy solo yo. La propuesta es revisable en un PR. design.md captura las decisiones arquitectónicas en un lenguaje que un futuro yo pueda entender. La carpeta specs/ es la parte que el asistente AI tratará como contrato durante la implementación y, lo que es más importante, es la parte que sobrevive al cambio y se fusiona con la especificación maestra en el archivo.

Una nota sobre lo que hace que las especificaciones del OpenSpec sean diferentes. Cada especificación describe escenarios funcionales, dadas narrativas de estilo /when/then que describen el comportamiento. No detalles de implementación. No "el controlador llama al repositorio". Comportamiento. Esta es la forma que sobrevive a los cambios del código base. Cuando refactorice la capa de persistencia dentro de seis meses, la especificación sigue siendo correcta porque la especificación nunca se refirió a cómo funcionaba la capa de persistencia. Se trataba de lo que el usuario veía y podía hacer.

Paso 3: Aplicar (o: Cómo dejé de ver la compilación)

/openspec:apply es el comando que crea la característica. Aquí es donde reside la mayor parte del tiempo de ejecución: alrededor de dos horas de trabajo autónomo en la función de línea de tiempo de actividad, de tres a cuatro horas cuando interrumpo para aclarar cosas a mitad de la compilación.

Lo que tuve que aprender aquí es cuándo interrumpir y cuándo alejarme. Mi primer instinto fue cuidar la fase de aplicación como cuido una sesión Claude Code: leer cada diferencia, aprobar cada cambio de archivo, cuestionar cada decisión. Ese instinto está mal con OpenSpec. La especificación ya codificaba mis decisiones. La fase de solicitud es simplemente la ejecución del contrato. Si me encuentro con ganas de interrumpir para "tomar una decisión diferente", la decisión correcta casi siempre es detener la solicitud, volver a la propuesta, corregir las especificaciones y volver a presentar la solicitud.

Una vez que internalicé eso, comencé a dejar la fase de aplicación ejecutándose en segundo plano mientras trabajaba en otra cosa. Pestaña abierta, terminal visible, pero no lo estoy mirando. La primera vez que hice esto fue incómodo. La quinta vez, fue el patrón normal. La décima vez, me sorprendí habiendo enviado dos funciones en paralelo ejecutando aplicar en dos terminales frente a dos propuestas diferentes.

Este es el momento que cambió mi modelo mental de AI coding. El cuello de botella dejó de ser la ejecución. Se convirtió en calidad de especificación. Lo que significa que mi tiempo comenzó a dedicarse a la parte del trabajo que realmente requiere juicio humano, y el resto pasó al agente.

Paso 4: Verificar (la característica asesina subestimada)

/opsx:verify es el comando del que nadie habla y es el que hizo que OpenSpec fuera irremplazable en el proyecto paralelo Next.js.

El proyecto Next.js implicó migrar un sistema de diseño antiguo a uno nuevo: mismos componentes, nuevos tokens, nueva escala de espaciado, nueva tipografía. Esta es una clase de trabajo de pesadilla para las herramientas de AI coding porque el código puede ser técnicamente correcto y visualmente completamente incorrecto. Un botón puede renderizar. Un botón también puede renderizarse con el tamaño incorrecto, con la fuente incorrecta, con el radio de borde incorrecto y pasar todas las pruebas que haya escrito.

/opsx:verify se entrega con una integración de extensión de Chrome que realiza comprobaciones de fidelidad visual según las especificaciones. Carga la página, captura el estado renderizado y lo compara con la intención del diseño codificada en la especificación. En la migración del sistema de diseño, detectó siete regresiones visuales que el conjunto de pruebas omitió. Inconsistencias de espaciado. Un peso de fuente incorrecto en una variante de título. Un componente que había heredado un margen del antiguo sistema y estaba desbordando su celda de la cuadrícula en ciertos puntos de interrupción.

Esta es la característica que no existe en ningún otro AI coding framework que haya probado. El kit de especificaciones no lo tiene. BMAD no lo tiene. Obra Superpowers puede exigir que usted haya escrito pruebas, pero no puede indicarle que la prueba se aprobó mientras la página se vea incorrecta. Para trabajos pesados ​​de UI, especialmente migraciones de sistemas de diseño, /opsx:verify es la diferencia entre enviar y enviar correctamente.

La advertencia honesta: no es magia. La extensión de Chrome necesita que su servidor de desarrollo esté en ejecución. Las comprobaciones visuales son tan buenas como la intención del diseño que codificó en la especificación. Y no puede detectar errores de interacción, sólo problemas de representación estática. Pero para la clase de errores que detecta, nada más lo hace.

Paso 5: Archivar (El truco de la documentación viva)

Este es el paso que casi me salté la primera semana. También es el paso que silenciosamente es el más importante.

/openspec:archive toma el cambio que acaba de enviar y fusiona sus deltas en la carpeta maestra specs/. La propuesta se mueve a un directorio changes/archive/. La especificación maestra, la fuente viva de la verdad, fusiona la nueva funcionalidad, aplica las modificaciones y elimina las eliminaciones.

El resultado es que después de cada función enviada, su repositorio contiene una descripción actual, precisa y legible por máquina de cómo se comporta todo el sistema. No es un README desactualizado. Ni una página de Confluence que no haya sido tocada en dieciocho meses. El estado actual real.

Probé lo que esto significa seis días después de usar OpenSpec pidiéndole a Claude Code que agregue una nueva característica al proyecto Laravel, sin darle ningún contexto. Le dije: "lea openspec/specs/, luego proponga un cambio que agregue X". Leyó las especificaciones. Propuso un cambio que identificó correctamente dos características existentes con las que necesitaría interactuar. Hizo esto sin que yo le preguntara sobre la arquitectura del código base, porque la arquitectura ya estaba en la especificación.

Esta es la primera vez que veo que la "documentación viva" en realidad es una parte de carga de un flujo de trabajo de AI coding en lugar de algo agradable de tener. En la mayoría de los proyectos, dedica los primeros cinco minutos de cada sesión de Claude Code a recargar el contexto. Con OpenSpec, el contexto se carga solo.

Si archive alguna vez se siente sobrecargado, puedo prometerle que no lo es. Saltarse el archivo es como se pudren los proyectos spec-driven. Todos los equipos con los que he hablado sobre el desarrollo abandonado de spec-driven lo hicieron porque sus especificaciones se desviaron de su código. El archivo es la disciplina que evita la deriva. Trátelo como parte de la "función terminada", no como un paso de limpieza opcional.

Dónde OpenSpec se queda corto (La sección honesta)

Llevo dos semanas y soy un fan, pero un fan que ha ejecutado esto en tres proyectos con formas muy diferentes. Aquí es donde no ayuda.

Pequeños cambios. Si el cambio es "corregir este error tipográfico" o "cambiar el nombre de esta variable", el flujo de trabajo OpenSpec está sobrecargado. No ejecute una propuesta para una solución de una sola línea. El marco no pretende lo contrario (Fission-AI lo recomienda explícitamente), pero he visto a los recién llegados forzar cada cambio a través del flujo de la propuesta y terminar con una carpeta changes/ que parece un cementerio de relaciones públicas triviales. Utilice OpenSpec para cosas en las que se beneficia que se piense en ellas. Sáltelo para las cosas que no lo hacen.

Sesiones de codificación en solitario en las que realmente no sabes lo que quieres. Si estás en modo de exploración pura (dibujar, crear prototipos, lanzar código a la pared), la fase de propuesta te ralentizará. El patrón correcto aquí es codificar vibe primero, luego, una vez que sepa lo que ha creado, escriba la especificación retroactivamente y archive como la primera propuesta. OpenSpec está bien con este flujo. Pero intentar especificar algo que aún no has diseñado es lo peor de ambos mundos.

El tiempo de ejecución de la aplicación de dos horas es real. La mayoría de las ejecuciones de aplicación duran entre 90 y 180 minutos para funciones no triviales. Si necesita que se envíe una función en veinte minutos, OpenSpec no es la herramienta adecuada. Esto no es un defecto: la calidad de las especificaciones es lo que hace que la fase de aplicación sea confiable, y esa calidad requiere tiempo para codificarse y ejecutarse. Pero gestiona tus expectativas. OpenSpec es una herramienta para realizar envíos correctos, no envíos rápidos.

La incorporación de Brownfield tiene aspectos ásperos. En el código base de Python heredado, mi primer intento de introducir OpenSpec resultó en una especificación maestra que tenía aproximadamente un 40 % de precisión con respecto al código real. El marco intentaba inferir especificaciones a partir de un código que no tenía ningún principio rector, y las inferencias eran necesariamente confusas. La solución fue ejecutar /opsx:onboard correctamente, tomarse el tiempo para escribir la especificación maestra a mano para los flujos principales y luego usar OpenSpec para nuevos cambios. Si llega esperando colocar OpenSpec en una base de código heredada y hacer que comprenda la base de código antes del viernes, se sentirá decepcionado. Planifique una semana de incorporación real.

La comunidad es pequeña. En comparación con la presencia de GitHub de BMAD o el respaldo empresarial de Spec Kit, OpenSpec es el ecosistema más pequeño. Los documentos son buenos. La cadencia de liberación es saludable. Pero todavía no existe una gran cantidad de tutoriales, complementos o integraciones de terceros. Si necesita algo que el marco no hace de forma nativa, lo escribirá usted mismo. Para mí, esto está bien (prefiero tener una herramienta pequeña y enfocada que una grande e inflada), pero vale la pena saberlo.

Dónde encaja OpenSpec en mi pila ahora

Después de dos semanas, OpenSpec se encuentra en la parte superior de mi flujo de trabajo de AI coding: encima de Claude Code, encima de las habilidades del agente que ejecuto, encima de las notas de planificación que solía guardar en Obsidian. Es lo primero que toco en un cambio no trivial y lo último que toco al enviarlo.

La pila completa se ve así:

1. OpenSpec escribe y mantiene la especificación: el contrato para lo que se está construyendo
2. Claude Code con Obra Superpowers ejecuta la especificación con aplicación de TDD durante la fase de aplicación
3. Revisión de git estándar detecta lo que TDD omitió
4. Archivar bloquea el cambio en la especificación viva, listo para la siguiente iteración

Cada herramienta hace lo que mejor hace. OpenSpec no intenta imponer TDD; ese es el trabajo de Superpowers. Superpowers no intenta gestionar las especificaciones: ese es el trabajo de OpenSpec. Claude Code no intenta recordar todo lo que se ha creado; ese es el trabajo de la especificación maestra.

Esta separación de preocupaciones es lo que hace que la pila realmente escale. Cuando algo se rompe, sé qué capa depurar. Cuando quiero actualizar una pieza, puedo cambiarla sin reconstruir las demás. La componibilidad es la victoria.

¿Debería utilizar OpenSpec?

Tres preguntas para responder honestamente:

¿Ofrecen funciones que requieren más de dos horas de trabajo concentrado? En caso afirmativo, OpenSpec se amortiza con la segunda función. Si solo envías microcambios, omítelo.

¿Alguna vez regresas a un proyecto después de dos semanas y necesitas recargar el contexto? En caso afirmativo, la especificación viva te ahorrará horas cada mes. Si todos tus proyectos están actualizados y tu memoria es perfecta, el valor es menor.

¿Confías más en tu asistente AI cuando tiene un contrato claro para ejecutar? En caso afirmativo, OpenSpec es la capa de contrato. Si prefiere simplemente charlar con el asistente y guiarlo paso a paso, el flujo de propuestas se sentirá como una fricción.

Respondí que sí a las tres y OpenSpec ha sido la incorporación más importante a mi flujo de trabajo desde que comencé a usar Claude Code. No porque haga algo dramáticamente mejor que las alternativas, sino porque hace que todas las demás herramientas de mi pila sean más confiables. La especificación es el punto de estrangulamiento aguas arriba. OpenSpec limpió el cuello de botella.

Preguntas frecuentes

¿Para qué se utiliza OpenSpec?

OpenSpec es un marco de desarrollo spec-driven para los asistentes de AI coding. Usted escribe una especificación de reducción de una característica y el marco se coordina con su asistente AI (Claude Code, Cursor, Codex y más de 20 personas más) para implementar la especificación, validar el resultado y fusionar el cambio en una fuente viva de verdad. Se usa más para funciones medianas y grandes en bases de código antiguas donde la calidad de las especificaciones tiene un valor compuesto.

¿En qué se diferencia OpenSpec del kit de especificaciones GitHub?

OpenSpec consolida las especificaciones en un único documento vivo con cambios basados ​​en delta, mientras que Spec Kit mantiene archivos de especificaciones separados por característica. OpenSpec produce especificaciones más ligeras (alrededor de 250 líneas frente a las 800 del kit de especificaciones), admite bases de código antiguas de forma nativa y ofrece un flujo de trabajo iterativo con la fase /opsx:explore. El modelo de cuatro fases más pesado de Spec Kit se adapta mejor al trabajo empresarial formal totalmente nuevo. Para obtener un desglose más profundo, consulte "Qué es realmente OpenSpec" más arriba.

¿OpenSpec funciona con Claude Code?

Sí, Claude Code es uno de los más de 20 asistentes de AI coding compatibles. Durante openspec init, selecciona Claude Code como su asistente y OpenSpec escribe los enlaces de comando de barra correspondientes en su proyecto. Cursor, Codex, Windsurf, Continuar, GitHub Copilot, Amazon Q, Gemini CLI y otros también son totalmente compatibles.

¿Cuánto tiempo dura una ejecución de aplicación de OpenSpec?

Una ejecución típica de openspec apply dura entre 90 y 180 minutos para funciones no triviales cuando se ejecuta de forma autónoma. Agregar puntos de control humanos y aclaraciones a mitad de construcción extiende esto a 3-4 horas de tiempo de reloj de pared. La mayor parte de ese tiempo el asistente AI está funcionando, no esperando; puede dejarlo ejecutándose en segundo plano mientras trabaja en otra cosa.

¿Puede OpenSpec reemplazar BMAD u Obra Superpowers?

No, y no deberías intentar hacerlo. OpenSpec es un marco spec-driven. BMAD es un orquestador de tuberías autónomo. Obra Superpowers es una capa de aplicación de SDLC. Resuelven diferentes problemas y se combinan bien: OpenSpec escribe la especificación, Superpowers aplica TDD durante la compilación, BMAD organiza canalizaciones de funciones múltiples. Para obtener un desglose completo de estas tres categorías, consulte la tabla comparativa cerca de la parte superior de este artículo.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Cartera: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io