Trabajar con IA sin que se te vaya de las manos. El ciclo de Spec Driven Development en cinco fases —especificar, planificar, trocear, implementar y revisar—, con el prompt de cada una listo para copiar, la plantilla de spec, unos cuantos prompts sueltos y la checklist de la revisión manual, que es la parte que no se delega. No hay ninguna IA detrás: se copia y se pega donde la uses, y lo que marcas se queda en tu navegador.
LOS PRINCIPIOS
Lo que se escribe primero es qué tiene que pasar, no cómo. El código es la salida; si la spec está torcida, el código sale torcido más rápido.
Pedir tres cosas a la vez sale barato y se paga en el diff. Una tarea por vuelta, y que el proyecto siga funcionando al acabarla.
El resumen que te escribe la IA no es el cambio. Lo que se mergea es lo que pone en las líneas, y esas las lees tú, enteras.
Si no sabes cómo vas a comprobar que está bien, todavía no se puede pedir. Primero cómo se verifica, después quién lo escribe.
Una conversación de cien vueltas se acuerda de todo menos de lo que importa. Cuando se enrede, abre otra con la spec y el estado de ahora.
Si no sabes contar por qué cada línea está ahí, no es tuyo y no lo mantienes. Preguntar hasta entenderlo forma parte del trabajo.
EL CICLO
Cinco fases. De cada una se sale con algo escrito.
Escribir qué tiene que pasar y para quién, sin decidir todavía cómo.
Antes de escribir código, escribe la especificación de este cambio. Qué quiero: <una línea> Dónde: <la zona del proyecto que toca> Devuélvemelo en este orden: 1. El problema en dos frases, sin solución dentro. 2. El comportamiento esperado, en frases «cuando… entonces…». 3. Los casos límite, y qué debe pasar en cada uno. 4. Lo que queda fuera de este cambio. 5. Las preguntas que no puedes responder tú solo. No propongas implementación todavía. Si algo es ambiguo, pregunta en vez de suponer.
Pasas cuando la spec cabe en una pantalla y la entiende alguien que no eres tú.
Decidir el cómo por escrito, mientras todavía es barato cambiarlo.
Esta es la spec aprobada: <pega aquí la spec> Hazme el plan técnico, todavía sin código: - Los ficheros que tocas y qué cambia en cada uno. - Lo que reutilizas de lo que ya existe, con su ruta. - El orden de los cambios, y por qué ese orden. - Los tres sitios por donde esto puede romper algo que ya funciona. - Una alternativa más simple que hayas descartado, y por qué. Párate en el plan. No escribas código hasta que te lo apruebe.
Pasas cuando puedes contar el plan de memoria y no hay ningún fichero ahí «por si acaso».
Partir el plan en cambios que se leen de una sentada.
Del plan aprobado, sácame la lista de tareas. Cada tarea tiene que: - Caber en un diff que se lee de una sentada. - Dejar el proyecto funcionando; nada de «esto se arregla en la siguiente». - Llevar su criterio de aceptación: cómo compruebo yo que está hecha. Numéralas en el orden en que hay que hacerlas y marca cuáles dependen de otra. No las implementes.
Pasas cuando ninguna tarea necesita explicación aparte para entenderse.
Una tarea, un diff. Después se vuelve a mirar.
Haz solo la tarea 1. Nada más. Reglas: - Mira antes el código que ya hay y sigue sus convenciones. - Sin dependencias nuevas. - Sin código muerto, sin TODO y sin opciones que no pidió nadie. - Si la spec se queda corta, párate y pregunta en vez de inventar. Al terminar, dame el diff y debajo una línea por fichero: qué cambia y por qué.
Pasas cuando el diff hace lo de la tarea y nada más.
La parte que no se delega. Lo lees tú y lo ejecutas tú.
Repasa tu propio cambio antes de que lo mire yo. - ¿Qué hace el diff que la spec no pedía? Quítalo. - ¿Qué pide la spec que el diff no hace? Dímelo. - ¿Qué caso límite no está cubierto? Enséñame la línea que lo cubre o admite que falta. - ¿Qué has supuesto sin confirmarlo? - ¿Cuál es la parte del cambio de la que menos seguro estás? Sin adornos: si algo está a medias, dilo.
Pasas cuando sabes explicar cada línea sin volver a preguntar.
LA PLANTILLA DE SPEC
Para no empezar con el folio en blanco.
# <título del cambio> ## Problema Qué duele hoy y a quién. Sin solución dentro. ## Fuera de alcance Lo que este cambio no toca. ## Comportamiento - Cuando <situación>, entonces <resultado>. - Cuando <situación>, entonces <resultado>. ## Casos límite - <caso> → <qué pasa> ## Criterios de aceptación - [ ] <cómo se comprueba> - [ ] <cómo se comprueba> ## Riesgos - <qué puede romper> → <cómo nos enteramos a tiempo> ## Decidido - <decisión>, porque <motivo>
PROMPTS SUELTOS
Para los ratos que no son una fase.
Cuando el código es de otro, o tuyo de hace un año.
Explícame este módulo antes de que lo toquemos: <pega el fichero o dime la ruta> - Qué hace, en tres frases. - Quién lo llama y a quién llama. - Qué invariantes da por supuestas y dónde se rompen si las cambio. - Qué parte tiene pinta de haberse escrito con prisa. Solo lectura: no propongas cambios todavía.
Cuando hay un fallo y la tentación es parchear a ciegas.
Hay un bug. Antes de arreglarlo, quiero reproducirlo. Síntoma: <qué ves> Cuándo pasa: <pasos> - Dame el test más pequeño que falle por este motivo y por ningún otro. - Dime qué hipótesis descarta ese test si pasa. - No arregles nada todavía: primero quiero verlo fallar.
Antes de mergear algo que te da un poco de miedo.
Ponte a romper este cambio, no a defenderlo: <pega el diff> - Tres entradas con las que se comporta mal. - Qué pasa con concurrencia, con datos vacíos y con datos enormes. - Qué falla en silencio en vez de dar error. - Si tuvieras que revertirlo en producción a las tres de la mañana, ¿qué se te complica? No me digas que está bien: dime por dónde se rompe.
LA REVISIÓN MANUAL
0 de 13 · se queda en tu navegador
Esta parte no se delega. La IA escribe el cambio; quien responde de él eres tú.
CUANDO SE TE VA EL FOCO
La señal, y qué hacer con ella.
Pídelo en trozos hasta que quepa en tu cabeza. Si no cabe, la tarea era demasiado grande.
Para. Escribe a mano el caso que falla, tira la conversación y empieza con eso delante.
Contexto quemado. Abre uno nuevo con la spec y el estado de ahora, no con el histórico.
Entonces no funciona. Que te lo explique, y compruébalo tú en el código.
Di que no. Con lo que ya hay, o no se hace.
Vuelve a la spec. Lo que sobra se queda fuera, aunque esté bien escrito.