Un agente de código ya escribe una app funcional en una tarde. El problema dejó de ser producir el código y pasó a ser otro: el agente no escribe peor código sin una especificación, escribe un código excelente para el problema equivocado. Cada pregunta que no contestaste la contesta él con un valor por defecto razonable, y lo descubres semanas después. El Spec-Driven Development (SDD) ataca justo eso: escribir primero qué debe hacer el software, resolver por escrito lo que está ambiguo, y tratar el código como el resultado de esa especificación. Lo apliqué a un MVP en React Native con Expo que hace una sola cosa —mostrar un listado de los sismos recientes en todo el mundo— porque es el tipo de pedido que cabe en una línea y esconde más decisiones de las que parece.
TL;DR
- SDD separa tres artefactos: la especificación (qué y por qué), el plan técnico (cómo) y las tareas. El agente implementa contra ellos en vez de contra un prompt suelto.
- El valor real no es el documento: es que las ambigüedades quedan marcadas y resueltas por escrito antes de que el agente elija por ti. Qué sismos entran en la lista, en qué orden y qué pasa sin conexión son decisiones de producto, no de código.
- Los criterios de aceptación se escriben como una tabla de casos y esa misma tabla se convierte en el test. Si la fila no está en la tabla, el comportamiento no está definido.
Qué es el Spec-Driven Development y en qué se diferencia de prompting
Un prompt es una instrucción que se consume y desaparece. Una especificación es un archivo versionado en el repositorio, que se revisa en un pull request y que sobrevive a la sesión del agente. Esa es toda la diferencia, y es más grande de lo que parece.
En el flujo típico con un agente, describes la funcionalidad en el chat y el resultado son mil líneas de código más una conversación que nadie va a releer. Las decisiones importantes —la magnitud mínima, cuántas horas hacia atrás, qué pasa sin conexión— quedaron en un turno intermedio del chat. Cuando alguien pregunta por qué la app muestra un sismo de magnitud 2.6 y no uno de 2.4, la respuesta no está en ninguna parte.
SDD separa el trabajo en artefactos distintos, cada uno con su propio nivel de abstracción:
Especificación → qué debe pasar y por qué
│
▼
Plan técnico → cómo se implementa (stack, librerías, estructura)
│
▼
Tareas → unidades de trabajo verificables
│
▼
Implementación → el código que el agente escribe contra lo anterior
La regla que ordena todo es que cada nivel habla de su nivel. La especificación evita decisiones de implementación salvo que sean una restricción real del producto: "debe funcionar sin conexión" o "los datos no salen del dispositivo" son requisitos aunque tengan consecuencias técnicas; "usar TanStack Query" no lo es. El plan sí nombra tecnología, pero no reabre decisiones de producto. Cuando esa separación se respeta, puedes cambiar de stack sin reescribir la especificación, y cambiar un umbral sin tocar el plan.
Hay herramientas que formalizan este flujo. Spec Kit, de GitHub, instala una serie de comandos en tu agente que producen exactamente estos artefactos en carpetas del repositorio:
# Instala el flujo en el proyecto y elige el agente que vas a usar.
uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app
# A partir de ahí, dentro del agente:
# /constitution → principios del proyecto (aplican a todas las features)
# /specify → la especificación de esta feature
# /clarify → resuelve las ambigüedades marcadas en la spec
# /plan → el plan técnico
# /tasks → el desglose en tareas
# /implement → ejecuta las tareas
No hace falta la herramienta: tres archivos markdown en specs/ y la disciplina de mantenerlos alcanzan. Lo que aporta es que el agente tiene los comandos, las plantillas y el orden ya cargados, y no se salta pasos.
Sigue leyendo
Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:
Lee el artículo completo en ramonchancay.me →
Publicado originalmente en www.ramonchancay.me/es/blog/spec-driven-development-react-native-app-sismos.
Top comments (0)