Was die Community beim Transcend Hackathon auf GitLab Orbit gebaut hat

Mehrere tausend Entwickler(innen) erhielten Zugang zu GitLab Orbit – ohne weitere Vorgaben, was damit zu tun sei. Die Community entwickelte daraufhin Lösungen für reale Probleme aus dem Produktionsalltag. Es sind die Fragen, die sich Woche für Woche stellen: Was bricht diese Änderung? Welche Tests sind wirklich relevant? Und was kostet diese Migration am Ende?

GitLab Orbit ist ein lebendiger, abfragbarer Graph des eigenen Codes samt Merge Requests, Pipelines, Deployments und Verantwortlichkeiten, in dem jede Beziehung zwischen diesen Elementen aktuell gehalten wird. Agenten schreiben zwar guten Code, tun sich aber schwer damit, das umgebende System zu verstehen. Die verbindenden Fragen – was hängt hiervon ab, welche Tests decken es ab, wer verantwortet die Folgen – bedeuteten früher, dass ein Agent Dateien durchsuchte oder eine Entwicklerin bzw. ein Entwickler sich durch vier Werkzeuge graben musste. Orbit macht daraus eine einzige Abfrage. Agenten erreichen Orbit über das Model Context Protocol (MCP), Menschen fragen ihn direkt ab, und die Antwort kommt aus dem Graphen selbst statt aus einer Recherche über mehrere Werkzeuge hinweg. Die Orbit-Startseite erzählt die ganze Geschichte. Uns interessierte, was Menschen bauen, sobald dieses Werkzeug ihnen gehört.

Am Hackathon nahmen 1.576 registrierte Entwickler(innen) teil, die 265 zugelassene Projekte im Showcase Track auf Basis von GitLab Orbit einreichten: Agenten, Flows und Skills. Unabhängig davon brachten 26 Mitwirkende 61 Verbesserungen direkt in die Orbit-Codebase ein – von zusätzlicher Sprachunterstützung über Bugfixes bis zu präziseren Docs. Die Community baute nicht nur auf Orbit auf, sie machte Orbit besser.

Welche Probleme die Community anging

Noch vor jeder Bewertung fiel eines auf: Sortiert man die Einreichungen danach, was sie tatsächlich leisten, ergibt sich ein deutliches Ungleichgewicht.

70 Teams bauten eine Variante desselben Werkzeugs: Zeig mir, was diese Änderung brechen könnte, bevor ich sie merge. Mehr als 30 entwickelten Hilfen für Onboarding und Codeverständnis – das Problem hilf mir, diese Codebase zu verstehen. Danach folgten Incident-Root-Cause-Analyse, Architecture Drift, die Diagnose instabiler Pipelines und das Verfolgen einer CVE über mehrere Repositories hinweg.

Das ist kein Zufall. Solche Fragen stellen sich ständig, und sie wurden bislang schlecht beantwortet, weil die Antworten über Git, CI, Deployment-Werkzeuge und einige wenig vertrauenswürdige Dashboards verstreut lagen. Liegen sie in einem einzigen Graphen, greifen die Teams gezielt darauf zu.

Das ist Orchestrierung mit Kontext und eingebauter Kontrolle, nicht Orchestrierung allein. Und wenn Dutzende unabhängige Teams von sich aus zur gleichen Abfrage greifen, ist das ein Signal, das Plattformverantwortliche lesen sollten: Der Kontext ist der Ort, an dem die Arbeit tatsächlich stattfindet. In den stark besetzten Kategorien war die Messlatte hoch. Projekte hoben sich ab, indem sie 68 andere Teams hinter sich ließen oder einen Weg gingen, den sonst niemand einschlug.

Am saubersten gebaut

Gewinner: Sankofa. Drei Agenten, jeder ausgelöst durch einen anderen Moment im Arbeitsalltag, alle lesen aus GitLab Orbit. Beim Öffnen einer Merge Request liefert Radar den Blast Radius: nachgelagerte Aufrufer, betroffene Pipelines und das Team, das die Folgen verantwortet. Bei der Zuweisung eines Issues erstellt Guide vorab eine kurze Einordnung. Taucht eine Schwachstelle auf, verfolgt Shield jeden Pfad dorthin. Der Kontext erscheint dort, wo bereits gearbeitet wird, und tritt dann in den Hintergrund.

„Wenn eine Sicherheitslücke gemeldet wird, verbringen Teams Tage damit, ihre Reichweite manuell nachzuvollziehen, weil nichts die Zusammenhänge automatisch herstellt."

Lester K, Sankofa

Shield erledigt das in einem einzigen Durchlauf über den Graphen.

Zweitplatziert: Stayed Shipped. Das Projekt stellt eine Frage, die gängige Dashboards nicht beantworten: Wie viele der Änderungen, die KI-Agenten im letzten Monat gemergt haben, sind noch in Produktion? Es verfolgt, ob eine gemergte Änderung Bestand hat oder still von einer erfahrenen Fachkraft nachgebessert wird – unsichtbar für jede Standardmetrik.

Am besten bedienbar

Gewinner: Carver. Carver beziffert eine Legacy-Migration, bevor man sich auf sie festlegt. Man gibt an, was migriert werden soll; Carver liest den Abhängigkeitsgraphen von GitLab Orbit und erstellt einen Kostenvoranschlag: wie viele Einheiten, wie aufwendig, in welcher Reihenfolge und wo die Risiken liegen. Überzeugt hat in dieser Kategorie das Ergebnis. Carver gibt eine Zeile pro Einheit aus, dimensioniert und mit Risikomarkierung, und zeigt Details erst auf Nachfrage. Die Migration von AngularJS zu Angular weist das Projekt in seiner Demo mit rund neun Wochen manuellem Aufwand gegenüber zehn Dollar Generierungskosten aus, wobei der ungetestete, tragende Service rot markiert ist.

„Es prüft Orbit, findet den Service nicht und fragt nach, wo der eigentliche Code liegt."

Anes Mulalic, Carver

Deshalb weigert sich der Agent, eine Zahl zu erfinden, die er nicht belegen kann.

Zweitplatziert: Marshal. Gleiches Gebiet, umgekehrter Ansatz: volle Autonomie. Man deklariert ein organisationsweites Ziel, und Marshal findet über GitLab Orbit jedes betroffene Repository, ordnet die Arbeit in eine Reihenfolge und reicht Merge Requests Welle für Welle ein, ohne dass ein Ziel verloren geht.

Größte Wirkung

Gewinner: CrossCut. CrossCut führt nur die Tests aus, die eine Änderung tatsächlich brechen könnte. Beim Öffnen einer Merge Request zieht es die geänderten Symbole heran, folgt dem Call Graph von GitLab Orbit bis zur echten transitiven Auswirkung und baut eine Pipeline, die genau diese Tests ausführt und keine weiteren. Kein Modell im Spiel, kein Raten, nur Traversierung. Bei einer großen oder repoübergreifenden Test-Suite reduziert das den CI-Umfang laut Projektangabe um 90 % oder mehr.

„Man braucht den Call Graph der gesamten Codebase, um zu wissen, welche Tests eine Änderung erreichen kann. Genau das baut GitLab Orbit – statt zu raten, fragen wir einfach den Graphen."

Pritesh Kumar, CrossCut

Zweitplatziert: OrbitWeaver. Es refaktoriert autonom und nutzt dafür den exakten Blast Radius von GitLab Orbit statt Vektorähnlichkeit. Es erfasst jede betroffene Datei und bearbeitet sie in Abhängigkeitsreihenfolge – das überzeugendste Argument dafür, warum ein echter Graph unscharfer Suche überlegen ist, wenn ein Fehler eine rote Pipeline bedeutet.

Beste Idee

Gewinner: Transcend. Die meisten Teams fragten GitLab Orbit direkt ab – für die meisten Fragen der richtige Weg. Transcend baute darauf eine zweite Reasoning-Engine auf, mit dem Semantic-Web-Stack aus OWL, SPARQL und RDF, um Fragen zu erreichen, die die native API nicht in einem einzigen Aufruf ausdrücken kann. Transitive Hülle. Joins, die die eigene Codebase verlassen und das strukturierte Wissen der Welt hinzuziehen. Die Demo fragt, welche Methoden zum Knowledge-Graph-Embedding eine Codebase implementiert, und erhält die Klassennamen samt den Papers, die sie inspiriert haben, deren Autor(inn)en und Jahreszahlen – live mit dem Code verknüpft. Orbit als Fundament zu begreifen, auf dem sich aufbauen lässt, statt als API, die man nur aufruft, war hier wirklich neu, und genau das zeichnet diese Kategorie aus.

Zweitplatziert: Universal Agent OS. Es baut die Governance-Schicht um Agenten herum, nicht den Agenten selbst: erst befragen, vor dem Coden planen, Belege sichern und Validierung erzwingen. Je größer der Anteil des Codes wird, den Agenten schreiben, desto mehr wird ihre Rechenschaft zum eigentlichen Problem. Es ist dasselbe Problem, das der Kontext von GitLab Orbit an jeder anderen Stelle dieser Liste sichtbar macht: Agenten produzieren in großem Umfang, und dennoch muss jemand für das Ergebnis geradestehen.

Contribute Track

Der Contribute Track lief parallel zum Showcase Track und war keine Nebensache. 26 Mitwirkende brachten 61 Merge Requests direkt in die Codebase von GitLab Orbit ein: Sprachunterstützung für C++20 Concepts, Go-Paketdeklarationen, Kotlin Coroutines und Ruby Lambdas; Ontologie-Korrekturen; einen SIGPIPE-Bug in der CI; das erste Tutorial für Orbit-Abfragen; und Aufräumarbeiten an der Dokumentation, damit die nächste Person nicht über max_depth versus max_hops stolpert. Neunzehn erhielten einen Geldpreis, alle 26 Swag-Credits.

Die Geldpreise gingen an die ersten 40 gemergten Beiträge; diese Liste spiegelt daher ebenso die Reihenfolge wie die Qualität wider. Es sind die Mitwirkenden, deren funktionierende Änderung als Erste geprüft und gemergt wurde. Glückwunsch den Preisträger(inne)n dieser Runde:

achalbajpai, aishahsofea, AlphaTheGoat27, anushkrishnav, bartekp854, bhandari.varun04, ChaitanyaManik17, fa220, fongse, gatlavishweshwarreddy26, gkepas, JonstonChan, koves, MattGaiser, MatthewOscar, nexpectArpit, priyansh3133, Vinayreddy765, zidanesalim.

Alle gemergten Beiträge im Überblick.

Was die Community uns gezeigt hat

Über ein Werkzeug lernt man etwas, indem man beobachtet, was Menschen damit bauen, bevor ihnen jemand sagt, wofür es gedacht ist. Niemand baute einen Chatbot. Die starken Einreichungen setzten im Kern alle beim Gleichen an: Sie nahmen eine Frage, die früher eine Recherche über vier Werkzeuge hinweg bedeutete, und beantworteten sie mit einer einzigen Abfrage.

• Was bricht, wenn ich das merge?
• Welche Tests sind wirklich relevant?
• Was kostet diese Migration am Ende?
• Ist die Änderung vom letzten Monat noch aktiv?

Diese Funktionen haben wir nicht ausgeliefert. Die Community fand sie, sobald der Graph in Reichweite war. Das sagt mehr über GitLab Orbit aus als jeder Benchmark.

Das komplette Teilnehmerfeld findet sich in der Projektgalerie. Viele gute Projekte passten nicht in acht Kategorien.

Was sich mit GitLab Orbit umsetzen lässt

Jedes der genannten Gewinnerprojekte ist eine Antwort auf dieselbe Frage: Was kann ein Agent leisten, wenn er aus First-Party-Kontext über das gesamte System hinweg schließt, statt aus Fragmenten zu raten? GitLab Orbit bildet Code, Work Items, Merge Requests, Pipelines, Deployments und Verantwortlichkeiten fortlaufend in einem Graphen ab, sodass Agenten und Entwicklungsteams aus einer einzigen Quelle der Wahrheit schöpfen. Für den Einstieg braucht es keinen Hackathon. Diese Muster hat die Community erprobt, jedes davon verankert in einem Anwendungsfall, für den Orbit gebaut wurde.

• Änderungen absichern, bevor gepusht wird. GitLab Orbit lässt sich in einer einzigen Abfrage nach jedem nachgelagerten Aufrufer einer Funktion, den davon gespeisten Pipelines und dem verantwortlichen Team fragen. Sankofas Radar tut dies an einer Merge Request; CrossCut nutzt denselben Call Graph und führt nur die Tests aus, die eine Änderung erreichen kann, was einen CI-Lauf laut Projektangabe um 90 % reduziert. So lassen sich verborgene Abhängigkeiten früh erkennen, statt sie erst am Ende der CI zu entdecken.
• Sicherere Migrationen mit vollem Systemkontext. Abfragen lässt sich, welche Services von dem abhängen, der migriert werden soll, in welcher Reihenfolge und wo das Risiko sitzt. Carver macht daraus einen bezifferten Kostenvoranschlag, Marshal treibt sie Repository für Repository voran. Beide ermitteln den Blast Radius aus dem realen Abhängigkeitsgraphen, sodass ein Plattformteam sich auf einen Migrationstermin festlegen kann, statt verborgene Abhängigkeiten erst nach drei Wochen zu entdecken.
• Blast-Radius-Analyse für Schwachstellen. Von einer verwundbaren Funktion aus folgt der Graph jedem erreichbaren Endpunkt, den Pipelines, die ihn bauen, und den verantwortlichen Teams. Sankofas Shield erledigt in einem einzigen Durchlauf, was früher eine Korrelationsarbeit Projekt für Projekt bedeutete.

Der rote Faden: Die Antwort lag nie im Code allein. Sie liegt darin, wie Code mit Pipelines, Deployments, Schwachstellen und Verantwortlichkeiten zusammenhängt, und GitLab Orbit hält diese Zusammenhänge aktuell, sodass sich alles in einer einzigen Abfrage klären lässt. Agenten auf der GitLab Duo Agent Platform fragen ihn nativ ab, externe Agenten verbinden sich über MCP, und Entwicklungsteams fragen denselben Graphen direkt über den Data Explorer ab. Ein Graph, eine Quelle der Wahrheit – für jeden Agenten und jede Person im Team.

GitLab Orbit ausprobieren

Allen Teilnehmenden ein Dankeschön. Wer selbst etwas bauen möchte, beginnt mit GitLab Orbit auf der GitLab Duo Agent Platform: Derselbe Kontext, den diese Teams genutzt haben, ist im eigenen Software-Lebenszyklus bereits verfügbar. Eine Neuauflage folgt. Wer zuerst davon erfahren möchte, meldet sich unter contributors.gitlab.com an.

Bereits Zugang zur GitLab Duo Agent Platform und zu GitLab Orbit – und neugierig, wie weit sich das treiben lässt? Für Co-Create bewerben.