Cursor Origin und das Ende der langweiligen Hosting-Frage

Mal ganz ehrlich: Achtzehn Jahre lang war die Frage „Wo hosten wir unseren Code?" die langweiligste Frage der Tech-Welt. GitHub, vielleicht GitLab oder Bitbucket – fertig. Das Thema war erledigt. Source Control Hosting war einfach nur Infrastruktur. Notwendig, zuverlässig, komplett unsexy.

Cursor glaubt, dass KI-Agenten genau diese langweilige Entscheidung wieder spannend gemacht haben.

Der perfekte Timing-Zufall

Am Montag begann Cursor damit, Origin an paying Kunden auszurollen. Dreieinhalb Stunden später ging GitHub in die Knie – Error-Rates kletterten auf fast 20% bei Pull Requests, Issues und der API. Archive und Raw File Downloads erreichten fast 50% Ausfallrate. Enterprise SSO crashte komplett: SAML, OIDC, SCIM Provisioning – alles. Sogar Copilot war betroffen.

Die Developer-Community tat, was sie am besten kann: Späße machen.

Vercel CEO Guillermo Rauch postete, dass man jetzt Repos in Cursor Origin hosten und auf Vercel deployen könnte – was wiederum selbst auf Vercel gehostet wird. „Und im Gegensatz zu GitHub ist es online", fügte er schelmisch hinzu. Cursor-Engineer Matt Palmer quote-tweetete den eigenen Launch mit dem besten Spruch des Tages: „Wir hätten das früher rausgehauen, aber GitHub war gerade down."

War das geplant? Vermutlich nicht. Product Launches werden Wochen vorher festgelegt. Aber manchmal schenkt einem das Universum etwas, und Cursor hat sauber zugepackt.

Was Origin wirklich ist – und was nicht

Hype beiseite, reden wir über das Produkt. Origin lebt als neuer Codebase-Tab direkt in Cursors Editor. Codebase benennen, URL kriegen, per Command Line pushen – und fertig ist die Standard-Forge-Erfahrung. Repositories, Pull Requests, Timelines, Commits, Checks, Merges. Das Grundgerüst stimmt.

Aber hier wird Origin interessant: Der KI-Agent operiert in derselben Oberfläche wie der Code und die Pull Requests, die er verändert.

Du kannst Fragen zu der Datei stellen, die du gerade anschaust. Du kannst einem Agenten einen Review-Kommentar geben und ihn bitten, den Pull Request direkt zu überarbeiten. Du kannst ihn bitten, einen Branch zu pushen – alles, ohne den Editor zu verlassen, in dem du Code schreibst. Der Agent ist kein separates Service obendrauf geschnallt. Er ist direkt in den Workflow eingewoben.

Das ist Cursors echte Wette. Sie bauen nicht einfach einen weiteren Git-Host. Sie setzen darauf, dass man seine KI-Agenten am liebsten dort hat, wo auch die Menschen arbeiten, die Code reviewen – nicht versteckt in einem anderen Tab oder Service.

Die Integrations-Strategie ist gezielt

Origin ist mit drei Day-One-Integrationen gestartet: Vercel, Depot und Buildkite. Diese Auswahl verrät genau, wen Cursor ansprechen will.

Vercel kümmert sich um Preview Deployments für jeden Pull Request und shipped nach dem Merge in Produktion – aktuell als öffentliche Beta für Pro- und Enterprise-Kunden. Depot und Buildkite übernehmen Continuous Integration, und das ist entscheidend: beide führen existierende GitHub Actions Workflows unverändert aus. Buildkite legt obendrauf noch native Pipelines.

Lies das nochmal: existierende GitHub Actions Workflows – unverändert.

Cursor verlangt nicht, dass Teams ihr Build-System umschreiben, Ingenieure umschulen oder Deployment-Pipelines rausschmeißen. Sie bitten Teams, einen zweiten Blick auf Code zu werfen, den sie sowieso schon haben. Das ist ein grundlegend anderer Sales-Ansatz als „steig auf unsere komplette Plattform um."

Die smartest Design-Entscheidung: GitHub nicht verlassen

Hier ist die Entscheidung, die Engineering Leads aufhorchen lassen sollte.

Origin verlangt nicht, dass du GitHub verlässt. Verbinde eine GitHub-Organisation, wähle Repositories aus, und sie erscheinen neben den Origin-nativen. Pushes gehen weiterhin an GitHub, das die Quelle der Wahrheit bleibt für alles, was dort angefangen hat. Zugriffsrechte spiegeln GitHubs existierende Read- und Write-Settings. Pull-Request-Konversationen synchronisieren bidirektional – kommentiere in Cursor, und es erscheint auf GitHub; antworte auf GitHub, und es taucht innerhalb von Sekunden in Cursor auf.

Das ist eine klassische Wedge-Strategie, sauber umgesetzt.

Rip-and-Replace-Migration von Source Control gehört zu den riskantesten Projekten, die eine Engineering-Organisation angehen kann. Das berührt Continuous Integration, Compliance-Nachweise, Audit Trails, Branch-Protection-Regeln, jede Integration in der Toolchain und die Muscle Memory jedes Engineers im Team. Kaum ein CTO genehmigt das für ein Produkt in früher Beta.

Aber ein Read-mostly Mirror, das GitHub autoritativ lässt? Das genehmigt sich quasi von selbst. Es kostet nichts, es auszuprobieren, erfordert keine Migration und gibt einen Vorgeschmack darauf, wie eine KI-native Code-Hosting-Erfahrung aussieht.

Was das für die Branche bedeutet

GitHub war seit fast zwei Jahrzehnten die Standardantwort auf „Wo hosten wir unseren Code?" Das ändert sich nicht über Nacht, und Cursor weiß das. Origin versucht nicht, GitHub zu ersetzen – Origin will der Ort werden, wo KI-unterstützte Entwicklung passiert, während GitHub das autoritative Backend bleibt für alles, was wirklich zählt.

Die Frage ist nicht, ob Origin GitHub verdrängen wird. Die Frage ist, ob Origin zur Oberfläche werden kann, die Developer tatsächlich benutzen, während GitHub die Infrastruktur darunter übernimmt.

Wenn KI-Agenten Code schreiben, reviewen und modifizieren – und das werden sie – dann wird der Ort, an dem diese Agenten arbeiten, strategisch wichtig. Cursor setzt ganz bewusst auf diese Karte.

Für Engineering Leaders, die die Landschaft bewerten, sind die Implikationen klar: Beobachte das, teste das Produkt, und achte darauf, welche Integrationen und Workflows sich im KI-nativen Kontext natürlich anfühlen. Die klassische Forge-Erfahrung hat uns gut gedient. Aber „gut genug für Menschen" und „gut genug für KI-unterstützte Teams" könnten unterschiedliche Fragen sein.

Und das könnte die interessanteste Entwicklung im Source Control Hosting seit achtzehn Jahren sein.