Notas
Por qué he dejado el Spec Driven Development
He dejado de usar el desarrollo basado en especificaciones porque planificarlo todo por adelantado genera capas, sobreingeniería y revisiones demasiado grandes. Ahora trabajo con historias cortas y rebanadas verticales que atraviesan todas las capas, mientras la IA escribe el código y yo marco el rumbo.
2 min de lectura
Hace unos meses comencé a usar el desarrollo basado en especificaciones: escribes una especificación detallada, se la entregas al agente y este se encarga de implementarla de principio a fin. Propuesta, especificación, diseño, tareas y código. Sobre el papel suena bien, y durante bastante tiempo quise creer que era el camino.
Tras meses de uso, he llegado a las mismas conclusiones que el desarrollador que contó la misma experiencia. Y no soy el único: gente como Kent Beck, Matt Pocock o Dave Farley también lo cuestionan. No me convence, y quiero explicar por qué.
El problema no es la planificación
Planificar es necesario. El problema es planificarlo todo de una vez. Cuando defines la arquitectura, el modelo de datos y el listado de tareas justo cuando menos sabes del problema, estás volviendo a la cascada de hace veinte años. Y el agente, si nadie le dice que lo haga sencillo, llena los huecos con sobreingeniería: interfaces que no necesitas, campos en la base de datos y te preguntas por qué están ahí, capas de abstracción pensadas para un futuro que no llegará.
Pides un inicio de sesión y te devuelve un documento de tres páginas con requisitos, plan de arquitectura, veintisiete tareas y cuatro capas. Y todavía no puedes iniciar sesión.
Nada funciona hasta el final
Las tareas salen por capas: primero toda la base de datos, después la API, después el frontend. Una base de datos sin API no puedes probarla; una API sin frontend no puedes usarla. Resultado: no tienes nada que funcione hasta el último día y, cuando llega, la revisión consiste en leer 3.000 líneas de código. El agente ha tardado quince minutos en corregirlo y tú pasas tres horas revisándolo. Después pides cambios hasta que te cansas y aceptas todo en bloque. Historia conocida.
Cómo trabajo ahora
Lo que me ha funcionado es mucho más antiguo que la IA: una lista de historias de usuario cortas, una cada vez. Como usuario, quiero registrarme con correo electrónico y contraseña. Se refina antes de construirla: los casos, los criterios de aceptación y, sobre todo, qué queda excluido.
Y cada historia se construye como una rebanada vertical: atraviesa la base de datos, la API y el frontend y, al terminar, tienes algo que puedes probar usándolo, no leyéndolo. Si algo está mal, te enteras en treinta minutos, no tres días después.
La IA escribe; tú marcas el rumbo. Decides qué se construye, qué no, cuándo refactorizar y cuándo no. Y cada pequeño paso se confirma: si el agente toca una prueba para hacerla pasar, lo ves al instante.
En resumen
El desarrollo basado en especificaciones no está pensado para programar; está pensado para delegar la especificación. La implementación técnica es mejor abordarla en pequeños pasos, con la IA escribiendo y tú pilotando. Menos documentos, menos capas, más software que funciona.