Soy desarrollador, tech lead y diseñador, y me he movido al lado de la mesa donde se toman las decisiones. Este es el producto que dirijo: el catálogo público de un pintor en activo y la tubería privada que lo alimenta. Cada requisito dice por qué existe y qué demuestra que sigue funcionando, y la compilación falla cuando una de esas pruebas deja de ser cierta.
Un catálogo de 192 pinturas, escrito como 400 páginas estáticas en inglés y español, de modo que todas se leen sin una sola línea de JavaScript. Detrás, un servicio prepara las fotografías, redacta y traduce un ensayo para cada cuadro, renderiza vídeo para las redes y registra cada obra en Ethereum.
Lo opera una sola persona. Esa restricción decide todo lo que hay en esta página: no hay equipo que absorba una mala decisión, ni QA que atrape una regresión, y nada puede exigir a un humano a las tres de la mañana.
Un changelog es un registro del pasado y no puede volverse falso. Un documento de requisitos es una afirmación sobre el presente, y sí puede: en silencio, y casi siempre lo hace.
Por eso cada entrada nombra aquello que la demuestra. Un script lee el archivo antes de cada despliegue y rechaza la compilación si un número se usa dos veces, si una entrada no tiene prueba, si una prueba nombra un archivo borrado o si cita un test que se ha renombrado.
Existe porque cuatro requisitos pasaron quince versiones marcados como «cumplido · demostrado por» unas pruebas borradas varias versiones antes. Nadie mintió. Nadie se dio cuenta. Ese es exactamente el fallo que un documento de requisitos debería impedir y el que peor impide.
También informa —sin tumbar la compilación— de los requisitos cuya única prueba es prosa. Veinticinco de los ciento uno del sitio están en esa lista. Esta página lo dice porque la herramienta lo dice.
Las instrucciones para los ensayos se reescribieron este mes a partir de datos y no de gusto. Veintidós ensayos se habían reescrito a mano antes de publicarlos; ciento treinta y seis no. Comparados entre sí, los editados iban de 188 a 633 palabras, mediana 442. Los intactos iban de 613 a 874, mediana 748. Los dos rangos apenas se solapan, y no se diferenciaban en nada más: misma longitud de frase, misma estructura, mismo argumento. Las instrucciones pedían entre 650 y 900 palabras. Ahora piden entre 380 y 560.
Una decisión anterior se corrigió igual. Una búsqueda se relanzaba en cada lectura, así que compilar 186 páginas eran 186 llamadas facturadas a una API de pago, y unos días de compilaciones sumaron unos noventa euros antes de que nadie mirara el contador. Aquello dejó de hacerse, y ahora una comprobación tumba cualquier compilación que llame a una API de pago: el gasto ya no puede repetirse por accidente.
157 ensayos escritos. 20 revisados. Solo un ensayo revisado puede publicarse, así que todo lo anterior está automatizado y produciendo mientras todo lo posterior espera a un único paso humano, y el trabajo se había estado yendo en hacer más rápido lo anterior.
Darse cuenta de eso, y decirlo en voz alta en lugar de sacar la siguiente funcionalidad, es el trabajo.
Casi todo el código lo escribe un agente de IA, a partir de una especificación que escribo yo y una revisión que hago yo. Eso es lo importante, no una nota al pie.
Un agente deja encantado que un requisito se pudra, que una abstracción se extienda, que un coste se dispare o que aparezca una funcionalidad que nadie pidió. El archivo de requisitos, las pruebas nombradas y las comprobaciones que tumban una compilación son lo que hace que trabajar así sea seguro. Mi parte es decidir qué se construye, por qué, en qué orden y qué no merece la pena, y poder enseñar el razonamiento después.
El servicio que hay detrás del catálogo vive en un repositorio privado y, deliberadamente, ni se enlaza ni se describe aquí.