Medio millón de specs y ningún dueño: lo que 2026 le hizo al Spec-Driven Development

 

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

https://luchosalazar.com/2026/02/10/specification-driven-development-un-nuevo-orden-en-el-desarrollo-de-nuevo-software-con-ia/

Y el del espejismo del control en

https://luchosalazar.com/2026/08/30/el-espejismo-del-control-cuando-lo-determinista-se-topa-de-frente-con-lo-probabilistico/

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://luchosalazar.com/2026/02/10/specification-driven-development-un-nuevo-orden-en-el-desarrollo-de-nuevo-software-con-ia/

·       https://luchosalazar.com/2026/08/30/el-espejismo-del-control-cuando-lo-determinista-se-topa-de-frente-con-lo-probabilistico/

·       https://www.luchosalazar.me/2026/10/apuntes-sobre-transformaciones-agiles.html

 

Apuntes sobre transformaciones ágiles VI: inteligencia artificial, estupidez organizacional

 

Algo debemos estar haciendo bien. O quizás no tanto.

Llevamos años intentando transformar las organizaciones. Llegaron Scrum, Kanban, las tribus, los escuadrones, los OKR, los nuevos modelos de liderazgo y toda una colección de nombres para hacer las cosas de otra manera. Algunas empresas cambiaron de verdad.

Otras aprendieron a presentar muy bien sus viejas costumbres en las conferencias de moda. Lo sé bien. Estuve ahí sentado mientras alguien presentaba sus “números”, aunque casi todos en el salón sabíamos que la realidad era otra.

Y ahora llegó la inteligencia artificial. El asunto se pone interesante.

Pensemos en un banco. Incorpora IA para que sus asesores respondan mejor las solicitudes de los clientes. La herramienta resume conversaciones, consulta información y redacta respuestas en segundos. Una maravilla. Pero el asesor todavía tiene que copiar la respuesta en otro sistema, llenar formularios, pedir autorizaciones y esperar a que otra área dé el visto bueno. El cliente sigue esperando. El banco automatizó una tarea, pero dejó intacto el problema.

El caso más sonado, al menos entre los consumidores finales, es el de los infames chatbots que pululan a diestra y siniestra. Una cadena de almacenes estrena uno de ellos, nuestra flamante IA vía WhatsApp para atender reclamos. Un paso más allá en la evolución de la inteligencia. ¿En serio? Compré un aire acondicionado que llegó con la tapa abollada y escribo. El bot me saluda con “mucho cariño” y me da un menú de cinco opciones, ninguna dice “llegó dañado”. Escribo “asesor”, “humano”, “persona”, “people”, “¿hay alguien allí?” “por favor”. No entendió. Al final el cambio exige ir a la tienda con la factura impresa, cosa que el bot nunca dijo. Y el tablero marca ocho de cada diez conversaciones resueltas sin intervención humana. ¿Resueltas, o el cliente se rindió? (Yo sí). El tablero no distingue.

Podemos discutir si el modelo de IA es el mejor del mercado, si el prompt está bien escrito o si necesitamos un agente que automatice los pasos siguientes. Todo eso puede importar. Pero el problema de fondo es otro: un proceso que obliga al cliente a esperar mientras la organización tramita internamente una solución que, en muchos casos, podría entregar antes.

Quizás algunas aprobaciones sean necesarias. Estamos hablando de un banco o de una cadena de supermercados, después de todo, y hay riesgos que no podemos ignorar. Pero también hay controles que sobreviven por costumbre, decisiones que podrían tomarse más cerca del cliente y pasos que nadie se ha atrevido a cuestionar. Rediseñar el proceso implica distinguir unos de otros, sin sacrificar la seguridad ni convertir la eficiencia en una excusa para hacer las cosas a la ligera.

Ahí es donde empieza a ponerse interesante la conversación sobre IA y transformación organizacional.

Una empresa puede comprar una herramienta extraordinaria y utilizarla para ejecutar un trabajo que nadie se ha detenido a cuestionar. Puede reducir minutos en una tarea y conservar intactas las horas de espera. Puede procesar más solicitudes y seguir ofreciendo una experiencia mediocre. Incluso puede terminar generando más trabajo: ahora hay que revisar lo que produjo la IA, corregirlo, aprobarlo y documentar que alguien lo aprobó.

¡Vaya manera de ganar productividad!

En mis apuntes anteriores sobre transformaciones ágiles he insistido en algunas de estas contradicciones. Queremos autonomía, pero nos cuesta soltar el control. Hablamos de experimentación, pero castigamos el error. Contratamos expertos que llegan con recetas que juran no ser recetas. Copiamos las estructuras del vecino y luego nos sorprendemos cuando no obtenemos los mismos resultados. Y, cuando el cambio no ocurre, decimos que la gente se resiste.

Ahora podemos añadir otro ingrediente a esta receta: la IA.

La tentación será (es) enorme. Automatizar los procesos existentes, producir más código, documentos, análisis y reportes. Todo en menos tiempo y, quizás, a menor costo. Pero producir más no garantiza que estemos resolviendo mejores problemas. Tampoco significa que hayamos aprendido a trabajar de otra manera.

Por eso, antes de incorporar IA a un proceso, yo empezaría por entender qué problema queremos resolver y qué partes del trabajo realmente aportan valor. Revisaría los controles, las dependencias y las decisiones que alargan el recorrido hasta el cliente. Después sí, experimentaría con la tecnología. Mediría el resultado completo, desde que aparece la necesidad hasta que el cliente obtiene una solución. Si solo medimos el desempeño de la herramienta, corremos el riesgo de celebrar una mejora que nadie siente.

Con la agilidad, todos queríamos parecernos a Spotify o a Netflix y “copiábamos y pegábamos” los modelos de estas empresas sin tener en cuenta el contexto, pero la gran mayoría de las organizaciones que conozco, sobre todo en este lado del hemisferio occidental, no se parecen en nada a Spotify o a Netflix. Hoy con la IA, todos queremos desarrollar software como lo hacen Anthropic u OpenAI, pero, otra vez, no somos ni la una ni la otra, ni remotamente parecidas.

Con el advenimiento de la IA generativa a muchos se les olvidó que el desarrollo de software tiene todo un proceso previo que es cuesta arriba, sinuoso, lleno de baches que parecen abismos, pletórico de ambigüedades y fijado por una visión poliédrica que nadie entiende realmente, pero que a su vez nadie está dispuesto a contradecir ni a pedir aclaraciones para que no supongan que no son aptos para el rol que ejecutan; es un proceso que empieza con la idea de alguien por algún motivo interno o externo a la empresa y todo lo que pasa desde allí hasta el justo instante en que le decimos al agente "genere" está lleno de incertidumbre y caos.

Porque una cosa es un Anthropic generando un software para algo que todavía no existe, o una startup o similar generando un producto que quiere llevar al mercado, y otra muy diferente es ajustarse a la normatividad de la DIAN o la ley Sarbanes Oxley o a la Super Salud con sus entregables de setecientas treinta y dos páginas y media a un espacio con quince puntillos, y esperar a que el área Jurídica interprete y proporcione pautas, y luego se ponga de acuerdo con Operaciones, y estos con Riesgos, y aquellos con los otros, y luego llamen al proveedor (hoy fábrica agéntica) al que finalmente le entregan el documento original sin ninguna otra salvedad ni comentarios adicionales... pasan meses... a veces años. Y simplemente nadie sabe qué quiere ni para qué era ni por qué. Solo que si no está en ejecución el 17 de diciembre lo multan.

Y hay otra cosa. No podemos pedirle a la IA que nos ayude a transformar la organización mientras seguimos premiando exactamente los comportamientos que impiden esa transformación. Si un jefe/supervisor necesita aprobarlo todo, el equipo seguirá esperando. Si equivocarse tiene consecuencias desproporcionadas, la gente esconderá sus errores. Si el éxito se mide por la cantidad de trabajo producido, produciremos más, aunque buena parte no sirva para nada. Sigue estando sobre la palestra el “como me midas me comporto” y el oscuro “si le das un número que obtener a un gerente, este lo conseguirá, así tenga que destruir la empresa para lograrlo”. La tecnología (léase IA) puede cambiar las condiciones del juego, pero las decisiones sobre cómo jugamos siguen siendo nuestras.

Después de tantos años hablando de transformación organizacional y todos sus derivados, esta me parece una buena oportunidad para revisar unas cuantas cosas. Empezando por nosotros mismos. Conviene distinguir los controles necesarios de aquellos que conservamos porque nos cuesta renunciar a ellos, revisar los procesos cuyo propósito original hemos olvidado y reconocer los experimentos que evitamos por miedo a quedar mal. También vale la pena mirar con cuidado eso que llamamos resistencia al cambio: a veces es resistencia a perder poder, comodidad o certezas.

Sin duda alguna, la IA nos da una oportunidad enorme para revisar el trabajo, redistribuir decisiones y eliminar obstáculos que durante años hemos considerado inamovibles. Pero aprovecharla requiere algo más que licencias, asistentes y agentes. Requiere curiosidad, pensamiento crítico y disposición para cambiar aquello que ya no tiene sentido. ¿Estamos dispuestos a hacer esta revisión profunda en nuestros comportamientos organizacionales? Yo creo que no.

Pero si no lo hacemos, terminaremos con organizaciones capaces de producir cantidades extraordinarias de trabajo y que seguirán resolviendo los problemas de siempre con las mismas reglas de siempre. Y después nos preguntaremos por qué la transformación no funcionó y por qué entramos a engrosar los estudios que señalan la infausta carga de no estar obteniendo ROI con IA.

Sin embargo, una vez más, ahora que la IA entra al juego, tenemos una razón más para cuestionar las reglas, no una excusa para dejar de hacerlo.

 

Acerca de los apuntes sobre transformaciones ágiles

Los apuntes anteriores conforman uno de los capítulos centrales de mi libro Cultura ágil: ese oscuro objeto del deseo y que lleva ese mismo título. Los escribí entre 2018 y 2022 en mi Gazafatonario. También los puedes leer en cualquier orden a partir de:

Gazafatonario IT: Apuntes sobre transformaciones ágiles

De exigir resultados y la inteligencia colectiva

Exigir resultados a una persona, a un equipo, no los garantiza.

Este era uno de mis mantras desde hace 2 décadas o más. Era un escenario típico con jefes y "líderes" que traían arraigadas prácticas de gestión del siglo pasado, incluso del anterior a ese.  

Pero sigue vigente, en pleno último trimestre de 2026. Y no, exigirle resultados a un equipo agéntico o a un equipo humano apoyado con IA no logra mágicamente que eso suceda. Ni siquiera con todo el poder actual de la inteligencia artificial.

Lo que sí funciona es el trabajo colaborativo, la inteligencia colectiva, el "meterse en el barro" junto con la orden o la idea, la comunicación bidireccional, el "te doy el tiempo que necesitas".

Pero ojo, eso tampoco quiere decir que "empezamos y en el camino vamos arreglando las cargas". La planificación -la "buena" planificación- está más vigente que nunca. Y el compromiso. Y el darlo todo por lograr un objetivo. Y el solicitar ayuda cuando lo veas necesario. Otro de mis mantras de siempre.

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

 

"El mayor peligro de la inteligencia artificial es, sin duda, que la gente llegue a la conclusión demasiado pronto de que la entiende". – Eliezer Yudkowsky.  ("Artificial Intelligence as a Positive and Negative Factor in Global Risk." Oxford University Press.)

Hace algunos meses escribí sobre Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA, donde conté de dónde vengo con esto de las especificaciones, treinta y nueve años después de mis primeros intentos de generar código sin tener que escribirlo línea por línea. Desde ese artículo no he parado. Sigo experimentando con SDD, spec tras spec, equipo tras equipo, casi con obsesión, tratando de sacarlos de la burbuja de la innovación donde muchos siguen atrapados: esa donde se hacen demos brillantes, PoC que enamoran en una presentación de viernes y el lunes siguiente nada llegó a producción, nada le cambió la vida a un usuario real.

Y en medio de ese experimento permanente me tropecé, otra vez, con la misma pregunta de siempre disfrazada de tesis novedosa: ¿quién gobierna lo que la IA hace con tu especificación? ¿Se puede tener gobernanza determinista sobre algo que, por diseño, no lo es?

Para responder a esta cuestión, volví a hacer un repaso de treinta años por los vericuetos de lo que significa una buena especificación de requisitos, hoy simplemente llamada “Spec” por obra y gracia de las nuevas tecnologías, y reviví aquellos atributos de claridad, precisión y verificación, entre otros (todo eso que aprendí, practiqué y promulgué con la IEEE 830 hace tantos años), y lo contrasté con el comportamiento que estoy observando en los practicantes actuales, sobre todo, con lo que sucede después de su elaboración, cuando esa Spec entra a un motor que, por naturaleza, no es determinista. La conversación deja de ser sobre requisitos justo ahí y se convierte en algo más incómodo.

En todo caso, la respuesta corta es “Sí”. Aunque no de la forma en que se la imagina la mayoría de los comités de "gobernanza de IA", sentados en su sala de reuniones creyendo que van a agarrar el toro por el cachos con una hoja de Excel.

La gobernanza, por naturaleza, es determinista: roles y responsabilidades fijas, políticas escritas, umbrales, puntos de aprobación, guardada bajo signos de pulcritud en los anaqueles de la gerencia de turno y sellada con incontables ISO numeral que ya nadie en la empresa recuerda, eso no cambia, así era hace 50 años y seguirá siendo así cuando nosotros ya no estemos. Lo que sí cambia es el elemento que estás tratando de gobernar. Escribí sobre esto hace más de una década hablando de Scrum y hace más de dos hablando de RUP y CMMi: las reglas del ajedrez son pocas y sencillas, pero el medio juego (esa zona donde ya no hay libro de aperturas que valga) es puro criterio, improvisación, riesgo calculado. Lo conté, por ejemplo, en Antipatrones Scrum: primer acercamiento, citando al mismísimo Schwaber: las reglas del juego son deterministas, las jugadas no.

Con la IA que escribe código pasa lo mismo, multiplicado. No puedes gobernar la línea exacta que un modelo va a escribir a las tres de la tarde con la temperatura configurada en 0.7. Gobiernas el tablero: la especificación de entrada, las reglas del entorno, los criterios de aceptación, quién firma antes de que esa pieza se mueva a producción. Y en casi todos los comités de "IA responsable" a los que me han invitado veo el mismo tejemaneje: terminan gobernando el proceso convencidos de que están gobernando el resultado, y ese resultado, con un sistema probabilístico, sencillamente no se puede garantizar. Retomo entonces al influyente, aunque controvertido Yudkowsky que cité arriba: el riesgo más grande aparece justo cuando crees que ya entendiste lo suficiente lo que está pasando y cómo está sucediendo como para bajar la guardia.

Lo que sí se puede gobernar

Pensándolo en capas, como aprendí a concebir los requisitos hace más de tres décadas:

La intención. La especificación sigue siendo el contrato, ese protocolo entre el humano y la máquina. Esto viene de mucho antes de ChatGPT, aunque hoy todo el mundo actúe como si se hubiera inventado la semana pasada. Escribí largo y tendido sobre esto en mi era preágil, cuando todavía creía que un documento de veinte, cien o hasta de doscientas páginas podía atrapar la realidad de un sistema, y terminé dejando consignada buena parte de esas ideas en mi libro Asuntos de la Ingeniería de Software, Volumen 2. Pero hoy, además de hablarle a otros humanos y de servir de apoyo al entendimiento entre las partes (humanas) sobre la solución que queremos, esa especificación le “debe” hablar a un sistema que traduce la intención en código sin ninguna garantía de hacerlo igual dos veces seguidas. Gobernar la calidad y la trazabilidad de esa especificación es la palanca más poderosa que existe. Si la Spec es floja, la gobernanza solo será ornamental.

Las barreras. Políticas convertidas en código: qué dependencias se prohíben, qué patrones de seguridad son obligatorios, qué licencias no se tocan ni con guante ni pinzas. Esto es determinista de cabo a rabo, y se automatiza sin pedirle permiso al modelo. Se aplica después, sobre lo que salió, sin importar cómo se generó.

El proceso y los puntos de control humano. Llevo años repitiendo esto hasta el cansancio: inspeccionar y adaptar no es un evento de calendario, es una actitud. Lo escribí en Nuestro Scrum empírico de todos los días y volví sobre ello en Mis notas sobre el Corazón de la Agilidad: sin esa reflexión constante, un equipo (o una organización entera) queda atrapado usando procesos que ya no sirven. Una Definición de Terminado sigue mandando, escribí acerca de esto en Sobre multifuncionalidad y la creación de un incremento de producto: llegar a la mitad del camino sin que nada alcance esa definición ya era mal presagio antes de que existiera un modelo generando el código por ti. La IA no se aprueba a sí misma su propio trabajo, faltaba más. Esa firma sigue siendo, y debe seguir siendo, humana.

La trazabilidad. Qué modelo generó qué, con qué prompt, bajo qué versión, aprobado por quién. Normas advenedizas como la ISO/IEC 42001 llegaron para que intentemos asegurarnos de que exista alguien a quien preguntarle después.

Esto ya existe: la constitución como artefacto de gobernanza

Miren, esto ya se puede tocar. En el ecosistema de Spec-Driven Development circula un archivo que hace exactamente lo que vengo describiendo: spec-kit, la herramienta de GitHub para SDD, te obliga a escribir un constitution.md antes de tocar una sola Spec, y ese archivo pesa: es el documento que la IA tiene que respetar, sí o sí, antes de generarte una línea de código. Algo así:

# Constitución del proyecto

 

## Principio 1: Ningún código a producción sin revisión humana

Toda funcionalidad generada por IA pasa por al menos un revisor humano antes de fusionarse.

 

## Principio 2: TDD no negociable

No se escribe implementación antes de que existan pruebas, aprobadas por una persona, y esas pruebas fallen primero.

 

## Principio 3: Cero secretos, cero dependencias sin licencia

Ninguna llave, token o credencial embebida. Ninguna dependencia sin licencia verificada.

 

## Principio 4: Todo criterio de aceptación debe ser verificable

Si no se puede probar automáticamente, no entra a la Spec.

En este último, como pregoné tantas veces en el pasado, podemos usar buena parte, si no toda la gobernanza de requisitos de la IEEE 830 o de los criterios FURPS+. Esta vez no entraré en detalles de algo que dejé claro hace más de 20 años, pero que quizás pueda volver a recordarles pronto.

En todo caso, ahí están: cuatro principios, cero ambigüedad. Listos para que los incorpores a tus propios desarrollos. Fíjate que ninguno le dice al modelo qué código escribir, eso ni siquiera les compete. Lo que hacen es fijar bajo qué condiciones ese código tiene permiso de existir, que ya es bastante. Esa tabla de cuatro renglones resume toda la diferencia entre gobernar el proceso y gobernar el resultado.

A propósito, valga la pena decir que, aunque OpenSpec no incluye explícitamente una "constitution.md" al estilo de Spec-Kit, nada evita crearla y ponerla en una capa de principios permanentes paralela a AGENTS.md, por ejemplo, con versionamiento, con un dueño explícito, con reglas concretas, entre otros aspectos, y referenciarla desde el flujo de OpenSpec. Este asunto está fuera del ámbito de este artículo, pero regresaré también a ello en otra oportunidad.

Lo que no se puede gobernar, aunque te vendan lo contrario

Hay que seguir anunciándolo a los cuatro vientos, como si se tratara de "la exhibición del más fabuloso hallazgo de los nasciancenos": el razonamiento interno del modelo no se gobierna. La línea exacta de código, tampoco. Ni siquiera puedes prometer que el mismo prompt, dos veces, te devuelva lo mismo. Un desarrollador senior con experiencia, frente a un problema nuevo, casi siempre converge hacia soluciones parecidas cuando entendió bien el encargo, al menos, ese era mi caso. Un modelo generativo, no. Le pides lo mismo cinco veces y te devuelve cinco soluciones distintas, todas con cara de que funcionan.

Lo he vivido con mi propia sangre, mientras experimento y ayudo a otros a experimentar con SDD: misma intención, distinta spec; misma spec modificada manualmente por mí sin llegar a la estrechez absurda de la restricción perfecta, distinto resultado. No una, no dos. Varias veces.

Y tampoco puedes prometer corrección garantizada para problemas verdaderamente nuevos. Esa fue siempre una promesa incumplida de la ingeniería de software prescriptiva, y la IA tampoco la va a cumplir ahora. Lo único que hace es ponernos esa promesa incumplida en la cara, sin anestesia. Cuarenta años desarrollando software me soportan.

¿Hasta qué punto, entonces?

Hasta que dejes de perseguir una certeza que, sencillamente, no vas a conseguir, y empieces a trabajar con algo bastante más útil: confianza calibrada. ¿Como así?  Sí, capas deterministas alrededor de un núcleo que no lo es. Verificación automatizada que no se preocupa por cómo llegaste al resultado, sino por lo que eres capaz de demostrar. Y personas (sí, humanos) con poder real para decir “no” cuando equivocarse cuesta caro. Eso es defensa en profundidad aplicada a un problema que antes ni siquiera teníamos. Y hay otra cosa: también tienes que aprender a delegar en la IA. Sí, delegar. Como antes lo hacías con tus pares o con las personas que estaban a tu cargo.

La gobernanza de IA para desarrollo de software se mete en las circunstancias bajo las que el código puede nacer, en qué pruebas tiene que sobrevivir y, sobre todo, en a quién le toca firmar cuando algo estalla en producción. Eso es, prácticamente, todo lo que alcanza a tocar. El código en sí mismo, línea por línea, queda fuera de su alcance directo, y cualquiera que te prometa lo contrario te está intoxicando con un tufillo disfrazado de perfume cinco estrellas mientras deja en tu escritorio la PPTx con la que harás alucinar a todos en el próximo comité corporativo.

Hace unos meses escribía que de nada sirve tener una Definición de Terminado impecable si, sprint tras sprint, no estás entregando valor real ni moviendo la aguja del negocio (lo dejé registrado en Tu Definición de Terminado no funciona y lo sabes). Con la IA pasa exactamente igual, solo que ahora hay más comités, más checklists, más gente convencida de que un marco de vigilancia es lo mismo que un producto que a alguien le importe.

Todo lo anterior para decirte que si me preguntas qué prefiero, un desarrollo blindado en gobernanza que no aporta valor real, o un desarrollador con IA que entrega, sin pedir tanto permiso, algo que el cliente ama de verdad, prefiero lo segundo cada vez. Y que los marcos de inspección se acomoden a esa verdad. No al revés.

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

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

Dime de dónde vienes y te diré para dónde vas

En el pasado “soñábamos” con pasar de los diseños de software modelados en alguna herramienta de “cuarta generación” al código sin tener que escribirlo. Mis primeros intentos de generar software datan de 1987 cuando trabajé con mi profesor de algoritmos y luego de sistemas expertos Fabián Ríos y mi amigo Fabio Ruíz en un compilador para el lenguaje LEXICO (creado por Fabián) para el cual también hicimos algunos traductores a los lenguajes populares de la época: C, Pascal, C++ y BASIC, entre otros, y creamos un entorno de programación que permitía a los nuevos estudiantes de Ingeniería de Sistemas correr y probar sus programas escritos en  LEXICO.

Con Fabián y Fabio y otros amigos fundamos el entonces Equipo de Ambientes de Programación, dedicado a estos menesteres, en los que también hicimos nuestros primeros pinitos en inteligencia artificial con el lenguaje PROLOG y con Lisp. De hecho, Fabián escribió el primer intérprete de LEXICO en PROLOG y nosotros lo probamos, mucho antes de construir el compilador.

En los 90 pasamos por las herramientas generadoras de código a partir de diagramas, en los 2000 estos diagramas eran descritos usando lenguaje UML, incluyendo los casos de uso, una técnica de especificación de requisitos funcionales y no funcionales que usábamos con la metodología RUP. Fueron intentos incipientes. Normalmente teníamos que escribir el 99,9 % del código fuente, o todo.

Escribí miles de líneas de código en más de una docena de lenguajes de programación de todo tipo. Pero dejé de programar hace 2 décadas, aunque he seguido acompañando equipos de desarrollo de software, incluso de vez en cuando todavía me llaman para resolver algún problema de rendimiento en bases de datos relacionales.

Hoy las cosas han cambiado con la inteligencia artificial. Es evidente que la tarea principal del programador cambió. De hecho, ya hemos sido advertidos de que algunas herramientas de IA podrán reemplazar a los programadores puros y duros en muy poco tiempo. Por ejemplo, y a propósito de compiladores, en Anthropic acaban de construir un compilador C con Opus 4.6 usando equipos de agentes IA en solo dos semanas, algo que dice mucho sobre el futuro del desarrollo autónomo de software. Nuestros amigos de Anthropic dicen que hasta el 90 % de su código será escrito por sus nuevas herramientas en los próximos tres a seis meses. Es solo cuestión de “cuando” el resto de nosotros lo hará. Pero llegaré a esto un poco más tarde.

El caso de los requisitos de software, los casos de uso y las historias de usuario

Cuando de desarrollar software se trata, mi mayor interés siempre fue la comunicación. Primero entre personas y luego entre personas y las máquinas. Por eso este asunto de los requisitos en todos sus colores, tamaños y sabores siempre ha estado en la palestra de mis prácticas favoritas. Y durante las tres últimas décadas he estudiado el asunto a fondo, he realizado miles de experimentos, pero también he ayudado a implementar cientos de productos de software en algunas de las más grandes empresas de Colombia y algunas de Latinoamérica.

En los 90 con requisitos a la usanza tradicional, grandes documentos de texto en “lenguaje natural”. Hice lo mejor que pude. Pero desde finales de esa década y toda la siguiente usé casos de uso. Escribí, revisé, corregí y ayudé a escribir miles de casos de uso y también diseñé, planteé arquitecturas de software, programé y probé a partir de ellos. Escribí mucho sobre el tema en mi blog Gazafatonario. Finalmente, toda esta experiencia quedó consignada en mi libro Asuntos de la Ingeniería de Software, Volumen II, aunque todos los artículos originales siguen en mi blog.

Los casos de uso eran una buena práctica, aunque bastante exigente para todos los involucrados, incluyendo el mismo usuario. Así que entré en la era “ágil” y empecé a trabajar con historias de usuario. Fui a la fuente. Extreme Programming. Lo primero que supe fue que se plantearon originalmente de manera escueta, diciendo que “son como casos de uso”, en la primera edición del libro de Kent Beck. Me pareció natural y rápidamente adopté e implementé el concepto en los equipos que acompañaba.

También, casi todo esto quedó registrado en los libros que publicara con mi gran amigo Jorge Abad, Historias de usuario: una visión pragmática, Volumen I y Volumen II. Y también, casi todo el material de estos libros pueden leerlo en nuestros blogs. El de Jorge es Lecciones Aprendidas.

Distintas técnicas, mismo objetivo: lograr que todos los involucrados entiendan lo que quiere el usuario y conseguir que todos entiendan exactamente lo mismo. Siempre fue difícil. Aunque con el enfoque ágil abreviamos los tiempos de desarrollo y entrega, en el proceso la información transmitida igual se corrompía. Lo solucionábamos más rápido, pero el retrabajo siempre estaba a la orden del día.

No me malentiendan. Yo sí puedo decir que tanto aquellas técnicas como estas son muy buenas y funcionan, con los equipos donde participé pusimos en producción muchos sistemas de información que hoy se continúan usando. De hecho, incluso los casos de uso, ni hablar de las historias de usuario, hoy reciben un nuevo aire con esto de la Spec-Driven Development con IA, que es el asunto que nos convoca.

Entra la inteligencia artificial generativa

Sé que me extendí en la historia, pero para mí era muy importante contarles de dónde vengo, ahora sí, para decirles hacia dónde voy.

Así que me voy a saltar toda la perorata de los últimos tres años, la IA no viene a reemplazarte y todo ese blablablá ampliamente difundido, comentado y embutido hasta la saciedad en nuestras mentes, e iré directo al punto: allí estaba la herramienta con la que había soñado hace cuatro décadas para generar código, pero los primeros intentos no funcionaron. Por muy buenos que eran los “prompts”, no salía nada más allá de lo que yo mismo podía hacer con otras herramientas.

Y empecé a iterar, a refinar, a usar la IA como colaboradora de primera categoría. A descargar en ella todo lo que creía que era útil para que pudiera construir mejores productos, al menos, mejores MVP. Y entonces hace por allá un año escuché o leí de SDD y las cosas tomaron su curso natural, en el fondo, era lo que había estado haciendo en los dos últimos años, alimentar o instruir a la IA con especificaciones más precisas, no ambiguas… ¡Hey, esperen! Esto me recuerda algo:

·       Instrucciones legibles

·       Otra información relevante que posea alguna influencia sobre esas instrucciones

·       Identificación unívoca de cada instrucción

·       Instrucciones correctas

·       No ambiguas

·       Completas

·       Consistentes

·       Verificables

·       Modificables

·       Trazables

Es difícil lograr todo eso de una buena vez, alguna vez, pero hay que hacer el mejor trabajo posible. Recordé aquel modelo de la IEEE 830 de 1998, el estándar de requisitos según el prestigioso Instituto de Ingeniería Eléctrica y Electrónica, bajo el cual escribí y modelé requisitos con distintas técnicas y en diferentes formatos durante muchos años.

Pero también empecé a hablarle a la IA de usabilidad, de confiabilidad, de desempeño, de capacidad de soporte e, incluso, de restricciones de diseño y requisitos de implementación. Y entonces también recordé ese otro modelo FURPS+ que complementó aquel estándar. ¡Ah, y la arquitectura! Ya llegaremos a ese nivel.

De todo esto ya escribí y publiqué. Por eso era necesario contar toda aquella historia previa. Lo de ahora es “empaquetar” todo eso en una especificación estructurada, práctica y sistemática y entregársela a una IA para que genere el código que queremos, el producto que necesitamos. Eso es, más o menos, Specification-Driven Development o SDD y no me voy a desgastar nombrándola en español como hice antes muchas veces con incontables conceptos que nacieron en inglés.

“Hola, mundo” con SDD

Un ejemplo para terminar. Así empecé hace tres décadas escribiendo sobre requisitos y casos de uso, y hace década y media sobre historias de usuario. Vendrá mucho más sobre esto, pero los dejaré con un ejemplo breve. La gran diferencia ahora es que podemos tener el resultado de esa especificación en minutos, cuando no en segundos. Y podemos iterar, ajustar, repetir, y en medio de todo ello, verificar, en muy muy muy corto lapso de tiempo. Veamos el ejemplo.

Hoy por hoy, escribir un mensaje en WhatsApp o un correo electrónico se ha convertido en algo común, pero nunca estás seguro de si suenas demasiado agresivo, muy tímido o poco profesional. La solución: una caja de texto donde escribes o pegas tu mensaje y la IA te ofrece 3 versiones instantáneas: una "Directa y Ejecutiva", otra "Empática y Amigable" y una más "Mínima (estilo Gen-Z)". ¿Te gusta la idea? A mí sí. Es un “Sintonizador de Tono Comunicacional”. Les dije que este asunto de la comunicación entre personas está en mi ADN. Aquí vamos entonces.

Una Specification para IA incluye (o debe incluir) la visión de lo que quieres:

Una herramienta de productividad diseñada para eliminar la ansiedad en la comunicación digital. Permite a los usuarios transformar mensajes crudos o mal estructurados en versiones optimizadas según el contexto social, asegurando que el mensaje sea efectivo y el tono sea el adecuado.

Incluso puedes probar eso como un prompt directo a tu IA favorita. Las posibilidades son infinitas. Pero con eso no vas a obtener lo que quieres, al menos no de inmediato. Ni siquiera en las mejores herramientas IA que existen hoy para crear productos digitales.

Una Spec también incluye la Estructura de la Interfaz (UI). Vamos con una parte de esta:

A. Panel de Entrada

Área de Texto: Un `textarea` sin bordes pesados, con una tipografía Serif o Sans-serif elegante.

Contador de caracteres: Discreto en la esquina inferior.

Botón de Acción: "Sintonizar Mensaje" (Efecto de brillo suave al pasar el mouse).

 

B. Panel de Resultados

Un grid de 3 columnas (o 1 columna en móvil) que muestra tres variantes:

1. Variante: Directa & Ejecutiva

Color: Azul Cobalto (Focus en eficiencia y claridad).

Badge: "Profesional".

Como esta App usa IA necesitamos un “system prompt” mínimo viable. Es otra parte de la Spec. Les dejaré esta sección aquí completa:

3. Lógica de Inteligencia Artificial (Prompt de Sistema)

Para generar los resultados, la aplicación debe enviar este contexto al LLM:

> "Actúa como un experto en comunicación asertiva y psicología organizacional. Tu tarea es reescribir el mensaje del usuario en 3 versiones estrictamente diferenciadas.

> Reglas:

> 1. Directo & Ejecutivo: Elimina rellenos, ve al grano, usa lenguaje formal pero activo. Ideal para correos a superiores o clientes.

> 2. Empático & Amigable: Usa lenguaje cálido, validación de sentimientos y suaviza peticiones. Ideal para equipos cercanos o situaciones delicadas.

> 3. Minimalista: Reduce el mensaje a su esencia absoluta (máximo 15 palabras). Ideal para Slack, WhatsApp o equipos rápidos.

>

> Output: Devuelve un JSON con las llaves: `profesional`, `amistosa`, `minimalista`."

Sí, por supuesto puedes probar el prompt directamente en la IA de turno.

Pero la Spec también puede incluir requisitos técnicos e interacciones, como “Cada tarjeta de resultado debe tener un botón de ‘Copiar’”, ¿lo recuerdan? Precisión, cero ambigüedad, completitud, etcétera, etcétera; también pueden tener historias de usuario o hasta casos de uso, pero eso será motivo de próximos artículos; incluso puede tener y es bueno que tengan instrucciones para la IA que se va a usar. Y mucho más.

Todo esto lo almacenan en un documento Markdown (.md) y se lo pasan a la IA. Esta vez usé Lovable, es apenas el “Hola, mundo” de SDD. Les dejo el documento completo para su descarga.

[Enlace a la especificación]

El resultado, en modo oscuro y colores vibrantes, dos de los requisitos precisos, consistentes y verificables que encontrarán en la Spec completa:

Me cuentan cómo les va corriendo la Spec que les dejé. En el próximo artículo les hablaré más en detalle de la anatomía de una Spec y avanzaremos en esto.

Hace poco, mi también gran amigo Daniel Ramírez decía en un artículo que “La vibra no escala, la arquitectura sí” y preguntaba al final: “¿En qué punto una automatización deja de ser una PoC y se convierte en un sistema que requiere una arquitectura de verdad?” Bueno mi estimado Daniel, SDD es un paso, uno grande, en esa dirección.

Déjenme saber en el foro qué se les ocurre que hagamos con esto.

 

Lucho Salazar

Villa de Nuestra Señora de La Candelaria de Medellín, 5 de febrero de 2026

39 años después.

Video generado con Grok