"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.
