· 5 min de lectura
SDDM: Spec-Driven Development para crear apps móviles con IA
Nuestro método para que la IA no se invente tu app: spec, plan y tareas antes del código, más una checklist de 15 casos móviles. Plantillas en PDF gratis.
Le pides a Claude Code «hazme un sistema de favoritos» y en diez minutos tienes un corazón que se rellena. Funciona. Lo enseñas, todo bien.
Hasta que lo pruebas en el metro sin cobertura. O tocas el corazón dos veces rápido y la receta aparece duplicada. O abres la pestaña de favoritos el primer día y está en blanco, sin una sola palabra que explique qué hacer.
Nada de eso es culpa de la IA. No se lo dijiste. Y cuando no se lo dices, el agente rellena los huecos a su manera.
Para eso usamos en AppFounders el SDDM: nuestra versión del Spec-Driven Development pensada para apps móviles. En este post te cuento qué es, cómo funciona y te regalo las plantillas que usamos.
Qué es el Spec-Driven Development
El Spec-Driven Development (SDD, desarrollo guiado por especificaciones) le da la vuelta a cómo trabajas con un agente de IA: antes de escribir código, escribes qué tiene que hacer la funcionalidad. Ese documento, la spec, es la fuente de verdad para ti y para el agente. El código sale de ella.
No nos lo hemos inventado. GitHub lo popularizó con Spec Kit, Amazon construyó Kiro alrededor de la idea y Thoughtworks lo tiene en su Technology Radar. Funciona por tres motivos:
- El agente deja de adivinar. Todo lo que necesita saber está escrito.
- Cambiar de idea es barato. Corregir un documento cuesta minutos; corregir código, días.
- Cada conversación parte del mismo sitio. Mañana abres otra sesión y el agente lee la misma spec, no tu memoria.
Por qué en móvil no basta con el SDD normal
El SDD genérico te dice «escribe una spec antes de programar». Lo que no te dice es qué tiene que tener esa spec cuando construyes una app móvil. Y ahí es donde los agentes fallan más.
Un agente te hace la pantalla bonita del caso feliz. Pero un iPhone de verdad:
- pasa a segundo plano a mitad de una compra,
- pierde cobertura en el ascensor,
- tiene el texto en tamaño grande porque su dueño no ve bien,
- deniega el permiso de notificaciones,
- y tiene un usuario impaciente que pulsa «Pagar» tres veces.
Eso es lo que separa una demo de una app que aprueba Apple y no recibe reseñas de una estrella.
SDDM: SDD + dos piezas para móvil
El SDDM (Spec-Driven Development Mobile) es el SDD que usamos en el curso, con dos añadidos:
- Una checklist móvil. Quince puntos que el agente repasa contigo al escribir cada spec: ciclo de vida, estado, conexión, persistencia, estados de pantalla, navegación, formularios, tamaños de pantalla, accesibilidad, permisos, rendimiento, segundo plano, privacidad, idiomas y cómo se prueba.
- Las reglas del proyecto. Un archivo
AGENTS.mdque describe cómo está construida tu app y cómo hay que extenderla. El agente no tiene que adivinar tu arquitectura: la lee. Así el código nuevo encaja con el que ya tienes, en vez de ser un parche distinto en cada conversación.
El flujo: cuatro documentos, cuatro aprobaciones
El agente escribe. Tú decides. Nada pasa a la siguiente fase sin tu aprobación.
| Fase | Responde a | Tu trabajo |
|---|---|---|
| SPEC.md | Qué construimos, para quién y qué pasa en cada caso | Responder sus preguntas. No dejarle suponer |
| PLAN.md | Cómo se implementa: archivos, datos, errores, orden | Leerlo con calma. Es el último momento barato para cambiar de rumbo |
| TASKS.md | En qué pasos pequeños lo hacemos | Comprobar que cada tarea dice cómo se valida |
| Código | La implementación, tarea a tarea | Probar en tu iPhone los casos de la spec |
La spec habla en lenguaje de producto: qué ve y qué hace el usuario. Nada de clases, tablas ni archivos. Eso va en el plan.
Y una regla de oro: si algo cambia por el camino, actualiza primero la spec y después el código. Si no, en dos semanas la spec mentirá y el agente trabajará con información falsa.
Un ejemplo: favoritos con y sin SDDM
Volvamos al «hazme un sistema de favoritos». Con SDDM, antes de tocar código, el agente te habría hecho preguntas como estas:
- ¿Qué ve el usuario si todavía no tiene favoritos?
- ¿Qué pasa si marca una receta sin conexión?
- ¿Qué pasa si toca el corazón dos veces seguidas?
- ¿Los favoritos se ven en modo avión?
- ¿Qué dice VoiceOver al llegar al botón?
- ¿Y si una receta se borra del menú?
Las respuestas acaban en una tabla dentro de la spec:
| Situación | Comportamiento esperado |
|---|---|
| Sin favoritos | Ilustración + «Pulsa ♥ en una receta para guardarla» |
| Sin conexión al marcar | Se marca al momento y se sincroniza al volver la red |
| Doble toque rápido | Un solo cambio; nunca queda duplicado |
| VoiceOver | El botón dice «Añadir a favoritos» o «Quitar de favoritos» |
Y cada requisito tiene un criterio de aceptación que puedes comprobar con el móvil en la mano: «Dado el modo avión activado, cuando abro Favoritos, entonces veo las recetas marcadas con su foto y su título». Nunca «funciona correctamente».
La spec completa de este ejemplo está en el PDF.
Cuándo usarlo (y cuándo no)
SDDM no es para todo. Para cambiar un color o un texto, pídeselo directamente al agente.
Compensa en funcionalidades con varias pantallas, datos o casos que se pueden torcer: login, pagos y suscripciones, sincronización, notificaciones, onboarding, rachas, favoritos…
Empieza hoy
Elige tu próxima funcionalidad con dos o tres pantallas, copia las plantillas y pídele al agente la spec. La primera vez tardarás un poco más. A la tercera no volverás a programar sin spec.