Durante años, muchos equipos han trabajado con una dinámica bastante conocida: idea rápida, desarrollo rápido, pruebas al final y documentación que casi siempre llega tarde o se queda obsoleta. Con la llegada de la IA generativa al desarrollo, ese problema no ha desaparecido; en algunos casos, incluso se ha acelerado. Por eso está ganando peso el spec-driven development, un enfoque que pone la especificación en el centro del proceso y no como un anexo olvidado. Microsoft lo describe como una aproximación “spec-first” para ingeniería nativa de IA, GitHub insiste en que la especificación debe ser la fuente compartida de verdad, y Thoughtworks señala que el término sigue evolucionando, pero siempre alrededor de la misma idea: primero definir con claridad, después construir.

¿Qué es realmente un Spec-Driven Developer?

Más que un cargo cerrado, yo lo entiendo como un perfil de desarrollo que trabaja desde la intención, el comportamiento esperado y los criterios verificables antes de entrar en la implementación. No se limita a “programar con IA”, sino que sabe transformar una necesidad difusa en una especificación útil para personas, agentes y herramientas.

Ese cambio de enfoque es clave. En vez de preguntar “¿cómo hacemos esto?” demasiado pronto, el Spec-Driven Developer pregunta primero “¿qué debe pasar exactamente, en qué contexto, con qué límites, para quién y cómo sabremos que funciona?”. Esa forma de pensar encaja muy bien con el movimiento actual hacia especificaciones vivas, checklists, validaciones y tareas derivadas automáticamente desde un documento central.

Dicho de otra forma: el valor ya no está solo en picar código rápido, sino en definir bien el problema para que el código, las pruebas y la documentación nazcan alineados. Cuando eso ocurre, la IA deja de ser una ruleta que a veces acierta y a veces improvisa, y pasa a convertirse en una herramienta de ejecución mucho más fiable. GitHub resume este punto muy bien al explicar que el problema no suele ser la capacidad del agente para escribir código, sino la ambigüedad de las instrucciones que recibe.

Aquí entra el método ASPECCT

El método ASPECCT es un marco de prompt engineering y estructuración de instrucciones que se suele presentar en siete piezas: Action, Steps, Persona, Examples, Context, Constraints y Template. Distintas guías lo proponen como una manera de redactar prompts más precisos y obtener respuestas más útiles y mejor organizadas.

Y aquí está lo interesante: aunque ASPECCT se suele explicar para conversar mejor con modelos de IA, en realidad también sirve para redactar mejores especificaciones funcionales, mejores historias de usuario, mejores briefs técnicos y mejores criterios de aceptación. Es decir, no solo mejora el prompt: mejora el pensamiento previo al desarrollo.

Cómo se conectan Spec-Driven Developer y ASPECCT

Un Spec-Driven Developer puede usar ASPECCT como una especie de andamio mental para no dejar huecos importantes en la definición del trabajo.

A — Action ¿Qué debe hacer el sistema o el agente? Aquí se define la acción principal sin vaguedades. No es lo mismo “gestiona pedidos” que “permite crear, editar, cancelar y auditar pedidos con trazabilidad por usuario”.

S — Steps ¿Qué secuencia o proceso debe seguir? Esto obliga a desglosar el flujo. Por ejemplo: validar datos, comprobar stock, registrar operación, notificar al cliente y guardar trazabilidad.

P — Persona ¿Qué rol adopta la IA o qué tipo de usuario representa el caso? Esta parte es muy útil cuando trabajas con asistentes de código, analistas automáticos o generadores de documentación. También sirve para perfilar al usuario final: admin, cliente, soporte, auditor, comercial.

E — Examples ¿Qué ejemplos concretos aclaran mejor la intención? En desarrollo, los ejemplos reducen muchísimos malentendidos. Un input real, una respuesta esperada o un caso borde pueden ahorrar más tiempo que dos párrafos abstractos.

C — Context ¿En qué entorno vive esta funcionalidad? Aquí entran el negocio, las dependencias, el stack, las reglas internas, el sistema legado, el tipo de cliente o el objetivo comercial.

C — Constraints ¿Qué restricciones no se pueden romper? Rendimiento, seguridad, formato, tono, compliance, tiempos de respuesta, compatibilidad, presupuesto o límites técnicos.

T — Template ¿Con qué estructura debe salir la respuesta o la especificación? Esta parte es especialmente potente cuando trabajas con IA, porque obliga a pedir la salida en un formato utilizable: tabla, checklist, JSON, plan técnico, historias de usuario, criterios Gherkin o documento funcional.

Un ejemplo práctico

Imagina que una empresa dice: “Queremos un chatbot para atender clientes”.

Eso, así escrito, es terreno perfecto para el caos.

Aplicado con mirada spec-driven y método ASPECCT, podría transformarse en algo como esto:

Action: Diseñar un chatbot web para resolver preguntas frecuentes, consultar estado de pedidos y escalar incidencias complejas a soporte humano. Steps: Identificar intención, validar si el usuario está autenticado, responder con base en documentación interna, solicitar datos mínimos cuando falten, y escalar a ticket si la confianza baja de cierto umbral. Persona: Actúa como asistente de soporte de primer nivel para una tienda online. Examples: Si el usuario pregunta “¿dónde está mi pedido?”, debe solicitar número de pedido y devolver estado, fecha estimada y enlace de seguimiento. Context: E-commerce con ERP conectado, base documental propia y atención en español. Constraints: No inventar políticas de devolución, no mostrar datos personales sin autenticación, tiempo máximo de respuesta de 3 segundos, tono claro y profesional. Template: Entregar arquitectura propuesta, flujos principales, riesgos, criterios de aceptación y backlog inicial.

La diferencia es brutal. Ya no hablamos de una idea simpática. Hablamos de una especificación accionable.

Qué ventajas aporta este enfoque

La primera ventaja es obvia: reduce ambigüedad. Y en desarrollo, menos ambigüedad suele significar menos retrabajo.

La segunda es que mejora la colaboración entre negocio, producto, desarrollo y QA. Cuando todos miran una especificación más clara, es más fácil discutir sobre comportamiento real y no sobre interpretaciones.

La tercera es especialmente actual: hace que la IA trabaje mejor. Tanto Microsoft como GitHub insisten en que una especificación bien definida reduce sorpresas, baja la improvisación del agente y mejora la calidad del resultado.

La cuarta es que deja una base mucho más sólida para evolucionar el sistema. Thoughtworks distingue entre varios niveles de madurez, desde un enfoque simplemente “spec-first” hasta modelos donde la especificación permanece anclada al ciclo de vida o incluso actúa como artefacto principal del sistema. Eso todavía está madurando, pero marca una dirección clara: mantener software será cada vez más parecido a mantener especificaciones bien diseñadas.

Pero tampoco es magia

Conviene decirlo claro: ni el spec-driven development ni ASPECCT arreglan por sí solos un mal producto, una mala arquitectura o una mala toma de decisiones. Si nadie entiende el negocio, si el equipo no valida con usuarios o si la organización cambia de rumbo cada semana, ninguna plantilla va a salvar el proyecto.

Además, existe un riesgo real: convertir la especificación en burocracia. El objetivo no es producir documentos bonitos. El objetivo es producir claridad útil. Si una especificación no ayuda a decidir, implementar, probar o mantener, entonces solo añade peso.

Cierre

Para mí, el valor del Spec-Driven Developer no está en escribir más documentos, sino en pensar mejor antes de construir. Y ahí el método ASPECCT encaja de maravilla porque obliga a concretar acción, contexto, ejemplos, límites y formato esperado.

En una época donde generar código es cada vez más fácil, la ventaja competitiva ya no está solo en producir más líneas, sino en definir mejor el comportamiento, la intención y las reglas del sistema. Quien domine eso trabajará mejor con personas, con equipos y también con IA.

Primero claridad. Luego implementación. Y después, verificación.

Toni Domenech