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.