GitHub wurde von KI durchdrungen

Am 9. Februar dieses Jahres, in der späten Nacht chinesischer Zeit, öffneten weltweit Millionen von Entwicklern GitHub und sahen dieselbe Seite.

Es war kein 404-Fehler, sondern etwas, das noch angstvoller war – es war die gelbe Warnleiste, die jedem Engineer die Nackenhaare zu Berge stehen lässt, und die Reihe von Indikatoren auf der Statusseite, die von grün auf rot wechselte.

github.com war ausgefallen.

Die API war ausgefallen.

GitHub Actions waren ausgefallen.

Git-Operationen waren ausgefallen – selbst Copilot war nicht verschont geblieben.

In dieser Nacht kam bei manchen die CI/CD-Pipeline an der kritischsten Stelle zum Stillstand, bei anderen blieb die automatisierte Bereitstellung in der Luft hängen, und wieder andere warteten auf einen PR, der nicht zusammengeführt werden konnte – hinter dem lag eine Funktion, die in Betrieb gehen musste, und dahinter standen echte Benutzer.

Nachher veröffentlichte GitHub einen Unfallbericht. Die grundlegende Ursache, aus technischer Sicht, war die Überlastung eines Kern-Datenbankclusters, der für die Authentifizierung und die Benutzerverwaltung zuständig war. Aber hinter diesen wenigen Worten verbarg sich eine erschreckende Kette von Auslösern –

Zwei Tage zuvor hatte das Engineering-Team, um einem neuen Modell so schnell wie möglich an die Benutzer zu bringen, die Aktualisierungszeit eines "Benutzereinstellungscache" von 12 Stunden auf 2 Stunden geändert. Es war nur diese eine Änderung einer Konfigurationszahl.

Als Ergebnis wurde die ursprünglich in 12 Stunden verteilte Cache-Neuschreibung auf 2 Stunden komprimiert, was zu einem intensiven "Cache-Neuschreibsturm" führte. Die asynchrone Aufgabenwarteschlange wurde augenblicklich überlastet, die gemeinsamen Infrastrukturkomponenten stürzten ab, und die Kaskadenreaktion breitete sich auf den Dienst aus, der für die Proxy-HTTPS-Git-Operationen zuständig war, was schließlich dazu führte, dass alle Verbindungen auf der gesamten Plattform aufgebraucht waren.

Eine Zahl wurde von 12 auf 2 geändert.

GitHub wurde von einer eigenen Konfigurationsänderung zerschlagen.

Aber wenn Sie nur diese eine Konfigurationsänderung sehen, haben Sie wahrscheinlich den wichtigsten Teil dieser Geschichte verpasst.

01 Kein Zufall, sondern zehn Zufälle

Der Unfall am 9. Februar war kein isoliertes Ereignis.

Tatsächlich hatte GitHub in den ersten drei Monaten des Jahres 2026 mindestens 8 große Störungen erlebt. Im Februar allein gab es 37 Störungen unterschiedlicher Größe. GitHub-CTO Vlad Fedorov gab später in einem Blogbeitrag zu, dass GitHub in diesen zwei Monaten nicht die "drei Neunen" – 99,9 % Verfügbarkeit – halten konnte, die es seinen Unternehmenskunden zugesagt hatte.

Wenn Sie sich die Störungsarchive dieser zwei Monate ansehen, werden Sie eine seltsame Regel bemerken: Jeder Unfall scheint auf unterschiedliche Ursachen zurückzuführen zu sein.

Am 2. Februar: Es gab Probleme beim Azure-Rechenanbieter, GitHub Actions waren fast 4 Stunden lang ausgefallen, und Copilot-Coding-Proxy, CodeQL und Dependabot waren alle betroffen.

Am 9. Februar: Cache-Neuschreibsturm und Überlastung der Authentifizierungsdatenbank.

Am 5. März: Ein Redis-Clusterstörung führte dazu, dass 95 % der GitHub Actions-Workflows nicht innerhalb von 5 Minuten starten konnten, mit einer durchschnittlichen Verzögerung von 30 Minuten.

Am 18. März: Die Verzögerung der Webhooks stieg auf 32-fache der normalen Höhe an.

Jeder Unfall scheint ein "Zufall" zu sein, und die unmittelbaren Ursachen sind unterschiedlich. Aber Fedorovs Erklärung verbindet sie zu einer Geschichte. Er sagte, dass hinter diesen Störungen drei gemeinsame strukturelle Ursachen lagen: "Schnelles Wachstum der Last, enge Kopplung zwischen den Diensten, die zu einer Ausbreitung lokaler Störungen führt, und das Fehlen der Fähigkeit des Systems, den Datenverkehr von anomalen Clients zu schützen."

Mit anderen Worten, die Grundlagen von GitHub beginnen, unter dem Druck der neuen Last Risse zu bekommen.

Und diese "neue Last" hat einen konkreten Namen.

02 275 Millionen Commits pro Woche

Wichtige Daten

Gesamtzahl der Commits im Jahr 2025: ca. 1 Milliarde

Anzahl der Commits pro Woche im Jahr 2026: 275 Millionen

Nach dieser Geschwindigkeit wird im Jahr 2026 insgesamt voraussichtlich: 14 Milliarden (14-facher Anstieg gegenüber dem Vorjahr)

Rechenleistung von GitHub Actions: 500 Millionen Minuten pro Woche im Jahr 2023 → 1 Milliarde im Jahr 2025 → 2,1 Milliarden Minuten in einer Woche Anfang 2026

Wenn Sie ein Infrastruktur-Engineer von GitHub wären, würden Sie sich wahrscheinlich bei einem Vergleich der Überwachungsdashboards von 2025 und 2026 die Augen aus den Köpfen treiben lassen.

Im Jahr 2025 hat GitHub insgesamt etwa 1 Milliarde Code-Commits verarbeitet. Diese Zahl ist bereits sehr hoch und das Ergebnis jahrelanger Akkumulation auf der GitHub-Plattform. Aber im Jahr 2026 betrug die Anzahl der Commits pro Woche bereits 275 Millionen. Umgerechnet – wenn diese Geschwindigkeit den ganzen Jahr hindurch beibehalten würde, würde die Gesamtzahl der Commits im Jahr 2026 fast 14 Milliarden betragen, was 14-mal so viel wie im Jahr 2025 ist.

Dies ist keine glatte Wachstumskurve, sondern eine steile Rampe. Die Veränderung der Rechenleistung von GitHub Actions spricht noch deutlicher für sich: 2023 wurden pro Woche 500 Millionen Minuten verbraucht, 2025 verdoppelte sich diese Zahl auf 1 Milliarde, und dann stieg sie in einer Woche Anfang 2026 direkt auf 2,1 Milliarden Minuten.

Wer schickt so wild Code ab?

Es sind nicht die menschlichen Entwickler.

Die Daten von GitHub zeigen, dass AI-Agenten die aktivsten "Benutzer" auf dieser Plattform werden. Das Tool Claude Code allein leistet jetzt 4,5 % aller Commits in allen öffentlichen Repositories auf GitHub. Pro Woche werden 2,6 Millionen Commits vorgenommen, und Ende September 2025 war diese Zahl noch nur 100.000 – ein 25-facher Anstieg in drei Monaten.

Die Anzahl der von AI-Agenten eröffneten PRs explodiert ebenfalls. Im September 2025 waren es etwa 4 Millionen AI-generierte PRs pro Monat, bis März 2026 stieg diese Zahl auf 17 Millionen – mehr als das Vierfache in nur sechs Monaten.

Ein Bild kann Ihnen helfen, zu verstehen, was das bedeutet.

Ehemals waren die "Benutzer" von GitHub hauptsächlich menschliche Programmierer. Sie arbeiten tagsüber, schlafen nachts und haben am Wochenende frei. Bei jedem Commit denken sie nach, zögern und haben eine begrenzte Tippgeschwindigkeit. Die Last des Systems folgt dem menschlichen Tagesrhythmus, hat Höhen und Tiefen und ist vorhersehbar.

Jetzt werden immer mehr "Benutzer" von AI-Agenten vertreten. Sie schlafen nicht, haben keine Pausen, zögern nicht und können mehrere parallele Agenten für eine Aufgabe starten. Die Anzahl der Commits pro Stunde eines Agenten übersteigt leicht die Arbeitsleistung eines echten Ingenieurs in einer Woche. Noch wichtiger ist, dass sie nicht nur Code committen, sondern auch ständig neue Repositories erstellen – sie behandeln Repositories als "Ausgabe" des Workflows, nicht als "Arbeitsraum" für Menschen.

Die Infrastruktur-Engineer von GitHub stehen vor einem Problem, das nicht nur eine höhere Datenmenge betrifft, sondern von grundlegend anderer Natur ist.

03 Es reicht nicht mehr, Copilot zu finanzieren

Die häufigen Störungen sind nur eine Seite des Problems. GitHub hat noch ein anderes, noch ärgerliches Problem – beim Rechnen stellte sich heraus, dass es Verluste gemacht hat.

Die ursprüngliche Preislage von Copilot basierte auf einer vernünftigen Annahme: Die Benutzer nutzen es hauptsächlich zur "Hilfs-Vervollständigung", jede Interaktion ist kurz und die Rechenleistung ist vorhersehbar. Der persönliche Tarif kostet 10 US-Dollar pro Monat, der kommerzielle Tarif 19 US-Dollar pro Monat, berechnet pro Sitzplatz. Dieses Modell hat in den letzten Jahren gut funktioniert.

Dann kam die Agentic AI.

Der Agentic-Workflow und die traditionelle Vervollständigung sind zwei verschiedene Dinge. Bei der Standard-Code-Vervollständigung sind die Anfragen linear und vorhersehbar, und der Rechenzyklus ist kurz. Ein Agentic-Coding-Session kann mehrere Stunden dauern, mehrere parallele Threads starten und mehrstufige Inferenzen, Selbstkorrekturen und Quellcodeumstrukturierungen durchführen – die Anzahl der Tokens, die in einer Session verbraucht werden, übersteigt leicht die monatliche Abonnementgebühr eines normalen Benutzers.

GitHub steht vor der Situation, dass einige wenige intensive Agentic-Benutzer mit einer monatlichen Gebühr von wenigen Dollar Rechenressourcen verbrauchen, die einem Wert von mehreren hundert Dollar entsprechen.

Angesichts dieser Situation reagierte GitHub direkt – zuerst die Datenflusskontrolle, dann die Preisanpassung.

Anfang dieses Jahres hat GitHub zwei parallele Beschränkungsmechanismen für Copilot eingeführt: eine Obergrenze für die Sitzungsdauer und eine Obergrenze für die wöchentliche Nutzung, beide Dimensionen werden anhand der Token-Verbrauchsmengen multipliziert mit der Modellrechengewichtung berechnet. Gleichzeitig wurde die Registrierung neuer Benutzer für einige persönliche Copilot-Tarife ausgesetzt.

Am 1. Juni hat GitHub eine grundlegendere Preisanpassung vorgenommen: Copilot wechselt vollständig auf die Nutzenbasierte Abrechnung, die alten Tarife werden durch "AI Credits" ersetzt. Ein AI Credit entspricht 1 Cent, und die Nutzung wird anhand des Token-Verbrauchs in Echtzeit berechnet.

Die Zeit der Sitzplatzbasierten Abrechnung ist vor der Agentic AI zu Ende.

Diese Veränderung ist nicht nur GitHub's Problem. Dies ist eine kollektive Preiskrise, die die gesamte AI-Tool-Industrie im Jahr 2026 erlebt – wenn AI beginnt, vollständige Workflows anstelle von Menschen auszuführen, anstatt nur "Hilfe" für Menschen zu leisten, wird alle Abonnementmodelle, die auf "pro Person pro Monat" basieren, ungültig.

04 30-fach, nicht 10-fach

Zurück zum Infrastrukturproblem. Wie will GitHub eigentlich auf diesen "14-fachen Anstieg" reagieren?

Hier ist ein Detail, das die Schwere des Problems zeigt:

Ende Dezember 2025 begann der Agentic-Workflow plötzlich zu beschleunigen. Die Engineer von GitHub erkannten, dass eine 10-fache Erweiterung nicht ausreichen würde. Bis Februar 2026, also nach der schweren Ausfall, kündigte GitHub an, dass es die Architektur auf das 30-fache der heutigen Größe neu entwerfen müsse.

Es geht nicht um eine Erweiterung, sondern um eine Neugestaltung.

Der Unterschied zwischen diesen beiden Begriffen ist sehr groß. Eine Erweiterung bedeutet, dass man die vorhandenen Maschinen vermehrt und den vorhandenen Datenbanken mehr Speicher hinzufügt – die Richtung bleibt die gleiche, nur die Größe wird größer. Eine Neugestaltung bedeutet, dass die vorhandenen Architekturannahmen bei einer 30-fachen Größe systematisch versagen werden, und man muss von Grund auf neu über die Art der Dienstaufteilung, des Datenflusses und der Störungsisolation nachdenken.

Die von GitHub offenbarten konkreten Richtlinien umfassen die Entkopplung kritischer Dienste, um Kaskadenausfälle zu vermeiden, die Einführung eines Gegendruckmechanismus und der Fähigkeit zur Datenflussminderung, die Bereitstellung unabhängiger Hosts für beliebte Dienste, die Beseitigung von Single Points of Failure und eine bessere Änderungsverwaltung – um Operationen wie "Änderung der Cache-TTL von 12 Stunden auf 2 Stunden" zu vermeiden, die ohne ausreichende Stress-Tests direkt in Betrieb gehen.

Es ist bemerkenswert, dass GitHub nicht allein ist.

Stripe hat bereits das Problem der Massenerstellung von Accounts durch AI-Agenten erlebt, AWS baut derzeit ein spezielles Identitätssystem, ein Log-System und ein Produktionssteuerungsmechanismus für Agenten auf. Diese Maßnahmen sind keine Vorsichtsmaßnahmen, sondern es sind bereits Signale auf den Überwachungsdashboards aufgetaucht, die sie zwingen, etwas zu tun.

GitHub war nur der erste, der zerschlagen wurde – weil es sich im Kern der AI-Toolkette befindet.

05 Der Code-Repository wird zum Auspuffrohr der AI

Halten Sie mal an und überlegen Sie sich die Natur dieser ganzen Angelegenheit.

Was ist GitHub? Die direkteste Antwort ist, dass es der Ort ist, an dem Programmierer ihren Code speichern. Aber auf einer tieferen Ebene ist es die Infrastruktur für die menschliche Softwarekooperation – die Commit-Logs sind die Spuren der Zusammenarbeit, die PRs sind die Behälter für die Diskussion, die Issues sind die Aufzeichnungen der Absichten, und die Actions sind die Ausführungsleitungen. Das gesamte System ist auf den Arbeitsrhythmus, den Denkstil und das Kooperationsmuster der Menschen ausgelegt.

AI-Agenten haben all das verändert.

Wenn ein AI-Agent täglich hunderte Male Code committen kann, und hinter jedem "Commit" keine menschliche Überlegung und Abwägung steckt, sondern nur ein Fortschrittsschritt in einer Aufgaben-Schleife – ist der Code-Repository noch ein "Behälter für die Zusammenarbeit"?

Wenn AI-Tools automatisch Repositories erstellen, PRs eröffnen, CI ausführen und mergen – sind die Entwickler noch die Hauptakteure in diesem Prozess, oder sind sie zu "Prüfern" oder sogar "Zuschauern" geworden?

GitHub-CTO hat bei der Beschreibung dieser Krise das Wort "schnelles Wachstum der Last" verwendet. Aber dieses Wort unterschätzt wahrscheinlich die Essenz des Problems – es geht nicht nur um eine quantitative Zunahme, sondern um eine qualitative Veränderung der Nutzungsmethode. Im alten Modell war GitHub ein "Werkzeug für Entwickler"; im neuen Modell wird GitHub zum "Auspuffrohr der AI", einer Ausgabeleitung für automatisierte Workflows.

Was das für GitHub bedeutet, gibt es noch keine Antwort. Eine 30-fache Erweiterung kann das Datenflussproblem lösen, aber nicht die Neudefinition des Geschäftsmodells und auch nicht die Identitätsproblematik "Wer sind meine echten Benutzer".

In letzter Zeit ist ein bemerkenswertes Phänomen aufgetaucht: Nach dem Ausfall hat GitHub eine Vielzahl von Engineering-Blogs veröffentlicht, in denen die grundlegenden Ursachen jeder Störung sehr detailliert beschrieben werden, fast bis zu einem erstaunlichen Maß an Transparenz. Manche denken, dass GitHub damit aktiv Vertrauen aufbauen will, andere meinen, dass es die Transparenz nutzt, um die Geduld der Entwickler-Community zu gewinnen – denn in der kommenden Umbauphase wird es noch mehr Instabilität geben.

Eine Plattform, die von ihrem eigenen Erfolg zerschlagen wird