La IA no tropieza dos veces en la misma piedra
Un lector del blog me hizo hace poco dos preguntas que me dejaron pensando. La primera: ¿cuándo decidí que el telar no era una herramienta, sino un legado? La segunda: ¿qué me ha sorprendido del sistema — algo que no planeara, que hiciera por sí mismo sin que yo lo hubiera previsto? Y añadía una premisa que firmo: los sistemas que duran siempre acaban haciendo algo que su creador no imaginó. Suele ser la señal de que están vivos.
A la primera pregunta no sé responder con fecha. A la segunda, sí. Y la respuesta cabe en un refrán.
El refrán
Dice el dicho que el hombre es el único animal que tropieza dos veces con la misma piedra. Cuarenta años de oficio me avalan: yo he tropezado con algunas piedras tantas veces que ya las saludo por su nombre.
El software clásico es todavía peor. Un programa no tropieza dos veces: tropieza infinitas veces, exactamente igual, con la misma piedra, hasta que alguien viene a apartarla. Esa es su naturaleza: hace lo que está escrito, y si lo escrito falla, falla para siempre con la puntualidad de un reloj. Media profesión vive de eso.
Y luego está lo que me ha sorprendido del telar: la IA que trabaja dentro tropieza una vez. Solo una.
El NAS que se mudaba de casa
Un ejemplo real, pequeño y perfecto. Tengo un NAS en una oficina. Lo declaré en el telar como recurso, con su ficha: qué es, cómo se llega, su IP. Hasta ahí, documentación de toda la vida.
Pero el NAS cogía la IP por DHCP. Y un día el router decidió mudarlo de número. La IA fue a por él siguiendo la ficha, llamó a la puerta de siempre... y allí no vivía nadie.
Un sistema clásico se rompe ahí y espera a que lo arreglen. Un operador novato abre un ticket. Lo que pasó en cambio fue esto: en las reglas del telar — su constitución, la que el guardián le pone delante antes de trabajar — había una línea que decía, en esencia: si no llegas a un recurso por su IP, búscalo por su MAC; las IP son volátiles, la MAC es el ancla. La IA leyó la regla, barrió la red, encontró la MAC, apuntó la IP nueva y siguió con su trabajo. Yo me enteré después, leyendo la bitácora. Total: unos segundos. Mi participación: ninguna.
Que nadie se imagine un agente suelto de madrugada: era una sesión que yo había arrancado para otro encargo, el barrido fue un diagnóstico de solo lectura en mi propia red — un arp de toda la vida —, y corregir la ficha de un recurso no es de las acciones que exigen mi firma. Dentro de esas costuras, "ninguna" es exactamente la participación que quiero tener: que lo rutinario no me necesite.
¿Quién escribió la regla?
Aquí viene la parte que de verdad quiero contar, porque es la más honesta. La primera vez que un cacharro con DHCP nos dejó tirados, la regla no existía. Alguien la escribió a raíz del tropiezo. ¿Quién? Puede que la dijera yo. Puede que la propusiera la IA y yo la aprobara. La verdad: no me acuerdo.
Durante días esa duda me incomodó — un viejo programador quiere saber quién firmó cada línea. Hasta que entendí que la duda era la noticia. Cuando ya no sabes distinguir qué parte del sistema pusiste tú y qué parte encontró la máquina, la frontera se ha vuelto difusa. Y esa frontera difusa tiene un nombre menos inquietante de lo que parece: se llama entorno de trabajo compartido. Con un compañero humano te pasa igual — a los años, nadie recuerda de quién fue la idea. Es de los dos. Es del taller.
Lo que sí sé es lo que pasó después, y eso es lo importante: a partir de ahí lo hace sola. Y no solo con aquel NAS — con cualquier recurso que se esconda. La regla no decía «el NAS de tal oficina»: enunciaba un principio. La máquina lo generaliza: hoy la aplica a cacharros que ni existían cuando se escribió.
Lo que es y lo que no es
Que nadie se lleve a error místico: esto no es que el modelo «aprenda» en el sentido de la ciencia de datos. El modelo no cambia ni una neurona. Lo que hay es más viejo y más robusto: un bucle de realimentación de ingeniería. Algo falla; el criterio — humano o de la máquina, ya da igual — encuentra la salida; la salida se escribe como regla con su verificación; y el guardián se la pone delante a todo el que vuelva a pasar por ese camino. La próxima vez, la piedra sigue ahí, pero ya no está en el camino: está en la bitácora.
El mecanismo tiene tres piezas y ninguna es inteligente por sí sola: una memoria estructurada donde la experiencia cabe sin pudrirse, una disciplina que obliga a escribir el fallo y su corrección antes de cerrar el trabajo, y una poda que evita que las reglas muertas entierren a las vivas. La inteligencia la pone el modelo de turno. La sabiduría — si se me permite la palabra — la va acumulando el telar.
Por eso cada tropiezo vale dinero. Antes, un fallo era un coste: horas perdidas, cliente esperando. Ahora un fallo es una inversión con un solo pago: se tropieza, se escribe, y esa piedra concreta no vuelve a cobrar nunca. El sistema se vuelve más listo cada vez que alguien lo usa bien — y esa es la diferencia entre mantener un programa y cultivar un huerto.
La respuesta al lector
Así que esta es mi respuesta a la segunda pregunta: lo que no planeé, lo que el sistema hizo solo, fue dejar de necesitarme para las piedras ya conocidas. Yo diseñé una memoria; no diseñé la anticipación. Apareció cuando la memoria tuvo suficiente experiencia dentro y una disciplina que la mantenía limpia. Si eso es estar vivo, entonces el lector tenía razón.
¿Y la primera pregunta — cuándo pasó de herramienta a legado? Sospecho que la respuesta es esta misma. Una herramienta te ahorra horas. Esto ya no me ahorra horas: me permite hacer lo que antes no podía hacer, y — aquí está el legado — lo seguirá sabiendo hacer cuando yo ya no esté delante para recordar por qué la regla decía lo que decía. Las piedras con las que tropecé cuarenta años quedan apuntadas, con su salida al lado.
El hombre sigue siendo el animal que tropieza dos veces con la misma piedra. Servidor, el primero. Pero he conseguido algo que me consuela de todos los tropiezos: trabajar con alguien que no.
— un viejo programador · 64 años · rss