En el texto anterior, comenté que el código fuente está dejando de ser la fuente de la verdad.

Esto naturalmente plantea la pregunta: entonces, qué pasa a serlo?

Mi visión: las especificaciones.

Solemos decir que el código es la fuente de la verdad porque, al final del día, es lo que se ejecuta. Es lo que define exactamente el comportamiento del sistema.

Pero esto también fue, en gran medida, una limitación de nuestras herramientas.

Recientemente escuché un podcast sobre Leonardo da Vinci. Muchas de sus ideas estaban correctas en teoría, como prototipos de helicópteros, máquinas de vuelo y trajes de buceo, pero no tenía las herramientas adecuadas para ejecutarlas. Faltaban motores, materiales y tecnología.

Con el software, ocurrió algo parecido.

Desde hace tiempo sabemos que lo ideal sería describir claramente qué debe hacer un sistema, y no cómo implementarlo. Pero, en la práctica, no teníamos cómo garantizar que eso se tradujera correctamente a código.

Aquí hay una diferencia importante:

• el código describe cómo funciona el sistema
• la especificación describe qué debería hacer el sistema

El problema es que, históricamente, mantener estas dos cosas alineadas siempre fue difícil. La especificación se quedaba desactualizada y, al final, el código terminaba siendo la referencia final.

No porque fuera lo ideal. Sino porque era lo que mejor funcionaba.

Con la IA, esto empieza a cambiar.

Si puedes generar código a partir de una especificación bien definida y validar ese código con pruebas automatizadas, el papel del código cambia. Deja de ser la definición y pasa a ser una implementación.

Lo que antes era más teórico empieza a volverse viable.

Y eso cambia completamente el foco del equipo.

Menos tiempo discutiendo detalles de implementación. Más tiempo discutiendo:

• comportamiento esperado
• reglas de negocio
• edge cases
• criterios de aceptación

La calidad del sistema pasa a depender mucho más de la calidad de la especificación que de la habilidad de escribir código línea por línea.

Si te detienes a pensarlo, es algo que ya tenía sentido desde hace bastante tiempo.

La diferencia es que ahora, quizá por primera vez, tenemos herramientas que permiten hacerlo de forma más consistente.

En el próximo texto, voy a entrar en algo más práctico: cómo estas especificaciones empiezan a aparecer en el día a día de los equipos y por qué los markdowns pueden convertirse en los archivos más importantes de tu equipo.