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
Y el del espejismo del control en
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
· SpecMine,
Agarwal y Vasilescu (25 de agosto de 2026).
https://arxiv.org/pdf/2608.25202
· resumen: https://www.alphaxiv.org/abs/2608.25202
·
Hill, Specification
Artifacts in Open-Source Pull Request Workflows Do Not Reduce Defects (ESEM
2026).
https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.ESEM.2026.84 · PDF: https://drops.dagstuhl.de/storage/00lipics/lipics-vol394-esem2026/LIPIcs.ESEM.2026.84/LIPIcs.ESEM.2026.84.pdf
· Spec
Kit Agents, Taghavi y Bhavani (abril de 2026).
https://arxiv.org/pdf/2604.05278
· Citation Discipline in Spec-Driven
Development, Subham
Panda (julio de 2026).
https://arxiv.org/pdf/2606.30689
· https://www.emergentmind.com/papers/2606.30689
· https://chatpaper.com/paper/305711
Mis artículos previos sobre el asunto:
· https://www.luchosalazar.me/2026/10/apuntes-sobre-transformaciones-agiles.html
No hay comentarios.:
Publicar un comentario