I. Dejé la Máquina Sola Ocho Horas
El miércoles a la noche me fui a dormir y dejé la máquina trabajando. Ocho horas, sin nadie mirando, sin aprobar nada en el medio.
Cuando me levanté había ocho tareas terminadas y una herramienta nueva con sus tests. Y arriba de todo eso, el número que me interesa de verdad: ocho veredictos en rojo, y los ocho los firmó una segunda máquina cuya única función era intentar demostrar que la primera se había equivocado.
Ninguno apareció releyendo. Ni uno.
Si alguna vez le pediste algo grande a una IA y volviste a una pared de texto que no podías verificar, entonces ya tuviste este problema en chico. La pregunta de esta edición es la única que importa cuando la dejás sola: de esas ocho horas, cuántas fueron reales, y cómo lo sabés.
II. Por Qué una Sesión de IA se Apaga Sola
Lo primero que hay que entender es que “dejarla trabajando” no existe como uno se lo imagina.
Una sesión de IA termina cuando manda su respuesta. Se apaga. No hay un proceso esperando. Si querés que a las tres de la mañana siga trabajando, algo tiene que volver a despertarla, y ese algo no puede vivir en su memoria, porque su memoria se borra cada vez.
Entonces vive en un archivo en el disco. Una lista de la noche, con casilleros. Cada vez que se despierta lee el archivo, ve qué está hecho y qué no, hace lo siguiente, marca el casillero y programa el próximo despertar. Suena burocrático y es lo único que hace que la noche exista.
Escribilo así y ganás algo más: cualquiera puede leer ese archivo a la mañana. Vos, la máquina, o la máquina de la noche siguiente que no tiene idea de qué pasó.
III. La Regla que Cumplía Perfecto y Me Robaba Seis Horas
Las primeras noches terminaban temprano y yo no entendía por qué. Había trabajo, había tiempo, la máquina estaba prendida, y a las tres de la mañana paraba.
Lo que encontré fue una regla que yo mismo había escrito: cuando la cola esté terminada, pará. Una cola de nueve tareas que se termina a las tres de la mañana produce una parada a las tres de la mañana. La máquina hizo exactamente lo que le pedí, y lo que le pedí no era lo que quería.
Eso es más incómodo que un bug, porque un bug se arregla. Una regla que se cumple perfecto y te deja seis horas de capacidad sin usar solo se ve si mirás el resultado en vez del código.
Si automatizaste algo y funciona pero el resultado te decepciona, empezá por ahí. Casi siempre está obedeciendo algo que le pediste sin darte cuenta.
IV. El que Hace no Puede Ser el que Aprueba
Cambié una sola cosa, y es la que te vas a llevar de esta edición.
El que hace el trabajo no marca el trabajo como hecho. Escribe, y después entra una segunda máquina, más chica y más barata, que no vio nada del proceso, con una sola instrucción: intentá demostrar que esto está mal.
Esa formulación es todo. “Revisá si está bien” y “demostrá que está mal” producen resultados distintos, porque una IA a la que le preguntás si algo está bien te dice que sí. No miente: busca confirmación, la encuentra, y te la trae. Pedirle que lo rompa la manda a buscar lo contrario.
Y en vez de una pregunta vaga recibe afirmaciones concretas: este archivo tiene que existir, tiene que contener esta línea, esta fila de la base tiene que tener este valor, este comando tiene que devolver este número. Tres respuestas posibles y nada más: confirmado con la evidencia citada, falló con la contradicción citada, o no pude verificarlo y este es el motivo. “Parece correcto” no es una respuesta y se rechaza.
La medición más limpia que tengo de esto es de la noche del martes, no la del miércoles: dieciséis errores en una sola noche, los dieciséis encontrados por verificadores, cero por releer. Y la prueba más fea de todas: la única tarea de esa noche a la que le salteé el verificador es exactamente la que traía el error fatal.
V. Tres Formas en que un Control te Miente
Poner un verificador no alcanza, porque el verificador también puede mentirte. Aprendí las tres formas en tres noches distintas, y las tres se aplican a cualquier sistema que midas, con IA o sin ella.
Un test puede pasar en verde sin haber tocado nunca lo que dice probar. Tenía uno que verificaba qué pasa cuando el sistema cruza un atajo del disco. Pasaba siempre. El dato que le llegaba venía ya resuelto, así que el test nunca cruzó el atajo. Verde, y terreno sin pisar.
Un test puede fallar por el motivo equivocado. Dos pruebas murieron por una columna vacía antes de que el sistema llegara a evaluar la regla que yo estaba probando. Fallaron, yo lo tomé como señal, y no habían llegado.
Y “sin errores” solo significa que nadie se cayó. El código que devuelve cero para decir “todo bien” me mintió cinco veces en una sesión. Un programa que corre y no revienta te dice que corrió.
El miércoles casi reporté una herramienta como rota por esto mismo. El comando que revisa el formato de un video me devolvía un valor que significaba “esto no tiene transparencia”. Era verdad, y era el instrumento equivocado: ese formato guarda la transparencia en otro lugar, donde ese comando no puede verla. Si me quedaba con la primera lectura, salía a instalar tres herramientas nuevas para arreglar un problema que no existía.
VI. Cómo Correr Esto Vos, en Cuatro Pasos
- Uno. Sacá el estado de la cabeza de la máquina y ponelo en un archivo. Una lista con casilleros, en el disco. Si la conversación se corta, el trabajo sigue.
- Dos. Separá al que hace del que aprueba. Dos procesos distintos, y el segundo nunca vio el trabajo del primero. Si usás el mismo, no tenés control, tenés una opinión repetida.
- Tres. Dale afirmaciones que se puedan tocar. No “revisá que esto esté bien” sino “este archivo tiene que contener esta línea”. Y exigí tres respuestas: confirmado, falló, o no pude verificarlo y por qué.
- Cuatro. Cuando te diga que todo salió bien, preguntale con qué lo midió. Si la respuesta es “el programa no dio error”, todavía no sabés nada.
Los cuatro pasos toman una tarde. El tercero es el que casi todo el mundo se saltea, y es el único que convierte al verificador en algo más que una segunda opinión.
Cada viernes sale un episodio, y esta carta es la versión escrita.
VII. Lo que Encontró la Noche que no Estaba en la Lista
Termino con lo que más me sirvió, que es lo que menos parece un resultado.
Le pedí que investigara qué existe afuera para resolver un problema de video que tengo desde marzo. Volvió con siete afirmaciones verificadas y una conclusión: la herramienta que necesito ya la tengo instalada. La estuve teniendo todo este tiempo. Iba a construir algo que ya era mío.
Y encontró algo que yo venía diciendo mal hace tres meses. Durante todo ese tiempo repetí que me quedaba sin espacio en una cuota de cinco gigas en la nube, cuando el que estaba lleno era el disco de esta máquina: cuatrocientos sesenta gigas con tres punto nueve libres. Tres meses diagnosticando el lugar equivocado.
Esas dos cosas tienen la misma forma. La noche no me agregó trabajo, me sacó dos cosas de encima: una construcción que no hacía falta y un diagnóstico que era falso. Si esta semana estás por contratar, comprar o construir algo, ese es el uso que casi nadie le da a esto.
Las horas se llenan igual cuando nadie va a buscar los errores, y desde afuera no se nota la diferencia. Yo estoy unos pasos adelante en el mismo camino que vos, dejando el mapa a la vista mientras lo dibujo.
Lo próximo es peor y más divertido: construí una máquina que publica en siete plataformas, funcionó, y después vi que de quinientas ochenta y cuatro publicaciones, quinientas setenta y nueve no se podían medir. Eso lo cuento cuando lo arregle.
Si conocés a alguien que esté por dejar algo corriendo sin mirar, reenviale esto.
Human, see you next week.
Welcome to The Lobby.
— Ivan
Watch the full episode → youtube.com/watch?v=LdzO-E1YCy4