Hay una diferencia enorme entre pedirle a una IA o a un equipo que “haga una app” y construir un producto con una dirección clara. En el primer caso, aparecen interpretaciones, retrabajo y resultados inconsistentes. En el segundo, cada decisión parte de una base sólida.

Ahí es donde entra el enfoque Spec Driven Developer: un modo de trabajar donde el desarrollo no arranca desde el código, sino desde la claridad. Antes de implementar, definimos el marco, concretamos qué debe hacer el sistema, resolvemos dudas, trazamos un plan y lo convertimos en tareas ejecutables.

La estructura es sencilla, pero muy potente:

1. Constitución
2. Especificaciones
3. Clarificación
4. Plan
5. Tareas

Cuando este flujo se aplica bien, el desarrollo deja de depender de intuiciones y empieza a apoyarse en decisiones explícitas.

1. Constitución

La constitución es el documento base. Es el punto de partida que da contexto a todo lo demás.

Aquí no hablamos todavía de pantallas ni de funciones concretas. Hablamos de propósito, alcance, usuarios, restricciones y criterios de éxito. Es decir: qué estamos construyendo, para quién, por qué y bajo qué límites.

Una buena constitución responde preguntas como estas:

• ¿Qué problema resuelve el producto?
• ¿Quién lo va a usar?
• ¿Qué objetivos de negocio persigue?
• ¿Qué restricciones existen?
• ¿Cómo sabremos si el resultado ha sido bueno?

Ejemplo simple

Imagina que quieres crear una app para que autónomos controlen sus gastos. Si empiezas directamente pidiendo pantallas o código, cada persona —o cada IA— rellenará huecos a su manera. Pero si primero defines la constitución, el proyecto gana dirección.

Ejemplo de prompt para crear la constitución

Actúa como product strategist. Ayúdame a redactar la constitución de un producto digital.Proyecto: una app web para autónomos que permita registrar gastos, categorizarlos y obtener un resumen mensual.Define:- propósito del producto- problema que resuelve- tipo de usuario- alcance inicial- restricciones- criterios de éxitoQuiero una redacción clara, concreta y sin tecnicismos innecesarios.

Por qué importa

Porque sin constitución todo el proyecto nace borroso. Y cuando el origen es borroso, las especificaciones también lo serán. La constitución no es burocracia: es alineación.

2. Especificaciones

Si la constitución define el marco, las especificaciones definen el comportamiento.

Aquí ya bajamos a detalle. Explicamos qué debe hacer el sistema, cómo debe responder, qué reglas debe cumplir y qué límites funcionales o no funcionales tiene.

Las especificaciones convierten una intención general en algo verificable.

Qué suelen incluir

• funcionalidades principales
• reglas de negocio
• flujos de usuario
• validaciones
• entradas y salidas
• comportamiento esperado
• requisitos no funcionales como rendimiento, seguridad o usabilidad

Ejemplo simple

Siguiendo el caso de la app para autónomos, una constitución puede decir que el usuario necesita controlar sus gastos. La especificación concreta dirá cosas como:

• el usuario puede registrar un gasto con fecha, importe, categoría y nota
• el sistema debe permitir filtrar por mes
• el resumen mensual debe mostrar total por categoría
• no se puede guardar un gasto sin importe
• las categorías iniciales serán vivienda, transporte, software, comidas y otros

Eso ya no es una idea. Eso es una base real para construir.

Ejemplo de prompt para generar especificaciones

A partir de esta constitución de producto, genera unas especificaciones funcionales claras.Necesito:- funcionalidades principales- flujos de usuario- reglas de negocio- validaciones- requisitos no funcionales básicosProyecto: app web para autónomos que registran y analizan gastos mensuales.Quiero que lo redactes en formato estructurado, fácil de revisar por producto, diseño y desarrollo.

Por qué importa

Porque una idea vaga genera resultados vagos. Las especificaciones obligan a concretar. Y concretar reduce errores, discusiones y retrabajo.

3. Clarificación

Este paso suele ser el más infravalorado, y sin embargo es uno de los más valiosos.

La clarificación consiste en detectar ambigüedades, contradicciones, huecos y decisiones pendientes antes de pasar a la ejecución. En otras palabras: hacer visibles las dudas que todavía están escondidas.

Aquí no se trata de producir más texto por producir. Se trata de encontrar todo lo que aún no está claro.

Qué busca la clarificación

• términos ambiguos
• supuestos no declarados
• conflictos entre requisitos
• decisiones que faltan
• casos límite no contemplados

Ejemplo simple

Supón que una especificación dice:

“El sistema mostrará un resumen mensual de gastos.”

Parece correcto, pero todavía deja preguntas abiertas:

• ¿Resumen del mes actual o de cualquier mes?
• ¿Se muestran importes con impuestos o sin impuestos?
• ¿Se agrupa por categorías?
• ¿Puede exportarse?
• ¿Qué ocurre si no hay datos?

La clarificación transforma una frase aparentemente válida en un conjunto de decisiones concretas.

Ejemplo de prompt para clarificar

Revisa estas especificaciones como si fueras un analista funcional senior.Tu tarea es:- detectar ambigüedades- señalar contradicciones- listar decisiones pendientes- identificar casos límite- proponer preguntas concretas para cerrar huecosNo reescribas todavía la solución. Primero quiero claridad total sobre lo que falta definir.

Por qué importa

Porque muchos problemas de desarrollo no nacen en el código, sino en requisitos mal entendidos. La clarificación evita construir rápido algo que todavía no estaba bien pensado.

4. Plan

Una vez que el problema está bien definido y aclarado, llega el momento de decidir cómo se va a construir.

El plan convierte las especificaciones en una estrategia de implementación. Ya no estamos preguntando “qué debe hacer el producto”, sino “cómo vamos a abordar su construcción”.

Aquí entran decisiones como arquitectura, fases, prioridades, dependencias y orden de ejecución.

Qué suele incluir un plan

• módulos del sistema
• secuencia de implementación
• prioridades
• dependencias entre partes
• riesgos
• entregables por fases
• criterios para un MVP

Ejemplo simple

Para la app de gastos, el plan podría dividir el trabajo así:

• fase 1: autenticación y gestión de usuarios
• fase 2: formulario de registro de gastos
• fase 3: listado y filtros
• fase 4: resumen mensual
• fase 5: exportación y mejoras

Eso ayuda a no intentar construir todo a la vez y permite organizar el trabajo con lógica.

Ejemplo de prompt para crear el plan

Con esta constitución, estas especificaciones y las aclaraciones ya resueltas, crea un plan de implementación.Necesito:- propuesta de arquitectura funcional- módulos principales- orden recomendado de desarrollo- dependencias entre módulos- definición de un MVP- riesgos principalesQuiero un plan realista, pensado para un equipo pequeño o para desarrollo asistido por IA.

Por qué importa

Porque incluso con buenas especificaciones, sin plan aparece el caos. El plan pone orden, prioriza y convierte la claridad conceptual en una ruta de ejecución.

5. Tareas

Las tareas son la última milla. Aquí el plan deja de ser estratégico y se vuelve operativo.

Una tarea bien definida debe ser concreta, ejecutable y verificable. No debería dejar al desarrollador preguntándose qué hacer exactamente.

Una buena tarea incluye

• objetivo
• descripción clara
• contexto suficiente
• criterios de aceptación
• dependencias
• prioridad

Ejemplo simple

Una mala tarea sería:

• “Hacer el resumen mensual”

Una buena tarea sería:

• “Crear componente de resumen mensual que muestre total de gastos del mes seleccionado y desglose por categoría. Debe manejar estado vacío y error de carga. Criterio de aceptación: si el usuario selecciona abril de 2026 y tiene datos, ve el total general y la suma por categoría.”

La diferencia es enorme. Una guía genera autonomía; una frase vaga genera dudas.

Ejemplo de prompt para descomponer en tareas

Descompón este plan en tareas pequeñas y accionables para ejecución técnica.Para cada tarea incluye:- título- descripción- objetivo- dependencia- prioridad- criterio de aceptaciónHazlo pensando en que cada tarea pueda ser ejecutada por una persona o por una IA sin necesidad de interpretar demasiado.

Por qué importa

Porque el valor del método no está solo en pensar mejor, sino en ejecutar mejor. Las tareas convierten la estrategia en trabajo real.

Cómo se conectan las 5 piezas

La fuerza de este enfoque no está en cada bloque por separado, sino en cómo encajan entre sí.

• La constitución da dirección.
• Las especificaciones concretan el comportamiento.
• La clarificación elimina dudas.
• El plan organiza la ejecución.
• Las tareas hacen posible construir.

Cuando falta uno de estos pasos, el siguiente hereda problemas. Si la constitución es débil, las especificaciones serán confusas. Si las especificaciones son ambiguas, la clarificación será interminable. Si no hay plan, las tareas saldrán desordenadas. Y si las tareas son vagas, la ejecución será inconsistente.

Por eso Spec Driven Developer no es solo una forma de documentar. Es una forma de pensar antes de construir.

Un ejemplo de flujo completo de prompts

Para verlo de forma más práctica, este sería un flujo sencillo y muy útil:

Prompt 1: constitución

Ayúdame a definir la constitución de una plataforma online para reservar clases particulares de idiomas.Incluye propósito, usuarios, alcance inicial, restricciones y criterios de éxito.

Prompt 2: especificaciones

A partir de esta constitución, redacta las especificaciones funcionales y no funcionales del sistema.Incluye flujos de usuario, reglas de negocio y validaciones.

Prompt 3: clarificación

Analiza estas especificaciones e identifica todas las ambigüedades, contradicciones, supuestos ocultos y decisiones pendientes.Devuélveme una lista de preguntas priorizadas.

Prompt 4: plan

Con las decisiones ya resueltas, crea un plan de implementación por fases para el MVP.Incluye módulos, dependencias, riesgos y orden recomendado.

Prompt 5: tareas

Descompón el plan en tareas técnicas pequeñas, accionables y verificables.Incluye criterio de aceptación para cada una.

Conclusión

Desarrollar sin especificaciones claras es avanzar a base de intuición. A veces funciona, pero casi siempre sale caro. El enfoque Spec Driven Developer propone algo mucho más sólido: pensar antes de construir, aclarar antes de implementar y dividir antes de ejecutar.

No se trata de escribir más documentos. Se trata de reducir suposiciones, mejorar la calidad de las decisiones y hacer que tanto las personas como las IAs trabajen con contexto real.

Cuando la base está clara, el desarrollo fluye mejor. Y cuando cada fase prepara bien a la siguiente, el resultado final gana en velocidad, coherencia y calidad.

Toni Domenech