Una pregunta habitual de los responsables de ingeniería antes de probar el Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, es corta: ¿y esto cuánto se nota? Hasta ahora hemos explicado el método. Este insight cuenta qué pasó en dos incidencias reales de un equipo de desarrollo con el que trabajamos, con sus números y con lo que no podemos decir a partir de ellos.
La idea que defiende este insight: en esas dos incidencias no solo cambió el tiempo: el equipo alcanzó un nivel de pruebas y validación que no había alcanzado antes. Y como son solo dos, no te pedimos que nos creas: te damos el ejercicio para que lo estimes con tu equipo y lo compruebes.
Las dos incidencias
Son dos incidencias de un equipo de desarrollo con el que trabajamos. No decimos cuál es el cliente ni su sector, para que no se pueda identificar. Estos son los tiempos, tal como los hemos registrado:
Son dos incidencias, no un estudio. No hay una media, no las extrapolamos al trabajo de un equipo entero y no sabemos cuánto de la diferencia se debe al método, cuánto al contexto que se preparó y cuánto a la propia forma de trabajar del equipo. La estimación es una previsión del equipo, no una medición, y quien lo cuenta es parte interesada.
Qué incluye el tiempo real
La hora y las 3 horas son el trabajo completo de cada incidencia, no solo escribir código. Y ese trabajo incluyó un nivel de pruebas y validación que el equipo no había alcanzado antes. Es el dato que más nos importa: no se tardó menos a cambio de comprobar menos, sino que se tardó menos y se comprobó más a la vez.
Por eso, si tu equipo mide solo horas, mide la mitad. Mide también qué se comprobó: pruebas añadidas, validación hecha, qué llegó a revisión. Es la línea de qué medir en un equipo de desarrollo con IA: entrega y calidad, no líneas de código.
Quién lo hizo y quién estimó
El trabajo se hizo conjuntamente con el equipo del cliente, no por nuestra cuenta: con todo el contexto de documentación del proyecto y con los agentes y skills que aplicamos habitualmente (las skills son instrucciones reutilizables que el agente sigue en cada tarea: cómo especificar, cómo probar, qué revisar). El equipo trabajó con el método y onext lo acompañó. Las estimaciones de 9 y 50 horas las hizo el equipo que trabaja habitualmente con esas incidencias, con su forma habitual de trabajar.
Por qué creemos que pasó
Es nuestra lectura, no una medición. No creemos que el agente teclee más rápido. Creemos que la especificación delimita qué hay que cambiar y cómo se comprobará antes de tocar código, que el agente trabaja dentro de ese marco y que una persona decide donde hay riesgo. Es el método que explicamos en AI-Accelerated Development.
También hay trabajo en el que el método compensa menos: un cambio trivial no necesita una especificación. Lo desarrollamos en cuándo compensa el SDD y cuándo sobra la especificación, con datos de un estudio de terceros. Este insight es el complemento con datos nuestros, pocos y con sus límites.
Compruébalo con tu equipo
No te pedimos que te fíes de dos incidencias. Te proponemos un ejercicio en dos pasos con el que sacar tus propios números:
- Descarga el ejercicio y estímalo con tu equipo. Está en el repositorio de ejemplo del taller y en la presentación en PDF. Estimadlo como estimaríais cualquier tarea, con vuestra forma habitual de trabajar, y apuntad la cifra antes de empezar. Apuntad también qué incluye: pruebas, validación, revisión.
- Compruébalo en el taller online del jueves 26 de noviembre (16:30–18:00, gratuito, 90 minutos). Haz el ejercicio tú mismo e inscríbete en el taller. Si prefieres hacerlo por tu cuenta, el repositorio explica la preparación.
Dos incidencias no demuestran nada general. Sí son una razón para medirlo en tu equipo: con tu estimación de antes, con las pruebas que hacéis hoy y con lo que ocurre al hacerlo desde la especificación.
Por dónde seguir
Si quieres comparar notas con alguien de fuera, el diagnóstico es gratuito. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Si te interesa cómo especificar para que se pueda comprobar, lo contamos en tu spec ya es un eval y, sobre el taller de TRGCON, en TRGCON 2026: gracias por la acogida y por el debate.
Preguntas frecuentes
¿Cuánto tiempo ahorra el SDD?
No lo sabemos en general, y con dos incidencias no podemos decirlo. En las dos que contamos pasó esto: una incidencia estimada en 9 horas por el equipo que trabaja habitualmente con ella se resolvió en 1 hora en total con desarrollo guiado por especificaciones, y otra estimada en 50 horas se resolvió en 3 horas en total, las dos con un nivel de pruebas y validación que ese equipo no había alcanzado. Son dos incidencias, no una media, y no las extrapolamos al resto del trabajo.
¿Quién hizo las estimaciones de 9 y 50 horas?
El equipo que trabaja habitualmente con esas incidencias, con su forma habitual de trabajar. No las hicimos nosotros.
¿Qué incluye el tiempo real?
Todo el trabajo de cada incidencia, con un nivel de pruebas y validación que ese equipo no había alcanzado antes. Es decir, se tardó menos y se comprobó más a la vez.
¿Quién hizo el trabajo?
Se hizo conjuntamente con el equipo de desarrollo del cliente, con todo el contexto de documentación del proyecto y con los agentes y skills que aplicamos habitualmente. El equipo trabajó con el método y onext lo acompañó.
¿Cómo puedo comprobarlo en mi equipo?
Descarga el ejercicio del taller (repositorio de ejemplo y presentación), estímalo con tu equipo como estimaríais cualquier tarea, apuntad la cifra antes de empezar y después hacedlo con el método. Podéis hacerlo por vuestra cuenta o en el taller online.
¿Cuándo es el taller online y cuánto cuesta?
El jueves 26 de noviembre de 2026, de 16:30 a 18:00. Es gratuito, dura 90 minutos y el aforo es de 27 personas. La inscripción está en la página del taller.
Fuentes
- Datos de las dos incidencias: onext y el equipo de desarrollo con el que trabajamos. No publicamos el detalle para que el cliente no sea identificable.
- Taller de SDD de TRGCON 2026 (conferencia de desarrollo de software, Madrid): repositorio de ejemplo y presentación (PDF).
- No hay fuentes externas: este insight cuenta datos propios de onext y no cita estudios de terceros.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →