Anysphere acaba de mover la pieza que faltaba. El editor que ya escribe una parte nada trivial del código que se produce hoy en el mundo ahora también lo aloja: Cursor abrió Origin, su propio git forge, en beta temprana para todos los planes pagados. Repos, pull requests, code browsing y sincronización con GitHub. El anuncio lleva horas en la portada de Hacker News con cientos de comentarios, y la discusión no es sobre features: es sobre quién se queda con la custodia del código.
Qué pasó
Origin es un git forge convencional en lo básico y deliberadamente incompleto en lo demás. Puedes crear un repo desde la web o desde un agente de Cursor, clonar y hacer push con git estándar, abrir y mergear pull requests, y navegar el código en cursor.com/codebase/{owner}/{repo}. La pieza interesante es el mirror de GitHub: conectas tu org, eliges qué repos sincronizar, y la copia en Origin se actualiza en tiempo real. Los PRs sincronizan en ambos sentidos — comentas en Cursor y aparece en GitHub, te asignan un review en GitHub y lo puedes mergear desde Cursor.
Cursor es explícito en que, para repos sincronizados, GitHub sigue siendo la fuente de verdad: los pushes siguen yendo allá. Es una estrategia de entrada lateral clásica: no te pide migrar, te pide dejar que se instale al lado.
El namespace es el detalle que muerde. Alguien de tu equipo tiene que reclamar el nombre del codebase, ese nombre queda incrustado en la URL de cada repo, y durante la beta no se puede cambiar. Los equipos en el modo de privacidad legacy no pueden habilitar Origin sin cambiar antes su configuración de Privacy Mode.
Por qué importa
Lo que está en juego no es el almacenamiento de git — montar un servidor git es un ejercicio de tarde. Lo que está en juego es dónde vive el contexto: los PRs, los reviews, los issues, el historial de decisiones. Ese es el activo que hace a GitHub difícil de reemplazar, y es exactamente el activo que un agente necesita para trabajar bien. Cursor no está construyendo un competidor de git; está construyendo el sustrato donde sus agentes tengan permiso, contexto y ejecución en el mismo lugar. Cuando el agente puede leer el repo, responder preguntas sobre el código que estás navegando, actualizar un PR y empujar una rama sin salir de la plataforma, el forge deja de ser infraestructura pasiva.
El timing tampoco es casual. Hace un mes GitHub estuvo seis horas roto a nivel global — Actions, git y autenticación — y buena parte de la industria descubrió en vivo cuánto de su pipeline depende de un solo proveedor. "Trae tus repos de GitHub y siguen funcionando aquí" es un pitch que se escucha muy distinto después de un incidente así.
El detalle técnico
Donde Origin se queda corto es en lo aburrido y crítico: no tiene CI propio. La respuesta de Cursor es delegar — conectas Depot o Buildkite, y ambos corren tus workflows de GitHub Actions existentes. Vercel se engancha desde la pestaña de Apps del repo y cada PR obtiene un preview deployment. Es una apuesta razonable, pero significa que el pegamento que realmente te ata a GitHub (Actions, el ecosistema de apps, los webhooks que consumen Sentry o Linear) sigue del otro lado.
La privacidad se hereda: Origin sigue el Privacy Mode del dueño del namespace, sea el equipo o el individuo. Para cualquiera que evalúe esto en un entorno regulado, ahí está la pregunta que hay que hacerle a legal antes que a ingeniería — no en qué región se guarda el blob, sino bajo qué acuerdo de procesamiento de datos queda el código fuente propietario cuando el vendor de tu editor también es tu forge.
En los comentarios de HN circulan afirmaciones sobre la propiedad de Cursor que no se sostienen con nada verificable; conviene ignorarlas y quedarse con la crítica técnica, que sí es sólida: la lección de GitLab es que la parte fácil es hostear git, y la parte donde se muere es todo lo demás.
Qué hacer
- Si tu equipo usa Cursor con plan pagado, decide el nombre del codebase antes de que alguien lo reclame por impulso: es inmutable durante la beta y queda en cada URL.
- Si eres admin y no quieres que esto entre por la puerta de atrás, Origin se deshabilita desde el dashboard del equipo. Hazlo de forma consciente, no por omisión.
- Antes de sincronizar cualquier repo, revisa qué implica que una copia en tiempo real de tu código propietario viva en un tercero más. El sync es granular: elige repos, no orgs.
- Como estrategia anti-lock-in genuina, esto no sustituye lo que ya sabías: réplicas de tus repos que tú controles y un CI que no dependa de un solo proveedor. Un segundo SaaS no es redundancia; es un segundo punto de falla con otra factura.
- Trátalo como beta: sin repos críticos, sin flujos de release que dependan de él.