Un asistente de programación puede corregir un bug en una sesión y volver a introducirlo al día siguiente. No siempre es un problema de inteligencia del modelo. Muchas veces, la corrección nunca se convirtió en una instrucción reutilizable.
Si queremos que un agente de IA mejore entre sesiones, no basta con pedirle que recuerde la conversación. Hay que diseñar un circuito en el que las decisiones importantes se documenten, se recuperen en el momento adecuado y se comprueben con una prueba.
Un agente no aprende solo porque recuerde una conversación
Cuando un asistente de programación repite el mismo error en varias sesiones, la primera reacción suele ser culpar a la memoria. Sin embargo, recordar texto no es lo mismo que conservar una decisión operativa.
Un historial puede contener cientos de mensajes y aun así no responder a las preguntas que importan: qué solución fue descartada, por qué se eligió una alternativa, qué prueba confirmó el cambio y qué regla debe aplicarse la próxima vez.
Por eso conviene separar tres conceptos: memoria, contexto y validación. La memoria conserva información; el contexto decide qué información es relevante para la tarea actual; la validación comprueba si la decisión sigue funcionando. Si falta cualquiera de las tres capas, el agente puede repetir una solución que ya demostró ser incorrecta.
El error repetido es un problema de representación
Un mensaje como «no vuelvas a hacer eso» es comprensible para una persona, pero demasiado ambiguo para un sistema. ¿Qué significa «eso»? ¿El nombre de una función, una dependencia, una suposición sobre los datos o una forma concreta de manejar los errores?
Para que una corrección sea reutilizable, hay que convertirla en una regla observable. En lugar de guardar «la última solución falló», conviene registrar: condición de entrada, comportamiento incorrecto, evidencia del fallo, solución elegida y prueba que debe ejecutarse antes de dar la tarea por terminada.
Este formato convierte una experiencia aislada en una pieza de contexto que puede recuperarse. También facilita que otra persona revise la decisión sin tener que reconstruir una conversación completa.
Un registro pequeño suele ser mejor que un historial enorme
El contexto persistente no tiene que ser una base de datos gigantesca. En muchos proyectos basta con un archivo breve de decisiones, una lista de errores conocidos y un conjunto de comandos de verificación.
Cada entrada debería responder a cuatro preguntas: qué ocurrió, en qué condiciones ocurrió, qué se decidió y cómo se comprobará la decisión. Las entradas antiguas deben revisarse cuando cambia la arquitectura; una regla correcta para una versión anterior puede convertirse en ruido después de una migración.
También ayuda separar las instrucciones estables de las notas temporales. El formato de nombres del proyecto puede ser una convención estable. Un workaround para una dependencia concreta puede tener fecha de caducidad y debería marcarse como provisional.
Cómo diseñar una memoria que ayude de verdad
Una memoria útil no intenta almacenar cada detalle. Prioriza la información que cambia la forma de trabajar. Por ejemplo: convenciones del repositorio, decisiones de arquitectura, errores que ya se reprodujeron y comandos que deben ejecutarse antes de cerrar una tarea.
La información también necesita una forma estable. Un registro con campos como «contexto», «problema», «decisión» y «verificación» resulta más fácil de consultar que una colección de notas escritas con estilos diferentes. La estructura no tiene que ser sofisticada; lo importante es que obligue a explicar la relación entre el fallo y la solución.
Este principio no es exclusivo del código. En un flujo de edición de audio, por ejemplo, un sitio web para cambiar la portada de un archivo mp3 puede resolver una tarea puntual, pero el proyecto también necesita conservar el nombre de la versión final, el formato esperado y las decisiones de publicación. La herramienta ejecuta una acción; el contexto mantiene la coherencia del proceso.
El ciclo de corrección que evita la repetición
Reproducir el fallo con el caso más pequeño posible.
Guardar el mensaje de error y la condición que lo provoca.
Explicar por qué la primera solución no era suficiente.
Escribir una regla concreta para evitar la repetición.
Añadir una prueba o comando que confirme la regla.
Actualizar el registro cuando la arquitectura cambie.
Este ciclo tiene una ventaja práctica: obliga a distinguir una solución real de un parche accidental. Si el agente solo recibe el mensaje «ya está arreglado», puede repetir el mismo patrón cuando cambien los datos. Si recibe una condición y una prueba, tiene una señal más clara para decidir cuándo aplicar la regla.
El contexto debe entrar antes de la generación
Guardar una regla no sirve de mucho si el agente solo la ve después de proponer el código. Las decisiones relevantes deben incorporarse al contexto antes de que empiece la planificación. En una tarea relacionada con archivos de audio, esto puede incluir el formato de entrada, la estructura de carpetas y el objetivo de la transformación. En una tarea de software, puede incluir las APIs disponibles, las restricciones de rendimiento y los tests obligatorios.
Una forma sencilla de hacerlo es dividir el flujo en dos fases. Primero, el agente resume las restricciones aplicables y señala los registros que está utilizando. Después, propone una solución y explica qué comprobaciones realizará. Esta pausa reduce la probabilidad de que el modelo improvise una convención que el proyecto ya había descartado.
La recuperación también debe ser selectiva. Si se inyectan todas las notas históricas en cada sesión, las reglas importantes compiten con información obsoleta. Es mejor recuperar entradas relacionadas con los archivos, símbolos o comandos que aparecen en la tarea actual.
Del código a otros flujos de trabajo
El mismo patrón sirve para tareas creativas. Cuando se trabaja con una canción, no solo importa el archivo de audio: también importan la versión, el tempo, la tonalidad, las pistas que se conservarán y los cambios que ya se probaron.
Por ejemplo, una herramienta para extraer coro de una canción puede formar parte de un flujo de edición. Pero, si el proyecto no registra qué archivo original se utilizó, qué resultado se eligió y cómo se nombraron las pistas, la siguiente sesión puede repetir pasos o trabajar sobre una versión equivocada.
La lección es sencilla: las herramientas producen resultados; los sistemas de contexto preservan decisiones. Tanto en el desarrollo como en la creación musical, la consistencia nace de conectar cada acción con una intención y una verificación.
Límites y mantenimiento
Ningún registro de memoria es permanente por definición. Las dependencias cambian, los endpoints se deprecian y las convenciones del equipo evolucionan. Una regla que no tiene propietario ni fecha de revisión puede convertirse en una fuente de errores.
Conviene revisar periódicamente las entradas más antiguas y eliminar las que ya no describen el proyecto. También es importante no guardar secretos, tokens ni datos personales en archivos que puedan llegar al contexto del agente. La persistencia mejora el trabajo solo cuando se combina con control de acceso y revisión humana.
Un agente mejora cuando recibe mejores señales, no simplemente cuando recibe más historial. Una regla corta, vinculada a una prueba concreta, suele ser más útil que una transcripción completa de una sesión complicada.
La misma lógica aparece en los flujos creativos. Una herramienta puede recordar un archivo, pero el proyecto necesita conservar decisiones: qué versión se eligió, qué parte se reutilizará y qué transformación debe evitarse. El contexto convierte acciones sueltas en un proceso reproducible.
La memoria de un agente no debería ser un cajón donde se acumula todo. Debería parecerse más a un manual vivo: pequeño, revisable y conectado con comprobaciones. Así, cada error corregido deja de ser una anécdota y se convierte en una mejora que puede beneficiar a la siguiente sesión.
Top comments (0)