GitHub cae mientras Cursor lanza Origin: una coincidencia que expone el futuro del código

Estoy revisando la línea de tiempo de la caída de GitHub del 17 de agosto y el dato que más me llamó la atención ni siquiera está en GitHub.

Ese mismo día Cursor presentó Origin, su propia plataforma para alojar código.

El timing fue extraño. Mientras equipos enteros tenían problemas con Actions, Webhooks, Pull Requests, Issues, Git Operations y Copilot, Cursor estaba anunciando una pieza que lo mete directamente en un terreno que hasta ahora parecía reservado para GitHub, GitLab y compañía.

La caída fue más grande que “no puedo hacer push”

GitHub empezó a presentar problemas alrededor de las 7:40 de la mañana, hora de Ciudad de México.

En distintos momentos del incidente hubo errores en la web, la API, descargas de archivos y varios servicios que muchos equipos usan para trabajar y desplegar aplicaciones. GitHub llegó a reportar alrededor de 20% de errores en experiencias web y tráfico de API, además de cifras cercanas a 50% en descargas de archivos y contenido raw.

Eso explica por qué la caída se sintió distinta dependiendo del equipo.

Para unos fue no poder abrir correctamente un repositorio. Para otros, un pipeline detenido. Para otros, Copilot sin responder.

Un pipeline es la cadena automática que prueba, construye o publica una aplicación. Piensa en una banda transportadora: si una estación se detiene, todo lo que viene detrás empieza a acumularse.

Y ahí está el problema real con una plataforma tan central como GitHub. Ya no guarda únicamente código. Alrededor de ella viven permisos, revisiones, automatizaciones, despliegues, bots, documentación y ahora también herramientas de IA.

Cuando GitHub falla, muchas veces descubres que dependías de GitHub para bastante más que guardar el repositorio.

Y en medio de eso apareció Origin

Cursor anunció Origin como un nuevo servicio de hosting de código integrado directamente en su editor.

Eso cambia bastante la conversación.

Hasta ahora, Cursor era principalmente el lugar donde escribías y modificabas código con ayuda de agentes de IA. El repositorio seguía viviendo normalmente en GitHub y buena parte de la colaboración terminaba allá.

Con Origin, Cursor empieza a mover piezas del flujo hacia su propio terreno.

Puede alojar repositorios, mostrar cambios, manejar pull requests y permitir que sus agentes trabajen directamente sobre el proyecto.

Un pull request es básicamente una propuesta de cambios antes de incorporarlos al proyecto principal. Es el punto donde normalmente otro desarrollador revisa qué cambiaste antes de aceptar el trabajo.

Si Cursor logra que esa revisión, los agentes y el repositorio vivan juntos, reduce bastantes saltos entre herramientas.

Y esa es la parte que me parece importante del anuncio.

La letra pequeña fue más interesante que el lanzamiento

Origin todavía tiene una relación muy cercana con GitHub.

Si llevas a Origin un repositorio existente mediante sincronización, GitHub sigue siendo la fuente principal. Origin conserva una copia para navegar, buscar y trabajar, pero varias operaciones continúan regresando a GitHub.

Eso es lógico para una beta. Nadie quiere migrar todos sus repositorios, permisos y automatizaciones solo para probar una herramienta nueva.

Pero el 17 de agosto ocurrió algo bastante oportuno para mostrar esa dependencia.

Cursor reportó problemas en servicios como Cloud Agents, Automations, Review Agents y Codebase derivados de la degradación de GitHub.

Dicho de otra manera: el mismo día que Cursor presentó una plataforma que puede competir con GitHub en una parte del flujo, también quedó claro que todavía necesita a GitHub para varios escenarios.

No lo veo como algo negativo. Me parece una fotografía bastante honesta de dónde está Origin hoy.

Está empezando.

Qué puede hacer Origin hoy

La propuesta todavía es temprana, pero ya se entiende hacia dónde quiere ir.

Cursor también está conectando Origin con servicios como Vercel, Depot y Buildkite.

Eso importa porque un repositorio aislado sirve de poco en un equipo real. Necesitas probar cambios, generar versiones, desplegar aplicaciones y saber quién hizo qué.

Origin parece apuntar justamente a ese paquete completo.

GitHub tiene una ventaja enorme: todo lo que ya vive alrededor

Mover un repositorio Git puede ser relativamente sencillo.

Mover una organización completa es otra historia.

En GitHub puedes tener años de historial, reglas de protección, permisos, Actions, secretos, integraciones, aplicaciones, bots, proyectos open source y procesos internos que nadie quiere reconstruir un viernes por la tarde.

Ese ecosistema pesa.

Por eso me cuesta comprar la idea de que Origin sea “el reemplazo de GitHub”. Al menos hoy.

Lo interesante está en otro lado.

Cursor ya controla una parte del día del desarrollador: el editor. Y con los agentes de IA cada vez hace más trabajo dentro de ese mismo espacio.

Si también controla el repositorio y la revisión de cambios, puede construir un flujo pensado desde el inicio para agentes, en vez de agregar IA encima de herramientas diseñadas hace años para trabajo exclusivamente humano.

Ahí sí veo una diferencia seria.

El incidente dejó una lección de arquitectura

Hay algo que conviene revisar después de una caída así, aunque mañana todo vuelva a funcionar perfecto.

Dependencias.

En sistemas empresariales es muy común descubrirlas cuando algo falla. Un servicio parece independiente hasta que deja de responder porque autentica contra otro. Ese segundo servicio depende de una API. La API depende de una cola. Y de repente tienes cuatro equipos mirando la misma pantalla.

Con GitHub pasa algo parecido.

Un proyecto puede seguir existiendo en tu máquina, pero si tu flujo depende de Actions, autenticación, revisiones, bots y despliegues conectados a GitHub, la caída afecta mucho más que el repositorio.

Yo revisaría al menos esto:

• Qué procesos críticos se detienen si GitHub no responde.
• Qué despliegues dependen completamente de Actions.
• Qué repositorios importantes tienen espejo o respaldo.
• Qué herramientas externas siguen usando GitHub por debajo.
• Qué parte del trabajo puede continuar de forma local durante una caída.

No para vivir esperando el próximo incidente.

Para saber qué tan grande es realmente tu dependencia.

Lo que me llevo

Origin me interesa porque mueve a Cursor de categoría.

Un editor con IA compite contra otros editores. Una plataforma que aloja código, maneja revisiones y conecta agentes empieza a competir por una parte mucho más importante de la infraestructura de desarrollo.

Todavía le falta camino.

El propio incidente del 17 de agosto mostró que GitHub sigue siendo una pieza importante incluso dentro de varios servicios de Cursor.

Pero también dejó claro por qué tiene sentido que aparezcan alternativas.

Durante años fue normal pensar en GitHub como el lugar predeterminado para alojar código. Ahora herramientas nacidas alrededor de IA están intentando rediseñar ese flujo completo.

Qué haría con Origin hoy

Yo no movería un proyecto crítico por una caída de varias horas.

Sí abriría un repositorio secundario en Origin y lo probaría.

Quiero ver cómo se siente revisar cambios desde Cursor, qué tanto contexto tienen realmente los agentes y cuántas operaciones siguen terminando en GitHub cuando trabajas con sincronización.

Ahí se va a notar si Origin es simplemente una comodidad más dentro de Cursor o si realmente empieza a construir una alternativa.

Por ahora me quedo con una imagen bastante curiosa del 17 de agosto: GitHub caído, Cursor presentando un competidor y Cursor sufriendo parte de la misma caída.

Difícil pedir una prueba de producción más rápida para una idea recién anunciada.