Loops que se mejoran solos
Producir y revisar no alcanza. Lo que separa un loop que converge de uno que no, es lo que hacés con lo que aprendiste.
Llevo un tiempo con agentes que codean por mí. Y hay algo que me molesta cada vez que reviso un PR: corrijo lo mismo otra vez. Sacar el any. Renombrar variables. Pedir tests para el edge case que faltó. Kickback tras kickback, las mismas correcciones. El agente produce, yo reviso, y la próxima tarea arranca como si nada de eso hubiera pasado.
No sé si el agente es el problema. Creo que el workflow no está cerrando.
El ciclo que dejamos a medias
El flujo típico que veo es así. Le das un prompt. El agente produce. Vos revisás. Si algo está mal, lo mandás de vuelta. Si está bien, shipeás. Parece un ciclo cerrado.
Pero me parece que se cierra antes de tiempo. Falta lo que pasa después de la review: volver a alimentar el sistema con lo que aprendiste.
Yo lo pienso como cuatro pasos: observar, producir, revisar, mejorar. Ese cuarto es el que casi nunca veo armado. Sin él, el sistema repite los mismos errores con la misma confianza. No converge, o al menos yo todavía no vi que converja solo.
Y acá hay algo que me parece que importa: ¿qué aprendió el sistema después de que el humano tocó el output? Si la respuesta es “nada”, el workflow sigue incompleto. No tengo una fórmula para medirlo. Es más una sensación que me persiste entre reviews.
Lo que armé en Bille (y qué falta)
En Bille, el proyecto en el que vengo laburando, intenté cerrar ese hueco. No digo que esté resuelto. Todavía estoy viendo qué funciona.
El flujo base ya lo conté en otro post: tareas en Linear con el label “Ready For Claw”, un coder agent que codea, corre lint, typecheck y tests, y si pasa abre PR. Un reviewer que lee el diff, busca bugs y problemas de arquitectura, y si encuentra algo kickbackea al coder. Tres kickbacks sin resolución y me avisa. Eso ya estaba.
Lo que agregué después es distinto. Cada intento queda en una nota de Obsidian: qué se hizo, qué falló, qué decidió el reviewer, cuántos kickbacks van. El próximo agente lee eso antes de arrancar. Los agentes son amnésicos por naturaleza. El filesystem no.
Y hay un paso más que para mí es el que importa. Después de que yo reviso un PR, corre un Learning Flow: toma mis comentarios de review, los analiza, y actualiza CODING_PREFERENCES.md. No es un log crudo. Es intentar convertir “otra vez le saqué el any” en algo que el próximo coder lee antes de escribir una línea.
¿Baja la cantidad de kickbacks? A veces. A veces no. Cuando no baja, el límite de tres me obliga a entrar yo. Me parece bien. Prefiero eso a un loop que gira en círculos sin avisar.
Los documentos de gusto
Las notas de Obsidian son memoria de tarea. Los taste documents son otra cosa. Yo les digo así a los style guides que evolucionan con el laburo real.
En código, CODING_PREFERENCES.md no es un copy-paste de reglas genéricas de TypeScript. Se alimenta de mis reviews. Si siempre le saco el any, eso debería quedar escrito para el próximo agente. Si siempre pido tests para edge cases, también.
En escritura hago lo mismo con este blog. Tengo un style guide que actualizo después de cada merge. Comparo lo que el agente escribió con lo que terminé publicando. Si siempre reescribo los párrafos que arrancan con “Además”, eso entra al guide. La próxima vez, con suerte, el agente ya lo sabe.
Un style guide estático te sirve para arrancar. Uno vivo, creo, es lo que hace que el loop deje de sentirse como automation pura.
La analogía que uso con amigos: es como un intern que de a poco aprende cómo te gusta el café, en vez de uno que te lo pide mal siempre. El primer mes te trae cortado cuando querés lagrima. Si vos siempre decís “no, lagrima” y eso queda registrado, el segundo mes ya debería saber. El feedback tiene que ir a algún lado que persista. Si no, estás gastando el mismo esfuerzo en cada review.
No es automático
Lo que me interesa de esto no es solo el mecanismo. Es que el paso de mejora no te lo da ninguna herramienta. No vi un feature de Cursor que actualice tus preferencias después de cada kickback. No hay un checkbox en Linear que diga “aprender de este comentario”. Es algo que tenés que construir encima del stack.
Y es fácil dejarlo afuera porque las otras tres partes ya funcionan. Producir, revisar, shipear. Esa rueda gira sola. El problema es que puede girar sin avanzar. Cada vuelta parece igual a la anterior si nadie escribe la lección en un lugar que el próximo agente lea.
No es solo código. Cualquier workflow donde un humano corrige output de IA tiene el mismo hueco. Marketing copy, diseño, specs de producto. Si la corrección no vuelve al sistema, el sistema no aprende. Punto.
Lo que me queda por resolver
Todavía estoy viendo qué funciona y qué no. El sistema de Bille es joven. Los taste documents cambian con cada iteración. A veces el Learning Flow propone algo que no quiero en el guide y lo edito a mano. A veces actualizo el guide yo directamente porque fue más rápido.
No tengo una respuesta clara sobre cuándo conviene automatizar el paso de mejora y cuándo conviene hacerlo a mano. Mi intuición, imperfecta: si lo corregís dos veces seguidas en reviews distintas, debería estar escrito en algún lado. Si es un one-off, capaz no.
Si estás usando agentes y sentís que corregís lo mismo una y otra vez, me pregunto si te pasa lo mismo que a mí. ¿Tenés algún lugar donde las correcciones vuelven al sistema? ¿O cada review es un evento aislado?
Yo voy a seguir iterando el flujo en Bille. Escribir las lecciones en CODING_PREFERENCES.md, en las notas de Obsidian, en los guides del blog. Ver si con el tiempo dejo de sacar el mismo any en el PR número doce. No sé si va a funcionar. Pero me parece el único paso que no puedo saltear si quiero que esto escale sin que yo me convierta en el cuello de botella eterno.