Metodologías de Ingeniería Agéntica: Superpowers vs OpenSpec

Lectura previa recomendada: Desarrollo Guiado por Especificaciones con IA Agéntica · Paradigmas Alternativos en Ingeniería de Software con IA · Análisis Profundo de Frameworks SDD

Cuando comencé a incorporar agentes de programación con IA en mi flujo de trabajo diario para ArceApps, la fase de luna de miel no duró mucho. Al principio, parecía magia: dejabas un prompt en el chat, veías cómo el código brotaba de la nada y le dabas a commit. Pero a medida que las aplicaciones crecían en complejidad, también lo hacía la fricción. Los agentes alucinaban decisiones arquitectónicas, sobrescribían abstracciones perfectamente válidas con implementaciones ingenuas y, lo peor de todo, rompían comportamientos existentes en silencio porque carecían del contexto general de lo que estaba intentando construir.

El problema central no era la capacidad de razonamiento del LLM; era la falta de una metodología estructurada. No dejaríamos suelto a un desarrollador junior en una base de código de producción sin una especificación técnica, un plan claro y un proceso de revisión de código. Sin embargo, habitualmente esperamos que los agentes de IA intuyan mágicamente nuestra intención arquitectónica a partir de un prompt de tres frases.

Esta realización condujo al auge del Desarrollo Guiado por Especificaciones (SDD) y los frameworks agénticos. En un artículo anterior, analicé GitHub Spec Kit, OpenSpec y BMAD-METHOD. Hoy quiero enfrentar a dos de los enfoques más fascinantes: Superpowers y OpenSpec.

Ambas herramientas pretenden resolver el mismo problema —mantener a los agentes de IA alineados y evitar el colapso de contexto—, pero lo abordan desde ángulos filosóficos completamente diferentes. Superpowers es una metodología prescriptiva basada en habilidades que impone prácticas de ingeniería estrictas como el Desarrollo Guiado por Pruebas (TDD). OpenSpec, por otro lado, es un flujo de trabajo guiado por artefactos que se centra en crear documentación viva antes de escribir cualquier código.

En este análisis profundo, exploraremos cómo funcionan estos frameworks bajo el capó, compararemos sus filosofías y discutiremos cuál podría encajar mejor en tu flujo de trabajo como desarrollador independiente. Como solo dev que construye proyectos en noches y fines de semana, mi tolerancia por el código repetitivo (boilerplate) y la ceremonia burocrática es increíblemente baja. Necesito herramientas que amplifiquen mi intención, no sistemas que me conviertan en un gestor de proyectos para mis propios proyectos paralelos. Veamos cómo se comparan estos dos.

La Evolución de la Programación con IA: Del Chat a la Metodología

Antes de comparar los frameworks específicos, necesitamos entender la evolución de cómo interactuamos con los agentes de IA.

Generación 1: La Era del Copiloto

La primera generación fue el autocompletado de código en línea. Escribías un comentario y la IA sugería las siguientes líneas. Era útil para el boilerplate, pero no cambiaba fundamentalmente la forma en que se diseñaba el software. El contexto se limitaba al archivo activo y quizás a algunas pestañas abiertas.

Generación 2: La Era del Chat

La segunda generación llevó la interfaz de chat al IDE. Podías resaltar un bloque de código y pedir a la IA que lo refactorizara, o pegar un mensaje de error y pedir una solución. Esto fue un gran salto adelante, pero todavía dependía del desarrollador para mantener todo el modelo mental de la aplicación en su cabeza. La IA era un becario inteligente al que tenías que microgestionar.

Generación 3: La Era Agéntica

Ahora estamos en la tercera generación, donde herramientas como Claude Code, Cursor y OpenCode pueden ejecutar tareas complejas en múltiples archivos. Pueden ejecutar comandos de terminal, leer logs y modificar la base de código de forma autónoma. Pero con este poder viene una nueva clase de problemas. Cuando a un agente se le da libertad para vagar por un repositorio, fácilmente puede perder de vista el objetivo original. Podría refactorizar una clase de utilidad central mientras intenta arreglar un error menor de UI, provocando fallos en cascada.

Aquí es donde las metodologías se vuelven críticas. Al igual que Agile y Scrum proporcionaron estructura a los equipos humanos, ahora necesitamos frameworks para la colaboración humano-IA. El objetivo es restringir la autonomía del agente dentro de límites definidos, asegurando que sus acciones estén alineadas con nuestra intención.

Esto nos lleva a Superpowers y OpenSpec. Ambos son respuestas al caos de la programación agéntica sin restricciones, pero representan dos filosofías distintas: el enfoque Orientado a Procesos (Superpowers) frente al enfoque Orientado a Artefactos (OpenSpec).

Superpowers: La Metodología Orientada a Procesos

Superpowers, desarrollado por Jesse Vincent y el equipo de Prime Radiant, se describe a sí mismo como “una metodología de desarrollo de software completa para tus agentes de programación”.

Si tuviera que resumir Superpowers en una sola frase, sería: “Hazlo bien, o no lo hagas en absoluto.”

La Filosofía Central

Superpowers es profundamente obstinado. No solo quiere ayudarte a escribir código más rápido; quiere obligarte a escribir código mejor. Actúa casi como un mentor senior estricto que mira por encima del hombro de tu agente, imponiendo rigurosos estándares de ingeniería.

El framework está construido sobre un conjunto de “habilidades” (skills) componibles que se activan automáticamente según el contexto de la conversación. Estas habilidades no son solo prompts; son flujos de trabajo ejecutables que guían al agente a través de fases específicas del desarrollo.

La característica definitoria de Superpowers es su insistencia absoluta e intransigente en el Desarrollo Guiado por Pruebas (TDD). Se refiere literalmente a esto como “La Ley de Hierro”: No hay código de producción sin una prueba que falle primero. Si el agente intenta escribir código de implementación antes que una prueba, la metodología le indica que borre el código y empiece de nuevo. Para un desarrollador independiente acostumbrado a montar cosas rápidamente a altas horas de la noche, este nivel de disciplina puede resultar chocante, pero es innegablemente efectivo para prevenir regresiones.

Las Fases del Flujo de Trabajo

Cuando inicias una tarea con un agente habilitado para Superpowers, no solo obtienes código. Obtienes un proceso estructurado:

1. Lluvia de ideas (Brainstorming): Antes de escribir una sola línea, el agente se detiene y hace preguntas. Refina ideas en bruto, explora alternativas y presenta un documento de diseño en trozos digeribles para tu validación. Esto previene la “prisa por implementar” que a menudo plaga las interacciones con la IA.
2. Uso de Git Worktrees: Una vez aprobado el diseño, Superpowers impone aislamiento. Crea un git worktree dedicado en una rama nueva, asegurando una línea base de pruebas limpia. Esto significa que el agente no está contaminando tu espacio de trabajo principal con código experimental.
3. Redacción de Planes: El agente desglosa el diseño validado en tareas pequeñas, que normalmente tardan de 2 a 5 minutos cada una. Cada tarea en el plan incluye rutas de archivo exactas, el código a escribir y los pasos de verificación necesarios para demostrar que funciona.
4. Desarrollo Guiado por Subagentes (SDD): Aquí es donde Superpowers realmente brilla. En lugar de ejecutar todo el plan en una sola y masiva ventana de contexto, despacha nuevos subagentes para cada tarea individual. Esta es una solución brillante al colapso de contexto. Cada subagente solo sabe de su tarea específica, evitando que se confunda con pasos anteriores o código no relacionado.
5. Desarrollo Guiado por Pruebas (TDD): Como se mencionó, esto se ejecuta concurrentemente con la implementación. El agente debe escribir una prueba que falle, ver cómo falla, escribir el código mínimo para hacer que pase y luego hacer el commit.
6. Revisión de Código: Entre tareas, un agente de revisión separado actúa como una puerta de calidad, comprobando la implementación contra el plan y reportando problemas por severidad. Los problemas críticos bloquean el progreso hasta que se resuelven.
7. Finalización: Una vez que todas las tareas están completas, el agente verifica toda la suite de pruebas, presenta opciones para fusionar o crear una PR, y limpia el worktree.

Lo Bueno, Lo Malo y Lo Estricto

Lo que me encanta de Superpowers: El aislamiento proporcionado por los subagentes y los git worktrees es fenomenal. Trata a los agentes de IA como tratamos al código modular: pequeño, enfocado y verificable independientemente. La estricta adherencia a TDD, aunque a veces frustrante cuando solo quieres prototipar, resulta en un código notablemente estable. Realmente se siente como trabajar con un equipo de ingeniería disciplinado en lugar de un motor de autocompletado caótico.

Los puntos de fricción: Superpowers es pesado. Es una metodología entera impuesta sobre tu flujo de trabajo. Si solo quieres un script rápido o un ajuste de CSS, las fases de lluvia de ideas y planificación se sienten como una exageración masiva. Además, depende en gran medida de las capacidades del entorno base del agente (como Claude Code o Codex CLI). Si el entorno no soporta subagentes de manera robusta, toda la metodología recae en un modo de ejecución secuencial mucho menos efectivo, que puede consumir rápidamente las ventanas de contexto.

OpenSpec: El Flujo de Trabajo Guiado por Artefactos

Mientras que Superpowers se centra en un proceso estricto y en barandillas de ejecución, OpenSpec toma una ruta fundamentalmente diferente. Desarrollado por Fission AI, OpenSpec es un flujo de trabajo guiado por artefactos.

Si Superpowers es un ingeniero senior estricto imponiendo TDD, OpenSpec es un pragmático Technical Product Manager ayudándote a escribir una especificación clara antes de pasársela al equipo de desarrollo.

La Filosofía Central

OpenSpec se basa en cuatro principios:

1. Fluido, no rígido: No hay puertas de fase estrictas. Puedes trabajar en lo que tenga sentido en un momento dado.
2. Iterativo, no en cascada: Aprendes mientras construyes y refinas la especificación sobre la marcha.
3. Fácil, no complejo: Presume de una configuración ligera y una ceremonia mínima.
4. Brownfield primero: Está diseñado explícitamente para trabajar con bases de código existentes, centrándose en especificar cambios en lugar de describir sistemas enteros desde cero.

A diferencia de la pesada metodología de Superpowers, OpenSpec opera mediante comandos de barra (ej., /opsx:propose, /opsx:apply) dentro de la interfaz de chat de tu asistente de programación. Actúa como una capa ligera sobre tu flujo de trabajo existente en lugar de reemplazarlo por completo.

El Ciclo de Vida del Artefacto

OpenSpec organiza tu trabajo en artefactos distintos controlados por versiones, almacenados en un directorio dedicado openspec/ en la raíz de tu proyecto. El flujo de trabajo gira en torno a la creación y refinamiento de estos documentos:

1. La Fuente de la Verdad (specs/): Este directorio contiene la documentación viva de cómo funciona tu sistema actualmente.
2. La Propuesta (changes/<change-name>/): Cuando quieres construir una nueva funcionalidad, ejecutas /opsx:propose <feature-name>. OpenSpec no escribe código; genera una carpeta estructurada para el cambio que contiene:
   • proposal.md: Por qué estamos haciendo esto y qué está cambiando.
   • specs/: “Especificaciones delta” que definen los requisitos y escenarios específicos para esta funcionalidad.
   • design.md: El enfoque técnico y la arquitectura.
   • tasks.md: La lista de verificación de implementación.

Este paso es crucial. Tú y la IA os alineáis en estos documentos markdown. Los revisas, los editas manualmente si es necesario y te aseguras de que el agente entienda perfectamente la intención antes de avanzar.

3. Implementación (/opsx:apply): Una vez aprobados los artefactos, ordenas al agente que implemente las tareas definidas en tasks.md. El agente utiliza las especificaciones delta y los documentos de diseño como su contexto, reduciendo las alucinaciones.
4. Sincronización y Archivado (/opsx:sync, /opsx:archive): Después de que el código se escribe y verifica, OpenSpec fusiona las especificaciones delta de nuevo en la fuente principal de la verdad (specs/) y archiva la propuesta de cambio, manteniendo tu documentación perfectamente actualizada con tu base de código.

Lo Bueno, Lo Malo y Lo Fluido

Lo que me encanta de OpenSpec: OpenSpec es increíblemente respetuoso con el tiempo del desarrollador y el flujo de trabajo existente. El enfoque “brownfield primero” es un soplo de aire fresco; la mayor parte de mi tiempo lo paso modificando ArceApps, no empezando desde astro new. Al obligar a la IA a generar un design.md y tasks.md primero, obtengo un contrato claro y legible de lo que tiene intención de hacer. Si el diseño es incorrecto, arreglo el archivo markdown, no el código. Reduce drásticamente la “rotación de IA” de generar código, darse cuenta de que está mal, e intentar hacer prompts para volver a encarrilarlo.

Los puntos de fricción: OpenSpec proporciona los artefactos, pero no impone estrictamente cómo ocurre la implementación. A diferencia de Superpowers, no obligará al agente a escribir pruebas primero, ni despachará inherentemente subagentes paralelos (aunque teóricamente podrías combinar los artefactos de OpenSpec con un entorno capaz de manejar subagentes). Si tu agente se vuelve rebelde durante la fase /opsx:apply e ignora el tasks.md, OpenSpec no tiene los ganchos profundos de proceso para detenerlo, dependiendo enteramente de la adherencia del agente subyacente a las instrucciones.

Comparación Cara a Cara

Para entender verdaderamente qué framework se adapta a tu estilo, comparemos cómo manejan las etapas críticas del desarrollo de software.

1. Planificación y Gestión del Contexto

Superpowers gestiona el contexto a través de la conversación y de rigurosas habilidades de planificación. Se basa en gran medida en la capacidad del agente para entrevistarte, extraer los requisitos y formular un plan dinámicamente. El plan es un estado efímero dentro de la memoria activa del agente o en archivos temporales.

OpenSpec externaliza el contexto en archivos markdown duraderos. El plan es un conjunto concreto de artefactos (proposal.md, design.md, tasks.md). Esto significa que el contexto está controlado por versiones, es fácilmente legible por humanos y se puede pausar y reanudar días después sin perder el estado.

El ganador aquí depende de la preferencia. Si quieres que la IA gestione el proceso internamente, Superpowers es más fluido. Si quieres documentos explícitos y revisables que actúen como contratos, OpenSpec es superior.

2. Ejecución e Implementación

OpenSpec le dice al agente qué hacer (a través de tasks.md) pero en gran medida deja el cómo al comportamiento predeterminado del agente. Es un traspaso: “Aquí está la especificación, ve a construirlo.”

Superpowers dicta exactamente cómo se escribe el código. Impone el ciclo TDD Rojo-Verde-Refactorizar, exige el aislamiento del git worktree y utiliza una compleja arquitectura de subagentes para ejecutar tareas de forma independiente. Es una ejecución altamente estructurada.

Superpowers gana la fase de ejecución sin lugar a dudas. Su uso de subagentes para prevenir la contaminación del contexto durante la implementación es un cambio de juego para funcionalidades complejas.

3. Flexibilidad vs. Rigidez

OpenSpec abraza la fluidez. Si estás a mitad de la implementación y te das cuenta de que el diseño necesita un ajuste, simplemente editas el design.md y continúas. No te fuerza a pasar por estrictas puertas de fase.

Superpowers es rígido por diseño. “Violar la letra de las reglas es violar el espíritu de las reglas”, dice su documentación. Si intentas saltarte escribir una prueba, peleará contigo. Si intentas acortar la fase de planificación, se resistirá.

Para indie hackers y prototipado rápido, la flexibilidad de OpenSpec es mucho más complaciente. Para infraestructura de misión crítica donde la estabilidad es primordial, la rigidez de Superpowers es una característica, no un error.

El Veredicto del Desarrollador Indie

Entonces, ¿cuál estoy adoptando para ArceApps?

La realidad de ser un desarrollador independiente es que tienes horas limitadas. Necesitas herramientas que maximicen tu apalancamiento sin empantanarte en ceremonias a nivel empresarial.

Si estoy construyendo un servicio backend aislado y altamente complejo —digamos, un nuevo flujo de autenticación o un script crítico de migración de datos— quiero Superpowers. La garantía de TDD y la seguridad del aislamiento de los subagentes valen la inversión inicial en conversación y planificación. Actúa como el riguroso programador en pareja que no tengo.

Sin embargo, para el 80% de mi trabajo diario —añadir nuevos componentes de UI al portafolio en Astro, escribir artículos para el blog, ajustar estilos de Tailwind o implementar funciones CRUD estándar— OpenSpec es el claro ganador. Su enfoque de “brownfield primero” se adapta perfectamente a cómo trabajo en realidad. Me encanta poder ejecutar /opsx:propose add-dark-mode, revisar un archivo markdown limpiamente generado que detalla exactamente qué variables CSS se tocarán, y luego aprobar la implementación. Proporciona justo la estructura suficiente para prevenir alucinaciones sin sentirse como una camisa de fuerza.

¿El Stack Definitivo?

El santo grial de la ingeniería agéntica podría no ser elegir entre ellos, sino combinar sus fortalezas. Imagina un flujo de trabajo donde uses OpenSpec para generar los artefactos duraderos y controlados por versiones (design.md, tasks.md), y luego entregues esas tareas exactas a un orquestador de subagentes estilo Superpowers que imponga TDD durante la ejecución de cada tarea específica.

Aún estamos en los primeros días del Desarrollo Guiado por Especificaciones. Tanto Superpowers como OpenSpec son intentos brillantes de domar el caos de la programación con LLMs. Demuestran que el futuro de la ingeniería con IA no se trata solo de mejores modelos; se trata de mejores metodologías.

A medida que avanzamos hacia 2026, los desarrolladores que prosperen no serán los que puedan escribir los prompts más rápidos. Serán aquellos que sepan cómo diseñar especificaciones claras y orquestar agentes de manera efectiva dentro de frameworks estructurados. Ya sea que te inclines por la estricta disciplina de Superpowers o la documentación fluida de OpenSpec, adoptar una metodología estructurada es la única manera de escalar tus esfuerzos de desarrollo en solitario sin perder la cordura.

Un Análisis Técnico Más Profundo: Integración con Herramientas Existentes

Para apreciar completamente la divergencia entre estos dos frameworks, debemos observar cómo se integran con el ecosistema existente del desarrollador. Esto no se trata solo de filosofía abstracta; se trata de lo que sucede en tu terminal y en tu IDE.

Superpowers: La Dependencia del Entorno (Harness)

Superpowers es fundamentalmente un conjunto de técnicas avanzadas de ingeniería de prompts y scripts de flujo de trabajo que deben inyectarse en un entorno o “harness” de agente existente. Soporta explícitamente herramientas como Claude Code, Codex CLI, Cursor y GitHub Copilot CLI.

La integración se basa en el concepto de “Habilidades” (Skills). Cuando instalas Superpowers en Claude Code, por ejemplo, esencialmente estás cargando una biblioteca de comportamientos predefinidos (test-driven-development, subagent-driven-development, writing-plans). El framework depende del LLM subyacente para reconocer el contexto de tu solicitud y activar autónomamente la habilidad adecuada.

Esto crea una experiencia sumamente mágica cuando funciona a la perfección. Dices, “Necesito arreglar el bug de autenticación”, y el agente decide autónomamente activar la habilidad systematic-debugging, te hace preguntas de sondeo, formula una hipótesis, crea un git worktree, escribe una prueba que falla y soluciona el error.

Sin embargo, esta profunda integración tiene una desventaja significativa: Dependencia Frágil del Entorno. Si Claude Code actualiza su prompt del sistema interno, o si el comportamiento del LLM sufre deriva (drift), los mecanismos de activación de las habilidades de Superpowers pueden romperse. El framework está luchando constantemente contra las tendencias nativas del agente subyacente. Además, la característica más potente —el despacho de subagentes— depende por completo de si el entorno anfitrión soporta la creación de instancias de agentes paralelas y aisladas. Si usas un entorno que solo soporta un historial de chat secuencial, Superpowers pierde su mayor ventaja y se convierte en un compañero conversacional que consume muchísimos tokens.

OpenSpec: El Enfoque Agnóstico al CLI

OpenSpec, por el contrario, adopta un enfoque más desacoplado. Es principalmente una herramienta CLI de Node.js (npm install -g @fission-ai/openspec) que gestiona el sistema de archivos.

La “integración” con tu agente de programación es mucho más laxa y resiliente. OpenSpec genera el directorio /openspec y los artefactos markdown. Luego confía en que el agente de programación (ya sea Cursor, Windsurf o una simple integración de terminal) lea esos archivos como contexto estándar.

Cuando escribes /opsx:propose en la interfaz de chat de tu IA, no estás activando una compleja máquina de estados interna del LLM como en Superpowers. Simplemente estás ejecutando un comando que le dice a la CLI de OpenSpec que genere algunas carpetas y una plantilla markdown basada en tu prompt.

Esta arquitectura desacoplada hace que OpenSpec sea increíblemente resiliente. No le importa si cambias de Claude 3.5 Sonnet a GPT-4o, o si te mudas de Cursor a una herramienta CLI personalizada. Mientras el agente pueda leer archivos markdown en tu repositorio, OpenSpec funciona. Los artefactos —proposal.md, design.md, tasks.md— son formatos universalmente comprendidos.

Esta resiliencia hace que OpenSpec sea mucho más fácil de adoptar para un desarrollador independiente que podría estar experimentando con diferentes herramientas de programación de IA. No te estás encerrando en el ecosistema de plugins de un entorno específico.

Escenarios del Mundo Real: Dónde Brillan

Aterricemos esta comparación en escenarios prácticos y cotidianos que encuentro mientras mantengo el portafolio de ArceApps.

Escenario A: La Refactorización de un Componente UI

La Tarea: Necesito refactorizar el componente de la tarjeta del blog (BlogCard.astro) para usar las nuevas propiedades CSS lógicas definidas en Tailwind v4, asegurando la compatibilidad RTL sin cambiar el diseño visual.

Usando Superpowers: El agente probablemente activaría la habilidad de brainstorming, haciéndome preguntas aclaratorias sobre casos límite en RTL. Luego crearía un nuevo worktree, escribiría una suite de pruebas verificando el diseño visual (lo cual es notoriamente difícil para componentes UI sin pruebas de regresión visual) y luego implementaría los cambios CSS. La sobrecarga de TDD para una refactorización CSS puramente estilística es inmensa y a menudo contraproducente. Pasaría más tiempo discutiendo con el agente sobre cómo probar clases CSS que escribiendo el CSS en sí.

Usando OpenSpec: Ejecutaría /opsx:propose refactor-blog-card-css. Genera un design.md anotando el cambio a propiedades lógicas (ej., cambiando ml-4 a ms-4). Apruebo el markdown. Ejecuto /opsx:apply. El agente lee el diseño, modifica BlogCard.astro y termina. Rápido, limpio y perfectamente alineado con la complejidad de la tarea.

Escenario B: Implementando un Algoritmo de Búsqueda Complejo

La Tarea: Necesito reemplazar la búsqueda básica del lado del cliente con un script de indexación TF-IDF personalizado que se ejecute durante el proceso de build de Astro y produzca un índice JSON altamente optimizado para que el cliente lo consuma.

Usando OpenSpec: Propongo el cambio, y OpenSpec genera un documento de diseño sólido detallando la matemática TF-IDF y los puntos de integración con Astro. Aplico el cambio. El agente intenta escribir el script de build y el consumidor del lado del cliente de una sola vez. Debido a que la tarea abarca múltiples límites arquitectónicos (paso de build en Node.js vs. hidratación en el navegador) y requiere lógica matemática precisa, el agente se confunde a mitad del tasks.md. Alucina una dependencia que falta, rompe el build de Astro y tengo que intervenir, revertir los cambios y guiarlo manualmente paso a paso.

Usando Superpowers: El agente reconoce la complejidad y activa writing-plans. Desglosa el algoritmo TF-IDF en funciones pequeñas y matemáticamente verificables. Activa subagent-driven-development. El Subagente A escribe una prueba para el cálculo de la frecuencia del término, ve que falla y la implementa a la perfección. El Subagente B maneja la frecuencia inversa de documento. El Subagente C escribe la prueba de integración de Astro. Debido a que cada subagente opera en un contexto aislado, no confunden la lógica del script de build con la lógica de UI del cliente. El riguroso TDD asegura que la matemática sea correcta antes de que toque siquiera el proceso de build de Astro. La funcionalidad aterriza perfectamente, probada de extremo a extremo.

Conclusión: La Ingeniería es Contextual

La comparación entre Superpowers y OpenSpec no se trata de encontrar la “mejor” herramienta en el vacío; se trata de encontrar la herramienta adecuada para el contexto específico de tu desafío de ingeniería.

Superpowers es la caballería pesada. Aporta disciplina de ingeniería rigurosa, pruebas impuestas y técnicas de aislamiento avanzadas a la programación con IA. Es ideal para trabajos de backend complejos, algorítmicos o de misión crítica donde la exactitud no es negociable.

OpenSpec es la infantería ágil. Proporciona una estructura ligera, guiada por artefactos, que respeta tu flujo de trabajo existente y escala a la perfección con proyectos brownfield. Es perfecto para el desarrollo de funcionalidades del día a día, ajustes de UI y las iteraciones rápidas que definen la experiencia del desarrollador indie.

Para el portafolio de ArceApps, me encuentro recurriendo a OpenSpec la inmensa mayoría de las veces. Su naturaleza fluida y sus contratos basados en markdown encajan perfectamente con un proyecto construido en Astro y contenido estático. Sin embargo, saber que herramientas como Superpowers existen —y entender la filosofía detrás del aislamiento de subagentes y la aplicación estricta de TDD— ha cambiado profundamente cómo escribo mis prompts y estructuro mis propios flujos de trabajo, incluso cuando no estoy usando explícitamente el framework.

En última instancia, el cambio hacia el Desarrollo Guiado por Especificaciones es la lección más importante. Ya sea que elijas el proceso estricto de Superpowers o los artefactos fluidos de OpenSpec, alejarse del chat no estructurado y avanzar hacia metodologías definidas es la clave para desbloquear el verdadero potencial de los agentes de IA en la ingeniería de software.