Cursor entwickelt Origin, einen möglichen GitHub-Konkurrenten für KI-Agenten

Was passiert mit dem Code-Hosting, wenn Menschen aufhören, den Code zu schreiben? Genau diese Frage beantwortet Cursor mit seinem neuen Projekt. Cursor kündigte auf dem Netzwerk X eine Plattform namens Origin an. Einen Ort, an dem Teams und KI-Agenten Code speichern, durchsuchen und gemeinsam daran arbeiten können. Der Beitrag löste eine Debatte darüber aus, wie die Code-Freigabe und Konfliktlösung künftig aussehen werden und ob Microsoft mit seinem GitHub endlich ernsthafte Konkurrenz bekommt.

Sehen wir uns an, was wir wirklich über Origin wissen.

Wie Cursor uns bis hierher gebracht hat

Vor Origin gab es Cursor. Einen rund um künstliche Intelligenz entwickelten Code-Editor, der die Arbeit von Programmierern stärker verändert hat als alles andere seit der Einführung von VS Code selbst. Er wurde 2023 öffentlich eingeführt und integrierte ein dialogorientiertes Modell direkt in den Editor. Kein Kopieren von Antworten aus dem Chat und Einfügen in das Projekt mehr. Sie schreiben Code, drücken die Tabulatortaste und das Modell vervollständigt ihn. Sie markieren einen Block, drücken Strg+K und beschreiben, was Sie möchten. Kein Wechseln zwischen Fenstern.

Das Ergebnis ließ sich messen. Frühe Nutzer berichteten bei Routineaufgaben von einer um 30 bis 50 Prozent höheren Schreibgeschwindigkeit. Wichtiger war jedoch, wie sich die Arbeit selbst veränderte. Entwickler begannen, ganze Module zu delegieren, nicht nur einzelne Zeilen. Sie beschrieben in Alltagssprache, was sie wollten, und überprüften anschließend das Ergebnis, statt jeden Buchstaben selbst zu schreiben. Aus dem Autor des Codes wurde nach und nach sein Prüfer und Regisseur.

Im Jahr 2025 ergänzte Cursor im Hintergrund laufende Agenten. Vollständig autonome Sitzungen, die eine Aufgabe aus GitHub übernahmen, eine Funktion programmierten, Tests ausführten und einen Pull Request öffneten. All das ohne einen Menschen. Hier kehrte sich die Logik um. Bei der Codeprüfung ging es nicht mehr darum, dass ein Mensch liest, was ein anderer Mensch geschrieben hat. Immer häufiger genehmigte ein Mensch die Arbeit einer Maschine, oder eine Maschine prüfte die Arbeit einer anderen Maschine und der Mensch bestätigte sie lediglich.

Origin ist eine direkte Folge dieser Veränderung. Sobald Agenten massenhaft Pull Requests produzieren, wird der Ort, an dem diese Anfragen eingehen, zum Engpass. Und GitHub wurde dafür nicht entwickelt.

Was Origin eigentlich ist

In der einfachsten Betrachtung handelt es sich um einen Speicherort für Repositorys, einen Bereich zur Prüfung von Pull Requests und zur gemeinsamen Arbeit an Änderungen. Das klingt wie GitHub. Das soll es auch, bevor es sich dann in jeder wesentlichen Grundannahme davon unterscheidet.

Der Unterschied liegt darin, für wen die Plattform entwickelt wurde. GitHub entstand 2008 für Menschen. Für Programmierer, die Code schreiben, Pull Requests öffnen, bei der Prüfung Anmerkungen verfassen und Branches zusammenführen, nachdem sie die Unterschiede zwischen den Versionen im Browser gelesen haben. Jede Oberfläche, mit der man dort interagiert, ist auf einen Menschen zugeschnitten, der Entscheidungen auf Grundlage des gelesenen Textes trifft.

Origin entsteht 2026, nach dem Aufkommen des agentenbasierten Programmierens. In der Welt, die Cursor aus eigener Anschauung kennt, wird heute ein großer Teil des Codes von autonom laufenden Agenten geschrieben. Sie implementieren Funktionen, beheben Fehler und öffnen Pull Requests. Und die Menschen, die diesen Code prüfen, lesen oft nicht jede Zeile. Sie entscheiden, ob sie die Arbeit der Agenten gesammelt genehmigen oder die Prüfung an einen weiteren Agenten übergeben.

Die Schwachstelle, die GitHub nicht einfach flicken kann

Ein Kommentar unter der Ankündigung brachte das eigentliche Problem besser auf den Punkt als jede Produktbeschreibung. Der Nutzer @subramanya schrieb: Wenn Agenten die Hauptnutzer sind, besteht der schwierige Teil in einem für Maschinen verständlichen Prüf-, Merge- und Konfliktstatus. Nicht in einer weiteren hübschen Oberfläche für Repositorys.

Und genau darin liegt der Kern der Sache. GitHub kann eine Funktion zur automatischen Codeprüfung hinzufügen und hat das auch wiederholt getan. Doch sein gesamtes Datenmodell für Pull Requests basiert auf menschlichem Denken. Ein Versionsunterschied ist eine visuelle Darstellung der Änderungen Zeile für Zeile. Ein Merge-Konflikt ist eine Textdatei mit Markierungen wie <<<<<<<. Eine Prüfungsanmerkung ist eine Zeichenfolge, die an eine Zeilennummer angeheftet ist. Nichts davon lässt sich von einer Maschine ohne Weiteres semantisch analysieren.

Damit ein Agent einen Merge-Konflikt bewältigen kann, muss er verstehen, warum er entstanden ist. Welche Absicht aus Branch A nicht mit der Absicht aus Branch B vereinbar ist und welche Lösung unter Berücksichtigung beider Änderungen die richtige ist. Markierungen in zeilenweisen Unterschieden zeigen das nicht. Und eine Anmerkung wie „Irgendetwas stimmt hier nicht“ erst recht nicht. Deshalb würde die agentenbasierte Codeprüfung mehrere Dinge gleichzeitig benötigen:

• Eine strukturierte, semantische Darstellung der Änderungen. Statt eines bloßen textlichen Unterschieds würden Änderungen als Objekte beschrieben: Die Signatur einer Funktion wurde geändert, eine Schnittstelle wurde angepasst, eine Abhängigkeit kam hinzu oder die Testabdeckung hat sich verschoben. Über eine solche Beschreibung kann ein Agent zuverlässiger nachdenken als über gewöhnlichen  Text.
• Einen maschinenlesbaren Merge-Status. Wenn zwei Branches miteinander in Konflikt geraten, sollte das System semantisch beschreiben können, worum es geht. Zum Beispiel, dass Branch A den Rückgabetyp der Funktion processPayment() in Promise<Result> ändert, während Branch B einen synchronen Aufruf derselben Funktion hinzufügt, der davon ausgeht, dass sie kein Promise zurückgibt. Der Agent kann dann eine Lösung auf Grundlage der Absicht vorschlagen, statt einzelne Zeichen zu vergleichen.
• Eine vorhersehbare Schnittstelle für die Prüfung. Die menschliche Prüfung eines Pull Requests ist unklar. Prüfer genehmigen nach flüchtigem Lesen, schreiben vage Anmerkungen und führen Änderungen trotz ungelöster Diskussionsstränge zusammen. Eine agentenbasierte Prüfung braucht klare Kriterien. Erfüllt die Änderung die festgelegten Anforderungen? Hält sie alle vorgegebenen Bedingungen ein? Waren die Tests erfolgreich? Diese Fragen kann eine Maschine zuverlässig beantworten.
• Nachvollziehbare Urheberschaft und eine Aufzeichnung der Entscheidungen. Wenn ein Agent einen Pull Request öffnet, sollte das Prüfsystem nicht nur die Codeänderung erfassen, sondern auch den Kontext der Entscheidung. Welche Anweisung der Agent erhielt, welchen Zustand des Codes er analysierte und welche Varianten er erwog. Erst dann ist eine menschliche Aufsicht sinnvoll, weil der Prüfer die Überlegungen des Agenten beurteilt und nicht nur dessen Ergebnis.

Nichts davon erfordert die Entwicklung neuer Git-Protokolle. Erforderlich ist vielmehr, neu zu durchdenken, wie eine Oberfläche für die gemeinsame Arbeit mit Git aussehen sollte, wenn Agenten vollwertige Beteiligte sind.

Das fehlende Glied in der Kette

Anfang 2025 waren Werkzeuge mit künstlicher Intelligenz hauptsächlich Assistenten. Sie vervollständigten Zeilen, machten Vorschläge während des Schreibens und überarbeiteten Inhalte per Chat. Gegen Ende 2025 verlagerte sich der Schwerpunkt auf autonome Agenten. Im Hintergrund laufende Agenten von Cursor, autonome Programmierer nach Art von Devin und der Unternehmenseinsatz agentenbasierter Pipelines. Und Mitte 2026 produzieren Unternehmen, die solche Pipelines betreiben, Pull Requests schneller, als Menschen sie prüfen können. Ein einzelner Ingenieur beaufsichtigt ohne Weiteres Dutzende agentenbasierte Anfragen pro Tag.

Der Engpass ist nicht mehr das Schreiben von Code. Es sind die Prüfung und das Zusammenführen. Und diese Ebene liegt heute bei GitHub, das weder für eine solche Belastung noch für diese Art der Urheberschaft oder diesen Prüfungsstil entwickelt wurde.

Cursor besitzt unterdessen den Editor. Das Unternehmen sieht aus nächster Nähe, wie seine Nutzer Code erstellen, wie ihre agentenbasierten Abläufe aussehen und wo es hakt. Origin zu entwickeln, ist aus dieser Position ein logischer Schritt. So lässt sich der nächste Engpass in der Kette kontrollieren.

Dahinter steckt auch ein Wettbewerbsgedanke. GitHub gehört Microsoft. VS Code gehört Microsoft. GitHub Copilot gehört Microsoft. Und Cursor konkurriert mit allen dreien. Auf GitHub aufzubauen bedeutet, dass Cursor-Nutzer ausgerechnet auf der Code-Hosting-Ebene von einem Konkurrenten abhängig sind. Je tiefer agentenbasierte Abläufe in diese Ebene hineinwachsen, desto unangenehmer wird diese Abhängigkeit. Origin ist unter anderem eine Wette auf die Verknüpfung der gesamten Kette. Den Editor besitzen, das Hosting besitzen und den agentenbasierten Prozess von Anfang bis Ende kontrollieren.

Reaktionen der Community

Die Ankündigung auf X löste eine breite Palette von Reaktionen aus, aus denen sich mehrere Richtungen herauskristallisierten. Einige bezeichneten Origin sofort als Konkurrenten von GitHub. Ein Kommentar lautete: ein Versuch, nicht von Microsoft abhängig zu sein. Das trifft wahrscheinlich zu und war vermutlich auch so gemeint.

Dann gab es die Skeptiker aus den Reihen der Techniker. Die bereits erwähnte Anmerkung von @subramanya, dass der schwierige Teil ein maschinenlesbarer Konfliktstatus und nicht eine weitere Oberfläche sei, zielt auf eine echte technische Herausforderung. Ein hübscheres GitHub mit einigen intelligenten Funktionen zu entwickeln, wäre noch kein Origin. Ein wirklich neues Datenmodell für die Zusammenarbeit von Agenten zu entwickeln, ist eine Aufgabe für viele Jahre. Und die Community hat das Recht, genau zu beobachten, was Cursor letztlich liefert.

Einige bemerkten auch das Wortspiel beim Namen. Origin überschneidet sich mit Blue Origin, dem Raumfahrtunternehmen von Jeff Bezos, und wird es in den Suchergebnissen vermutlich verdrängen. Vielleicht ist das Zufall, vielleicht eine klug gewählte Bezeichnung im Sinne des „Beginns des Agentenzeitalters“.

Und das sachlichste Lob kam von Ingenieuren, die bereits an die Grenzen des auf Menschen ausgerichteten GitHub gestoßen waren, als sie darauf agentenbasierte Pipelines betrieben. Sie freuen sich nicht über eine weitere Git-Oberfläche. Sie freuen sich über eine Infrastruktur, die Agenten als vollwertige Beteiligte behandelt und nicht als nachträglich auf ein System für Menschen aufgesetzte künstliche Intelligenz.

Für wen Origin gedacht ist

Für Teams, die bereits Agenten von Cursor einsetzen. Wenn bei Ihnen im Hintergrund laufende Agenten Pull Requests erzeugen, Funktionen aus Tickets umsetzen oder in Test- und Korrekturschleifen laufen, gehören Sie zur wichtigsten Zielgruppe. Origin verspricht, den Kreis zu schließen. Dieselbe Plattform, die den Code erstellt, hostet ihn auch und führt ihn durch Prüfung und Zusammenführung, wobei der Kontext der Arbeit des Agenten auf dem gesamten Weg erhalten bleibt.

Dann für Unternehmen, die in Pull Requests von künstlicher Intelligenz versinken. Die Kapazität menschlicher Prüfungen wächst nicht im gleichen Tempo wie die Geschwindigkeit der Codeerstellung. Ein System, das agentenbasierte Anfragen zur Vorprüfung an einen anderen Agenten senden kann und den Menschen erst an der Freigabeschranke einbezieht, ist eine direkte Antwort darauf.

Und schließlich für Unternehmen, die sich mit ihrer Abhängigkeit von Microsoft auseinandersetzen. Dass GitHub Microsoft gehört, ist für einige von ihnen ein sensibles Thema, insbesondere dort, wo Microsoft zugleich Wettbewerber ist oder bei der Beschaffung von Dienstleistungen eine Rolle spielt. Origin bietet einen Weg aus der Welt von VS Code, Copilot und Azure.

Quelle: explainx.ai