Durante treinta años el recurso escaso en software fueron las personas capaces de convertir una petición ambigua en código que funciona. La ambigüedad se absorbía en silencio, con desarrolladores preguntando por los pasillos y haciendo suposiciones razonables. Era ineficiente, era invisible, y funcionaba.

Un agente no absorbe la ambigüedad. La resuelve, al instante y con seguridad, en la dirección que apuntase la petición. Esa única propiedad es la razón de que la especificación haya dejado de ser papeleo y se haya convertido en lo que determina el resultado.

Qué contiene una especificación útil

Casi todas las organizaciones que dicen escribir especificaciones están escribiendo listas de deseos. La diferencia aparece de inmediato en cuanto un agente actúa sobre ellas.

Una especificación con la que un agente puede construir y una persona puede verificar enuncia cuatro cosas.

El resultado, en los términos del negocio. No «añadir un filtro en la pantalla de informes», sino «un responsable de zona puede ver las diez tiendas con peor cobertura de stock esta semana, y la cobertura de stock es esta fórmula». Lo primero es una petición de funcionalidad; lo segundo acota qué significa correcto.

Las reglas, incluidas las que todo el mundo sabe. El conocimiento institucional que vive en la cabeza de tres personas es exactamente lo que un agente no puede ver. Qué clientes están exentos, qué pasa al cierre del ejercicio, qué categorías de producto se comportan distinto y por qué. Es la parte más lenta de escribir y la que decide si el resultado sirve.

Los casos límite, decididos en lugar de descubiertos. Qué pasa sin datos, con valores negativos, con un registro que existe en un sistema y no en el otro. Cada uno de ellos lo va a decidir alguien. La elección es si lo decide el negocio por adelantado o un modelo a las tres de la mañana.

La prueba que demuestra que funciona. Escrita antes de construir y en términos que el negocio aceptaría. Sin ella, «terminado» vuelve a significar «el código está integrado», que es la definición que dejó de significar algo en el momento en que el código se abarató.

Quién la escribe

No la función tecnológica sola, que no tiene las reglas. No el negocio solo, que no va a alcanzar la precisión necesaria sin ayuda. El arreglo que funciona es que el negocio sea dueño de la especificación con apoyo técnico, y que se usen para escribirla y ponerla a prueba los mismos modelos que todo el mundo está desplegando.

Esto último importa más de lo que parece. El uso temprano de IA más fiable en una organización lenta no es generar código. Es interrogar un borrador de especificación: qué no has dicho, qué se contradice con qué, qué pasa en este caso que no has mencionado. Es poco vistoso, es rápido, y ataca la parte del proceso que era el cuello de botella de verdad.

Por qué las organizaciones se resisten

Escribir las cosas con precisión saca a la luz el desacuerdo. Un requisito vago permite que tres interlocutores crean que van a recibir tres cosas distintas y aplaza la discusión hasta la entrega, cuando ya es problema de otro. La precisión adelanta esa discusión a una sala donde hay que zanjarla.

Ese es el coste real del desarrollo dirigido por especificación, y es un coste que cae sobre los responsables de negocio y no sobre los ingenieros. También es exactamente el objetivo. Las organizaciones no se vuelven lentas porque la gente escriba código despacio. Se vuelven lentas porque las decisiones se aplazan, y una especificación es un instrumento para obligar a que las decisiones ocurran pronto.

Cómo empezar sin montar un programa

Coge una iniciativa que importe y que esté atascada. Escribe la especificación en condiciones, con los cuatro elementos de arriba, y ponle un responsable de negocio con nombre. Cronometra cuánto lleva eso y cuánto lleva después la construcción. Y compara ambas cifras contra lo último comparable que entregó la organización.

La comparación suele zanjar la discusión más rápido que cualquier presentación. La especificación tarda más de lo que nadie espera y la construcción se desploma a una fracción de lo que costaba, y cuando un equipo ha visto esa proporción una vez ya no vuelve atrás por voluntad propia.

Qué le hace esto a la organización

Se siguen tres consecuencias, y conviene planificarlas en lugar de descubrirlas.

El papel de definir vuelve a ser sénior y central, después de una década borrándose de los organigramas como resto de la cascada. Vuelve con otras herramientas y otro nombre, y las personas capaces de hacerlo no están ahora mismo en los puestos que lo premian.

La capacidad de revisión pasa a ser la restricción. Cuando construir es barato, el cuello de botella es cuánta gente sabe juzgar bien si lo que ha vuelto está bien. Esa capacidad hay que construirla a propósito, porque antes venía como subproducto de escribir el código.

Y la discusión se adelanta. Las reuniones se ponen más duras al principio de una iniciativa y mucho más fáciles al final, que es un cambio que casi cualquier consejo aceptaría y que casi cualquier mando intermedio resiste, porque la incomodidad es inmediata y el beneficio está a un trimestre vista.