Das Repository ist nicht mehr der Mittelpunkt
GitHub und GitLab holen die Agenten in ihre Werkzeuge. Aber sie bauen sie in ein Arbeitsmodell ein, das um Code herum entstanden ist. Wenn Maschinen den Code schreiben, zählt etwas anderes.
Seit vielen Jahren dreht sich bei uns die Entwicklung um dasselbe Ding: das Repository. Ein Ticket beschreibt, was zu tun ist. Jemand legt einen Branch an, schreibt Code, öffnet einen Pull Request. Eine Kollegin liest ihn, stellt Fragen, gibt frei. Der Code landet im Hauptzweig. GitHub und GitLab haben aus diesem Ablauf eine ganze Industrie gemacht, und er hat lange gut funktioniert.
Inzwischen schreiben bei uns Agenten einen großen Teil des Codes. Für Workspace, für Shopcloud, für unsere Apps und Spiele. Und je mehr sie schreiben, desto deutlicher merke ich, dass der Ablauf nicht mehr zu der Arbeit passt, die wir tatsächlich machen.
Ein Nachmittag mit drei Agenten
Ein Beispiel, so ähnlich erleben wir es ständig. Wir bauen ein kleines Spiel. Ein Agent arbeitet an der Darstellung, ein zweiter an der Spiellogik, ein dritter schreibt Tests, die auf Linux und Windows laufen. Jeder liefert ordentliche Arbeit, jeder öffnet seinen Pull Request.
Dann spielen wir die erste Runde, und sie dauert zu lange. Nicht ein bisschen, sondern so, dass der Spaß weg ist.
Damit beginnt die eigentliche Arbeit, und die hat mit Code erst einmal wenig zu tun. Welche Annahme war falsch? Welche der offenen Aufgaben passen noch, welche nicht mehr? Was der Logik-Agent gestern gebaut hat, beruht auf der alten Rundenlänge. Die Tests prüfen etwas, das wir so nicht mehr wollen. Und der Darstellungs-Agent weiß von alldem nichts, weil seine Sitzung längst beendet ist.
Davon steht im Repository nichts. Dort liegen drei saubere Pull Requests. Was fehlt, ist die Verbindung zwischen dem, was wir erreichen wollten, der Entscheidung, die sich gerade geändert hat, und den Änderungen, die davon betroffen sind.
Die Großen haben das gesehen
Es wäre billig, GitHub und GitLab vorzuwerfen, sie verschliefen die Agenten. Das tun sie nicht. GitHub lässt seit einem Jahr Agenten verschiedener Anbieter über Agent HQ und Mission Control arbeiten, beobachten und steuern. Auf der Universe vor zwei Tagen kam „Copilot Projects“ dazu, angekündigt mit dem Satz „Give Copilot a goal“: Agenten arbeiten parallel über mehrere Repositories an einem Ziel, die Sitzung wandert zwischen App, Editor, Kommandozeile und Web mit. GitLab hat die Duo Agent Platform im Januar allgemein verfügbar gemacht, mit Agenten über den ganzen Entwicklungszyklus, auch auf eigenen Servern. GitLabs Chef schrieb im Mai: „Software will be built by machines, directed by people.“
Den schönsten Satz hat GitHub selbst geliefert. Jay Parikh sagte auf der Universe: „Completed work, not more code, is the output that matters.“ Dem stimme ich ohne Einschränkung zu.
Und trotzdem: Schaut man genauer hin, bleibt der Ablauf derselbe. Ein Ticket oder ein Arbeitspaket, eine Agentensitzung, ein Branch, ein Pull Request, ein Review. Die Agenten sind schneller und zahlreicher geworden, aber sie arbeiten in den Gleisen, die für Menschen gebaut wurden, die einander Code zeigen.
Mehr Code ist nicht mehr Fortschritt
Die Zahlen passen zu dem, was wir im Alltag sehen. GitHub meldet, dass der Copilot-Agent allein von Mai bis September 2025 über eine Million Pull Requests erstellt hat. Der DORA-Bericht 2025 nennt KI einen „Verstärker“: Teams liefern mehr, aber die Instabilität steigt mit. In der Umfrage von Stack Overflow ärgern sich zwei Drittel der Entwickler am meisten über Ergebnisse, die „fast richtig, aber nicht ganz“ sind. Und Open-Source-Projekte kämpfen mit einer Flut automatisch erzeugter Beiträge, so sehr, dass GitHub Maintainern inzwischen erlaubt, Pull Requests ganz abzuschalten.
Das Schreiben ist nicht mehr der Engpass. Der Engpass ist das Entscheiden: Was gilt jetzt? Was verwerfen wir? Was hat sich am Ziel geändert, und was folgt daraus? Ein Werkzeug, das vor allem das Lesen von Codezeilen besser macht, verbessert den falschen Schritt.
Was wir eigentlich festhalten müssten
Wenn Agenten den Code schreiben, ist der Code nicht mehr das Wertvollste, das wir besitzen. Code lässt sich neu erzeugen. Was sich nicht neu erzeugen lässt, ist die Kette dahinter: Was soll entstehen? Welche Entscheidungen haben wir auf dem Weg getroffen, und warum? Welche Arbeit hängt an welcher Entscheidung? Und gegen welches Ziel, mit welchen Eingaben, haben wir ein Ergebnis geprüft?
Wenn sich das Ziel ändert, wie bei unserer zu langen Spielrunde, müsste genau diese Kette sichtbar werden. Nicht als Liste geänderter Dateien, sondern als Frage: Diese drei Aufgaben beruhen auf der alten Annahme, diese Tests prüfen das Falsche, und diese Entscheidung steht jetzt neu an.
Und die Arbeit müsste eine einzelne Sitzung überleben. Ein Agent bricht ab, ein Rechner fällt aus, ein anderer Agent eines anderen Anbieters soll weitermachen. Git sichert den Code zuverlässig. Den Stand der Arbeit, also Absicht, offene Fragen und bisherige Prüfungen, sichert es nicht.
Vier Einwände, die ich ernst nehme
Das Ziel war immer wichtig. Natürlich. Wir haben immer für Kunden entwickelt. Aber das Ziel lebte in Köpfen: im Gespräch mit dem Kunden, beim Entwickler, der nachfragte, wenn etwas nicht passte, bei der Kollegin im Review, die wusste, worum es eigentlich ging. Agenten tragen dieses Wissen nicht mit. Sie waren nicht beim Kunden, sie erinnern sich nicht an gestern, und wenn sich das Ziel ändert, erfährt es keiner von ihnen von selbst. Neu ist also nicht, dass das Ziel zählt. Neu ist, dass es niemand mehr nebenbei im Kopf mittragen kann. Es muss dort stehen, wo die Arbeit entsteht.
Die Großen ziehen nach. Ja. „Give Copilot a goal“ zeigt in genau diese Richtung, und der frühere GitHub-Chef Thomas Dohmke hat mit Entire ein eigenes Unternehmen gegründet, das die Begründungen von Agenten neben den Commits speichert. Es geht mir also nicht darum, was die Plattformen können. Ein Ziel, das man an ein Repository hängt, und ein Ziel, an dem sich Repositories, Agenten, Tests und Infrastruktur ausrichten, sind zwei grundverschiedene Dinge.
Spezifikationen sind schon einmal gescheitert. Auch das stimmt. Birgitta Böckeler hat für Martin Fowler die neuen Werkzeuge für spezifikationsgetriebene Entwicklung angesehen und gewarnt, man könne sich die Nachteile von modellgetriebener Entwicklung und von Sprachmodellen zugleich einhandeln. Sie würde lieber Code lesen als Berge von Markdown-Dateien. Ich verstehe das. Ein Ziel ist für mich aber kein Pflichtenheft, das vorab fertig sein muss. Es ist etwas, das sich mit jeder Erkenntnis verändert, und gerade deshalb braucht es einen Ort.
Die Belege sind dünn. Ebenfalls richtig. METR hat 2025 gemessen, dass erfahrene Entwickler mit KI sogar langsamer waren, und schreibt in der Aktualisierung vom Februar selbst, die neuen Daten seien unzuverlässig. Dass Agenten alles schneller machen, behaupte ich gar nicht. Sie verschieben die Arbeit: weg vom Schreiben, hin zum Führen. Und für das Führen haben wir bisher kaum Werkzeuge.
Warum wir Kernonaut bauen
Wir haben uns diese Fragen nicht am Schreibtisch ausgedacht. Wir stoßen jeden Tag darauf, bei unserer eigenen Software. Deshalb bauen wir Kernonaut, eine Plattform, in der das Produktziel die Grundlage der Entwicklung ist. Agenten bekommen daraus ihre Aufträge, Ergebnisse werden gegen das Ziel geprüft, und wenn sich das Ziel ändert, soll sichtbar werden, welche Arbeit und welche Entscheidungen davon betroffen sind. Arbeiten soll man auf eigenen Rechnern oder auf Cloud-Rechnern, die man ausdrücklich freigegeben hat.
Kernonaut ist noch in Entwicklung, und ich will hier nichts versprechen, was noch nicht läuft. Aber ich bin ziemlich sicher, dass sich die Mitte verschiebt. Das Repository wird bleiben, so wie das Dateisystem geblieben ist. Nur wird es nicht mehr der Ort sein, an dem wir entscheiden, was entsteht.
Das Produktziel war immer das Wichtigste. Wenn Agenten entwickeln, wird es auch zur wichtigsten Schnittstelle. Und genau diese Schnittstelle hält heute noch niemand richtig fest.
Quellen: GitHub Universe 2026 · Mission Control und Agent HQ · GitLab Duo Agent Platform · GitLab „Act 2“ · Octoverse 2025 · DORA 2025 · Stack Overflow 2025 · Pull Requests abschalten · Entire · Böckeler, Spec-driven development · METR, Februar 2026