Por qué los humanos creen que recuerdan todo, y por qué SDLC Memory demuestra que no es así
Author: Yauheni Kurbayeu
Published: Feb 22, 2026
LinkedIn
Existe una ilusión silenciosa dentro de toda organización de ingeniería. Creemos que recordamos.
- Creemos que recordamos por qué elegimos esta arquitectura.
- Por qué existe esa restricción.
- Por qué ocurrió realmente ese incidente.
- Por qué separamos la lógica de la UE de la de EE. UU.
- Por qué pospusimos esa migración.
Pero la ciencia cognitiva dice algo muy incómodo.
Según investigaciones de psicología cognitiva sobre la capacidad de la memoria de trabajo, nuestra memoria de trabajo activa normalmente puede retener aproximadamente cuatro unidades significativas de información al mismo tiempo. No cuarenta. No cuatrocientas. Cuatro. Todo lo demás se reconstruye a partir de fragmentos, hábitos y pegamento narrativo. Y a menos que repitamos o externalicemos la información, se degrada rápidamente. No es una falla de liderazgo. Es biología.
Ahora compáralo con los agentes modernos de IA. Claude puede operar con 200K tokens, a veces incluso 1M. Codex soporta 400K. Eso suena enorme en comparación con un cerebro humano que maneja cuatro restricciones activas.
Pero aquí está el giro.
Ni siquiera eso es suficiente para un SDLC vivo.
La escala de la memoria real de entrega
Tomemos una configuración muy ordinaria: tres equipos, quince ingenieros, sprints de dos semanas. Nada extremo. Ninguna complejidad de hiperescalado. Solo un producto SaaS saludable evolucionando en producción.
Si comprimes el trabajo en resúmenes de nivel de decisión, como tickets destilados a su intención, PRs resumidos por impacto, ADRs capturados con alternativas, incidentes estructurados con causas y mitigaciones, aún generas una cantidad sorprendente de material de razonamiento estructurado.
En la práctica, eso significa aproximadamente 150 tickets por mes entre equipos. Alrededor de 200–250 pull requests. Un puñado de ADRs y conversaciones de arquitectura. Algunos incidentes de producción. Resultados de planificación de sprint. Decisiones de revisión. Aceptaciones de riesgo.
Cuando condensas todo eso en artefactos canónicos y estructurados —no ruido bruto de Slack, no logs, sino memoria preparada para razonamiento— llegas a aproximadamente 200 000 tokens por mes.
No tokens teóricos. Memoria real de entrega.
A escala empresarial, con 80 ingenieros y constante churn arquitectónico entre equipos, ese número sube a entre uno y un millón y medio de tokens por mes.
Ahora compáralo con las ventanas de contexto.
Doscientos mil tokens apenas caben en algunos modelos modernos. Cuatrocientos mil dan algo más de espacio. Un millón parece generoso.
Pero aquí está la realidad estructural: un solo trimestre de memoria de entrega ya supera lo que cabe cómodamente en una sola ventana de sesión. Y las sesiones se reinician.
Una ventana de 400K te compra tiempo. No te compra continuidad.
Esta es la misma limitación que enfrentan los humanos, solo a una escala diferente.
El problema real no es el almacenamiento
Curiosamente, el almacenamiento es trivial.
En tu escala actual, un año completo de memoria SDLC curada, incluyendo embeddings y relaciones de grafo, podría consumir menos de 70 MB. Incluso a escala empresarial, seguirías cómodamente por debajo de medio gigabyte de memoria estructurada.
El costo de infraestructura es insignificante.
Lo que es costoso es la continuidad cognitiva.
Cuando la memoria vive solo en la cabeza de las personas, cada cambio de director reinicia el contexto. Cada incidente repite errores anteriores. Cada debate arquitectónico reproduce argumentos que ya se resolvieron hace seis meses. Los equipos redescubren restricciones como si fueran nuevas ideas.
No tienes un problema de memoria porque falte documentación.
Tienes un problema de memoria porque falta memoria estructurada, consultable y causalmente vinculada.
Por qué ventanas de contexto más grandes no nos salvarán
Aumentar las ventanas de contexto parece progreso. Y lo es. Pero es escalado horizontal de la capa equivocada.
Una ventana de contexto grande sigue estando ligada a una sesión. Sigue siendo transitoria. Sigue reiniciándose.
Sin una estructura duradera, el agente olvida cuando termina la sesión. Sin una estructura duradera, los humanos reconstruyen desde fragmentos.
Seguimos intentando resolver la continuidad con prompts más grandes.
Lo que realmente necesitamos es memoria en capas.
El cerebro SDLC Hot / Warm / Cold
Si tratamos el SDLC como un sistema vivo, la memoria debe comportarse como un sistema nervioso.
Memoria caliente (Hot) es lo que está ocurriendo ahora.
- El sprint actual.
- Incidentes abiertos.
- Riesgos activos.
- Preguntas sin resolver.
- Es fluida, se actualiza diariamente y es lo suficientemente pequeña para inyectarse en una sesión de agente.
- Este es tu conjunto operativo de trabajo.
Memoria templada (Warm) es el cerebro evolutivo del producto.
- Decisiones arquitectónicas.
- Trade-offs. Postmortems.
- Restricciones de cumplimiento.
- Límites de propiedad.
- Artefactos canónicos como Decisions, Questions, Risks, Actions, ADRs y las relaciones entre ellos.
Esta capa abarca meses. Evoluciona, pero no desaparece. No se inyecta completa; se recupera selectivamente.
Memoria fría (Cold) es evidencia.
- Hilos brutos de Jira.
- Transcripciones de Slack.
- Diffs de PR.
- Grabaciones.
- Logs.
- Prueba inmutable de lo que ocurrió y por qué.
- Rara vez se inyecta directamente, pero siempre está vinculada.
La idea clave es simple.
Hot se mueve. Warm estabiliza. Cold preserva.
Los agentes consultan entre capas. Los humanos razonan entre capas. Ninguno debería depender solo del recuerdo.
La capa que falta: Provenance
El verdadero poder no proviene solo de la búsqueda vectorial.
Proviene de las relaciones.
Muchos equipos asumen que RAG resuelve la continuidad. Ayuda, pero la similitud no es una explicación. Encontrar un “ticket similar” no es lo mismo que entender por qué existe una restricción.
Toda decisión significativa debe saber:
- Quién la tomó.
- Cuándo.
- Con qué evidencia.
- Qué alternativas se rechazaron.
- Qué impacta.
- Qué riesgos mitiga.
- A qué incidentes contribuyó posteriormente.
- Si reemplazó una decisión anterior.
Ahí es donde la estructura de grafo se vuelve esencial.
- Una base de datos vectorial te ayuda a encontrar “ideas similares”.
- Una base de datos de grafos te ayuda a responder “¿por qué existe esto?”
La búsqueda vectorial recupera relevancia. El recorrido del grafo reconstruye causalidad.
Cuando combinas ambos, dejas de buscar texto y empiezas a recorrer razonamiento.
Ahí es cuando el SDLC se vuelve trazable.
¿Qué ocurre cuando los equipos se mueven hacia agentes de IA?
Ahora imaginemos un futuro que no es hipotético, un futuro cercano que muchos líderes ya están percibiendo. Con los agentes de IA volviéndose cada vez más capaces, encuestas muestran que grandes proporciones de desarrolladores y equipos de ingeniería ya dependen de la IA en los flujos de trabajo diarios, con algunas estimaciones indicando que más del 80 % de los ingenieros utilizan regularmente herramientas de IA para asistir en tareas de desarrollo y programación.
Incluso hay voces que sugieren que en pocos años muchas tareas tradicionales de ingeniería de software estarán ampliamente automatizadas por agentes, dejando a los humanos más enfocados en planificación, diseño y supervisión en lugar de escribir código directamente.
En este escenario, donde entre el 50 % y el 80 % del trabajo diario de programación y ejecución es manejado por agentes de IA, el problema de la procedencia (provenance) se vuelve dramáticamente más agudo. Cuando los ingenieros humanos escriben menos líneas de código y pasan más tiempo dirigiendo agentes autónomos, el contexto y la justificación de las decisiones se vuelven aún más esenciales:
- El producto del trabajo deja de ser el artefacto principal.
- Lo que importa pasa a ser por qué y cómo un agente eligió una implementación particular, no solo lo que produjo.
Incluso estudios que encuentran que las herramientas de IA aumentan la productividad individual o del equipo (con incrementos que a menudo oscilan entre aproximadamente un 20 % y un 60 % o más) también destacan que los desarrolladores terminan pasando más tiempo supervisando el trabajo, validando resultados y corrigiendo problemas generados por agentes, el tipo de razonamiento de alto nivel que no puede automatizarse sin memoria del contexto previo.
Los agentes de IA pueden reconocer patrones y escribir código, pero no llevan inherentemente objetivos organizacionales, estrategia de producto o los trade-offs de decisiones pasadas, a menos que estos se codifiquen explícitamente en una capa estructurada de procedencia.
Este cambio amplifica la necesidad de la capa Warm de Provenance:
- Cuando los agentes crean código de forma autónoma, debes saber qué llevó a esa decisión tanto como qué hace el código.
- Cuando los agentes reemplazan tareas repetitivas, los humanos quedan con manejo de excepciones, estrategia y orquestación — los aspectos más difíciles de recordar sin memoria estructurada.
- Cuando un producto necesita demostrar cumplimiento, explicar mitigación de riesgos o reconstruir la intención meses después, el grafo de procedencia se convierte en el único registro fiable.
Sin él, las organizaciones corren el riesgo de construir sistemas opacos que ni siquiera sus propios creadores pueden justificar completamente.
Por qué esto importa aún más en la era de la IA
A medida que la IA reduce el costo de ejecución, la velocidad de entrega converge entre organizaciones. La generación de código mejora en todas partes. La creación de pruebas se acelera en todas partes. La documentación se redacta sola.
Lo que no converge es la disciplina de la memoria.
- Los equipos sin memoria SDLC estructurada vuelven a debatir decisiones pasadas.
- Reintroducen riesgos ya mitigados.
- Repiten errores arquitectónicos.
- Pierden contexto cada vez que rota el liderazgo o se va un ingeniero clave.
Los equipos con procedencia en capas explican decisiones bajo presión. Incorporan ingenieros y agentes de IA al razonamiento en lugar del folklore. Permiten que los agentes de IA operen con un verdadero anclaje histórico. Mantienen continuidad de gobernanza incluso cuando las personas cambian.
La diferencia no es la herramienta.
Es la memoria estructural.
Por qué esto importa para los líderes
Si gestionas múltiples equipos, especialmente en un entorno SaaS con fuerte cumplimiento normativo, ya estás simulando este sistema en tu cabeza.
Recuerdas qué dependencia es frágil. Recuerdas qué flujo de agentes produjo una release problemática. Recuerdas por qué la lógica de la UE se comportó de forma diferente en el último despliegue.
Pero tu cerebro no es un almacenamiento duradero. Es un motor de razonamiento con una ventana activa diminuta.
La carga cognitiva que sientes no es una debilidad.
Es una sobrecarga estructural.
Estás sosteniendo aproximadamente 200 000 tokens por mes en un procesador de cuatro unidades.
En un futuro donde los agentes de IA realizan la mitad o más del trabajo de ejecución, esa carga de memoria no desaparece. Se desplaza: de recordar código a recordar intención, causalidad y justificación.
Reflexión final
Los humanos no pueden recordar todo. Los agentes tampoco pueden recordarlo todo. Incluso ventanas de millones de tokens no son continuidad.
Pero las organizaciones pueden recordar todo si tratan la memoria como infraestructura, no como documentación.
La ejecución se está volviendo más barata. La memoria se está convirtiendo en el diferenciador.
En un mundo acelerado por la IA, los equipos con la memoria estructurada más fuerte no solo se moverán más rápido.
Se moverán de forma consistente y responsable. Serán los equipos capaces de explicar no solo qué se hizo, sino por qué se hizo, mucho después de que el código haya sido escrito.