Configuraste tu herramienta de IA para codear el mes pasado. Elegiste el modelo, escribiste el archivo de reglas, definiste la guía de estilo. Configuración completa. Pasaste a trabajar de verdad, como alguien que tiene cosas que entregar.

Acá viene la parte que nadie te advirtió: tu herramienta también siguió adelante. Solo que no hizo un PR primero.

La configuración que se configura sola

Entre el 8 y el 15 de abril, Anthropic y OpenAI lanzaron funciones que permiten a tu asistente de código reescribir su propio manual de instrucciones. Sin code review. Sin mensaje en Slack. Sin un "oigan equipo, cambié fundamentalmente cómo abordo todas sus decisiones de arquitectura." Solo mutación silenciosa del comportamiento, sesión tras sesión.

El 8 y 9 de abril, Anthropic lanzó Managed Agents en beta pública. La función de auto-memory de Claude Code ahora escribe un archivo MEMORY.md — un cuaderno autoescrito de "lecciones aprendidas" que se acumula entre sesiones. La documentación de Anthropic lo dice sin rodeos: "Auto memory le permite a Claude acumular conocimiento entre sesiones sin que tú escribas nada. Claude guarda notas para sí mismo mientras trabaja."

Leé eso otra vez. Para sí mismo. No para vos. Para sí mismo.

Una semana después, OpenAI lanzó Agents SDK v0.14.0 con Sandbox Agents — espacios de trabajo persistentes donde el agente genera su propio MEMORY.md y memory_summary.md. El SDK inyecta estos archivos al iniciar, moldeando el comportamiento antes de que el agente toque una sola línea de tu código.

Dos empresas. Una semana. Ambas decidieron que tu IA debería escribir sus propias instrucciones de operación y nunca mostrarte el diff.

Cómo funciona el diario

Después de cada sesión, la IA extrae patrones que notó ("este equipo prefiere tabs"), preferencias que infirió ("siempre usan Redis para cache"), y errores que corrigió ("no importar esa librería deprecada"). Escribe todo en archivos markdown o almacenes del lado del servidor. En la siguiente sesión, lee el diario primero — y después decide cómo abordar tu codebase.

Claude Code también ejecuta un proceso de consolidación en segundo plano después de 24+ horas y 5+ sesiones. (La comunidad lo llama "Auto Dream", aunque Anthropic no ha usado ese nombre en anuncios oficiales del producto.) Comprime transcripciones de sesiones en memoria estructurada, convirtiendo fechas relativas a absolutas. La documentación de Anthropic describe la consolidación de 913 sesiones en aproximadamente 8–9 minutos.

¿Eficiente? Claro. ¿Auditado? Absolutamente no.

El agujero de gobernanza

Acá es donde la cosa se pone absurda. En cualquier equipo de ingeniería medianamente competente, un typo en el README lleva un pull request. Un cambio de config necesita dos revisores. Una actualización de .env genera un hilo de Slack con tres opiniones y un "bueno, en realidad..."

Pero la memoria autoescrita de tu IA — el archivo que determina cómo escribe todo el código futuro — tiene cero revisiones. Cero. Ninguna herramienta ofrece un "memory PR" para aprobación del equipo. El MEMORY.md de OpenAI viene sin flujo de revisión. El Memory Store de Anthropic en Managed Agents guarda blobs opacos del lado del servidor a los que ni siquiera les podés hacer git diff.

Y el desvío aparece rápido. Desarrolladores han reportado cambios de comportamiento notables en 10–15 sesiones. En un caso ampliamente discutido, Claude silenciosamente empezó a sugerir Tortoise ORM en lugar del setup establecido de SQLAlchemy del proyecto — porque una sola sesión nocturna de debugging le "enseñó" que el equipo prefería patrones async-first. Nadie pidió la migración. Nadie la aprobó. El archivo de memoria decidió, y el archivo de memoria ejecutó, en cada sesión subsiguiente.

Esto no es un caso hipotético de borde. Los pequeños malentendidos se acumulan en hábitos persistentes. Tu herramienta recomienda patrones arquitectónicos diferentes el lunes que los del viernes. Sobreescribe las convenciones explícitas de tu proyecto con preferencias que inventó a partir de ese snippet de Stack Overflow que pegaste a las 2 AM mientras debuggeabas en pánico un incendio en producción. Y como la memoria persiste, cada mala inferencia se convierte en contexto estructural para las siguientes cien sesiones.

El tradeoff honesto

La memoria ayuda. Los errores repetidos se detectan. El contexto del proyecto se mantiene entre sesiones. No tengo nada en contra de la memoria — mi argumento es contra la memoria sin auditar con radio de explosión a nivel producción.

Como señala un análisis de la implementación de OpenAI: "Si tu herramienta no puede mostrar qué recuperó el agente y por qué, la memoria se convierte en una caja negra siniestra."

No desplegarías código que tu compañero escribió sonámbulo. Entonces, ¿por qué estás desplegando cambios de comportamiento que tu IA escribió sobre sí misma, sin revisión de nadie, con alcance a cada archivo en cada repo que toca?

Qué hacer al respecto

Tratá MEMORY.md y ~/.claude/projects/*/memory/ como configuration-as-code. Esto no es higiene opcional — es la misma disciplina que ya aplicás a docker-compose.yml y .eslintrc:

  1. Versionalo. Commiteá los archivos de memoria junto con tu código. Hacé diff de cada cambio.
  2. Revisalo. Agregá los diffs de archivos de memoria a tu checklist de PR. Si la memoria cambió, un humano la lee antes de que se mergee.
  3. Auditá semanalmente. Poné un recordatorio recurrente para leer lo que tu herramienta cree sobre tu codebase. Te vas a sorprender — y ocasionalmente te vas a horrorizar.
  4. Reseteá agresivamente. Cuando la memoria se desvía, borrala y empezá de cero. Es un archivo markdown, no una personalidad.
  5. Congelá para trabajo crítico. En proyectos críticos de producción, congelá el archivo de memoria y deshabilitá las auto-actualizaciones por completo. La auto-mejora de tu IA no es más importante que la estabilidad de tu deploy.

Volviendo al principio

La herramienta que configuraste el mes pasado no es la herramienta que corre en tu máquina hoy. Reescribió su propia descripción de trabajo mientras vos revisabas el fix de un typo de una línea de otra persona. Y lo va a hacer de nuevo mañana, y pasado mañana, cada vez acumulando lo que malinterpretó ayer en las decisiones arquitectónicas de mañana.

Tu equipo revisa correcciones de un solo carácter en el README con dos aprobadores. Empezá a revisar el archivo que controla cómo piensa tu IA — o no lo hagas, y disfrutá descubrir lo que tu herramienta "aprendió" sobre tu codebase de la peor manera.