Featured image of post Auf Menschentempo ausgelegt: Was Anthropics neue Versionskontrolle für die IT-Strategie bedeutet
Copilot & AI

Auf Menschentempo ausgelegt: Was Anthropics neue Versionskontrolle für die IT-Strategie bedeutet

Anthropic ging von 2.500 auf 30.000 Merges pro Tag und baute die Versionskontrolle neu. Was das für Architektur, Review, Identitäten und Controlling heißt.

English

Im Mai 2026 hat Anthropic rund 2.500 Code-Änderungen pro Tag in sein Monorepo gemergt. Im September waren es über 30.000. Git und die Mirror-Infrastruktur drumherum kamen nicht mehr hinterher, also hat ein Team aus sieben Leuten ein eigenes Versionskontrollsystem gebaut und das komplette Monorepo in fünf Monaten migriert (Anthropic Engineering).

Kaum jemand, der das hier liest, wird ein Versionskontrollsystem bauen. Darum geht es bei der Geschichte auch nicht. Jede Organisation hat Prozesse, die auf das Tempo von Menschen ausgelegt sind: Change Advisory Boards, Vier-Augen-Freigaben, Access Reviews, CI-Pipelines, Budgets in Personentagen. Sobald Agents einen großen Teil der Arbeit erledigen, werden genau diese Prozesse zum Engpass. Die Frage ist, welche davon du umbaust, bevor sie brechen.

Kurz gesagt

  • Agents werden zu den Hauptnutzern deiner Systeme. Architekturentscheidungen sollten von Maschinen-Clients ausgehen, die immer online sind und APIs in hoher Frequenz aufrufen.
  • Review und Freigabe müssen weg von „ein Mensch hat alles angesehen“ hin zu Regeln, die festlegen, wo ein Mensch hinsehen muss.
  • Jeder Agent braucht eine Identität, eine verantwortliche Person und eine Kostenstelle. Ohne diese drei kannst du Agentenarbeit weder steuern noch budgetieren.

Was Anthropic tatsächlich geändert hat

In den Schlagzeilen heißt es „Anthropic hat Git rausgeworfen“. Der Engineering-Beitrag selbst ist vorsichtiger. Das neue System heißt Scion, das Review-Werkzeug Antique. Anthropic schreibt ausdrücklich, dass Scion kein allgemeiner Ersatz für Git ist, weil dafür die gesamte Entwicklungs-Toolchain ersetzt werden müsste. Veröffentlicht wurde das Design, damit Git-Plattformen Teile davon übernehmen können.

Warum sie es trotzdem gemacht haben, zeigen die Zahlen. Die Historie des Main-Branch umfasst fast 100 GB, eine komprimierte Arbeitskopie über 25 GB, und die CI zieht rund 25 Millionen Checkouts pro Tag. Git ist für verteilte Clients gebaut, die offline arbeiten. Die Clients bei Anthropic sind fast ausschließlich Agents und Jobs, die immer online sind. Scion verlagert die teure Arbeit auf den Server: Commits, Merges, Rebases, Historie und Blame laufen dort, Clients bekommen schlanke, virtualisierte Checkouts, die Dateien bei Bedarf nachladen, und vieles ist per API ganz ohne lokales Repository nutzbar. Laut Beitrag braucht die neue Infrastruktur etwa 200-mal weniger CPU und Speicher als die alten Git-Mirrors, CI-Checkouts dauern Sekunden statt Minuten.

Drei Entscheidungen aus dem Beitrag sind über Versionskontrolle hinaus relevant:

  1. Es gibt keine Merge Queue mit globalem Lock. Anthropic hat stattdessen in Tests nach dem Merge und vor dem Deployment investiert. Konflikte zwischen parallelen Änderungen kommen vor, und Claude behebt sie meist schneller, als ein Mensch sie bemerken würde.
  2. Antique kann semantische Regeln für Freigaben abbilden. Eine Änderung nur an Kommentaren wird anders behandelt als eine Änderung an sensibler Logik, damit menschliche Reviewer ihre Zeit dort verbringen, wo es zählt.
  3. Zugriffssteuerung auf Repository- und Verzeichnisebene war von Anfang an eingebaut, nicht nachträglich ergänzt.

Agents sind die neuen Hauptnutzer

Die erste Lehre betrifft die Architektur. Die meisten Unternehmenssysteme gehen von einem Menschen vor einem Bildschirm aus. Agents verhalten sich anders: Sie pollen, sie laufen parallel, und Mittagspause machen sie auch keine.

In Microsoft 365 sieht man das heute schon am Throttling von Microsoft Graph. Microsoft nennt zwei typische Ursachen: viele Anfragen über alle Anwendungen eines Tenants hinweg und viele Anfragen einer Anwendung über alle Tenants hinweg. Regelmäßiges Abfragen einer Ressource und wiederholtes Durchsuchen von Collections werden ausdrücklich als Muster genannt, die zu Throttling führen. Empfohlen werden stattdessen Delta Queries und Change Notifications, für große Datenmengen verweist Microsoft auf Graph Data Connect statt der REST-APIs (Microsoft Learn). SharePoint Online geht noch einen Schritt weiter: Eine Anwendung, die Limits dauerhaft überschreitet, kann komplett blockiert werden (Microsoft Learn).

Diese Hinweise wurden für Integrationsentwickler geschrieben. Inzwischen gelten sie für jeden Agent, der im Auftrag von jemandem Postfächer, Sites oder Teams-Kanäle liest. Wenn ich ein Agent-Szenario bewerte, frage ich deshalb zuerst, wie es Änderungen erkennt, und erst danach, was es tut. Ein Agent, der alle zehn Minuten eine Dokumentbibliothek komplett durchsucht, läuft im Pilot einwandfrei und wird zum Problem, wenn 40 Abteilungen ihn kopieren.

Für eigene Systeme gilt dasselbe in umgekehrter Richtung. Wenn Agents die Hauptnutzer einer internen Plattform werden, braucht sie eine ordentliche API, Change Feeds und Limits pro Client. Eine Weboberfläche mit einem Scraping-Agent davor ist der Git-Mirror deiner Organisation: Sie funktioniert, bis das Volumen sich verzehnfacht.

Review nach Absicht statt Zeile für Zeile

Die zweite Lehre betrifft Kontrollprozesse. Das Team bei Anthropic prüft weiterhin jede Änderung, aber es prüft die Absicht und nicht jede Zeile. Ihre wichtigste Aufgabe ist nach eigener Beschreibung, Claude „Nein“ zu sagen: wenn Systemgrenzen verletzt werden oder Claude wegen hypothetischer Bedenken überkonstruiert.

In regulierten Umgebungen ist das der unbequeme Teil. Viele Change-Prozesse versprechen implizit, dass eine qualifizierte Person alles geprüft hat. Bei 30.000 Änderungen am Tag lässt sich dieses Versprechen nicht halten, und ehrlich gesagt wurde es oft schon bei 30 pro Woche nicht gehalten. Das CAB, das in 45 Minuten einen Stapel Changes durchwinkt, prüft vor allem, ob das Formular vollständig ist.

Nach meiner Erfahrung wollen Auditoren Belege dafür sehen, dass Änderungen kontrolliert und nachvollziehbar sind. NIS2 verlangt Risikomanagementmaßnahmen, zu denen auch Sicherheit bei Entwicklung und Wartung gehört; dass ein Mensch jede Zeile liest, schreibt die Richtlinie nicht vor. Damit bleibt Raum für ein Modell, das ITIL als Standard Changes kennt, angewendet auf die Arbeit von Agents:

  • Geringes Risiko (Dokumentation, Tests, Formatierung, Konfiguration innerhalb definierter Leitplanken): automatische Prüfungen, kein verpflichtendes menschliches Review, vollständige Protokollierung.
  • Mittleres Risiko (Geschäftslogik, Integrationen): menschliches Review von Absicht und Testnachweisen, mit der Zusammenfassung des Agents als Grundlage.
  • Hohes Risiko (Authentifizierung, Berechtigungen, Datenflüsse über Vertrauensgrenzen, alles Regulierte): Review Zeile für Zeile durch eine benannte Person, wie bisher.

Was über die Stufe entscheidet, muss eine Regel sein und kein Bauchgefühl. Anthropic bildet das im Review-Werkzeug ab, du kannst es in Branch Protection Rules, CODEOWNERS-Dateien oder einem Genehmigungsflow in Power Automate abbilden. Die Regel selbst ist die Kontrolle, die ein Auditor sehen will.

Bei einem Teil des Anthropic-Ansatzes wäre ich vorsichtig: Prüfungen hinter den Merge zu verlegen. Für eine interne Entwicklerplattform ist das ein vertretbarer Tausch. Für ein System in einer KRITIS-Umgebung, bei dem eine fehlerhafte Änderung direkt in Produktion landen kann, würde ich das nicht machen. Die Absicherung muss vor dem Deployment sitzen, auch wenn sie nicht mehr vor dem Merge sitzt.

Jeder Agent braucht eine Identität und einen Verantwortlichen

Anthropic hat die Zugriffssteuerung in Scion vom ersten Tag an eingebaut, bis auf Verzeichnisebene. In Microsoft 365 entspricht dem die Identitätsschicht für Agents. Microsoft Entra Agent ID gibt Agents eigene Identitäten im Verzeichnis, erzeugt aus Agent Identity Blueprints. Jede Agent-Identität braucht einen menschlichen Sponsor, der für Zweck, Lebenszyklus und Access Reviews verantwortlich ist. Verlässt der Sponsor das Unternehmen, geht die Verantwortung auf seine Führungskraft über. Conditional Access und Access Packages aus dem Entitlement Management gelten auch für Agents (Microsoft Learn). Stand Oktober 2026 ist Identity Governance für Agents als Preview gekennzeichnet, und die Lizenzierung hängt an Microsoft 365 E7 oder Agent 365. Prüf die aktuellen Bedingungen, bevor du damit planst.

Darüber liegt in Microsoft Agent 365 die Registry als gemeinsames Inventar für Microsoft- und Fremd-Agents, inklusive der Anzahl an Agents ohne Besitzer (Microsoft Learn). Die Governance-Seite habe ich ausführlicher im Beitrag zum Agent Lifecycle beschrieben.

Strategisch heißt das: Ein Agent, der unter einem geteilten Dienstkonto oder mit den delegierten Rechten einer Person läuft, lässt sich im Audit-Log nicht unterscheiden, nicht separat drosseln und nicht separat abrechnen. Das später für Hunderte Agents nachzuziehen, ist genau die Art Projekt, für die niemand Budget freigibt.

Agentenarbeit messen

Beim Budget bricht es an derselben Stelle. Das Controlling rechnet in den meisten IT-Organisationen noch in Personentagen, und für Agentenarbeit gibt es in diesem Modell keine Zeile. Ein praktikabler Weg ist, Agent-Sitzungen über ein AI Gateway zu leiten. Dann lässt sich jedes Token und jede Stunde Laufzeit einem Projekt und einem Repository zuordnen und mit echten Preisen bewerten.

Ein Feature, das letztes Jahr 20 Tage gebraucht hat und dieses Jahr 3 Tage Review plus Agentenlaufzeit, passt nicht in dieses Modell. Agentenstunden zu zählen ist ein Anfang, aber Stunden sind eine Input-Kennzahl. Wissen willst du die Kosten pro akzeptierter Änderung: Tokens und Laufzeit plus die menschliche Zeit für Review, Nacharbeit und die Fälle, in denen jemand „Nein“ sagen musste. Ohne den menschlichen Anteil sieht Agentenarbeit billiger aus, als sie ist.

Für Microsoft-Agents sammelt die Observability in Agent 365 Aktivitätsdaten und soll Kennzahlen wie Nutzung und Zeitersparnis liefern (Microsoft Learn). Das deckt einen Teil des Bildes ab. Coding-Agents außerhalb von Microsoft 365 brauchen eine eigene Zuordnung, und dort kommt der Gateway-Ansatz ins Spiel.

Entscheidungen für die nächsten zwölf Monate

Anthropic erwartet, dass andere Organisationen in den nächsten sechs bis zwölf Monaten auf diese Art Problem stoßen. Auch wenn dein Zeitplan länger ist, diese Entscheidungen würde ich jetzt treffen:

  1. Menschlich getaktete Kontrollen erfassen. Liste jede Freigabe, jedes Review und jeden Pipeline-Schritt auf, der von einer Person und einem Arbeitstag ausgeht. Markiere, was beim zehnfachen Volumen bricht.
  2. Risikostufen für Änderungen einführen. Schreib auf, welche Änderungen einen Menschen brauchen, welche nur eine Prüfung der Absicht und welche nur Protokollierung. Mach die Regel maschinenlesbar.
  3. Agents eigene Identitäten geben. Keine geteilten Dienstkonten, jeder Agent mit Sponsor, Berechtigungen über Access Packages mit Ablaufdatum.
  4. Integrationen für Maschinen-Clients auslegen. Delta Queries, Change Notifications und API-Budgets statt Polling und Scraping.
  5. Agentenkosten zuordnen. Tokens und Laufzeit pro Projekt plus die menschliche Review-Zeit, ab dem ersten produktiven Agent.

Was ich nicht tun würde: Anthropics Werkzeuge nachbauen. Deren Problem waren 25 Millionen Checkouts am Tag. Deins ist wahrscheinlicher ein Change-Prozess, der zwei Wochen für eine Konfigurationsänderung braucht, die ein Agent in zehn Minuten vorbereitet hat. Dort fängst du an.

Quellen