The latest articles on DEV Community by Luis Torres (@ltorresu82). https://dev.to/ltorresu82 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1090788%2F83343dcb-e76d-4c9d-8958-645b996b4c13.jpg https://dev.to/ltorresu82 en Luis Torres Sat, 30 May 2026 17:02:47 +0000 https://dev.to/ltorresu82/los-agentes-de-codigo-necesitan-memoria-durable-no-solo-contexto-2hia https://dev.to/ltorresu82/los-agentes-de-codigo-necesitan-memoria-durable-no-solo-contexto-2hia <p>Este texto nace de una práctica concreta usando agentes de código en repos reales.<br> El problema no fue que faltara contexto, sino que algunas decisiones importantes<br> quedaban en lugares donde el repositorio no podía recordarlas.</p> <p>Cuando trabajamos con agentes de código, es normal pensar primero en contexto:<br> archivos relevantes, instrucciones del proyecto, historial de la conversación,<br> errores recientes, logs, planes y pruebas.</p> <p>Todo eso ayuda al agente a resolver la tarea actual.</p> <p>Pero hay un problema distinto que aparece rápido en repos reales: algunas decisiones<br> técnicas no deberían vivir solo en el chat.</p> <p>Si una decisión cambia una frontera de servicio, define qué sistema es fuente de<br> verdad, fija un contrato de API, decide un runtime productivo o establece una<br> política técnica como "no usar fallbacks silenciosos", esa decisión afecta el trabajo<br> futuro. No basta con que el agente actual la entienda. El repositorio también debe<br> recordarla.</p> <p>Ahí entra la idea de memoria durable del repo.</p> <h2> El problema </h2> <p>Un agente puede recordar contexto durante una sesión. Incluso puede tener memoria<br> privada entre sesiones, dependiendo de la herramienta. Pero esa memoria no siempre es:</p> <ul> <li>visible para el equipo;</li> <li>revisable en pull requests;</li> <li>versionada junto al código;</li> <li>portable entre herramientas;</li> <li>explícita sobre qué decisiones están aceptadas y cuáles siguen en evaluación.</li> </ul> <p>Eso importa porque muchas decisiones técnicas condicionan cambios futuros.</p> <p>Por ejemplo:</p> <ul> <li>"Este servicio es la fuente de verdad del workflow".</li> <li>"Esta API es la única frontera válida para herramientas de agentes".</li> <li>"Si falta configuración obligatoria, el sistema debe fallar claro".</li> <li>"El entorno local debe activarse con un perfil explícito".</li> <li>"Esta integración es candidata, pero todavía no está aceptada".</li> </ul> <p>Si esas reglas quedan solo en una conversación, el próximo desarrollador o agente puede<br> volver a discutirlas, duplicarlas o romperlas sin saberlo.</p> <h2> ADRs como memoria del repositorio </h2> <p>Una forma simple de resolverlo es usar ADRs: Architecture Decision Records.</p> <p>Un ADR no tiene que ser largo. De hecho, mientras más corto y concreto, mejor. Su valor<br> está en registrar:</p> <ul> <li>qué decisión se tomó;</li> <li>por qué era necesaria;</li> <li>qué consecuencias debe respetar el trabajo futuro;</li> <li>si está aceptada, propuesta, pendiente o reemplazada.</li> </ul> <p>La pregunta de corte que uso es esta:</p> <blockquote> <p>Si otro agente o desarrollador toca esta parte en dos meses, ¿necesita conocer esta<br> decisión para no romper la arquitectura?</p> </blockquote> <p>Si la respuesta es sí, probablemente debe vivir como ADR, actualización de ADR o<br> candidato pendiente.</p> <p>Si la respuesta es no, probablemente basta con código, tests o documentación de<br> implementación.</p> <h2> No todo merece un ADR </h2> <p>El objetivo no es documentar todo.</p> <p>Cambiar el texto de un botón, refactorizar una función local o ajustar un detalle visual<br> normalmente no necesita un ADR. Son cambios importantes para el producto, pero no<br> necesariamente gobiernan decisiones futuras de arquitectura.</p> <p>En cambio, mover la fuente de verdad de un workflow desde un servicio backend hacia<br> constantes del frontend sí debería encender una alerta. Eso cambia ownership, contratos<br> y expectativas futuras. Si ya existía una decisión previa, no basta con editar código:<br> hay que actualizarla o reemplazarla explícitamente.</p> <p>La memoria durable no busca generar burocracia. Busca evitar que decisiones importantes<br> queden invisibles.</p> <h2> Qué hace Decision Memory </h2> <p>Decision Memory es un skill open source para agentes de código. Su trabajo es ayudar al<br> agente a decidir si una decisión técnica debe:</p> <ul> <li>crear un ADR;</li> <li>actualizar un ADR existente;</li> <li>reemplazar una decisión previa;</li> <li>quedar como candidata pendiente;</li> <li>o mantenerse como documentación de implementación.</li> </ul> <p>La idea no es que el agente escriba más documentación por defecto. La idea es que, cuando<br> detecte una decisión durable, ayude a moverla desde memoria temporal hacia memoria<br> versionada del repositorio.</p> <p>También ayuda a detectar señales de deuda técnica oculta:</p> <ul> <li>fallbacks silenciosos;</li> <li>configuración inventada por defecto;</li> <li>mocks o no-ops en runtime productivo;</li> <li>decisiones temporales sin criterio de salida;</li> <li>duplicación de reglas de dominio entre frontend y backend.</li> </ul> <h2> Memoria de agente vs memoria de repo </h2> <p>La memoria del agente sigue siendo útil. Sirve para preferencias, patrones recurrentes,<br> comandos habituales y contexto operativo.</p> <p>Pero las decisiones arquitectónicas deberían estar donde el equipo pueda revisarlas:<br> en el repositorio.</p> <p>Una división práctica es:</p> <ul> <li>memoria del agente para preferencias y hábitos de trabajo;</li> <li>instrucciones del repo para reglas operativas del agente;</li> <li>ADRs para decisiones técnicas que condicionan arquitectura futura;</li> <li>documentación de implementación para detalles locales;</li> <li>candidatos pendientes para ideas relevantes que todavía no están validadas.</li> </ul> <p>Esa separación reduce ambigüedad. También permite que distintas herramientas lean el<br> mismo repositorio sin depender de la memoria privada de una sesión o de un proveedor.</p> <h2> Ejemplo de uso </h2> <p>Una pregunta útil para un agente sería:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Usa decision-memory para evaluar esta decisión: mover la fuente de verdad del workflow desde el backend hacia constantes del frontend. No edites archivos. Clasifica si requiere un nuevo ADR, actualizar un ADR existente, reemplazar una decisión previa o quedar como documentación de implementación. </code></pre> </div> <p>Una respuesta esperada sería:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Clasificación: requiere ADR o actualización de ADR existente. Razón: cambia la fuente de verdad, el ownership del dominio y el contrato entre backend y frontend. Futuros cambios necesitarán conocer esta decisión para no reconstruir estados paralelos ni romper la arquitectura. </code></pre> </div> <h2> Proyecto </h2> <p>El skill está publicado como open source:</p> <ul> <li>GitHub: <a href="https://github.com/ltorresu82/skills" rel="noopener noreferrer">https://github.com/ltorresu82/skills</a> </li> <li>skills.sh: <a href="https://www.skills.sh/ltorresu82/skills/decision-memory" rel="noopener noreferrer">https://www.skills.sh/ltorresu82/skills/decision-memory</a> </li> </ul> <p>Instalación:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>npx skills add ltorresu82/skills <span class="nt">--skill</span> decision-memory </code></pre> </div> <p>La tesis es simple: los agentes de código no necesitan solo más contexto. Necesitan mejor<br> memoria. Y las decisiones que gobiernan el futuro de un sistema deberían vivir cerca del<br> código, versionadas y visibles para humanos y agentes.</p> ai architecture opensource software