El 17 de agosto, GitHub experimentó una amplia interrupción del servicio, y el mismo día, Cursor abrió el Origin early beta a usuarios pagos. Los repositorios de código están siendo integrados con Agentes que operan de forma continua; la infraestructura de colaboración actual está diseñada para adaptarse al ritmo de trabajo humano. Estudios muestran que el 40,2% de los repositorios presentan PR de Agentes superpuestos, con una proporción de conflictos de merge del 41,7%. Cursor Origin está diseñado para escrituras frecuentes de Agentes, soportando 22,6 commits/s por repositorio, e integrando repositorio, PR, checks y revisiones. Origin se posiciona como una capa de control sobre Git, rehaciendo los flujos de colaboración frecuente de Agentes. xAI, X, SpaceX y Cursor, bajo el liderazgo de Musk, han formado una cadena completa de producción de IA: Colossus proporciona potencia de cómputo, Grok ofrece modelos, Cursor ejecuta código y Origin gestiona el estado del proyecto. GitHub se expande desde la colaboración humana hacia Agentes, mientras que Cursor rediseña forge según la carga de trabajo de los Agentes; ambas vías compiten cada vez más intensamente.Autor y fuente del artículo: Leifengwang
El propietario del repositorio de código está pasando de ser una persona a un Agente.
El 17 de agosto, GitHub experimentó una interrupción generalizada del servicio. Las cadenas principales, como Web, API, Actions, Pull Requests, Operaciones Git y Webhooks, se vieron afectadas progresivamente, con tasas de error en las solicitudes Web y API que alcanzaron cerca del 20% en algunos períodos.
En el mismo día, Cursor comenzó a abrir gradualmente el Origin early beta para todos los planes de pago. Los repositorios, PR, checks, revisiones, fusiones y automatizaciones comenzaron a integrarse en un mismo sistema, y la posición de Cursor fue clara: la alojamiento de código debe comenzar a diseñarse para “agent scale”.
Lo curioso es que ambos eventos coincidieron en el mismo momento, amplificando exactamente un cambio: el repositorio de código está integrando cada vez más Agentes en funcionamiento continuo, mientras que la infraestructura existente de colaboración de software se ha adaptado durante mucho tiempo al ritmo de trabajo humano.
Una persona puede escribir horas de código y generar solo unos pocos commits; un agente puede modificar, hacer push, activar verificaciones y continuar con el siguiente ciclo en cuestión de minutos. Que los commits sean más rápidos es solo la superficie; el cambio más profundo es que la escala temporal de todo el sistema de producción de software está siendo comprimida.
Muchos de los nuevos problemas que enfrenta GitHub, y muchos de los problemas que Origin desea resolver, podrían comenzar aquí.
01 GitHub no envejeció de repente
Cuando nació GitHub, la unidad básica de colaboración en software era estable: la persona.
Un ingeniero escribe código durante varias horas y realiza un commit; el desarrollo de una función lleva días y se convierte en un PR; la revisión puede aparecer media hora después o bien al día siguiente; que CI tarde unos minutos en ejecutarse es aceptable, y manejar un conflicto de fusión más tarde no hace que todo el sistema pierda sentido.
Alrededor de este ritmo, GitHub estableció los sistemas de Pull Request, Issue, Review, Actions, Webhook y permisos. Incluso en proyectos como el Linux Kernel, que mantienen un alto volumen de commits durante mucho tiempo, este ritmo aún refleja claramente una escala de tiempo humana.
LWN informa que, durante todo el ciclo de desarrollo de Linux 7.0, se realizaron 14.251 commits no de fusión, provenientes de 2.362 desarrolladores. Estas confirmaciones ocurrieron dentro de un ciclo de desarrollo que duró varias semanas, con discusiones por correo, revisiones de mantenedores, integración de subsistemas y el ciclo de lanzamiento.
Cursor mostró otro tipo de carga en la demostración de lanzamiento de Origin en junio: 22.6 confirmaciones/s en un solo repositorio.
Este número pertenece a datos de demostración en vivo y no es un benchmark de producción verificado por reproducción independiente; no demuestra que Origin pueda mantener un rendimiento equivalente a largo plazo en operaciones reales. Sin embargo, es suficiente para ilustrar el tipo de carga de trabajo que Origin está diseñado para: múltiples agentes que escriben continuamente en el mismo estado de código.
Los desarrolladores humanos tienen naturalmente límites de flujo. Pensar, escribir código, asistir a reuniones y descansar generan mucho tiempo en blanco entre entregas, por lo que un forge diseñado alrededor de personas puede transferir gran parte de la carga del sistema al tiempo para que lo absorba.
El agente no tiene esta restricción.
Docenas de agentes pueden bifurcarse simultáneamente desde el mismo SHA base, modificar archivos relacionados en tiempos cercanos, y luego hacer push, abrir PR, invocar verificaciones, leer revisiones, modificar código y hacer push nuevamente. Un solo commit puede seguir activando actualizaciones de índice, verificaciones de permisos, Webhooks, CI, escaneo de código, actualización del estado de revisión y cálculo de mergeabilidad.
Por lo tanto, lo que debe soportar el cambio no es el modelo de objetos de Git en sí, sino más bien el plano de control de forge sobre Git: API, autenticación, tareas en segundo plano, programación de CI, Webhooks, protección de rama, estado de revisión, cola de fusiones y la carga en cascada formada entre estos componentes.
Un estudio publicado en julio sobre Agent PR en GitHub ha observado este patrón concurrente. El estudio analizó 33.596 Agent PR en 2.807 repositorios, y el 40,2% de los repositorios presentaron Agent PR con superposición temporal.
En las modificaciones concurrentes reproducidas por muestreo, el porcentaje de conflictos de fusión de texto entre PR de diferentes Agentes alcanzó el 41,7%, mientras que entre PR concurrentes generados por el mismo Agente fue del 19,8%.
La colaboración entre múltiples agentes genera nuevos problemas de control de concurrencia. El fallo de GitHub no demuestra que el tráfico de agentes haya superado la infraestructura existente, pero ofrece precisamente una ventana de observación: cuando la producción de software pasa de eventos humanos de baja frecuencia a eventos machine de alta frecuencia, la planificación de capacidad, el diseño de colas, la propagación de estado y los modelos de consistencia enfrentan un tipo diferente de carga de trabajo.
El diseño de Origin también se desarrolla desde aquí.
02 Origin reescribir el costo de colaboración
Si Origin simplemente agrega una entrada para alojar un repositorio Git, le resultará difícil desafiar las relaciones con desarrolladores, el ecosistema de código abierto, el sistema de permisos empresariales y la cadena de herramientas ya establecidos por GitHub.
Su oportunidad proviene de que el agente cambió los costos de colaboración. El stacked PR es un ejemplo típico.
Los desarrolladores humanos tienden a organizar una función en un PR relativamente completo. Cada vez que se divide en un PR adicional, se incrementa el contexto, se añade una revisión y se generan dependencias de rama. Si un cambio se divide en decenas de PR, las personas fácilmente dedican gran parte de su esfuerzo a mantener estas relaciones.
La estructura de costos del agente es diferente. Cuando se realiza una modificación que abarca decenas de archivos, cualquier fallo en un paso puede hacer que el agente necesite volver a comprender un contexto amplio. Al dividirlo en conjuntos de cambios más pequeños, las modificaciones en el esquema, el servicio, la interfaz de usuario, etc., pueden establecer dependencias claras, verificándose cada nodo por separado y limitando el tratamiento de fallos solo a las partes relacionadas.
Un pequeño PR puede convertirse así en un punto de control del agente, permitiendo que la tarea tenga capacidad de validación local, reintento local y seguimiento de dependencias.
La adquisición de Graphite por Cursor también puede entenderse aquí. La versión temprana beta actual de Origin aún no incorpora completamente el flujo de trabajo apilado de Graphite, pero las pull requests apiladas y la cola de fusiones consciente de pilas, en las que Graphite ha invertido a largo plazo, coinciden exactamente con los cuellos de botella posteriores que surgen tras el aumento de la velocidad de generación de código por parte del Agente.
Después de aumentar la cantidad de PR, la carga de trabajo de la cola de fusión también aumentará. El Agente A y el Agente B pueden trabajar simultáneamente desde el mismo SHA base, y ambos pasarán las pruebas por separado.
Después de que A ingrese a main, los resultados de la prueba de B solo demuestran que el código es válido en el estado anterior, pero no garantizan que siga siendo seguro tras ingresar al nuevo main. Por lo tanto, la cola debe reconstruir los estados candidatos según main en constante cambio, volver a ejecutar las verificaciones y gestionar las dependencias entre PR.
Los conflictos también pueden evolucionar gradualmente desde interrupciones manuales hasta estados de falla recuperables en la tubería. Cursor ya ofrece la capacidad /babysit, que maneja continuamente comentarios de PR, checks fallidos y conflictos. Después de que una fusión candidata presente problemas, el contexto relevante puede ser reasignado al Agente para corregirlo y volver a validar en un entorno aislado.
La revisión también se estructurará automáticamente. La colaboración humana depende en gran medida del lenguaje natural y la experiencia del equipo, mientras que los Agentes que funcionan durante largos períodos necesitan leer claramente qué check falló, qué threads aún no se resolvieron, qué política no se cumplió y cuál es el SHA actual del head.
Origin ya ha expuesto a través de API objetos como repository, commit, checks, PR, y distingue entre revisión formal y discusión normal.
Estos estados estructurados luego pueden consumirse directamente por Automations. Los eventos push, PR opened o PR pushed activan el agente en la nube, y los resultados se escriben de vuelta en los checks y la PR; en caso de fallo, se ingresa al proceso de manejo. MCP, hooks y Agent API permiten que herramientas externas se integren en la misma cadena de eventos.
“Desconectar de GitHub” resuelve la ruta de migración. El equipo puede primero hacer un mirror del repositorio de GitHub, manteniendo GitHub como source of truth, mientras se migra el flujo de trabajo del Agente a Origin; una vez que funcione de forma estable, se puede cortar la sincronización y Origin gestionará el repositorio de forma independiente.
Esto permite que Cursor primero asuma Agent, PR, review, checks y Automation, y luego vaya transfiriendo gradualmente más estados de ingeniería a su propio sistema.
La lógica del producto de Origin es por lo tanto clara: Git continúa encargándose del control de versiones, y lo que Origin quiere reinventar es la capa de control que gira en torno a la colaboración de agentes de alta frecuencia sobre Git.
03 Old Ma está consolidando una cadena de producción de IA
Durante el último año y medio, una serie de acciones entre xAI, X, SpaceX y Cursor han ido formando una relación más completa de cadena de suministro.
xAI adquiere X, luego se integra al sistema de SpaceX; Cursor obtiene recursos de cómputo de Colossus y también se integra al sistema de SpaceX. Mientras tanto, se lanza Grok 4.6 y Origin comienza a abrirse.
Este enfoque es similar a la estrategia de integración vertical que Musk aplicó anteriormente en Tesla: cuando los eslabones externos comienzan a generar fricción en la iteración, se extiende hacia arriba y hacia abajo en la cadena, incorporando las interfaces clave dentro del mismo sistema.
El agente actualmente enfrenta precisamente este problema. El modelo puede realizar el razonamiento, pero una tarea de software también requiere acceder al repositorio, modificar archivos, ejecutar pruebas, procesar CI, recibir revisiones, resolver conflictos y recuperar la ejecución tras un fallo.
Si estos pasos están dispersos en múltiples sistemas, cada tarea requiere sincronizar repetidamente permisos, contexto y estado, y el costo de las interfaces se acumulará continuamente en el ciclo de Agent en ejecución.
Colossus, Grok, Cursor y Origin pueden corresponder a diferentes niveles en esta cadena: Colossus proporciona potencia de cómputo, Grok proporciona capacidad de modelo, Cursor proporciona un agente de código y un entorno de ejecución, y Origin almacena el estado del repositorio, PR, checks y revisiones.
El código genera una cadena continua: el modelo toma una decisión, Cursor convierte esa decisión en modificaciones reales, y Origin guarda el estado del proyecto y gestiona la colaboración posterior.
Esto también cambia la escala para evaluar a Grok 4.6. Las capacidades del modelo siguen siendo importantes, pero la salida del sistema Agent también depende del entorno de ejecución y la infraestructura de ingeniería. Un código, aunque tenga una buena calidad de generación, no permitirá que las capacidades del modelo se amplifiquen continuamente si aún requiere copia, ejecución, revisión y reenvío manuales.
Una vez que el modelo haya alcanzado un nivel utilizable, la velocidad con la que el código puede ingresar a los procesos de ejecución, validación y fusión afectará cada vez más la producción del sistema completo.
La posición de X en esta cadena aún es bastante ambigua. Cuenta con contenido en tiempo real, relaciones de usuarios, identidad y una red de distribución, y en el futuro podría convertirse en una fuente de tareas y un punto de entrada para la distribución; en esta etapa, Grok Bot se asemeja más a la capa de ejecución continua de tareas que a un simple “chatbot pasivo que espera preguntas”, como muchos imaginan.
Cursor necesita Origin, y esto también explica: después de generar el código, se requiere un sistema que guarde permanentemente el estado del proyecto, coordine las modificaciones, verifique los resultados y conecte las ejecuciones posteriores. Si esta ubicación permanece siempre externa, la cadena de producción del software Agent tendrá una dependencia crítica.
Y Origin completa precisamente esta capa.
04 Divergencia entre GitHub y Origin
GitHub ya cuenta con PR apilados, cola de fusiones y API REST, y continúa integrando el agente de codificación Copilot en Issues, Actions, PR y revisiones de código. Solo mirando la lista de funciones, ambas partes verán cada vez más superposiciones en el futuro.
La diferencia proviene principalmente de los supuestos de diseño.
GitHub se basa en una red madura de desarrolladores humanos, por lo que la ruta más natural es permitir que el Agente ingrese a los sistemas existentes de Issues, PR, Actions y protección de ramas.
Cursor puede rediseñar estos componentes a partir de la colaboración de agentes de alta densidad. Si en un repositorio se ejecutan durante mucho tiempo decenas de agentes, aumenta la cantidad de PR, se reducen los niveles de modificación y acelera el cambio de estado, entonces los sistemas de revisión, verificaciones, fusión y permisos deben reorganizarse en torno al comportamiento de las máquinas.
El rol del PR también puede ampliarse. Puede pasar de ser una modificación de código principalmente destinada a ser leída por personas, a convertirse en una unidad de trabajo de ingeniería que incluye diff, dependencias, evidencia de pruebas, fuentes, nivel de riesgo y estado de aprobación.
La responsabilidad humana se centrará más en la capa de reglas: qué directorios permiten modificaciones automáticas, qué tan grande puede ser el salto de versión permitido para las actualizaciones de dependencias, qué validaciones se requieren para las migraciones de base de datos, qué aprobaciones deben pasar el código relacionado con autenticación y pagos, y en qué situaciones el agente debe detenerse.
En consecuencia, las métricas de Agent-native forge también cambiarán. 22.6 commit/s es llamativo, pero el número de commits en sí mismo no representa la eficiencia de producción de software. Las métricas más significativas serían el tiempo transcurrido desde que una tarea entra en el sistema hasta su merge, la capacidad de recuperación local tras un fallo, el porcentaje de modificaciones completadas automáticamente por la política, el costo computacional de los cambios aceptados, y la atención humana consumida por las modificaciones de alto riesgo.
Origin desea controlar la superficie de control de producción de software que se forma al combinar repository, checks, review, permisos y events.
La competencia entre GitHub y Origin se centrará gradualmente en dos caminos: GitHub se expandirá desde un sistema maduro de colaboración humana hacia Agentes, mientras que Cursor intentará rediseñar forge según la carga de trabajo de los Agentes.
05 Old Ma is already on the next level
Por otro lado, después del lanzamiento de Grok 4.6, es fácil que el exterior siga discutiendo sobre los benchmarks, la capacidad de código, los puntajes de razonamiento y el precio. Pero al ver juntos a Colossus, Grok, Cursor y Origin, en realidad este enfoque ya se ha extendido a la cadena de producción de software después del modelo.
Colossus proporciona potencia de cómputo, Grok se encarga de la inferencia, Cursor convierte las capacidades del modelo en modificaciones de código, y Origin gestiona el estado posterior del repositorio, PR, verificaciones y revisiones. Cuando las capacidades del modelo mejoran, los beneficios se transmiten directamente a lo largo de la cadena de ejecución; incluso si una sola generación de modelos no logra una diferencia significativa, la infraestructura posterior puede seguir acumulando ventajas.
Entonces, la posición de Grok 4.6 hoy en una de las listas puede ser solo un resultado temporal. La pregunta más a largo plazo es quién puede organizar el modelo, el entorno de ejecución y el estado de la ingeniería de software en un sistema de producción que funcione de manera continua.
Mientras todos aún discuten qué modelo es más inteligente en esta ronda, ya no se dan cuenta de que Lao Ma ha subido un nivel.