A los seis meses, un equipo tiene un tipo concreto de amnesia. El código está todo ahí, legible, corriendo. Lo que ha desaparecido es todo lo de alrededor. ¿Por qué partimos el servicio? ¿Por qué es nullable este campo cuando obviamente no debería? ¿No probamos ya a cachear aquí y lo quitamos? Nadie se acuerda, o tres personas se acuerdan distinto, y quien de verdad lo decidió se fue en primavera.
Los equipos no olvidan el código. El código es lo único que sobrevive, porque es el artefacto que todos están obligados a conservar. Lo que se evapora es la capa de encima: las decisiones, las razones detrás de ellas, y los callejones sin salida. Esa capa es la memoria de producto, y casi nada en un montaje normal es responsable de guardarla.
Las tres cosas que se olvidan
Las decisiones. No el resultado, que se ve en el código, sino el hecho de que se tomó una elección siquiera. Alguien decidió usar esta cola en vez de aquella, hacer este endpoint síncrono, capar los reintentos a tres. En el código solo parece que las cosas son así. La decisión, el momento en que pudo ir de otra manera, no deja rastro salvo que alguien la registre.
Las razones. Esta es la cara. El porqué nunca es visible en el código, porque el código es el resultado de una razón, no la razón en sí. Puedes leer que los reintentos están capados a tres. No puedes leer que están capados a tres porque el proveedor de aguas abajo te throttleaba a cuatro y despertó a alguien a las 3 de la mañana. Pierde la razón y la decisión parece arbitraria, lo que significa que la siguiente persona, o el siguiente agente, la “arreglará” y redescubrirá el aviso de las 3 de la mañana.
Los callejones sin salida. Los caminos que probaste y abandonaste. La capa de caché que montaste y quitaste porque provocaba lecturas viejas. La librería que evaluaste y rechazaste. Estos son los más completamente olvidados de todos, porque no queda código que siquiera insinúe que pasaron. El trabajo se hizo, la lección se aprendió, y luego la evidencia se borró junto con la rama. Así que el conocimiento de “esto ya lo probamos y aquí está por qué falló” no existe en ningún sitio, y el equipo está condenado a probarlo otra vez.
Lo que cuesta cuando nada recuerda
Con un equipo humano, la memoria olvidada aparece como re-litigación. El mismo debate sobre la misma arquitectura, cada pocos meses, sin que nadie pueda señalar por qué se zanjó la última vez. Las decisiones se revierten en silencio por gente que nunca supo que eran decisiones. El cerebro de producto se pudre y lo sientes como una sensación vaga de que el equipo no deja de tener las mismas conversaciones.
Con agentes, el coste es más afilado y más rápido, porque un agente no tiene memoria ninguna más allá de lo que le entregas. Un agente no sabe que ya probaste el enfoque de caché y lo abandonaste. Así que cuando la tarea parece pedir caché, monta la caché, con seguridad, caminando directo de vuelta por el callejón sin salida del que tardaste dos semanas en salir. Revierte una decisión porque nunca supo que se tomó una decisión. “Limpia” el campo nullable raro porque nada le dijo que el campo es raro a propósito. Cada hueco en la memoria de producto se vuelve un sitio donde el agente hace daño comportándose de forma razonable, porque razonable-sin-memoria es justo el fallo.
Y esto compone con agentes en paralelo. Cada uno empieza en frío, así que cada uno es igual de capaz de re-caminar el mismo callejón sin salida, y lo pueden hacer a la vez, en partes distintas del codebase, toda la tarde.
La memoria tiene que atarse a lo que explica
El instinto es escribirlo en algún sitio. Un doc de decisiones, una página de wiki, un canal donde se anuncian las elecciones. Es mejor que nada y se degrada igual que se degrada cada carpeta de notas: se separa del código, nadie la enlaza con nada, y seis meses después el registro de la decisión y el código que supuestamente explica no tienen ninguna conexión que puedas seguir.
La memoria de producto solo es útil cuando está atada a lo que explica. Una decisión flotando en un doc es una anécdota. La misma decisión enlazada al código exacto que gobierna, y al código que se quitó cuando se abandonó un callejón sin salida, es memoria que de verdad puedes usar. Ahora cuando un agente, o una persona, mira la lógica de reintentos, la razón de que esté capada a tres está justo ahí, atada a la lógica de reintentos, no enterrada en un doc del año pasado que nadie va a encontrar. Cuando un agente se plantea montar una caché, el registro de la última caché y por qué se quitó es alcanzable desde el sitio donde iría la caché.
Esa es la diferencia entre un archivo y una memoria. Un archivo es donde la información va a olvidarse de forma organizada. Una memoria es conocimiento atado al contexto donde de verdad hará falta, que para un codebase significa atado al código, en una estructura que tanto personas como agentes puedan recorrer. Es la misma razón por la que un grafo de conocimiento de producto enlaza artefactos al código en vez de guardarlos al lado, y la razón por la que el contexto para agentes de código va de estructura sobre prosa: la memoria que no está atada a donde hace falta es memoria que no se encontrará a tiempo.
El callejón sin salida es la memoria más valiosa y la que nada guarda
De las tres, el callejón sin salida merece atención especial, porque es a la vez la memoria más útil y la que tus herramientas están estructuralmente diseñadas para borrar. Cuando abandonas un enfoque, lo normal es borrar la rama, revertir los commits, cerrar el PR. Limpias. Y limpiar es justo el acto de destruir el único registro de que el intento pasó. El código que habría insinuado “alguien fue por aquí y se dio la vuelta” es precisamente el código que quitas.
Así que el modo de fallo está garantizado. No queda ningún artefacto diciendo “probamos event sourcing aquí y lo abandonamos porque el coste de replay era insostenible a nuestro volumen”. Seis meses después alguien propone event sourcing, fresco y entusiasmado, y no hay nada en el codebase que lo contradiga, porque la evidencia se recogió y se tiró. El equipo vuelve a pagar las dos semanas para reaprender lo que ya sabía.
Para un agente esto es peor, porque el agente es el que más entusiasmo pone en volver a proponerlo. No tiene tejido cicatricial. Lee el estado actual, ve un problema que event sourcing resolvería con elegancia, y lo monta, sin ninguna conciencia de que esta idea exacta se probó y falló por una razón concreta que sigue aplicando. Lo único que corta el bucle es una memoria del callejón sin salida que sobreviva a la rama borrada: un registro, atado a la parte del sistema que le concierne, que diga esto se probó, esto es por qué se dejó, y esta es la restricción que lo hizo fallar. Eso es algo que tienes que guardar a propósito, porque cada valor por defecto de tu flujo está intentando tirarlo.
Dónde encaja PaellaDoc
Esta es una capa que PaellaDoc guarda en tu máquina. Las decisiones se registran cuando se toman, con sus razones, y se enlazan al grafo junto al código que gobiernan. Los enfoques abandonados se capturan como lo que son, probados y rechazados y por qué, así que el callejón sin salida se recuerda incluso después de que la rama desaparezca. Cuando un agente trabaja, esa memoria es alcanzable desde el código del que va, así que el agente deja de revertir decisiones zanjadas y de re-caminar caminos que el equipo ya dejó atrás. El código nunca fue lo que olvidaste. Esta es la parte que tu sistema debería guardar, para que tu equipo deje de pagar por reaprenderla.
¿Qué decisión ha re-litigado tu equipo más veces, y dónde está de verdad escrita la razón de que se zanjara? Cuéntame en el foro.
Preguntas frecuentes
¿Qué es la memoria de producto?
La capa por encima del código que un equipo olvida: las decisiones que se tomaron, las razones detrás de ellas, y los callejones sin salida que probaste y abandonaste. El código sobrevive porque todos están obligados a conservarlo. Esa capa no, salvo que algo sea responsable de guardarla, y en casi todos los montajes nada lo es.
¿Por qué mi equipo revive las mismas decisiones ya zanjadas?
Porque la razón por la que se zanjó vive en la cabeza de alguien, y esa persona se fue en primavera o ahora se acuerda distinto. Sin un registro enlazado al código que gobierna, una decisión no deja rastro, así que parece arbitraria y la revierte en silencio gente que nunca supo que era una decisión.
¿Por qué los agentes reconstruyen enfoques que ya abandonamos?
Porque un agente no tiene memoria más allá de lo que le entregas, y la rama borrada que probaba que el enfoque falla es justo lo que tu flujo tiró. Ve un problema que el enfoque abandonado resolvería con elegancia y lo monta, caminando directo de vuelta por el callejón sin salida, porque razonable-sin-memoria es el fallo.
¿Dónde debería vivir la memoria de producto?
Atada a lo que explica, no flotando en un doc. Una decisión enlazada al código exacto que gobierna es memoria que puedes usar; la misma decisión en una wiki es una anécdota que nadie encuentra. Cuando la razón del cap de reintentos está sobre la lógica de reintentos, una persona o un agente que lee ese código la ve a tiempo.