La Spec como Artefacto Primario y las 7 Fases del Desarrollo con IA

Hace pocos días encontré un libro llamado Spec-Driven Development de Bezael Pérez publicado este 2026. Decidí comprarlo y ahora les quiero compartir algunas enseñanzas del mismo. Específicamente les hablaré de la especificación y su relación con las 7 Fases del Desarrollo que se proponen. Confío que les va a gustar.

Fuente: Infografía generada con NotebookLM a partir de los capítulos 3 y 4 del libro.

1. El artefacto vivo frente a la documentación estática 

Tradicionalmente, los documentos de requisitos se redactan antes de programar y quedan abandonados en los repositorios documentales de la empresa. Por eso el autor propone tratar la especificación técnica (la "spec") como un artefacto primario que reside directamente en el repositorio del código y se versiona mediante las herramientas de control de código fuente.

Este enfoque garantiza que el comportamiento esperado sobreviva a las conversaciones efímeras mantenidas con la IA. La máquina lee este archivo para contextualizar su entorno antes de modificar el sistema. Si ocurren cambios a nivel de negocio, se altera el documento primero y el código se adapta a la nueva realidad.

2. Definir el comportamiento sobre la arquitectura 

Un fallo técnico muy extendido al instruir a una IA consiste en dictar el stack tecnológico deseado. El texto señala el peligro de indicar implementaciones específicas a las herramientas generativas.

Esto porque exigirle a la máquina que invalide el acceso de un usuario tras un cierre de sesión otorga libertad al agente para decidir el método técnico más óptimo. Este modelo de trabajo preserva la responsabilidad humana sobre el control de las lógicas operativas y delega a la inteligencia artificial la carga de la ejecución del código.

3. El proceso de interrogatorio inverso 

Redactar una especificación técnica de alta calidad exige anticipar casos límite.

Para optimizar el tiempo, el autor sugiere invertir el flujo habitual de preguntas mediante una técnica denominada "grilling". El gestor técnico entrega el contexto base al agente y le solicita que realice todas las preguntas necesarias para comprender los objetivos finales del requerimiento.

Este "interrogatorio" previo fuerza la aparición de restricciones lógicas no contempladas inicialmente. La sesión preparatoria revela los vacíos de información antes de la etapa de programación y evita correcciones de alto impacto en los tiempos del proyecto.

4. La precisión del documento y el límite de extensión 

El Documento de Requisitos de Producto (PRD) constituye la base del método.

A mayor extensión de texto, mayor ruido interpreta el modelo de lenguaje. El libro aconseja un límite cercano a las quinientas palabras para mantener la eficacia del agente.

Un PRD funcional consta de apartados muy específicos, prestando especial atención a los elementos fuera de alcance (Out of Scope) y a las asunciones técnicas del sistema (Assumptions). Indicar los elementos excluidos impide la integración de módulos no solicitados por el equipo.

Detallar el estado real de la infraestructura evita la toma de decisiones basada en esquemas inexistentes.

5. La orquestación del flujo de trabajo 

La transición del documento a la realidad requiere un sistema estructurado. Por esa razón el autor describe un proceso basado en siete fases secuenciales.

(1) (2) Tras definir la idea y realizar la investigación técnica, el equipo consolida el PRD apoyado en diseños rápidos o Prototipos (3) (4).

La evolución metodológica destaca en la fase de estructuración de tareas o Kanban (5). El trabajo se divide en cortes verticales de funcionalidad completa, priorizando los elementos de mayor incertidumbre técnica mediante balas trazadoras.

(6) El ciclo de ejecución queda bajo la responsabilidad de la IA, pero obliga al supervisor humano a leer el código generado antes de dar por finalizada la tarea.

(7) El control de calidad cierra el ciclo para certificar la fidelidad del sistema respecto al contrato operativo.

La técnica Spec-Driven Development formaliza la relación productiva entre ingenieros y algoritmos. Restablecer la especificación como el núcleo del proyecto exige rigor técnico y aleja a los equipos de la generación automática de software carente de supervisión.

Al aplicar un flujo de trabajo disciplinado fundamentado en requerimientos claros, los profesionales de TI recuperan el control estratégico de los sistemas. El rol humano evoluciona desde la escritura manual de instrucciones hacia el diseño preciso de comportamientos, lo cual garantiza la escalabilidad del producto a largo plazo.

¿Qué les parece?

¿Les hace sentido?

Por favor compartan sus opiniones y experiencias en los comentarios.

Saludos cordiales.

Profesor Gerardo Cerda Neumann

Editor del Blog de la Comunidad