AI 8 min

La Entrevista de Requisitos y el Bucle "SpecOps": Cómo usar la IA de Sparring y rehacer código sin dolor

Aprende a usar la IA como sparring para redactar especificaciones EARS y cómo el bucle iterativo SpecOps permite rehacer el código sin acumular parches o deuda técnica.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

Seamos sinceros: a nadie le apetece sentarse un lunes por la mañana a escribir un documento Markdown de mil líneas detallando cada API, cada caso de prueba y cada validación de un desarrollo complejo. Es aburridísimo, consume un tiempo precioso y, si estás trabajando en una base de código existente con partes legacy (ese código antiguo que nadie quiere tocar pero que mantiene a flote la empresa), da una pereza tremenda.

La buena noticia es que en el Spec-Driven Development (SDD) no tienes que redactar la especificación a pelo. La IA no es solo un motor para picar código; su verdadero superpoder es actuar como un sparring técnico (un analista de negocio ultra rápido que te exprime la cabeza para extraer los requisitos y darles estructura).

Hoy vamos a ver cómo funciona este flujo interactivo paso a paso, qué pasa cuando la especificación que has diseñado no es la adecuada (y cómo la IA rehará la implementación sin dejar código muerto), y cómo enfocar este ciclo continuo al estilo de un flujo "SecDevOps" o "SpecOps" de mejora continua.

1. El Patrón "Interrogatorio": Cómo hacer que la IA escriba la Spec por ti

Imagina que en el proyecto de nuestro restaurante necesitamos añadir una funcionalidad gorda: la gestión de alergias en las reservas. En lugar de redactar el archivo spec.md desde cero, vamos a dejar que el agente haga el trabajo sucio.

Primero, inicializamos una especificación vacía en el directorio con Spec Kit:

specify init --here --integration agy

Esto nos dejará listos para interactuar con la consola o el chat de nuestro editor (en este caso, Google Antigravity). Ahora, abrimos el chat y le tiramos este prompt de oro (el patrón "Interrogatorio"):

"Quiero que actúes como un analista de negocio experto en desarrollo de software. Tu objetivo es ayudarme a redactar el archivo specs/alergias-reserva.md usando la sintaxis EARS. No asumas nada por tu cuenta. Hazme preguntas de opción múltiple, de una en una, sobre cómo debe comportarse el sistema con las alergias de los clientes (validaciones, almacenamiento, integraciones). Cuando tengamos suficiente información, redacta tú el documento de especificación."

El Sparring en acción:

El agente empezará a entrevistarte de forma súper enfocada:

  • IA: "¡Entendido! Vamos con la primera pregunta para el sistema de alergias:

1. ¿Cómo debe reaccionar el sistema si un cliente introduce una alergia que no está en nuestro diccionario estándar de alérgenos (ej. marisco, gluten)?

  • A) Rechazar la reserva con un error de validación.
  • B) Permitir texto libre, guardarla con una etiqueta 'No verificado' y notificar por correo al chef.
  • C) Mapearla automáticamente usando similitud semántica con el alérgeno más cercano.
  • ¿Cómo lo ves?"

Tú solo tienes que responder: "La B, pero añade que la notificación al chef se envíe solo si la reserva es para el mismo día".

En menos de diez minutos y con un par de intercambios rápidos de chat, la IA habrá extraído toda la lógica de tu cabeza y habrá generado un archivo alergias-reserva.md impecable en sintaxis EARS, sin que hayas tenido que pelearte con la estructura Markdown.

2. El Bucle "SpecOps": ¿Qué pasa cuando la Spec no es la adecuada?

Aquí es donde entra la realidad del desarrollo de software. Has terminado de implementar la funcionalidad de alergias, ejecutas la aplicación en tu entorno de pruebas y... ¡sorpresa! Te das cuenta de que la especificación que diseñaste no era adecuada.

Por ejemplo, especificamos que si había una alergia "No verificada", se enviaba un email al chef. Pero al probarlo nos damos cuenta de que el servicio de correo externo es lentísimo y bloquea el hilo principal de Node.js, o que el chef recibe 200 correos al día y está a punto de matarnos. La especificación original tenía un fallo de diseño técnico.

En el desarrollo tradicional (y en el destructivo Vibe Coding), la inercia nos empuja a abrir el archivo email.service.ts y meter un parche rápido (un hotfix) con una cola de tareas asíncrona o un try/catch guarro.

En SDD, el protocolo es radicalmente distinto. Seguimos un ciclo iterativo continuo similar a DevSecOps, al que podemos llamar "SpecOps":

 ┌────────────────────────────────────────────────────────┐
 │                      Bucle SpecOps                     │
 ├────────────────────────────────────────────────────────┤
 │                                                        │
 │     1. Detectas el fallo de diseño (ej. bloqueo)       │
 │                            │                           │
 │                            ▼                           │
 │     2. Corriges la especificación (specs/spec.md)      │
 │                            │                           │
 │                            ▼                           │
 │     3. Actualizas el plan (plan.md)                    │
 │                            │                           │
 │                            ▼                           │
 │     4. Regeneras las tareas (tasks.md) <─── ¡CRUCIAL!  │
 │                            │                           │
 │                            ▼                           │
 │     5. El agente REHACE el código por completo         │
 │                            │                           │
 │                            ▼                           │
 │     6. Validación automática y despliegue              │
 │                                                        │
 └────────────────────────────────────────────────────────┘

La regla de oro del Bucle SpecOps:

La especificación y el código se tratan como un binomio indisoluble. Si el código está mal, es porque la especificación era incompleta o incorrecta. Por tanto: nunca se corrige el código en local; se corrige la especificación y se deja que la IA vuelva a compilar la solución.

3. Ejemplo Práctico: Actualizar la Spec y dejar que la IA rehaga la implementación

Vamos a simular el problema del correo del chef. Nuestra especificación original en specs/alergias-reserva.md decía esto:

# INCORRECTO:
SI la reserva contiene un alérgeno no verificado, ENTONCES el sistema DEBERÁ enviar un correo electrónico síncrono al chef con los detalles.

Para solucionar el bloqueo del hilo de ejecución, abrimos directamente el archivo specs/alergias-reserva.md en el editor y lo actualizamos con la solución adecuada (un patrón de eventos asíncronos):

# CORRECTO (Sintaxis EARS):
CUANDO una reserva contenga un alérgeno no verificado, ENTONCES el sistema DEBERÁ publicar un evento `AllergyNotificationRequested` en la cola de mensajería local.

CUANDO la cola de mensajería procese el evento `AllergyNotificationRequested`, ENTONCES el servicio de correo DEBERÁ despachar la notificación al chef de forma asíncrona.

Una vez modificado el archivo de especificación física en nuestro disco, abrimos el chat de Antigravity (o tu editor compatible con Spec Kit) y ejecutamos la fase de actualización lógica:

/speckit.plan

El agente leerá la nueva especificación, la comparará con el código que ya existe en el repositorio y te propondrá un plan de refactorización limpio:

  • "He detectado que el envío síncrono de correo en reservas.service.ts viola la nueva especificación. El plan es eliminar ese acoplamiento directo, crear un bus de eventos sencillo en memoria (o usar la librería de eventos del proyecto) e implementar el consumidor asíncrono en notifications.consumer.ts."

El paso obligatorio de sincronización: regenerar las tareas

Aquí viene el gran secreto de producción que muchos tutoriales ignoran: nunca debes pasar directamente a la implementación sin antes actualizar el checklist. Si ejecutas la implementación directamente, el agente tendrá un ataque de amnesia y leerá la lista de tareas antigua que todavía está guardada en tasks.md, ignorando la reestructuración arquitectónica que acabas de diseñar.

Por eso, ejecutas estrictamente:

/speckit.tasks

Esto actualizará el archivo tasks.md tachando las tareas antiguas que ya no aplican y añadiendo las nuevas subtareas técnicas para la migración asíncrona.

Al tener el checklist de tareas sincronizado, ejecutamos finalmente la fase de implementación:

/speckit.implement

¿Cómo rehace la IA lo implementado?

Aquí ocurre la magia del SDD. Como el código es un subproducto transitorio, la IA no se limita a meter un parche sobre el código viejo. El agente borrará la implementación síncrona obsoleta y escribirá la nueva arquitectura asíncrona desde cero.

No habrá "código muerto", ni variables huérfanas en los servicios, ni dependencias inútiles importadas en la cabecera. La base de código se mantiene tan limpia, cohesionada y profesional como si un desarrollador sénior la hubiera reescrito con mimo durante todo un fin de semana.

4. El Reto de la Base de Código Existente: Lidiar con Código Legacy

Es muy bonito ver cómo funciona esto en un proyecto nuevo de restaurante donde todo está reluciente. Pero, ¿qué pasa cuando entras a trabajar en una empresa con un monolito de hace cinco años lleno de código legacy y sin un solo test unitario?

Intentar especificar todo ese monstruo de golpe para poder usar SDD es una utopía. En producción, la estrategia inteligente consiste en aplicar el patrón de "Delta Spec" (Especificación de Delta):

  1. Deja el código legacy en paz (Read-Only): No intentes documentar el pasado. El código antiguo se queda en el repositorio como contexto de lectura para la IA. Las herramientas de SDD son perfectamente capaces de leer código legacy para entender cómo integrarse con él, sin necesidad de que esté especificado en Markdown.
  2. Especifica únicamente el cambio (El Delta): Si te piden añadir un sistema de cupones de descuento a ese checkout legacy, creas una spec pequeña (specs/descuentos.md) que detalle exclusivamente las reglas de los cupones.
  3. Define los puntos de contacto: En tu especificación de delta, define claramente cómo se engancha la nueva funcionalidad con el sistema antiguo:
  • "SI el checkout legacy procesa el pago, ENTONCES el sistema de cupones DEBERÁ marcar el cupón introducido como canjeado en la base de datos."
  1. Aísla el código nuevo: Intenta que el agente implemente el nuevo desarrollo en módulos separados y limpios, utilizando patrones de diseño como Wrappers o Adapters para comunicarse con la parte legacy. Así mantendrás el código nuevo bajo un estándar de máxima calidad SDD, mientras el monolito antiguo sigue funcionando en su rincón sin molestar.

Resumen de Aprendizaje

Si quieres dominar el bucle práctico del SDD en tu día a día, grábate estas pautas a fuego:

  1. Usa la IA de Sparring: No te rompas la cabeza escribiendo specs eternas a mano. Pídele al agente que te entreviste con preguntas de opción múltiple y que maquete el Markdown por ti.
  2. Adopta la mentalidad "SpecOps": Si descubres un fallo de lógica o rendimiento en tus pruebas, prohibido parchear el código. Modifica la spec, actualiza el plan, regenera las tareas obligatoriamente con /speckit.tasks, y let the IA cleanly regenerate the module.
  3. Respeta el código legacy: No pierdas el tiempo documentando sistemas antiguos. Usa Specs de Delta para tus nuevas funcionalidades y deja que el agente lea el código legacy existente solo como contexto de integración.

En el siguiente artículo, El Reto del Código Existente (Brownfield) y la Gestión de Múltiples Specs con Jira/Git de la serie daremos un paso al frente para resolver el gran dilema que surge cuando el proyecto crece en serio: ¿Cómo gestionar múltiples specs conviviendo en paralelo sin que la IA sufra de amnesia ni se pise las tareas? Veremos cómo organizar tu flujo si trabajas con convenciones de Git estrictas basadas en tus tickets de Jira o Agility (por ejemplo, ramas con nomenclatura feature/S-143562_pasarela-pago), y cómo utilizar la ingeniería inversa para documentar sistemas antiguos complejos. ¡Nos vemos en el próximo artículo!

📚 Serie Spec-Driven Development (SDD)

  1. Spec-Driven Development (SDD): Gobernanza de Agentes IA y el Fin del 'Vibe Coding'
  2. El Chasis de la Gobernanza: Constitución vs. AGENTS.md (Y cómo no ahogarte en deuda de sincronización)
  3. El Pipeline SDD en la Práctica: De la Sintaxis EARS a las Tareas Atómicas
  4. La Entrevista de Requisitos y el Bucle "SpecOps": Cómo usar la IA de Sparring y rehacer código sin dolor
  5. El Reto del Código Existente (Brownfield) y la Gestión de Múltiples Specs con Jira/Git
  6. Google Antigravity y MCP: Sandboxing, Autocorrección y la Nube