# Trabajar con asistentes de IA sin perder el hilo: reglas y memoria en el repositorio > Un método para desarrollar con asistentes de IA de forma trazable: reglas únicas, memoria versionada, prompts de sesión, relevos y un guardián antes de cada commit. - URL: https://www.enter20.com/blog/trabajar-con-asistentes-de-ia-sin-perder-el-hilo-reglas-memoria-repositorio/ - English: https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/ - Actualizado: 23 de octubre de 2026 - enter 2.0 — IA práctica, datos gobernados, dashboards, automatización y sistemas de información para organizaciones que necesitan decidir mejor. - Publicado: 2026-10-23 - Actualizado: 2026-10-23 - Tema: Método de trabajo con IA - Etiquetas: IA, asistentes de código, método, documentación, trazabilidad - Para: Responsables IT, equipos técnicos pequeños y quienes contratan desarrollo asistido por IA - Equipo de enter 2.0 ## Respuesta breve Un asistente de IA que programa es tan fiable como el contexto que recibe. Si las reglas y el estado del proyecto viven en el repositorio, versionados junto al código, cualquier asistente o persona puede empezar donde lo dejó el anterior, y cada cambio deja rastro. El método cabe en pocos ficheros: un documento de reglas vinculantes, una carpeta de memoria ligera, tres prompts de sesión (empezar, cerrar, relevar) y un guardián que se ejecuta antes de cada commit. ## Puntos clave - Si las reglas y el estado del proyecto viven en el repositorio, versionados junto al código, cualquier asistente o persona puede continuar donde lo dejó el anterior. - Conviene un único documento de reglas vinculantes y que los ficheros de instrucciones de cada herramienta solo apunten a él, para que no haya dos verdades. - La memoria compartida debe ser ligera a propósito y tener límites de tamaño, porque una memoria que crece sin control deja de leerse. - Una nota de relevo con la tarea, lo hecho, lo que está a medias, el siguiente paso exacto y lo no verificado permite retomar el trabajo sin reconstruir nada. - Un guardián antes de cada commit comprueba que lo privado sigue ignorado y que no hay nada con forma de secreto; si falla, no hay commit. ## Una sola fuente de reglas Cada herramienta tiene su fichero de instrucciones, y es tentador mantener varias versiones. Es mejor que exista un único documento de reglas y que los ficheros de cada herramienta solo apunten a él. Así no hay dos verdades sobre lo que se puede y no se puede hacer. Las reglas útiles son concretas: dónde se trabaja y dónde no, qué datos nunca se abren, qué acciones exigen aprobación de una persona (desplegar, cambiar un secreto, tocar el DNS, escribir a alguien), cómo se informa del estado y qué comprobaciones preceden a un commit. ## Memoria ligera a propósito La memoria compartida necesita pocos ficheros con funciones claras: el objetivo actual y el estado, el sistema tal como es hoy, los procedimientos, lo pendiente, las decisiones duraderas con fecha y un registro de lo hecho en cada sesión. Lo superado se archiva para que cada sesión arranque leyendo poco. Poner límites de tamaño a esos ficheros, y que el guardián falle si se superan, obliga a resumir y a archivar. Una memoria que crece sin control deja de leerse, y una memoria que no se lee no existe. ## Empezar, cerrar y relevar Al empezar, el asistente lee las reglas y el estado, informa de la situación del repositorio y no cambia nada hasta que una persona confirma. Al cerrar, actualiza el registro, lo pendiente y las decisiones, pasa las comprobaciones y prepara el commit. Las dos rutinas se escriben una vez y se comparten entre herramientas. El relevo es la pieza que suele faltar: una nota fechada con la tarea, lo hecho, lo que está a medias (con los ficheros), el siguiente paso exacto y lo que no se verificó. Con esa nota y un commit marcado como trabajo en curso, otro asistente, de otro fabricante o la misma persona al día siguiente, retoma sin reconstruir nada. ## Un guardián antes de cada commit y palabras de estado honestas Un script que comprueba que lo privado sigue ignorado y que el cambio preparado no contiene nada con forma de secreto cuesta poco y evita el error más caro. Si falla, no hay commit, y solo dice el nombre del problema, nunca el valor. Por último, el vocabulario: «preparado» significa que funciona en local con las pruebas pasadas; «desplegado», que está publicado y comprobado con peticiones reales; «validado», que la persona responsable lo ha recorrido en su equipo. Usar tres palabras distintas evita que un prototipo se cuente como una entrega. ## Preguntas frecuentes ### ¿Cómo evito que se pierda el contexto de un proyecto al trabajar con asistentes de IA que programan? Guardando las reglas y el estado del proyecto en el repositorio, versionados junto al código, en lugar de en el chat de una herramienta, que se pierde al cerrarla. Así cualquier asistente o persona puede empezar donde lo dejó el anterior, y cada cambio deja rastro. El método cabe en pocos ficheros: un documento de reglas vinculantes, una carpeta de memoria ligera, tres prompts de sesión (empezar, cerrar y relevar) y un guardián que se ejecuta antes de cada commit. ### ¿Qué reglas conviene dar a un asistente de IA que programa en nuestro repositorio? Reglas concretas, reunidas en un único documento al que apunten los ficheros de instrucciones de cada herramienta. Deben decir dónde se trabaja y dónde no, qué datos nunca se abren, qué acciones exigen aprobación de una persona (desplegar, cambiar un secreto, tocar el DNS o escribir a alguien), cómo se informa del estado y qué comprobaciones preceden a un commit. Mantener una sola fuente evita que haya dos verdades sobre lo que se puede y no se puede hacer. ### ¿Cómo puede otro asistente de IA u otra persona retomar una tarea que quedó a medias? Con una nota de relevo fechada que recoja la tarea, lo hecho, lo que está a medias (con los ficheros), el siguiente paso exacto y lo que no se verificó. Junto con un commit marcado como trabajo en curso, permite que otro asistente, aunque sea de otro fabricante, o la misma persona al día siguiente retome el trabajo sin reconstruir nada. Es la pieza que suele faltar. ### ¿Qué diferencia hay entre un trabajo preparado, desplegado y validado? «Preparado» significa que funciona en local con las pruebas pasadas; «desplegado», que está publicado y comprobado con peticiones reales; «validado», que la persona responsable lo ha recorrido en su equipo. Usar tres palabras distintas evita que un prototipo se cuente como una entrega. ## Servicios y casos conectados - [Diagnóstico de IA y datos](https://www.enter20.com/servicios/diagnostico-ia-datos/) - [Herramientas operativas a medida](https://www.enter20.com/servicios/herramientas-operativas/) - [Gobernanza, continuidad y operaciones IT](https://www.enter20.com/servicios/gobernanza-continuidad-it/) - [Plataforma operativa modular para una fundación](https://www.enter20.com/trabajos/plataforma-operativa-fundacion/) - [Automatización documental con Python y revisión humana](https://www.enter20.com/trabajos/automatizacion-documental-python/)