Anthropic creó Scion para reemplazar Git

A las seis de la tarde, la mejora que pidió ventas está terminada, pero todavía no puede usarse. Falta revisar el cambio y comprobar que sigue funcionando el resto del sistema. Esta es una escena hipotética, aunque el pendiente resulta familiar para cualquiera que haya esperado una actualización de su software.

Ahora aumenta de golpe la cantidad de trabajo que llega a esa revisión. Anthropic reportó que pasó de unos 2,500 cambios integrados al día en mayo de 2026 a más de 30,000 en septiembre. Para soportar esa carga, creó Scion y migró su repositorio principal desde Git en cinco meses, según su publicación del 13 de octubre.

Mi lectura del anuncio es esta: una herramienta que acelera una parte del trabajo puede dejar al descubierto la siguiente espera. Antes de pedirle a tu proveedor que copie a Anthropic, conviene entender qué problema resolvió.

Sí, Scion ocupa el lugar de Git

Git es una herramienta de control de versiones. Piensa en un historial ordenado de un documento compartido: permite saber qué cambió y recuperar una versión anterior. La documentación de Git explica esas funciones y su diseño distribuido, donde las copias pueden incluir el historial completo.

Scion pertenece a esa misma categoría. La diferencia principal es que concentra operaciones en servidores y entrega al cliente los datos que necesita. Está pensado para agentes conectados, con una carga de trabajo enorme.

Anthropic aclara que Scion no es un reemplazo apropiado de Git para uso general. Esa advertencia cambia la conversación: tenemos un caso de infraestructura especializada, no una instrucción para que todas las empresas cambien de herramienta. Los datos del caso son reportados por la propia compañía en su artículo de ingeniería.

El problema de negocio está en la espera

Para un dueño de pyme, guardar el historial del software puede sonar lejano. Hasta que una actualización cambia mal un cálculo de descuentos y alguien necesita averiguar qué pasó.

Ahí importa que el proveedor pueda identificar el cambio y recuperar una versión que funcionaba. También importa cuánto tarda en revisar una mejora antes de ponerla frente a tus clientes. Son preguntas operativas que puedes hacer aunque nunca hayas programado.

Mi interpretación del caso de Anthropic es que la velocidad de producción exige revisar la capacidad del proceso completo. Si una parte genera trabajo más rápido de lo que la siguiente puede procesarlo, aparece una fila.

Esa fila puede ser visible, como un tablero lleno de tareas pendientes. También puede esconderse en mensajes: “ya quedó, falta que lo autoricen”. Mientras tanto, el área que pidió el cambio sigue usando una solución provisional.

Una comparación con un taller

Supongamos que un taller compra una máquina que corta piezas mucho más rápido. El encargado de inspección sigue siendo la misma persona, con el mismo horario.

Al terminar el día hay más piezas cortadas. Los pedidos entregados podrían seguir siendo los mismos porque esperan inspección. Si el gerente evalúa únicamente la máquina, verá una mejora. Si revisa el pedido completo, encontrará la espera.

Con desarrollo de software, yo usaría esa misma mirada. El trabajo producido tiene valor cuando llega a una entrega útil y confiable. La cantidad de cambios, por sí sola, deja esa pregunta abierta.

Qué pedirle a tu proveedor

En lugar de empezar con “¿ya usan la nueva herramienta?”, pediría evidencia sobre una mejora reciente. Puede ser algo concreto: agregar una condición de descuento o corregir un reporte que tu equipo necesita cada semana.

La conversación puede apoyarse en esta tabla:

No necesitas exigir una presentación complicada. Una explicación clara, con fechas y un ejemplo verificable, permite tener una conversación mucho más útil que una lista de herramientas.

Si el proveedor desconoce dónde se fue el tiempo, ese es un buen primer pendiente. Cambiar de tecnología mientras la espera sigue sin identificarse vuelve difícil comprobar si la inversión sirvió.

Un ejercicio pequeño antes de gastar

Yo empezaría registrando unas cuantas mejoras recientes. Para cada una, anotaría cuándo se solicitó y cuándo estuvo disponible para el usuario. Después separaría el tiempo de trabajo del tiempo detenido.

Es una propuesta de diagnóstico, no un resultado obtenido en un proyecto mío. Sirve para formular una hipótesis: quizá la demora está en conseguir una autorización; quizá falta información desde el principio.

Si el pendiente es una autorización que solo puede dar una persona, vale la pena acordar criterios y horarios de revisión. Si se devuelve trabajo porque la solicitud era ambigua, conviene precisar qué resultado espera el usuario antes de comenzar.

La solución dependerá de lo que encuentres. El objetivo del registro es evitar que la conversación termine demasiado pronto en la compra de una herramienta.

Mide también lo que vuelve

Una entrega rápida puede parecer exitosa hasta que el equipo empieza a reportar errores. Por eso acompañaría el tiempo de entrega con un registro de correcciones posteriores.

No hace falta convertirlo en un sistema complicado. Basta con distinguir una solicitud nueva de un arreglo a algo que acababa de publicarse. Así puedes ver si estás avanzando o si parte de la capacidad se consume reparando trabajo reciente.

Lo que me llevo

El anuncio me interesa por la relación entre capacidad y diseño. Una empresa puede llegar a una escala en la que una herramienta habitual requiere demasiados ajustes. En ese punto, construir una solución propia merece una evaluación seria.

Para una pyme, yo exigiría una explicación del problema y del costo de mantener esa solución. Quien propone construir una herramienta también debe explicar quién la atenderá cuando falle y cómo se comprobará que mejora el servicio.

La medida útil para el negocio es cuánto tarda una mejora en funcionar de manera confiable para quien la necesita.

Antes de cambiar la herramienta, ubica la fila

Scion ofrece un caso concreto para hablar de cómo cambia el desarrollo con IA. Mi recomendación para una pyme es empezar con una entrega reciente y reconstruir su recorrido.

Si tu equipo ahorra tiempo al producir trabajo, revisa dónde termina ese ahorro. Puede aparecer como una entrega más rápida o quedarse acumulado en pendientes. Esa diferencia te ayuda a decidir qué conviene mejorar primero.

Referencias

• Redesigning source control at Anthropic
• Git: About Version Control