«¡En marcha!»
Un sistema automático tiene un trabajo: tomar un artículo terminado y ponerlo a disposición de los lectores. Arranca, revisa el inventario, actualiza registros, comprueba versiones antiguas y organiza las tareas pendientes.
Actividad no le falta.
Al terminar, presenta su parte de guerra:
Estado: correcto. Artículos nuevos enviados a publicación: 0.
Un momento. ¿La expedición llegó a salir de la muralla? ¿O se pasó el día rellenando el formulario de salida?
La escena recuerda al regreso del Cuerpo de Exploración en el primer episodio de Attack on Titan. Keith Shadis, su comandante por entonces, tiene que reconocer que la expedición no ha logrado lo que buscaba.[1][2]
En la serie es un momento trágico con pérdidas humanas. No tiene nada que ver con la gravedad de un programa que falla. La comparación se limita a una situación absurda: mucho esfuerzo, ninguna entrega.
Derrotados por el papeleo antes de ver un titán
La misión original era sencilla: recibir un texto, comprobarlo y publicarlo.
Pero primero hay que ordenar el inventario. Después, reconciliar los registros. Luego, revisar lo que se publicó antes. Y, ya que estamos, recalcular la lista para la próxima ejecución.
Cada paso parece razonable por separado. Si todos son obligatorios antes de publicar una sola pieza, el resultado es magnífico:
El Cuerpo de Exploración agota su tiempo en la reunión previa a la expedición.
En una ejecución real, la preparación y el mantenimiento de registros consumieron el tiempo disponible antes de que empezara el trabajo principal. Otras ejecuciones sí avanzaron con la publicación. No se trata de un fallo permanente, sino de tareas auxiliares que a veces se comen el objetivo.
La siguiente expedición ha perdido el mapa
Dividir el trabajo y retomarlo después es sensato. Para eso hay que guardar dónde se quedó.
Sin embargo, una ruta del sistema no logró conservar cierta información necesaria para continuar. Hasta podía perderse el orden de las tareas aplazadas.
«¿Por dónde llegamos ayer?»
«No encuentro el informe».
«Pues volvamos a inspeccionar la entrada».
Olviden a los titanes: rescaten primero el archivo.
Reintentar una tarea no garantiza terminarla. Se pueden acumular salidas heroicas mientras los encargos más antiguos siguen esperando.
Volver sano y salvo no significa cumplir la misión
El otro problema es la palabra «correcto».
Para un programa, puede significar que terminó sin un fallo inesperado. Incluso una parada voluntaria por falta de tiempo puede recibir esa etiqueta.
Técnicamente, quizá sea verdad. Pero quien espera el artículo quiere otra respuesta.
¿Se puso en marcha? Sí. ¿Actualizó registros? Sí. ¿Terminó sin estrellarse? Sí.
¿Puede leerse el artículo nuevo? Todavía no.
Guardar, enviar a publicación, mostrar en la web y comprobar el resultado son pasos distintos. Un único mensaje alegre no explica cuál se completó.
Menos desfiles. Más misiones terminadas
Se puede nombrar a otra inteligencia artificial como comandante para que investigue cada fracaso. Pero entonces la fábrica automática depende de un comandante que pasa la noche reescribiendo informes.
Lo útil es menos espectacular: terminar un artículo de principio a fin, recordar dónde se interrumpió el trabajo y no bloquear las piezas sanas por culpa de una averiada. Las tareas administrativas no esenciales pueden esperar.
En lugar de contar expediciones, contemos artículos que el público ya puede abrir.
En la pantalla vuelve a aparecer «correcto».
Estupendo. La próxima vez, traigan un artículo y no solo los permisos de salida.
Referencias (2)
[1] Sitio oficial del anime, episodio 1 de Attack on Titan.
[2] Explicación en japonés de la frase sobre la falta de resultados. El ejemplo técnico procede de registros anonimizados, no de la ficción.
