Los agentes te empujan al monorepo, no al monolito

Ahora que los agentes de IA escriben buena parte del código, tener cada servicio en su repositorio sale más caro que antes. Anthropic acaba de cambiar git por un sistema propio para poder seguir con un solo repositorio. Juntar el código no te obliga a juntar los servicios, pero ojo: un commit atómico no es un despliegue atómico, y ahí se acaba la ventaja.

Tres pull requests para un campo

Le pides a tu agente que añada la fecha de entrega a la API de pedidos. La API está en el repositorio orders-api, los tipos compartidos en contracts y el front en web. El agente hace su parte en el repositorio que tiene abierto y ahí se queda: los otros dos cambios te tocan a ti, y en orden, porque antes hay que publicar una versión nueva de contracts.

En un equipo, eso se lo reparten los responsables de cada repositorio, con alguna reunión de por medio. El agente, en cambio, solo ve lo que tiene en su copia de trabajo. Puedes darle los tres repositorios, claro, pero entonces el monorepo lo estás montando tú a mano. Con todo en el mismo sitio, el cambio entero es una rama, una revisión y una pasada de la CI, y el agente ve quién usa la API antes de tocarla.

De ahí viene la idea de que la IA ha vuelto a poner de moda el monorepo. No es nueva: en febrero, Nx, que vende una herramienta para monorepos, anunció un webinar con el título «Why Monorepos are King in the Age of AI». Era la opinión de quien vende la herramienta, sin datos detrás. Los datos han llegado esta semana.

Lo que ha hecho Anthropic

El 13 de octubre, Anthropic contó en su blog de ingeniería que había sacado su monorepo de git.

En mayo de 2026 hacían una media de unos 2500 merges al día; en septiembre, más de 30 000. Doce veces más en cuatro meses. La historia de la rama principal ocupa casi 100 GB, la copia de trabajo comprimida pasa de 25 GB y la CI hace unos 25 millones de checkouts al día. El modelo de git da por hecho que cada uno trabaja sin conexión y con una copia completa del repositorio; en Anthropic, casi todos los clientes son agentes y jobs que están siempre conectados.

Scion, el sistema que lo sustituye, hace justo lo contrario: el trabajo pesado se queda en el servidor (consultar la historia y el blame, crear los commits, hacer los merges) y cada cliente se baja solo los directorios que pide. Entre siete personas construyeron Scion y una herramienta de revisión de código, Antique, y migraron en cinco meses. Según Anthropic, consume 200 veces menos CPU y memoria que la infraestructura de réplicas de git que tenían antes, y la CI hace los checkouts en segundos en vez de minutos. Ese volumen de merges se lo atribuyen a Claude, y con Claude construyeron también Scion. No lo van a liberar, según The Register; Anthropic dice que no sirve como sustituto general de git y que prefiere contar las ideas para que otros las lleven a git.

Monorepo no es monolito

Ante ese volumen, Anthropic cambió de herramienta y se quedó con un solo repositorio. Su artículo no dice nada de microservicios, y no conviene leerlo como un argumento a favor del monolito. Una cosa es dónde guardas el código y qué cambios revisas juntos, y otra, qué despliegas y qué puede caerse por separado. Google lleva años con un único repositorio para decenas de miles de desarrolladores (lo contó en Communications of the ACM en 2016) y también tuvo que construirse su propio sistema, Piper, para sostenerlo.

Los microservicios resuelven dos tipos de problemas. Unos son de producción: piezas que escalan de forma distinta, que tienen que poder fallar sin arrastrar al resto o que necesitan otro runtime. Otros son de organización: equipos que quieren desplegar sin esperar a nadie. Yo creo que lo de un repositorio por servicio llegó sobre todo por lo segundo: cada equipo con su repositorio, su pipeline y su ritmo.

Si el equipo es pequeño, o eres tú solo con varios agentes, los motivos de organización pesan bastante menos, pero los de producción siguen ahí. Para mí, lo que cambia es que el repositorio ya no tiene por qué copiar el organigrama. Los servicios se siguen separando donde lo pide producción, como siempre.

Un commit atómico no es un despliegue atómico

Aquí está la pega. En un monorepo, el agente cambia la API y el código que la llama en el mismo commit, la CI lo prueba todo junto y sale en verde. Pero en producción no llega todo a la vez: durante un rollout conviven pods con la versión vieja y con la nueva, y hay clientes que no controlas, como una app móvil o la integración de otra empresa, que se actualizan cuando les viene bien.

Así que de la compatibilidad hacia atrás te sigues encargando tú. Es el patrón que se conoce como parallel change o expand and contract: primero aceptas lo nuevo, luego lo usas, y lo viejo lo quitas cuando ya nadie lo envía. Un agente que ve el repositorio como si fuera un único programa no tiene por qué saberlo. Anthropic cuenta algo parecido de su migración, aunque en otro terreno. Los agentes a veces se saltan restricciones básicas del sistema por seguir un patrón que nunca se tendría que haber permitido, y muchas veces lo que hacían los ingenieros era decirle que no a Claude.

Cuándo no compensa

Un solo repositorio tiene costes que el primer día no se ven:

• La CI tiene que saber qué ha cambiado. Si no filtras por rutas, un cambio en la documentación lanza los tests de todos los servicios, y cuantos más merges hacen los agentes, más se nota en la factura y en la cola.
• Si del repositorio salen varias cosas con versiones distintas, la herramienta que calcula las versiones tiene que saber qué commit afecta a cuál.
• Tu repositorio estará muy lejos de los casi 100 GB de historia de Anthropic. Pero lo que multiplican los agentes es el número de merges, y eso lo vas a notar en la cola de merges y en lo que tarda la CI mucho antes que en git.
• Si hay código que no todo el mundo debe ver, como el de un cliente, ten en cuenta que los permisos se suelen dar por repositorio. Anthropic se ha montado un control de acceso propio, que permite dar permisos por directorio, para proteger el código más sensible sin renunciar al monorepo. Si no tienes gente para construir algo así, ese código, mejor en otro repositorio.

Y tampoco compensa cuando los equipos no comparten código ni calendario de versiones, o cuando cada parte usa herramientas tan distintas que una CI común acabaría siendo varias CI cogidas con pinzas.

Pruébalo

Si ya trabajas en un monorepo, o estás pensando en juntar repositorios, apunta en las instrucciones de tu agente (AGENTS.md, CLAUDE.md o el fichero que lea tu herramienta) qué directorios se despliegan por separado, dónde corre cada uno (servidores, móviles, navegadores) y qué compatibilidad tienen que mantener entre sí. Son diez minutos, y el agente lo tendrá delante la próxima vez que toque una API. Tampoco es una garantía, porque el agente puede saltársela, así que revisar sigue siendo cosa tuya.

Los detalles de Scion están en el artículo de Anthropic, «Redesigning source control at Anthropic». Picaporte Labs es una sola persona, en España; si algo de esto no cuadra con lo que ves en tu equipo, escríbeme.