Scion: cuándo dejar de copiar el repositorio

Un trabajo de integración continua necesita saber qué carpetas cambió una propuesta. Para responder, prepara una máquina, descarga el repositorio, reconstruye una copia de trabajo, calcula una diferencia y lo descarta todo. La pregunta era pequeña. El equipaje no.

Mientras esto ocurre pocas veces, resulta cómodo utilizar el mismo procedimiento para cualquier tarea. Cuando se multiplica por miles de ejecuciones, la comodidad empieza a aparecer en la factura y en el tiempo de espera. La reacción inmediata suele ser acelerar la descarga. Antes conviene preguntar por qué ese trabajo necesitaba una copia del repositorio.

El caso de Scion permite discutir esa decisión con un ejemplo reciente, sin convertir una arquitectura excepcional en una receta para todos.

Qué problema declaró Anthropic

En su explicación de Scion, publicada el 13 de octubre de 2026 y ampliada el día 15, Anthropic declara haber pasado de unas 2.500 integraciones de cambios diarias en mayo a más de 30.000 en septiembre. Describe alrededor de 25 millones de checkouts diarios para CI y una copia de trabajo comprimida superior a 25 GB. Son magnitudes comunicadas por la compañía para su monorepositorio, no mediciones independientes ni cifras extrapolables a otro equipo.

Su respuesta fue construir un sistema propio de control de versiones con operaciones en el servidor, consultas por API y materialización parcial o bajo demanda. La compañía explica que sus consumidores son, en gran medida, agentes y trabajos conectados. Esa premisa permite intercambiar autonomía local por un cliente que necesita menos datos.

Lo interesante para un equipo de otra escala es separar el síntoma de la solución elegida. Un checkout lento puede esconder exceso de datos, almacenamiento deficiente, demasiada concurrencia o una dependencia innecesaria del sistema de archivos. Cada explicación conduce a una intervención distinta.

Una copia de trabajo es una forma de resolver preguntas

Conviene clasificar las operaciones de CI por los datos y la autonomía que necesitan, antes de cambiar el sistema de control de versiones. Un compilador puede requerir archivos y herramientas locales. Una comprobación de carpetas afectadas puede necesitar únicamente una diferencia. Una investigación sobre cuándo apareció un fallo necesita recorrer historia. Llamar «checkout» a la preparación de las tres oculta requisitos diferentes.

Imaginemos un repositorio con varios productos y documentación común. Un trabajo solo decide si debe ejecutarse la batería de pruebas del producto A. Si obtiene por una consulta la lista de rutas modificadas, puede resolver esa decisión sin materializar el producto B. Otro trabajo compila A y sí necesita sus archivos y dependencias. Un tercero busca el cambio que introdujo una regresión y necesita explorar versiones anteriores.

La optimización del primero no se puede imponer sin más al tercero. Ahorrar historia a una tarea que después debe reconstruirla puede desplazar el coste hacia múltiples accesos pequeños, más sensibles a la latencia o a la disponibilidad remota. Reducir bytes transferidos no garantiza reducir tiempo total.

Git ya ofrece alternativas anteriores a una sustitución. Su documentación de clonado parcial describe cómo omitir inicialmente determinados objetos y obtenerlos cuando hagan falta mediante remotos que se comprometen a proporcionarlos. Recortar profundidad de historia, seleccionar archivos de la copia de trabajo y filtrar objetos son decisiones distintas; no conviene agruparlas bajo «clonar menos».

Medir el trabajo evitado, no solo el tiempo de descarga

Para valorar una intervención, separaría cuatro costes: descubrir qué datos necesita la tarea, transferirlos, prepararlos localmente y ejecutar el trabajo útil. Después observaría qué vuelve a pedirse por haberlo omitido al principio. Esa última parte evita celebrar una descarga inicial rápida que obliga a reconstruir el repositorio durante la ejecución.

Tomemos un cálculo ilustrativo, no una medición: 8.000 trabajos diarios descargan 300 MB cada uno. Son 2,4 TB decimales de transferencia lógica diaria. Si cada tarea pudiera resolver su objetivo con 20 MB, el volumen correspondiente sería 160 GB. La diferencia de 2,24 TB identifica un margen teórico; no acredita ahorro de red facturado, porque pueden intervenir cachés, compresión, tráfico interno y costes de consulta.

Tampoco debemos sumar el tiempo ahorrado en tareas paralelas y presentarlo como reducción del plazo de entrega. Una mejora puede liberar recursos sin cambiar el camino crítico. Otra puede adelantar la primera señal de fallo y ahorrar trabajo posterior. Ambas pueden ser valiosas, pero resuelven problemas distintos.

El criterio de aceptación debería incluir ejecuciones con caché fría, accesos a historia y variaciones de concurrencia. Esta cautela tiene relación con cómo la caché altera las conclusiones sobre rendimiento: repetir la misma operación en condiciones favorables demuestra menos de lo que a veces queremos concluir.

Un mapa de materialización para elegir la intervención

Propongo este mapa como herramienta de diseño. Su finalidad es decidir la intervención más pequeña que elimina trabajo innecesario sin romper la operación.

• Solo necesita una respuesta sobre metadatos. Valorar una consulta remota acotada. Conservar revisión exacta, semántica del resultado y comportamiento ante indisponibilidad. Evitar que «la rama actual» cambie entre la consulta y la ejecución dependiente.
• Necesita archivos de un subconjunto conocido. Valorar materialización selectiva y reutilización local de objetos. Comprobar dependencias indirectas, archivos generados y herramientas que recorren más rutas de las previstas.
• Necesita explorar historia de forma imprevisible. Comparar una copia suficientemente completa con recuperaciones bajo demanda. La mejor opción depende de la conectividad y del patrón real de consultas.
• Necesita operar durante una interrupción del servicio. Preservar los datos y capacidades locales que sostienen esa autonomía. Una caché parcial solo permite continuar las operaciones cuyo contenido y lógica siguen disponibles.

Para cada familia registraría bytes obtenidos, bytes utilizados cuando sea medible, tiempo hasta el primer resultado útil, consultas adicionales y operaciones que dejan de funcionar sin red. No necesitamos una cifra mágica de tamaño de repositorio. Necesitamos saber qué comportamiento estamos comprando con cada copia.

Centralizar también cambia quién puede seguir trabajando

Trasladar operaciones al servidor reduce la carga de algunos clientes, pero convierte la disponibilidad y la capacidad de ese servicio en parte de su funcionamiento. La decisión debe incluir las ráfagas después de una interrupción: clientes que recuperan el trabajo pendiente pueden concentrar consultas justo cuando el servicio vuelve a estar disponible.

También cambia el coste de salida. Scripts, herramientas de revisión y procesos de diagnóstico pueden empezar a depender de una API particular. Antes de invertir en otra plataforma, interesa identificar cómo se conserva la historia necesaria, qué herramientas pierden compatibilidad y qué capacidad tenemos para mantener la nueva infraestructura. Un sistema propio necesita una justificación más amplia que una comparación de velocidades.

En muchos equipos bastará con dejar de hacer checkouts para preguntas que no los necesitan, ajustar la materialización y medir de nuevo. En otros, la escala y el patrón de trabajo justificarán un rediseño profundo. El caso de Scion ayuda a hacer visible esa frontera; no demuestra que Git haya dejado de servir para nuestro repositorio.

El trabajo que preguntaba por las carpetas modificadas sigue necesitando una respuesta correcta y ligada a una revisión concreta. Quizá lo que podemos retirar es el viaje que le obligábamos a hacer para obtenerla.