290 sesiones, 13 lecciones: lo que los agentes de IA aprendieron por sí mismos

Casi todas las mañanas aparece una lección en la parte superior de mi terminal. Dice: ejecuta las pruebas que escribiste e informa si pasaron o fallaron antes de decir que terminaste.

Nadie de nuestro equipo escribió esa frase. La escribió un agente, de noche, después de repasar un día entero de su propio trabajo y darse cuenta de que seguía escribiendo pruebas sin ejecutarlas después.

A esto se le llama automejora recursiva (RSI). Suena a algo sacado de un artículo sobre el fin del mundo. En la práctica se parece más a un músico que escucha la grabación después del concierto. Oyes el pasaje en el que te apresuraste. Lo anotas. Mañana te apresuras un poco menos.

Tenemos este ciclo funcionando en nuestras propias máquinas desde mediados de septiembre. Casi todo lo que leo sobre la RSI de los agentes de IA trata de lo que podría hacer algún día. Esto trata de lo que el nuestro ha hecho hasta ahora.

Cómo funciona el ciclo

Sno Station lo ejecuta una vez al día. Los pasos son sencillos.

Recopila las sesiones del día de Claude Code y Codex. Cada sesión recibe una etiqueta rápida: vale la pena conservarla o no, tuvo éxito o falló. Las que se conservan pasan a un modelo evaluador, que busca un momento en el que se aprendió algo. Por lo general es una persona que corrige al agente, aunque a veces el agente detecta su propio error y otras veces el entorno simplemente le juega una mala pasada.

Para cada momento, el modelo evaluador escribe una lección con cuatro partes. La situación que la desencadena. El consejo. El motivo. Y la evidencia, citada palabra por palabra de la sesión, con la línea de la que salió.

Después, la lección tiene que superar dos filtros.

El primero es mecánico. Cada cita que presenta la lección debe aparecer, carácter por carácter, en la sesión de la que dice proceder. Una lección basada en una cita que no está allí se descarta. El segundo filtro es otro modelo cuya única tarea es dudar. Compara cada frase de la lección con la evidencia, y una lección que afirma más de lo que esta respalda no pasa.

Después interviene una persona. Leo lo que queda y decido si conservarlo o no.

Las lecciones que sobreviven se muestran a los agentes al comienzo de sesiones posteriores, una línea por lección, con las que más han ayudado arriba. Si una lección parece relevante, el agente puede abrirla completa.

Qué salió de todo esto

Estas son las cifras, tomadas de los propios registros del ciclo en nuestra máquina de compilación.

Recopiló 1.879 sesiones. De ellas, 290 se enviaron al modelo evaluador. 13 lecciones superaron ambos filtros. Conservé 6. Las otras 7 siguen ahí, esperando a que tome una decisión.

290 sesiones, 13 lecciones. Al principio me sorprendió esa proporción. Luego lo pensé. ¿Cuántos días de tu propio trabajo contienen algo que anotarías y pegarías en la pared? La mayoría de los días son solo días.

Y las lecciones son pequeñas. Si quieres que te diga la verdad, esperaba algo más grandioso. Aquí tienes tres, citadas tal como las escribieron los agentes.

Después de cambiar el nombre de un paquete o directorio con git mv en un espacio de trabajo npm, antes de ejecutar la prueba de verificación, comprueba explícitamente si hay artefactos obsoletos en los directorios de salida de compilación que git ignora para cada paquete (dist/, build/, out/). Muévelos o elimínalos.

Antes de crear cada fragmento de un parche, lee el intervalo exacto de líneas en el destino de ese fragmento para captar el contexto literalmente. Nunca reutilices identificadores ni sintaxis de una lectura anterior y truncada del mismo archivo.

Etiqueta la capacidad como «no documentada en las fuentes examinadas» hasta que un contrato explícito o una prueba delimitada establezca que no existe.

La primera nos costó una tarde el día en que ocurrió. Se cambió el nombre de un paquete, todo el código fuente estaba bien y la instalación seguía fallando porque un archivo compilado antiguo aún estaba en una carpeta que git no examina. La segunda es el tipo de cosa que un agente hace cuarenta veces por semana: recuerda más o menos lo que decía un archivo y escribe un parche basándose en su memoria en vez de consultar el archivo.

La tercera es mi favorita. Un agente estaba comparando productos, no encontró una función en la documentación de un competidor y comunicó que ese competidor no la tenía. El silencio no demuestra la ausencia. Esa es una lección que también he tenido que enseñar a personas.

Son las cosas que un ingeniero veterano lleva consigo sin darse cuenta. Cicatrices. La diferencia es que un agente comienza cada sesión sin cicatrices.

Cuánto vale

Todavía no puedo decir cuánto ayuda nada de esto.

Las lecciones se mostraron al inicio de 5.595 sesiones. Un agente abrió una de ellas completa 135 veces. Es decir, alrededor del 2 por ciento de las veces. La versión de una línea hace casi todo el trabajo, o nada lo hace. No siempre sé cuál de las dos cosas es cierta.

El ciclo también comprueba sus propios resultados. Después de mostrar una lección, pregunta si el agente la siguió y si eso ayudó. Hasta ahora tiene dos respuestas claras de «la siguió y ayudó». Las dos corresponden a la misma lección. Otros siete casos quedaron sin aclarar.

¿Y la lección que aparece en la parte superior de mi terminal, la de ejecutar tus pruebas? Después de ponerla en marcha, los agentes a veces seguían saltándose las pruebas. 4 fallos en 12 sesiones. Antes de la lección eran 22 en 119. La muestra es demasiado pequeña para decir que empeoró. Desde luego, también es demasiado pequeña para decir que mejoró.

Así que todavía no lo sé. Lo digo sin rodeos. Si hoy me obligaras a ponerle un valor, diría que cada lección conservada evita un error que cuesta entre diez minutos y una tarde, y que esos mismos seis errores se repiten con suficiente frecuencia como para que importe. Una noche de evaluación de 193 sesiones costó unos cincuenta centavos. El costo de equivocarse sobre su valor es bajo.

En lo que sí confío es algo más pequeño que una medición. Reconozco las lecciones. Las leo y pienso: sí, eso pasó, y sí, eso es lo que yo le habría dicho.

Qué salió mal

El propio ciclo necesitó el mismo tratamiento que da a los agentes.

Al principio, un defecto permitió que algunos borradores de lecciones pasaran el segundo filtro sin que se revisaran en absoluto. Los descartamos todos. Las cifras anteriores solo incluyen las que pasaron por todo el proceso.

También habíamos construido el ciclo con demasiado cuidado. Una prueba canaria, una comprobación de hash, recuperación tras fallos. Una noche eliminamos 724 líneas de todo eso y funcionó mejor. Habíamos envuelto un sistema para aprender de los errores en protecciones contra errores que nunca había cometido.

Luego, a finales de septiembre, el ciclo se quedó en silencio. Había desaparecido un archivo de configuración y cada noche se despertaba, no encontraba nada que tuviera permitido enviar y volvía a dormirse. Siguió así durante una semana antes de que alguien se diera cuenta. Cuesta querer a algo que falla en silencio a las tres de la mañana.

Eso ya está en la lista. Probablemente debería convertirse en una lección.

Hacia dónde va esto

Trece lecciones no son un agente que se reescribe a sí mismo. Son un cuaderno de notas. Hace un mes, nuestros agentes cometían el martes el mismo error que habían cometido el lunes, sin recordar ninguno de los dos.

Algunas mañanas el recordatorio está ahí y las pruebas siguen sin ejecutarse.

Sno Station es de código abierto, y la revisión nocturna forma parte de él. Está en sno.ai.