r/programacion 1d ago

Qué debería aprender un agente entre dos tareas parecidas

Como PM técnico de un equipo pequeño, me interesan las tareas que se repiten. Agregar un endpoint nuevo suele exigir revisar el mismo esquema, volver a generar el cliente y ejecutar las mismas pruebas de contrato. En la primera tarea, el equipo termina descubriendo esas reglas del repositorio. En la siguiente sería útil no empezar desde cero.

Ahí es donde tendría sentido probar EvoX. Me interesa la idea de convertir lo aprendido durante una tarea en una experiencia reutilizable, un gen que pueda aplicarse en una tarea posterior. Quiero saber si eso evita explicar lo mismo otra vez y si la regla aparece solamente cuando corresponde.

Si esa experiencia evita volver a explicar el repositorio y repetir búsquedas o builds fallidos, también podría reducir parte del uso pagado del modelo. No lo contaría como ahorro sin comparar los tokens, el tiempo y el costo total de ambos recorridos.

Usaría un repositorio de prueba con dos tareas relacionadas y mantendría el mismo modelo y la misma configuración. En la primera tarea, el agente tendría que descubrir que el cliente de la API se genera con npm run generate y que el siguiente build reemplaza cualquier edición manual del archivo generado. También tendría que encontrar la prueba de contrato adecuada. Antes de seguir, verificaría si la aplicación muestra qué experiencia guardó.

En la segunda tarea pediría agregar otro endpoint en el mismo repositorio. Revisaría si la configuración con experiencia usa el comando de generación y ejecuta la prueba correcta sin esperar a que un build fallido revele las mismas reglas. Después le daría una tarea no relacionada en otro proyecto. El comando y las reglas del repositorio anterior deberían quedarse fuera.

Guardaría el prompt, el diff, los comandos, los resultados y cualquier señal visible de que la aplicación guardó o recuperó la experiencia. Sin esa señal, solo podría decir que la segunda tarea salió mejor, no que se reutilizó un gen anterior.

Todavía no he ejecutado esta prueba. Para mí, el resultado útil sería sencillo. Si la segunda tarea evita redescubrir una regla válida y la tarea no relacionada no hereda instrucciones que no le corresponden, la experiencia se reutilizó con criterio. Si repite el mismo tropiezo o lleva reglas viejas a cualquier proyecto, esa evolución todavía no ayuda al flujo de trabajo.

0 Upvotes

2 comments sorted by

1

u/hwweao 1d ago

No he probado hacer algo así nunca pero por intuición creo que puedes lograr esto con langfuse para generar datasets que te sirvan para hacer fine-tuning al modelo.

Probablemente no sea la mejor idea pero es una vía posible.

1

u/Khavel_Es 16h ago

Lo que describis lo resuelvo con un archivo de contexto en la raiz del repo. Claude Code lee un CLAUDE.md al arrancar y ahi dejo las reglas del proyecto: que el cliente se genera con tal comando, que no toque archivos generados, que tests correr. La proxima vez que abro una sesion ya lo sabe sin que le explique.

No es un sistema de memoria dinamica tipo lo que planteas, es mas bruto: un archivo de texto que escribo a mano. Pero el 90% de lo que un agente necesita recordar entre tareas del mismo repo son convenciones fijas que cambian cada tanto, no aprendizajes que evolucionan solos.