«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. Vuelvo a Yudkowsky, el mismo 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.

Deja un comentario