Trabajar con agentes en varios repositorios separados

Un repositorio de backend y uno de cliente van juntos, pero viven separados: un agente necesita para esto una estrategia distinta a la de un único monorepo.

Diferencia con el monorepo

El capítulo "Usar agentes de IA en monorepos grandes" trata sobre UN repositorio con muchos subproyectos bajo un mismo techo. Aquí se trata de lo contrario: varios repositorios independientes y versionados por separado —por ejemplo, un backend de API y un repositorio de frontend separado— que juntos forman un sistema, pero cada uno tiene su propio historial de Git, su propio CLAUDE.md y su propio pipeline de despliegue.

Contexto por repositorio

Cada repositorio conserva su propio CLAUDE.md con sus propias convenciones. Un agente que arranca en el repositorio de backend conoce automáticamente sus reglas; no carga por sí solo las reglas del repositorio de frontend, porque ambos repositorios técnicamente no saben nada el uno del otro.

Establecer acceso a un segundo repositorio

Claude Code puede incorporar una copia adicional de un repositorio, obtenida por separado (checked out), mediante un acceso a directorio adicional: la misma técnica que también da acceso a paquetes vecinos en un monorepo funciona igual para un segundo repositorio completamente separado en el disco.

Cambios coordinados y orden

Si cambia un contrato de API, normalmente el cambio de backend debe fusionarse y estar desplegable primero, antes de adaptar el cliente, o bien ambos lados deben mantenerse compatibles hacia atrás durante una fase de transición. Sin un orden y un versionado deliberados, corres el riesgo de tener suposiciones incompatibles entre el cliente y el servidor.

EJEMPLO

Tarea: añadir un nuevo campo 'currency' a la información de precios; el repositorio de backend 'tm2-api' y el repositorio de frontend 'tm2-web' están separados. Paso 1 (en el repositorio tm2-api): añadir el campo de forma aditiva al esquema de respuesta; el cliente antiguo sigue siendo compatible porque el campo es opcional. Desplegar. Paso 2 (acceso a tm2-web mediante --add-dir o una sesión separada): adaptar el cliente para que use el nuevo campo si está presente, y en caso contrario use el valor por defecto anterior. Paso 3: solo después de confirmar el despliegue de ambos lados, marcar el campo en el backend como obligatorio.

🛠️ EJERCICIO — PRUÉBALO TÚ

Simula un cambio coordinado a través de dos repositorios locales separados.

Crea localmente dos repositorios Git pequeños y separados, uno como 'API' y otro como 'Client', que compartan un 'contrato' mediante un archivo de texto sencillo (por ejemplo, un esquema JSON).
Modifica el contrato en el repositorio API de forma aditiva (nuevo campo opcional) y haz commit.
Da a un agente acceso a ambos directorios y haz que adapte el cliente para que use el nuevo campo si está presente.
Comprueba si el cliente sigue funcionando también sin el nuevo campo (contrato antiguo).

✅ AUTOEVALUACIÓN

☐ ¿Siguió funcionando el cliente con la versión antigua del contrato mientras ya existía la nueva versión?
☐ ¿Tuvo el agente que acceder explícitamente al segundo directorio de repositorio, o lo hizo automáticamente?

QUIZ RÁPIDO

¿Qué diferencia fundamentalmente el trabajo con varios repositorios separados de un monorepo con muchos subproyectos?