¿Qué hay de “Spec” en Spec-Driven Development?

 

Lo que no les conté cuando les hablé del «Medio millón de specs» que SpecMine recopiló en más de 70 mil repositorios es lo que dice el resumen del mismo trabajo: la spec la escribe el desarrollador o, con más frecuencia, la redacta una herramienta de IA y el desarrollador la «cura».

Curar. Según mi Gazafatonario, palabra de médico, de museo, de párroco de pueblo que absuelve sin haber oído la confesión. Cuarenta años en este oficio me han enseñado a desconfiar de los verbos que suenan bien y no dicen quién hizo qué. En el experimento que hice con el Sintonizador de Tono, el agente tomó doce decisiones que yo no había tomado y solo dos tomaron el tinte de preguntas. Si eso es curar, el paciente se cura solo.

También les dije en mi artículo anterior que la anatomía de una spec la podían encontrar muy fácil en la Web o preguntándole a cualquiera de los chatbots que circulan por allí. Pero pudieron más mis ganas de escribir sobre el asunto. De publicar realmente, porque ya lo había escrito desde el mismo febrero, solo que actualicé el artículo con algunas otras cositas que aprendí desde entonces. Además recordé la recomendación que siempre doy a escritores noveles: si es tu visión, si es tu experiencia, siempre hay algo que aprender de allí.

Las specs pueden contener historias de usuario o casos de uso. No se alarmen, en realidad eso no tiene nada de especial, siempre ha sido así. Son formas apenas. Lo importante sigue siendo la conversación entre humanos. Llegaré a eso en un momento, entremos en materia.

Mi primera recomendación es que abran el spec-template.md de Spec Kit (el del repositorio, al 30 de octubre, última fecha en que lo revisé) y miren lo que le piden al agente: escenarios de usuario con prioridad, cada uno comprobable por separado y escrito en Gherkin (GIVEN/WHEN/THEN - Dado/Cuando/Entonces); requisitos numerados (FR-001) con su «MUST»; criterios de éxito medibles; y una sección de supuestos, que la plantilla describe como valores predeterminados escogidos cuando la descripción no decía algo. Está bien configurada.

Sin embargo, lo que no van a encontrar es una sección para lo que no se va a hacer (aparece una sola vez, como ejemplo dentro de los supuestos) y mucho menos una para indicar quién decidió qué. Y aquí viene mi primera recomendación propia: puedes modificar la plantilla a tu antojo, aunque no te emociones mucho con ello, no vaya a ser que termines creando un monstruo de esos que ni la misma IA sea capaz de manejar. Escribe esas «no-metas» y las preguntas abiertas al final y acompáñalas de reglas muy simples y directas. Por ejemplo, Kiro escribe historias de usuario con criterios de aceptación y comportamientos en notación EARS (CUANDO «ocurra esto», EL SISTEMA DEBERÁ «hacer esto otro»), y no genera el diseño hasta que uno confirma los requisitos.

Es que esto no es nada novedoso. He escrito sobre ello desde hace más de dos décadas. En el Gazafatonario escribí que un requisito tiene que ser verificable, atómico y no ambiguo, y dediqué unos diez consejos a las palabras que, en su momento, había que sacar de un caso de uso (que después se podían aplicar a las historias de usuario y hoy, por supuesto, a las Specs): «automáticamente», «procesar», «administrar», «gestionar». Las sigo viendo en muchas especificaciones de las que ya se ha producido software en 2026, con IA o sin IA y siempre me pregunto qué interpretó el programador, sea humano o máquina.

La Spec de mi Sintonizador de tono podría tener una línea como esta:

El sistema debe procesar automáticamente el mensaje y entregar las versiones con el tono adecuado.

Dos de mis cuatro palabras vetadas. Así la escribiría hoy:

Cuando el usuario pulse «Sintonizar» con un mensaje de hasta 1.000 caracteres, el sistema muestra tres versiones: Directa, Empática y Mínima. La Mínima no pasa de quince palabras.

Es apenas un ejemplo, las quince palabras se cuentan; no obstante, el atributo «Empática» no es verificable, al menos no de manera automática. Aun así, un criterio verificable puede requerir personas: tres lectores reciben las versiones sin etiqueta y señalan cuál es la Empática. Si aciertan en ocho de diez, pasa (otra vez, ese umbral es un ejemplo). Falla de verdad y no obliga a convertir «cálido» en una lista de palabras.

Las historias de usuario ya estaban ahí

Los «escenarios de usuario» de Spec Kit, las historias de Kiro o los «requisitos» de OpenSpec son historias de usuario con otro disfraz, y de eso he escrito en cantidades industriales. Con mi gran amigo Jorge Abad les dedicamos dos tomos, Historias de usuario: una visión pragmática. Vistas con ojos de SDD, me dejan cuatro ideas.

La primera, las siempre muy comentadas aunque pocas veces entendidas «tres C». Les contaba desde entonces que una historia tiene Carta, Conversación y Confirmación. El spec.md es la carta y los criterios de aceptación son la confirmación. ¿Y la conversación? Spec Kit le deja al agente tres preguntas. Hemos insistido en esto hasta el cansancio: lo más importante de una historia son las conversaciones a su alrededor, y que tenemos que pasar de un mindset «especificacional» a uno conversacional. Una spec generada por un agente es lo especificacional llevado al extremo: un documento completísimo del que casi nadie conversó.

La segunda, la hipótesis. Una historia es una hipótesis mientras el producto no esté en manos del usuario, y escribí sobre pasar de «requisito» a «necesidad o hipótesis». La spec también lo es. Sus criterios de éxito son la manera de saber si acertamos, y ahí vuelve la frase que ya conocen: reflexionar con datos, no con supuestos.

La tercera, objetivo y solución. Una buena historia dice qué quiere lograr la persona («elegir un método de envío») y le deja la solución al equipo; una mala historia dicta el botón. En mi Sintonizador hay de las dos: «eliminar la ansiedad en la comunicación digital» es objetivo, y «Azul Cobalto» es solución. Lo que escribo como solución lo decido yo. Lo que dejo abierto lo decide el agente, y me toca revisar el plan.

La cuarta, el tamaño. Escribí que ¡El tamaño sí importa!: una historia pequeña, de una décima a una sexta parte de la velocidad del equipo, se entiende rápido y se termina. Para una spec uso una regla igual de rudimentaria, aunque efectiva: si no se revisa en diez minutos, es grande, y se divide por capacidad.

Ahora bien, Spec Kit le ordena al agente que, ante lo que falta, «adivine» con criterio y lo anote como supuesto. Si tiene más de tres dudas, se queda con las tres más críticas y adivina el resto. Está escrito así en sus instrucciones.

En mi miniserie de 2012 sobre los casos de abuso (no, no de esos, me refiero a los malos usos de las especificaciones escritas con casos de uso, quizás un mal juego de palabras, pero que en esa época me sonó distintivo) hay un capítulo para decir que el analista no es psíquico. Y un año después añadí que los supuestos pasivos degradan la calidad de la especificación y que había que cambiarlos por hechos, preguntándole a más de una persona. La plantilla vuelve al agente el analista psíquico del que yo advertía. Con la velocidad que se gana, adivinar y dejarlo anotado es razonable. El problema aparece cuando nadie lee lo anotado, y sigo sin encontrar un dato que me diga cuántos lo leen. Mi hipótesis es que ese número tiende a cero.

Espero que a estas alturas se estén haciendo las mismas preguntas que yo. ¿La Spec se revisa? ¿Se modifica? Mi respuesta y mi recomendación es que sí, con tres miradas distintas, porque cada una ve lo que las otras no.

La primera es la mecánica, y se delega: contradicciones, ambigüedades, criterios sin forma de probarse. Spec Kit trae compuertas para eso (clarify, checklist y analyze en su ruta completa). Mi contradicción entre «Mínima (estilo Gen-Z)» y «Minimalista» cae aquí. A lo largo de este entramado, en general, he usado a Spec Kit como modelo, pero esto sucede con Kiro o con OpenSpec, o con cualquier otra de las herramientas que tenemos para jugar a SDD. Incluso con las propias.

La segunda es la de las decisiones, y es humana. Se lee lo que el agente asumió, lo que preguntó y cada «debe» que uno no recuerda haber pedido, y a cada decisión se le pone dueño y fecha. Si el agente supuso «límite de 2.700 caracteres» y me parece bien, lo cambio por una decisión mía, con mi nombre y mi razón.

La tercera es la de lo ausente, también humana, y va con lista: datos personales, costo, qué pasa cuando algo falla, límites, retención. En mi experimento con el sintonizador de tono, seis de las doce decisiones no aparecieron en ninguna sección, y leer lo escrito nunca las encuentra. Esto ya me había pasado preIA. El extraño caso del caso de uso faltante. Es un juego de palabras, apenas para mi Gazafatonario.

Y modificarla: la misma spec retocada a mano por mí me ha devuelto resultados distintos, así que toco decisiones y no el estilo. Cambio el supuesto, no reescribo el párrafo. En un prototipo me quedo con la primera mirada; con una factura electrónica o un dato de salud, las tres, y con una persona que firma.

Finalmente, la Spec

Para ver todo junto, les dejo aquí la spec del botón «Copiar» del Sintonizador de tono:

# Spec: copiar una versión del mensaje

## Historia
Como persona que acaba de sintonizar un mensaje, quiero copiar la
versión que me gustó con un clic, para pegarla en WhatsApp o en el
correo sin seleccionar texto a mano.

## Decisiones aprobadas
- [Producto, 20261108] Copiar entrega solo el texto de esa versión,
  sin título ni formato.
- [Producto, 20261108] Una versión por clic. No hay «copiar todas».

## Comportamiento
R1. CUANDO la persona pulse «Copiar» en una tarjeta, EL SISTEMA
    DEBERÁ dejar en el portapapeles el texto de esa tarjeta y
    cambiar el botón a «Copiado» durante dos segundos.
R2. CUANDO el navegador no permita usar el portapapeles, EL SISTEMA
    DEBERÁ seleccionar el texto y mostrar «Presiona Ctrl+C».

## Restricciones
- No enviar ni guardar el mensaje en ningún servidor al copiar.
- No agregar dependencias nuevas.
- No tocar el panel de entrada ni el prompt de sistema.

## Fuera de alcance
- Compartir directo a WhatsApp o al correo.
- Historial de lo copiado.

## Criterios de aceptación
- [ ] R1: pegar en un editor entrega exactamente el texto de la
      tarjeta (automática).
- [ ] R1: a los dos segundos el botón vuelve a decir «Copiar»
      (automática).
- [ ] R2: con el permiso denegado aparece el mensaje de respaldo
      (automática).
- [ ] Tres personas que no conocen la app copian una versión sin
      ayuda en menos de diez segundos (humana).

## Supuestos del agente (por revisar)
- Los saltos de línea se conservan.

## Preguntas abiertas
- [ ] ¿Contamos cuántas veces se copia cada versión, sin guardar
      el texto? Decide: Producto.

Cada pieza evita algo concreto. La historia proporciona el porqué y abre la conversación. Las decisiones tienen dueño. Las restricciones impiden que el agente «mejore» lo que nadie pidió, como guardar el mensaje en un servidor. Cada criterio nombra su prueba, y uno la hace una persona. La pregunta abierta es la hipótesis: si la gente copia más una versión que otra, algo nos dice sobre el tono, pero antes hay que decidir qué se mide y qué no se guarda.

Ahora bien, hace 20 años publiqué una lista de trece condiciones para decir que un caso de uso estaba terminado, y bastaba con cumplir diez. Para una spec mi lista corta es esta:

1.      Cada requisito tiene una manera de fallar.

2.      Cada decisión tiene dueño y fecha.

3.      Lo que no se va a hacer está escrito.

4.      Las preguntas abiertas siguen abiertas, y el agente no las cerró por su cuenta.

5.      Dos lectores distintos entienden lo mismo.

Si le faltan dos, no está terminada. La quinta es de mi cosecha de 2012: la especificación tiene que producir la misma interpretación en el diseño y en las pruebas.

No ha sido gratuito esto de mencionarles muchas de mis publicaciones anteriores. Créanme, no es un simple «yo ya lo había dicho». Lo que hice aquí (o al menos traté de hacer) fue reunir y resumir, en dos mil palabras lo que he escrito en cientos de miles a lo largo de más de 30 años. Las cosas no han cambiado en materia de especificación de requisitos de software, después de todo.

2026, 2027 y lo que viene después

Me gustan los tres niveles de Spec que Piskala identifica: spec-first (sirve para arrancar y luego se bota), spec-anchored (vive y evoluciona con el código) y spec-as-source. Cuánto hay que saber de la spec depende del nivel en el que uno juegue. Para el segundo hay que saber leer una spec como la leería un analista, aunque nunca se escriba desde cero. Pero eso fue para este 2026: saber ver lo que falta. Aquí no era mejor pájaro en mano que un ciento volando. Léanlo así: una spec que existe y no gobierna nada es peor que no tener spec, porque da falsa confianza.

Las cosas cambian muy rápidamente, así que para 2027 apuesto, y subrayo que es apuesta y no dato, a que lo que se pueda volver prueba será prueba: las quince palabras, los esquemas de las interfaces. La spec que quede para humanos será más corta: historia, decisiones con dueño, lo que no se hará. Más corta, pero también más importante.

Lo bueno de estas apuestas es que se pueden ganar si te lo propones. Si nadie está trabajando en ello, qué esperas para empezar a hacerlo.

Lucho Salazar

Envigado, 10 de noviembre de 2026.

 

Referencias

Algunos estudios y papers

•        Agarwal, S. y Vasilescu, B. SpecMine: A Large-Scale Corpus of Spec-Driven Development Artifacts (25 de agosto de 2026). https://arxiv.org/pdf/2608.25202 

•        Hill, B. 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

•        Piskala, D. B. Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. https://arxiv.org/html/2602.00180v1

•        Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork. https://arxiv.org/pdf/2609.00252

•        SDAD: Spec-Driven Agentic Development for the AI-Native SDLC. https://arxiv.org/pdf/2608.20341

Herramientas y guías de práctica

•        GitHub Spec Kit: templates/spec-template.md, templates/commands/specify.md y docs/quickstart.md (repositorio al 30 de octubre de 2026). https://github.com/github/spec-kit

•        Kiro, Feature Specs y Requirements-First Workflow (actualizada el 25 de septiembre de 2026). https://kiro.dev/docs/specs/feature-specs/ y https://kiro.dev/docs/specs/feature-specs/requirements-first/

•        Glukhov, R. Spec-Driven Development Workflow: From Requirements to Code. https://glukhov.org/app-architecture/documentation/spec-driven-development-workflow/

De mi Gazafatonario IT (luchosalazar.me)

•        Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA (10 de febrero de 2026). https://www.luchosalazar.me/2026/02/specification-driven-development-un.html

•        El poder de las historias de usuario: sembrando narrativas para cosechar productos disruptivos (4 de agosto de 2023). https://www.luchosalazar.me/2023/08/el-poder-de-las-historias-de-usuario.html

•        Historias de usuario: un nuevo orden en los requisitos del software (2013). https://www.luchosalazar.me/2013/07/historias-de-usuario-un-nuevo-orden-en.html

•        Diferencias en el tratamiento de los requisitos entre Cascada y Ágil (2018). https://www.luchosalazar.me/2018/02/diferencias-en-el-tratamiento-de-los.html

•        ¡El tamaño sí importa! (2016). https://www.luchosalazar.me/2016/06/el-tamano-si-importa.html

•        Historias de usuario: una visión pragmática (libros con Jorge Abad). https://www.luchosalazar.me/search/label/Historias%20de%20usuario%3A%20una%20visi%C3%B3n%20pragm%C3%A1tica

•        Casos de abuso, partes 1 a 12 (2012). https://www.luchosalazar.me/2012/09/casos-de-abuso-parte-1.html

•        Diez consejos útiles y simples para escribir casos de uso (2012). https://www.luchosalazar.me/2012/10/diez-consejos-utiles-y-simples-para.html

•        El extraño caso del caso de uso faltante (2012). https://www.luchosalazar.me/2012/12/el-extrano-caso-del-caso-de-uso-faltante.html

•        Sobre «interpretación» vs. «realización» de casos de uso (2012). https://www.luchosalazar.me/2012/04/sobre-interpretacion-vs-realizacion-de.html

•        ¿Es usted la persona correcta para responder mis preguntas? (2013). https://www.luchosalazar.me/2013/04/es-usted-la-persona-correcta-para.html

•        Lecturas fundamentales 4 y 5, la Ley de la Terminación de un Caso de Uso (2006). https://www.luchosalazar.me/2006/12/lecturas-fundamentales-4-1-de-2.html

Artículos propios recientes

•         Medio millón de specs y ningún dueño: lo que 2026 le hizo al Spec-Driven Development. https://www.luchosalazar.me/2026/11/medio-millon-de-specs-y-ningun-dueno-lo.html

•         El espejismo del control: cuando lo determinista se topa de frente con lo probabilístico (agosto de 2026). https://www.luchosalazar.me/2026/08/el-espejismo-del-control-cuando-lo.html

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.