Cuando el agente escribe el código, el problema deja de ser “¿qué herramienta uso?” y pasa a ser “¿cómo gobierno lo que el agente hace?”

Cursor, Claude Code, Kiro, OpenCode y docenas de CLI más resuelven la superficie: IDE o terminal, modelo A o modelo B. Pero si el flujo es abrir un chat, describir la feature en prosa y aceptar el diff sin más, estás en vibe-coding: código plausible que deriva de la intención, requisitos enterrados en un historial que cerrarás mañana y ningún artefacto que sobreviva al contexto de la sesión.

El hilo es el marco: por qué las specs versionadas importan en la era IAG, cómo se comparan los enfoques, y dónde encaja cada uno en el principio RPS.

El problema del vibe-coding

Vibe-coding funciona hasta que deja de funcionar. El agente genera código que compila, pasa los tests que le pediste y encaja con el estilo del repo. Tres semanas después no recuerdas por qué eligió esa abstracción, el requisito original vivía en el mensaje 47 del chat y el siguiente agente (o tú, con memoria fresca) reinterpreta la intención desde cero.

En el marco RPS, vibe-coding es piedra degenerada: tiene la forma de la piedra (cero ceremonia, máxima velocidad aparente) pero sin sus virtudes. Piedra consciente asume reversibilidad alta y coste del fallo bajo. Vibe-coding en un módulo con datos sensibles, en código que vivirá años o en un dominio regulado es improvisación con apariencia de pragmatismo, no piedra consciente.

Los síntomas son predecibles:

• Drift: el código se aleja de lo que pediste sin que nadie lo note hasta la revisión, o hasta producción.
• Contexto perdido: cerrar el chat es borrar la spec.
• Código plausible, no correcto: el agente optimiza para “parecer bien”, no para cumplir invariantes que nunca quedaron escritos.
• Alucinaciones silenciosas: APIs inventadas, dependencias que no existen, configuraciones que “deberían” funcionar.

Ninguno de estos problemas es culpa del modelo. Son síntomas de ausencia de acuerdo explícito entre humano y agente antes de implementar.

Qué es SDD

Spec-Driven Development (SDD) pone la especificación como artefacto versionado en el repositorio (no en el historial del chat) y la trata como contrato entre humanos y agente. La spec dice qué debe hacer el sistema, bajo qué restricciones y qué no debe hacer. El agente implementa; los humanos revisan contra la spec, no solo contra el diff.

En un banco o en una empresa con datos regulados, SDD es papel auténtico en RPS: pagas estructura inicial (specs, revisiones, gates) a cambio de control del riesgo. El riesgo de verdad es filtración de datos a APIs externas, alucinaciones en producción o decisiones que nadie puede auditar seis meses después, no que el código quede feo.

Tampoco es “siempre escribir un PRD de veinte páginas”. Es elegir cuánta estructura necesitas según equipo, dominio y coste del fallo.

Niveles de madurez

La mayoría de equipos no necesitan el nivel 3 desde el día uno. Pero confundir el nivel 0 con piedra consciente es el error habitual.

La constitución mínima: AGENTS.md y reglas del proyecto

Antes de frameworks formales existe un escalón mínimo: decirle al agente cómo comportarse en este repo.

AGENTS.md es un convenio emergente, Markdown en la raíz del proyecto con convenciones, límites y contexto que cualquier agente debería leer antes de tocar código. Es portable entre Cursor, Claude Code, Copilot, OpenCode y la mayoría de herramientas que respetan instrucciones de proyecto.

En Cursor, el equivalente práctico son las reglas de proyecto (.cursor/rules/): archivos con convenciones de este blog, por ejemplo, o restricciones de estilo. No sustituyen una spec de feature, pero evitan que cada sesión empiece de cero.

En RPS es piedra mínima: casi cero ceremonia, máximo efecto por línea escrita. No tiene workflow formal ni deltas ni trazabilidad. Pero es un puente: mañana cambias de IDE o de agente y la constitución del proyecto viaja contigo.

Este repositorio aún no tiene AGENTS.md; usa reglas de Cursor. Adoptar AGENTS.md sería el siguiente paso natural, misma intención, más portabilidad.

OpenCode: el agente que arranca en piedra mínima

Conviene separar frameworks SDD (OpenSpec, Kiro) de agentes que ejecutan el trabajo. OpenCode es un agente open source (licencia MIT) pensado para terminal, con extensiones de escritorio e IDE. No sustituye un framework de specs, pero encaja en este post porque incorpora varios hábitos de gobernanza mínima sin ceremonia extra.

/init analiza el proyecto y genera un AGENTS.md en la raíz. Es el puente más directo entre “constitución del repo” y herramienta: no escribes el archivo a mano desde cero; lo revisas, lo ajustas y lo versionas. Misma intención que las reglas de Cursor, con un artefacto portable que otros agentes también pueden leer.

Modos Build y Plan (conmutables con Tab en la TUI) separan análisis de ejecución. En Plan, el agente es de solo lectura: explora el código, propone enfoques, no toca ficheros. En Build, escribe y ejecuta comandos. No es SDD completo (no hay deltas ni trazabilidad requisito→código), pero es nivel 1 honesto: piensa antes de mutar. Si cierras la sesión sin exportar el plan, vuelves al vibe-coding con pasos extra.

Agnóstico de proveedor: más de setenta modelos vía API (Anthropic, OpenAI, Google, GitHub Copilot) o inferencia local con Ollama. En RPS es piedra con puente fuerte: pagas poca fricción operativa y eliges tú quién procesa el código. La ancla depende del proveedor de modelo que conectes, no del agente en sí.

OpenCode no almacena tu código ni tu contexto en sus servidores, relevante cuando el perímetro importa, aunque eso no sustituye criterio sobre qué mandas al modelo. Conecta con soberanía digital: el agente puede ser puente; el modelo cerrado en la nube sigue siendo decisión tuya.

OpenSpec, Kiro o Spec Kit definen qué debe hacer el sistema. OpenCode (como Cursor o Claude Code) es quien lo implementa. La gobernanza viene de los artefactos del repo (AGENTS.md, specs, tests), no del nombre del agente.

OpenSpec: papel con puente fuerte

OpenSpec es un framework agnóstico de herramienta para SDD orientado a brownfield y cambios incrementales. Las specs viven en openspec/specs/; los cambios propuestos, en openspec/changes/ con deltas explícitos: ADDED, MODIFIED, REMOVED.

La idea central: antes de implementar, el agente (o tú) propone un cambio estructurado. Revisas la spec del delta, la apruebas, y entonces se implementa. Después archivas el cambio y la spec base se actualiza.

Por qué encaja en RPS como papel:

• Pagas estructura a cambio de alineación y menos sorpresas.
• Los artefactos son Markdown en tu repo, no en un SaaS propietario.
• Funciona con Cursor, Claude Code, Copilot u OpenCode sin vendor lock-in del framework.

Puente fuerte: las specs son tuyas; el agente es intercambiable. Ancla baja: dependes de la disciplina de seguir el workflow, no de un proveedor concreto.

OpenSpec brilla cuando el proyecto ya existe, los cambios son frecuentes y necesitas que el agente no reinvente requisitos en cada sesión. Comandos como /opsx:propose o /opsx:apply aceleran el ciclo; la documentación oficial cubre el detalle, aquí importa el criterio, no la sintaxis.

Kiro SDD: papel con trazabilidad, ancla en ecosistema

Kiro lleva SDD más lejos: workflow estructurado requirements → design → tasks, notación EARS para requisitos, specs en .kiro/specs/ y hooks que validan antes y después de que el agente ejecute herramientas.

Donde OpenSpec es agnóstico y ligero, Kiro apuesta por trazabilidad requisito→diseño→tarea→código y por integración profunda en IDE y CLI propios. Para equipos regulados o proyectos donde “¿quién pidió esto y por qué?” no es pregunta retórica, esa trazabilidad es papel de verdad, no teatro.

El coste en RPS:

• Ancla en el ecosistema Kiro/AWS/Bedrock: no es que las specs no sean tuyas, sino que el workflow completo asume sus herramientas.
• Papel/tijeras según contexto: papel si el dominio exige auditoría; tijeras si adoptas hooks, multi-agente y metodología completa en un homelab de una persona.

Kiro no compite con OpenSpec en “cuál es mejor”. Compiten en cuánta estructura institucional necesitas y cuánta ancla aceptas a cambio.

Kiro vs OpenSpec

Otros nombres en el mapa

GitHub Spec Kit: referencia de GitHub para SDD con más ceremonia que OpenSpec; útil en greenfield con equipos que ya viven en GitHub. Papel con puente (Markdown en repo), algo más de ancla en el ecosistema GitHub.

Cursor Plan Mode: SDD ligero sin framework extra: planificas antes de ejecutar, el agente sigue el plan en la misma sesión. Piedra/papel según disciplina: si exportas el plan a un archivo versionado, se acerca al nivel 1; si muere al cerrar el chat, es vibe-coding con pasos extra.

OpenCode: ya tratado arriba: agente OSS, no framework SDD. Destaca por /init → AGENTS.md, modo Plan de solo lectura y agnosticismo de modelo. Piedra operativa con puentes; la profundidad de herramienta (IDE vs CLI, comparativa con Cursor) queda para el post del panorama de agentes.

BMAD, Tessl, Antigravity: metodologías multi-agente o comerciales con más peso. Tijeras en RPS: máximo potencial metodológico, riesgo de overkill si eres una persona y el dominio no lo pide. Mención honesta sin review en profundidad: no los he usado en producción.

SDD en el marco RPS

Volver a la triada:

La pregunta útil es qué estrategia estoy usando y si el contexto lo justifica, no cuál framework tiene más estrellas.

Un equipo de banca que procesa PII y usa modelos en la nube sin SDD no está en piedra; está en piedra degenerada con consecuencias legales. Un desarrollador solo que escribe Spec Kit completo para un script de 40 líneas no está en papel; está en falso papel.

Puentes y anclas en SDD

Conecta con soberanía digital: puedes tener specs impecables y seguir filtrando datos si mandas el contenido del repo a un modelo cerrado sin criterio. SDD gobierna la intención; la soberanía cognitiva gobierna el perímetro.

Cuándo no hace falta SDD

SDD es papel, y papel tiene coste: no es obligatorio.

Quédate en vibe-coding (piedra consciente, no degenerada) cuando:

• El artefacto se tira en horas o días.
• Nadie más mantendrá el código.
• El fallo es barato y reversible.
• Estás explorando, no construyendo.

Sube a AGENTS.md o reglas cuando:

• El proyecto vivirá semanas o meses.
• Vuelves al repo con agentes distintos.
• Hay convenciones que el agente rompe en cada sesión.

Sube a OpenSpec o equivalente cuando:

• El código ya existe y los cambios se acumulan.
• Necesitas que el agente proponga deltas antes de implementar.
• Varias personas (o varias sesiones) deben compartir la misma intención.

Sube a Kiro o metodología pesada cuando:

• Hay requisitos de auditoría o regulación.
• Los comandos del agente pueden ser destructivos.
• El coste de una alucinación en producción es inaceptable.

Lo que no resuelve SDD

SDD no sustituye revisión humana. No garantiza que el agente siga la spec, solo que tienes contra qué medir el incumplimiento. No elimina la necesidad de tests, CI ni criterios de aceptación. Y no elige el modelo por ti: un spec excelente con un agente sin acceso a ella es decoración.

Lo apalancado es saber cuándo la spec merece el esfuerzo, y cuándo es ruido.

Qué viene después

Este post nombra la gobernanza: vibe-coding como piedra degenerada, SDD como papel, y el espectro entre AGENTS.md y frameworks completos. Otros posts de la serie IAG bajarán al panorama de herramientas (Cursor, Kiro, Claude Code, OpenCode, IDE vs CLI) y a casos operativos en homelab (compose → quadlet, SSO, diagnóstico con agente en terminal), siempre con el mismo criterio: no recetas por recetas, sino saber qué estás pagando cuando eliges.

Pagas estructura a cambio de alineación cuando el agente escribe el código y necesitas que la intención sobreviva al chat.