Alle 388 PRs wurden vollständig von KI erstellt, 180 davon wurden bereits zusammengeführt. Der Vater von Claude: Den Programmierern bleibt nichts anderes übrig als zu unterschreiben.

388 PRs, davon 180 zusammengeführt.

All dieser Code wurde vollständig von KI geschrieben.

Boris Cherny, der Schöpfer von Claude, hat kürzlich diese Zahlen auf X veröffentlicht. Sie stammen aus einem „seltsamen Experiment“, das er in den letzten Wochen durchgeführt hat: Er ließ Claude die tägliche Wartung seiner eigenen App übernehmen.

Er sagt, dass einige frühe Anzeichen darauf hindeuten, dass dieser Weg tatsächlich funktionieren könnte.

Der Ort des Experiments ist ein Slack-Kanal namens „proj-claude-maintains-apps“.

In diesem Kanal führt Claude Tag täglich eine Reihe von Routineaufgaben aus, die sechs Umgebungen abdecken: iOS, Android, Desktop, Web, CLI und Agent SDK. Jede Zeile hat eine eigene unabhängige Routine, und der Fortschritt wird jeweils im obersten Thread des Kanals veröffentlicht.

Es verhält sich wie ein echter Kollege: Es wartet nicht darauf, dass ihm Aufgaben zugewiesen werden, sondern beginnt pünktlich mit der Arbeit, findet Probleme, ändert den Code, erstellt PRs und wartet dann auf die Überprüfung durch Menschen.

Ein geschlossener Kreislauf aus regelmäßigem Erkennen von Problemen, Einreichen von Änderungen, Akzeptieren von Überprüfungen und Anpassen der Aufgabenregeln an das Feedback läuft bei Anthropic bereits seit mehreren Wochen.

Das Einzige, was die Ingenieure noch tun müssen, ist die Entscheidung zu treffen, ob die PR zusammengeführt werden soll.

Claude erledigt täglich die lästigen Arbeiten

Welche Aufgaben hat Boris Claude zugewiesen? Sehen wir uns zuerst die Liste an.

Prüfung auf Abstürze.

Man öffnet die App im Simulator und klickt wahllos herum, bis sie abstürzt, dann lokalisiert man die Ursache und erstellt eine Reparatur-PR. Jede PR muss zudem die Schritte zur Reproduktion und eine Wahrheitstabelle enthalten.

Boris hat in die ursprünglichen Anweisungen für Claude extra einen Satz geschrieben: Es muss die echte App ausgeführt werden, keine gefälschte Ersatzlösung darf zur Täuschung verwendet werden.

Wiederholte Abstraktion und Zusammenführung. Scannen Sie die Implementierungen im Code-Repository, die ähnlich aber nicht vollständig identisch sind, und erstellen Sie PRs, um sie zu einer einzigen zusammenzufassen.

Bereinigung von totem Code. Diese Aufgabe erfordert das meiste Können: Code, der statisch nachweislich nie ausgeführt wird, wird direkt gelöscht; bei Code, der nur „vermutlich“ nie ausgeführt wird, wird zuerst ein Protokoll eingefügt, um einen Tag lang zu beobachten. Wenn bestätigt ist, dass er nie aufgerufen wird, wird er am nächsten Tag gelöscht.

Behebung von Abstraktionslecks. Wenn eine Ebene offengelegt wird, die nicht sichtbar sein sollte, wird sie von Claude repariert.

Weitere Aufgaben: Entfernen von Tests, die unter allen Umständen bestehen, Aufspüren der Ursache von zeitweise fehlschlagenden Tests, Entfernen der Schalter für die vollständige Produktivsetzung aus dem Code, sowie Entscheidung über die Veröffentlichung oder Löschung von vergessenen internen Funktionen anhand ihrer Nutzungshäufigkeit.

Zuerst ein Protokoll hinzufügen, einen Tag beobachten und dann löschen – das ist das Gespür, das nur erfahrene Ingenieure haben.

Wenn man diese Liste von Anfang bis Ende durchgeht: Keine der elf Aufgaben, die Claude übernommen hat, besteht darin, „etwas Neues zu erstellen“.

Es handelt sich ausschließlich um Arbeiten, die man normalerweise am wenigsten gerne erledigt, die nach Abschluss keine Leistungsnachweise bringen und die man auch auf das nächste Quartal verschieben kann, ohne dass jemand danach fragt.

Wenn das Schreiben von Code billiger wird, wird die Code-Überprüfung teurer

Wer soll 388 KI-generierte PRs prüfen, die einem Team innerhalb weniger Wochen entstehen?

Anthropic hat in seiner Ankündigung zur Code-Überprüfung im März dieses Jahres eine Zahl genannt: Im vergangenen Jahr ist der durchschnittliche Code-Ausstoß pro Mitarbeiter um 200 % gestiegen, wodurch die Code-Überprüfung zu einem Engpass geworden ist.

Und dies ist nicht nur ein Problem von Anthropic.

Die Ingenieurdatenplattform Faros AI hat 2026 einen Bericht veröffentlicht, der auf zweijährigen Telemetriedaten basiert und 22.000 Entwickler sowie mehr als 4000 Teams abdeckt.

Faros AI „The Acceleration Whiplash“: Bei hoher KI-Adoptionsrate steigt die Anzahl der abgeschlossenen Epics pro Mitarbeiter um 66,2 %, während die Anzahl der wöchentlichen Bereitstellungen um 11,7 % sinkt.

Auf der Ausgabenseite gibt es tatsächlich einen Anstieg: Die Anzahl der abgeschlossenen Epics pro Mitarbeiter steigt um 66,2 %, der Aufgaben-Durchsatz um 33,7 % und die PR-Zusammenführungsrate um 16,2 %.

Aber die Anzahl der tatsächlich wöchentlich in die Produktivumgebung bereitgestellten Versionen sinkt um 11,7 %.

Es werden mehr PRs zusammengeführt, aber weniger davon veröffentlicht. Der gesamte Zwischenschritt ist durch den Überprüfungsprozess blockiert.

Die Kosten müssen die Entwickler tragen.

Die Anzahl der Fehler pro Entwickler steigt um 54 %;

Die Anzahl der Produktivausfälle pro PR steigt um 242,7 %; der Anteil des Codes, der nach der Zusammenführung wieder gelöscht wird, steigt um 861 %; die durchschnittliche Größe einer PR steigt um 51,3 %;

Das Schlimmste ist die Wartezeit.

Die mittlere Wartezeit auf eine Überprüfung steigt um 441,5 %, und weitere 31 % der PRs werden zusammengeführt, ohne jemals eine Überprüfung durchlaufen zu haben.

Zusammengenommen ergeben diese Zahlen den typischen Arbeitstag eines Entwicklers: Mit einem Klick werden innerhalb von fünf Minuten Tausende von Codezeilen generiert; dann verbringt er den ganzen Nachmittag damit, diese Tausenden von Zeilen Zeile für Zeile durchzulesen.

Der Teil des Code-Schreibens wurde von der KI übernommen, aber der Teil des Code-Lesens muss weiterhin von Entwicklern erledigt werden.

Die Code-Überprüfung wurde genau für dieses Problem entwickelt. Anthropic hat eine Reihe von Zahlen zu Effekten und Kosten veröffentlicht:

Vor der Produktivsetzung erhalten nur 16 % der PRs sinnvolle Überprüfungsbemerkungen, nach der Produktivsetzung sind es 54 %.

Bei großen PRs mit mehr als 1000 Zeilen werden bei 84 % Probleme erkannt, durchschnittlich 7,5 Stück. Bei kleinen Änderungen mit weniger als 50 Zeilen sinkt dieser Anteil auf 31 %, durchschnittlich 0,5 Stück.

Weniger als 1 % der von Ingenieuren markierten Fehler werden als „falsch identifiziert“ eingestuft.

Die Überprüfung einer PR dauert durchschnittlich 20 Minuten und verbraucht Tokens im Wert von 15 bis 25 US-Dollar.

In dieser Ankündigung wird außerdem erwähnt: Dieses System genehmigt keine PRs, die Genehmigung ist Aufgabe des Menschen.

Die festgelegte Grenze lautet: Die KI kann aktiv Probleme finden, Code ändern und PRs erstellen, ohne dass der gesamte Prozess von Menschen genehmigt werden muss. Aber jede Änderung verbleibt in der PR. Ob sie in den Hauptzweig zusammengeführt und in die Produktivumgebung übernommen wird, muss am Ende unbedingt von einer Person bestätigt werden.

Boris hat in seinem Beitrag den nächsten Schritt geschrieben: Er will Wege finden, die Kosten für die Zusammenführung solcher mechanischen Änderungen zu senken.

Die Kosten, die er senken will, sind die Kosten der Zusammenführung, da der Engpass nicht mehr bei der Generierung liegt.

Boris repariert nicht die PRs, sondern die Routinen

Sehen wir uns an, wie dieses System aufgebaut ist: Die drei Komponenten sind klar voneinander getrennt.

Claude Tag ist die Eingangsschnittstelle. Es ist im Slack-Kanal eingebunden, reagiert, wenn es erwähnt wird, und übernimmt auch aktiv Aufgaben im Rahmen der erlaubten Berechtigungen und Anweisungen.

Anthropic hat es am 13. August gerade aktualisiert, sodass es den Kontext des gesamten Kanals berücksichtigt, um zu beurteilen, wann es eingreifen soll und wann es nichts tun soll.

Routinen (Routineaufgaben) sind die Ausführungsebene.

Dies ist eine Funktion, die am 14. April eingeführt wurde: Man konfiguriert einmal die Prompts, das Code-Repository und die Konnektoren, danach läuft sie nach Zeitplan, wird durch API-Aufrufe ausgelöst oder startet automatisch als Reaktion auf GitHub-Ereignisse.

Sie läuft auf der Cloud-Infrastruktur von Claude Code und ist nicht von lokalen Geräten abhängig.

Funktionsweise von Claude Code Routinen: Drei Auslösemethoden – Zeitsteuerung, API-Aufruf und GitHub-Ereignisse – die in der Cloud ausgeführt werden.

Claude Code Review ist die Überprüfungsebene, und Menschen sind die Genehmigungsebene.

Erst wenn diese vier Ebenen verbunden sind, entsteht der Kanal, der jeden Morgen automatisch mit der Arbeit beginnt.

Aber das Wertvollste, was man lernen kann, ist Boris' Methode der Optimierung.

Wenn eine bestimmte Art von PR ständig nicht besteht, korrigiert er nicht jede einzelne fehlgeschlagene PR, sondern kehrt zurück, um die Routine zu ändern, die sie generiert hat, und beobachtet dann das Verhalten in den folgenden Tagen.

Manchmal muss eine bestimmte Art von Aufgabe mehrere Tage lang nacheinander optimiert werden, bis sie stabil läuft.

Zusammengefasst: Nicht das Ergebnis reparieren, sondern die Regel.

Prompts sind hier keine einmaligen Eingaben mehr, sondern ein Vermögenswert, der langfristig gewartet werden muss: Schreiben, Inbetriebnahme, Beobachten, Iterieren – es ist genau so, wie einen Onlinedienst zu betreiben.

Das ist auch der Grund, warum dieses System immer reibungsloser läuft.

Jede Anpassung wird in die Regeln aufgenommen, sodass in der nächsten Charge von PRs am nächsten Tag einige unnötige Fälle weniger auftreten.

Wenn Sie das System nachbauen wollen, müssen Sie diese Hürden überwinden

Die Werkzeuge sind öffentlich zugänglich.

Routinen sind für die Tarife Pro, Max, Team und Enterprise verfügbar: Pro erlaubt 5 Routinen pro Tag, Max 15, Team und Enterprise 25. Man kann sie mit wenigen Klicks in claude.ai/code erstellen oder im CLI den Befehl /schedule eingeben.

Aber die eigentlichen Hürden liegen woanders:

Wie weit Sie die Berechtigungen für das Repository freigeben können, ob die Testabdeckung ausreicht, ob Sie eine Simulatorumgebung mit echten Geräten betreiben können, ob Sie die Kosten für die Überprüfung pro Aufgabe tragen können – und das Schwierigste: Ob es jemanden gibt, der bereit ist, den Zusammenführen-Knopf für eine von der KI eingereichte PR zu drücken.

Diesen Monat hat das Rust-Projekt ebenfalls Regeln für KI-Beiträge aufgestellt: KI-generierter Code muss im Voraus angekündigt werden, darf keine kritischen Pfade berühren, muss ausreichend getestet werden, und die Nutzung von großen Sprachmodellen muss ehrlich offengelegt werden. Kritische Änderungen, die die Korrektheit des Codes betreffen, werden nachdrücklich nicht zur Generierung durch große Sprachmodelle empfohlen.

Am wichtigsten ist: Die Betreuer sind nicht verpflichtet, von KI eingereichte PRs zu überprüfen, und können sie direkt schließen.

Die einzelne Entwickler können sich aus Boris' Experiment genau diese Regel abschauen: Übergeben Sie zuerst die Aufgaben mit den klarsten Akzeptanzkriterien an die KI.

Aufgaben, bei denen man überprüfen kann, ob sie richtig oder falsch sind, kann die KI jetzt bewältigen: Ob diese Aktion die App zum Absturz bringt, ob zwei Code-Schreibweisen dasselbe tun, ob dieser Test niemals fehlschlägt – all das kann sofort überprüft werden.

Aufgaben, bei denen man nicht klar sagen kann, was als „richtig“ gilt, kann die KI noch nicht bewältigen: „Ist diese Abstraktionsebene übermäßig gestaltet?“, „Ist die Richtung dieser Umgestaltung richtig?“ – die Akzeptanzkriterien hängen vollständig von subjektiver Beurteilung ab und lassen sich nicht in Prompts schreiben.

Deshalb hat sie als erste Aufgaben nicht die kreative Arbeit übernommen, sondern die Reinigungsarbeit.