¿Para qué sirven los logs?

Guía para los vibe coders.

Te llama un cliente. Hizo un pedido ayer, pagó, y nunca le llegó el correo de confirmación. Quiere saber si el pedido existe.

Abres el panel. El pedido está: número 4521, pagado, en preparación. Le dices que sí, que está todo bien, que le reenvías el correo ahora. El cliente queda tranquilo. A él no le interesa por qué no llegó el correo.

A ti sí. Porque si le pasó a él, le pasó a otros, y mañana llama el siguiente. El panel no te lo va a decir: el panel muestra el estado de las cosas, no lo que pasó.

Entonces abres los logs. Buscas 4521 y aparece la historia: el pedido se guardó, el pago se confirmó, se llamó al servicio de correo y el servicio respondió 429 Too Many Requests: límite diario alcanzado. El correo nunca salió. Tu código registró el error y siguió como si nada. Nadie lo reintentó, nadie avisó.

Buscas 429 y aparecen veintitrés más, todos desde el pedido 4512 en adelante. Fue un buen día de ventas y el plan gratuito del proveedor de correo tiene un tope diario. Ahora sabes qué pasó, a quiénes les pasó, y qué hay que arreglar: encolar y reintentar cuando se abra la ventana, o cambiar de plan. Treinta segundos.

Ahora imagina que no hay logs. El pedido está en el panel y el correo no llegó, y no tienes nada más. ¿Qué haces? ¿Lo vuelves a correr a ver si pasa de nuevo? ¿Le preguntas al agente que escribió el código? Si solo tiene el código, el agente va a leerlo y decirte lo que debería haber pasado. No tiene idea de lo que pasó. Nadie la tiene. Adivinas.

Esa es la diferencia. El código dice lo que el programa hace en general. El log dice lo que hizo esa vez.

Y no hace falta que lo leas tú. Si los logs están, se los pasas al agente y le pides que averigüe qué pasó con el pedido 4521. Con evidencia delante, el agente deja de adivinar: encuentra el 429, cuenta los otros veintitrés, y te propone el reintento. Lo que cambia no es el agente, es lo que tiene a mano.

Por qué no basta con escribir en un archivo

La forma más simple de saber qué hizo un programa es que lo escriba: una línea en el código que anota "llegué hasta aquí" o "el valor es tal" en un archivo. Un programador con un error que no podía reproducir en su máquina hacía exactamente eso, lo subía al servidor y esperaba a que el error volviera a ocurrir.

Funciona, hasta que deja de funcionar. El archivo crece hasta llenar el disco y tumbar el servidor. Escribir en disco a cada paso hace el programa lento. Cada programador anota con su propio formato y nadie puede leer el de otro. Por eso existen las bibliotecas de logging: niveles (esto es un error, esto es solo información), rotación de archivos, escritura en segundo plano, un formato común. Cualquiera que uses hoy resuelve esos mismos problemas.

Después viene la idea importante: no esperar a que llame el cliente. Si el log ya dice que el correo falló, el sistema puede avisarte en el momento, no tres días después. Los logs dejan de ser algo que miras cuando hay un problema y pasan a ser algo que te dice que hay un problema.

Hoy no hay sistema serio sin logs. Es tan normal que ya nadie se pregunta para qué están.

Por qué se llama "log"

Antes de que existieran las computadoras, los marineros medían la velocidad del barco tirando al agua un trozo de madera —un log, en inglés— atado a una cuerda con nudos a intervalos fijos. Contaban cuántos nudos pasaban por la mano en medio minuto. De ahí viene el "nudo" como unidad de velocidad. El resultado se anotaba en el logbook, junto con el rumbo, la hora y el clima, para que cualquiera pudiera reconstruir el viaje después. Cuando los programadores empezaron a escribir lo que hacía un programa en un archivo, le pusieron el mismo nombre. Es la misma idea: un registro de lo que pasó, hecho para que alguien lo lea después. En español la palabra es bitácora: la caja de madera junto al timón donde se guardaba la brújula, y donde el oficial de guardia escribía el cuaderno con el rumbo, la velocidad y todo lo que pasaba. El inglés nombra el instrumento; el español, el lugar donde quedaba el registro. Por eso en informática todavía se dice “archivo de bitácora”, aunque casi todo el mundo diga log.

Lo que no cambia con los agentes

Si tu aplicación la escribió un agente, nada de lo anterior desaparece. La red sigue fallando. El servicio de correo sigue tardando. El proveedor de pagos sigue cobrando dos veces cuando el reintento entra en mal momento. Nada de eso depende de quién escribió el código, y el agente tampoco se salva de cometer errores propios. La diferencia es otra.

Antes, cuando algo fallaba, abrías el código y lo leías. Hoy el código lo escribió un agente, es más del que una persona puede leer, y cada vez se lee menos. Mucha gente ya no revisa lo que el agente genera; mira si funciona. Pero una cosa es no leer el código y otra es no saber qué hizo cuando corrió.

La distancia entre tú y lo que pasó creció. Antes había un programador que recordaba qué había escrito y por qué. Ahora hay un agente que no recuerda nada de la sesión anterior y un código que nadie leyó entero. Lo único que queda en el medio es el log. Si está, y el agente puede consultarlo, sabes qué pasó. Si no, le preguntas y te va a contar lo que debería haber pasado, con mucha seguridad.

Los logs además sirven para más que encontrar errores: con ellos se analiza qué hace la gente en tu aplicación y se deja constancia de qué hizo el sistema y cuándo, por si alguien lo pregunta después. Pero eso viene solo. Primero tienen que existir.

Qué hacer

La prueba es tu propio pedido 4521: elige cualquier pedido de ayer y pídele a tu agente que reconstruya qué pasó con él. No el código, lo que pasó. Si puede contarte la secuencia —qué se llamó, con qué resultado, cuánto tardó— tienes logs y el agente los puede consultar. Si no puede, falta una de las dos cosas: o los logs no existen, o existen y el agente no llega a ellos. Las dos se arreglan.

Si no existen, pídele al agente que registre cada paso importante: qué se llamó, con qué resultado, cuánto tardó, y a qué pedido corresponde. Ese último dato es el que hace posible todo el ejemplo de arriba. Y revisa que lo haya hecho, porque es lo primero que se queda afuera cuando lo único que se mide es si el código funciona.

Cuando el cliente llame, y va a llamar, que tengas algo que mirar. Y que tu agente también.