Luego de que en febrero (2026) les dejara un «Hola, mundo» con el Sintonizador de Tono y les prometiera la anatomía de una Spec para un siguiente artículo, tomé una decisión diferente: la de esperar a ver qué ocurría con SDD. Todo está cambiando muy rápidamente y quise ser prudente. Eso sí, no dejé de trabajar con SDD, mucho menos con IA. Ni de hacer experimentos. Prueba de ello fue mi artículo de hace un par de meses sobre lo determinístico y lo probabilístico en el desarrollo de software con IA.

Pueden leer esos artículos en

Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA

Y el del espejismo del control en

El espejismo del control: Cuando lo determinista se topa de frente con lo probabilístico

Sigo en deuda con lo de la morfología de la Spec, lo admito, pero creo que es algo que pueden encontrar muy fácil en la Web o con la ayuda de alguno de los LLM que circulan por allí. He estado escribiendo un libro sobre todo esto, ya veremos si vale la pena publicarlo. Por ahora, quiero contarles lo que pasó mientras tanto, que incluso fue bastante más de lo que yo imaginaba cuando escribí aquel artículo desde mis recuerdos de 1987.

En febrero el SDD era una idea que defendíamos algunos con entusiasmo y casi sin datos. Hoy hay datos. A veces parecen muchos, aunque quizás son pocos; en cualquier caso, son datos discutibles y a ratos incómodos, pero hay. Y lo primero que dicen es que escribir la spec era la parte fácil. De hecho, este artículo se iba a llamar “Escribir la spec era lo fácil: el año en que SDD dejó de ser una moda y empezó a cobrar la cuenta”, pero preferí este otro que ya dejaba entrever el camino que iba a tomar.

Casi medio millón de archivos

En agosto, Shyam Agarwal y Bogdan Vasilescu publicaron SpecMine, un corpus con 470.795 archivos de especificación recogidos en 73.030 repositorios públicos, producidos con herramientas como Spec Kit, Kiro y OpenSpec, casi todo desde 2025. Me gustan los corpus, mi favorito es el CORPES XXI de la Real Academia de la Lengua, pero eso es otra historia. Ahora, léanlo otra vez, que yo también lo hice: más de setenta mil repositorios. Cada archivo tiene un autor en el historial de git. Quién es el dueño de cada decisión que contiene es otra pregunta, y es la que nadie está respondiendo.

Otro trabajo, montado sobre ese corpus, cruzó 266 repositorios con 154 publicaciones de Reddit y 21 entrevistas para averiguar cuánto se revisan las specs y quién las escribe. Esta fue una de las cuestiones que más vueltas me dieron este año y lo discutí con amigos y colegas bajo el precepto de “no están revisando las specs”. Que haya que averiguarlo ya dice bastante. Mi respuesta de bolsillo (la IA redacta, uno retoca) no vale como dato. Lo que sí tengo firme es que la misma spec, retocada a mano por mí, me ha devuelto resultados distintos más de una vez. Cuánto retoca el resto del mundo, quiero verlo con números.

También este año, B. Hill, en las actas del ESEM 2026, les hizo a las herramientas la pregunta que preferían no recibir: ¿escribir la spec reduce los defectos? Revisó 88.052 pull requests de 119 repositorios y ninguna de sus cinco hipótesis se sostuvo. La calidad de la spec no predijo defectos ni retrabajo, y las specs tampoco acotaron el alcance de los cambios hechos con IA. Lo que sí apareció fue una explicación muy humana: uno escribe spec para lo más difícil, así que las specs andan donde andan los problemas. Aunque muchos ni siquiera se toman el trabajo de revisarlas, mucho menos de escribirlas. Sigue siendo mi hipótesis.

Ahora la salvedad que importa. Hill midió referencias a issues y tickets, porque ningún repositorio de su muestra subía los archivos de Spec Kit, y los autores de SpecMine avisan que sus resultados no se pueden comparar con los de él. Esto me dejó a mitad de camino porque no pude concluir a partir de allí si el SDD falla o no. Eso sí, sé que la promesa de menos defectos que vendimos todo el año no tiene todavía respaldo medido. Un practicante, Eberhardt, según recoge el mismo trabajo, midió Spec Kit unas diez veces más lento que iterar sin él, con miles de líneas de spec de por medio. Así que si en sus empresas van a apostar por esto, midan antes de aplaudir: defectos que se escapan y retrabajo por cambio, con spec y sin spec, en el mismo equipo. Es lo que hizo Hill, solo que con 88 mil cambios.

Advertencia: Antes de que se me olvide, les dejo al final los enlaces a estos trabajos y publicaciones. Solo leí apartes de estos trabajos. La razón principal es que apenas son una pequeña porción de fuentes de las muchas que he estado consultando para enterarme de en dónde estamos y para dónde vamos con esto de desarrollo agéntico. Pero los subí a Gemini Notebook e hice las preguntas que me parecieron de interés, entre ellos las de los datos que estoy usando aquí. Y antes de que me cuestionen, les confirmo que sí verifiqué una a una las respuestas de la herramienta contra las fuentes primarias. Con esta premisa, sigamos mirando qué pasó este 2026.

En abril, Pardis Taghavi y Santosh Bhavani le pusieron nombre a algo que muchos vivimos: los agentes se quedan ciegos de contexto. Entregan una spec, un plan y unas tareas coherentes entre sí que no encajan con el código que ya existe, con API inventadas y rutas que no están. Su remedio no tiene nada de glamoroso: antes de cada fase, un paso de solo lectura que mira el repositorio, y después, otro que valida lo que salió. En 128 ejecuciones sobre 32 funcionalidades y cinco repositorios, la calidad subió 0,15 en una escala de 1 a 5 (un tres por ciento, para que no nos emocionemos) y las pruebas existentes siguieron pasando entre el 99,7 y el 100 %.

Eso se puede copiar mañana. Antes del plan, pídanle al agente un inventario del repositorio en un archivo que ustedes lean: módulos, convenciones, dependencias. Después del plan, que compruebe que cada ruta y cada librería que nombró existe de verdad. Es una tarde de configuración, y se acaba la sorpresa de descubrir en la revisión que el plan hablaba de un módulo que no existe.

Subham Panda, en julio, comparó tres maneras de amarrar requisito y código con dos modelos (Claude Sonnet 4.6 y GLM-5-turbo). En una de ellas, cada línea de código cita el identificador del requisito que la autoriza, algo como REQ-014.2 en un comentario. Si el código cita un requisito que no existe en la spec, ahí hay una invención. Con ese mecanismo detectó el 86,4 % y el 88 % de las alucinaciones, según el modelo, sin un solo falso positivo. Spec Kit y OpenSpec, que enlazan por artefacto o después de escribir el código, no detectaron ninguna de forma automática. El precio: con citas, el mismo encargo repetido produce resultados menos parecidos entre sí. Es mi espejismo del control de agosto con números: o detectas lo que nadie autorizó, o consigues salidas más parecidas, pero las dos cosas a la vez todavía no. Además, detectar no es impedir, y eso se nos olvida. Si quieren probarlo sin comprar nada: numeren los requisitos de su spec (REQ-001, REQ-002…), pídanle al agente que cite el número en un comentario junto a cada bloque de código y corran un script de diez líneas que busque citas a números que no existen. Con una funcionalidad pequeña se ve en media hora. ¡Qué fácil es hacerlo con IA!

De vuelta al inicio

Para ver con mis propios ojos eso de que la IA completa lo que uno no dijo, pasé el Sintonizador de Tono que les dejé en mi publicación de febrero por el recorrido de Spec Kit, con las instrucciones tal como están en su repositorio al 30 de octubre y una constitución mínima: los cuatro principios del artículo de agosto. Con el comando que redacta la spec le pedí al agente que adivinara con criterio lo que no se dijo, que anotara la suposición en una sección de supuestos y que hiciera como máximo tres preguntas. La retención de datos aparece en su lista de valores por defecto sobre los que ni siquiera hay que preguntar.

Salieron doce decisiones que yo no había tomado. El agente hizo dos preguntas, y las dos eran sobre contradicciones mías: en la descripción, la tercera variante es «Mínima (estilo Gen-Z)», y en el prompt es «Minimalista», máximo quince palabras. Cuatro quedaron a la vista como supuestos: dos mil caracteres de límite, sin cuentas ni historial. Las otras seis nadie las nombró y pasaron al plan disfrazadas de detalle técnico: el modelo y la temperatura, el envío del mensaje completo (con nombres, con todo) a un tercero sin avisarle al usuario, el registro del texto original «para depurar», un tope de diez peticiones por minuto, qué hacer si el modelo devuelve un JSON roto y qué cuenta como «palabra» en la prueba de las quince. De esa última me reí: la definió el agente, la probó el agente y la pasó el agente.

La constitución, a la que yo le tenía fe, frenó lo que yo había pensado. Nada de secretos en el código, y la llave terminó en una variable de entorno. Del mensaje del usuario, lo más delicado de toda la aplicación, no decía una palabra, y por eso no frenó nada. Peor aún, mi cuarto principio («si no se puede probar automáticamente, no entra a la Spec») empujó al agente a volver mecánico el «suena cálido»: la variante empática debía contener alguna expresión de una lista de validaciones que él mismo armó. El agente obedeció mi regla al pie de la letra y, de paso, cambió lo que yo quería decir. Háganlo ustedes con su agente y su spec, les toma unas muy pocas horas, y cuéntenme qué decidió el suyo.

Ahora, lo que sigue sin cumplirse y lo que viene

Regenerar todo desde la spec, a mi juicio, no está listo. El estudio de Hill no vio que las specs acotaran los cambios de la IA, Panda mostró que la trazabilidad cuesta consistencia, y yo sigo recibiendo cinco soluciones distintas con cara de que funcionan. La spec sirve, y mucho, como contrato que alguien firma. Como botón de regenerar, todavía me falla. Y cuando hay una DIAN o una Superintendencia de Salud de por medio, con sus documentos de cientos de páginas, el asunto se pone peor, que de eso ya les conté en octubre.

Para 2027 creo que la conversación se mueve de los documentos en Markdown hacia contratos que una máquina pueda comprobar, y hacia verificaciones que no repitan el mismo error de interpretación con cinco nombres de rol distintos. De eso hablamos pronto. Mientras tanto, te dejo una pregunta incómoda, de esas para antes de dormir: cuando el pipeline pasa a verde, ¿a quién le atribuyes cada cosa que ahora funciona?

Referencias

Mis artículos previos sobre el asunto:

Deja una respuesta