La especificación volvió a importar, y esta vez la lee una máquina

Llevamos veinte años con la misma escena. Alguien escribe un documento de requisitos, se revisa en una reunión, se aprueba, y a la semana el producto ya no se parece a lo que pone ahí. El documento queda en una carpeta y la verdad pasa a estar en el código.

Esto tiene una consecuencia que normalizamos: la especificación nunca fue la fuente de la verdad, era una foto del día que se escribió.

Y entonces llega algo que nadie vio venir. El agente que genera el código lee la especificación. Literalmente. Es su entrada.

De golpe, aquel documento que nadie abría vuelve al centro, y con una propiedad nueva: cada ambigüedad que dejes dentro se convierte en una decisión que toma la máquina por ti.

Qué es esto del desarrollo guiado por especificación

La idea cabe en una línea: escribe primero qué tiene que pasar, con precisión suficiente para que no quepan dos lecturas, y genera desde ahí.

No es nuevo en el fondo —es lo que prometía BDD— pero sí cambia en algo importante:

Esa es toda la diferencia, y es enorme. Una persona que lee «el usuario podrá filtrar los pedidos» sabe que tiene que preguntar por qué campos, si el filtro se guarda, qué pasa sin resultados. Un agente no pregunta. Decide. Y decide con lo que ha visto en otros proyectos, que no es el tuyo.

Dónde se nota la diferencia

Un ejemplo pequeño y real, de los que aparecen cada semana:

Ninguna de las tres es un defecto. El código hace lo que pone. El defecto estaba en la frase, y antes se arreglaba preguntando. Ahora no hay nadie preguntando.

Lo que convierte un deseo en una especificación

La diferencia entre un requisito y algo de lo que se puede generar código es que el segundo se puede comprobar sin discutir.

Fíjate en que esto no es una lista nueva. Es exactamente lo que llevamos años pidiendo en los refinamientos y nunca conseguimos del todo, porque el coste de la ambigüedad lo pagaba alguien más tarde y nunca quedaba claro quién.

Ahora el coste es inmediato y visible: código generado que hace otra cosa.

Dónde encaja QA en esto, y por qué es buena noticia

Aquí está la parte que me interesa de verdad.

Durante años, escribir criterios de aceptación precisos fue la parte menos valorada del trabajo. El que insistía en concretar el caso del importe negativo era el pesado de la reunión.

Esto conecta con algo que escribí hace tiempo en empieza por el criterio; el código viene después: la parte difícil nunca fue escribir el assert, fue decidir qué merece uno. Esa decisión ahora tiene un consumidor nuevo y mucho más literal.

Tres trampas que ya me he encontrado

Generar la especificación desde el código. Es tentador: le pides al agente que documente lo que hay y te devuelve una especificación preciosa. Pero eso no es una especificación: es una descripción. Dice lo que el sistema hace, incluidos sus defectos, y los bendice. Una especificación dice lo que debe hacer, y para eso hace falta alguien que decida.

Confundir precisión con volumen. Cuarenta páginas no son más precisas que dos. Suelen ser menos: nadie las lee enteras, se contradicen entre sí, y el agente —que sí las lee enteras— se queda con una de las dos versiones.

Dejar de revisar lo generado porque la spec era buena. Esta es la peor. La especificación acota lo que pediste, no garantiza lo que salió. Que el agente tuviera buenas instrucciones no significa que las siguiera, y lo generado sigue necesitando que alguien lo mire.

Ese último paso es donde esto se gana o se pierde. El día que alguien arregla algo tocando el código y no la especificación, el documento vuelve a ser una foto vieja y estamos otra vez en 2010, pero con más código generado.

Lo que más gracia me hace de todo esto es que no hay nada nuevo en el consejo. Escribe qué tiene que pasar, con precisión, antes de construirlo. Lo llevamos diciendo desde siempre y nunca tuvimos un argumento lo bastante bueno.

Ahora lo hay, y es muy simple: todo lo que no escribas con precisión lo va a decidir una máquina que no conoce tu negocio, no pregunta, y va a hacerlo muy rápido.