Das Wichtigste in Kürze

  • Laut dem Claude-Code-Team von Anthropic schreibt Claude rund 90 Prozent des Codes von Claude Code selbst.
  • Von Juni bis September 2026 haben sich die zusammengeführten Änderungen mehr als verdoppelt, die Rückläuferquote fiel um über 40 Prozent.
  • Der Review läuft mehrschichtig: zuerst breite automatische Prüfungen, dann tiefe Analyse, menschliche Zeit nur für die wichtigsten Entscheidungen.
  • Die vollständige Beschreibung steht kostenlos im offiziellen Blog auf claude.dev, inklusive Regeln wie You land it, you own it.

Kurzüberblick

TypBlogbeitrag über KI-gestützten Code-Review
GerätePC- und Smartphone-Browser
KostenBlog kostenlos lesbar, Claude Code separat
SprachenEnglisch; weitere Sprachen auf der Seite prüfen
Highlight90 % KI-Code, doppelte Merges, 40 % weniger Rückläufer
Einstiegclaude.dev öffnen, Blog lesen, Prozess testen
KategorieTech-Trends
UrheberClaudeDevs
Offizielle Seiteclaude.dev ↗
Trend-Index🔥 1,8 Mio. Trend-Index
Zuletzt aktualisiert

Was Anthropic mit den 90 Prozent wirklich sagt

Das Claude-Code-Team von Anthropic hat in einem offiziellen Blogbeitrag beschrieben, dass Claude inzwischen etwa 90 Prozent des Codes von Claude Code schreibt. Claude Code ist der KI-Programmierassistent des Unternehmens, der Entwicklerinnen und Entwickler im Terminal und im Editor unterstützt. Die Aussage ist bemerkenswert, weil sie nicht von einem externen Beobachter stammt, sondern vom eigenen Team, das das Produkt täglich weiterentwickelt.

Die Zahlen, die das Team nennt, beziehen sich auf den Zeitraum von Juni bis September 2026. In diesen Monaten haben sich die zusammengeführten Änderungen, also die akzeptierten und eingebauten Beiträge, mehr als verdoppelt. Gleichzeitig sank die Quote der Änderungen, die zurückgewiesen oder zurückgerollt werden mussten, um mehr als 40 Prozent. Beide Entwicklungen zusammen deuten darauf hin, dass mehr Code schneller akzeptiert wurde, ohne dass die Qualität darunter litt.

Der Beitrag ist kein reines Produktmarketing, sondern eine Prozessbeschreibung. Er erklärt, wie das Team den Code-Review umgebaut hat, damit Menschen bei dieser Menge an KI-generiertem Code nicht zum Flaschenhals werden. Genau deshalb wird das Thema gerade breit diskutiert: Viele Teams fragen sich, ob sie ähnliche Abläufe übernehmen können.

  • Offizielle Quelle

    Die vollständige Beschreibung steht im Blog auf claude.dev. Dort findest du auch einen Einstieg zu Claude Code.

  • Kernaussage

    Claude schreibt rund 90 Prozent des Codes von Claude Code, während Merges steigen und Rückläufer sinken.

  • Warum das zählt

    Es zeigt, wie ein Team Review-Prozesse anpassen kann, wenn KI den Großteil des Codes liefert.

So funktioniert der mehrschichtige Review-Prozess

Der zentrale Gedanke ist, Review nicht als einzelne Prüfung zu behandeln, sondern als Abfolge von Schichten. Zuerst laufen breite automatische Prüfungen, die möglichst viele Änderungen abdecken und offensichtliche Fehler früh herausfiltern. Erst danach folgt eine tiefe inhaltliche Analyse, die sich auf Logik, Architektur und Risiken konzentriert. Menschliche Reviewer kommen erst am Ende ins Spiel und verbringen dort nur die minimale Zeit, die nötig ist, um Rückläufer und Vorfälle zu vermeiden.

Ein weiterer Baustein ist die Verfolgung des gesamten Lebenszyklus einer Änderung. Das Team betrachtet nicht nur den Moment des Merges, sondern auch, was danach passiert: ob etwas zurückgerollt wird, ob Fehler auftreten, ob Nacharbeit nötig ist. Diese Rückmeldungen fließen zurück in die automatischen Prüfungen und in die Schulung des Reviewers, sodass der Prozess mit jeder Änderung etwas besser wird.

Dazu kommt die Regel You land it, you own it. Wer eine Änderung einbaut, bleibt dafür verantwortlich, auch wenn die KI den Code geschrieben hat. Diese Klarheit verhindert, dass Verantwortung zwischen Automatisierung und Team verschwimmt. Zusätzlich teilt das Team Kontext systematisch, damit Reviewer nicht bei jedem Beitrag von null anfangen müssen.

  • Schicht eins

    Automatische Prüfungen mit hoher Abdeckung fangen einfache Fehler ab, bevor Menschen Zeit investieren.

  • Schicht zwei

    Die tiefe Analyse prüft Logik und Architektur dort, wo Automatik nicht ausreicht.

  • Menschliche Schicht

    Menschen konzentrieren sich auf wenige kritische Entscheidungen statt auf jede Zeile.

  • Verantwortung

    You land it, you own it macht klar, wer nach dem Merge für eine Änderung geradesteht.

So führst du den Ansatz im eigenen Team ein

Der Blogbeitrag enthält einen eigenen Abschnitt dazu, wie man den Prozess übernimmt. Der naheliegende erste Schritt ist, die Regel You land it, you own it auf den nächsten Pull Request anzuwenden und zu beobachten, wie sich Diskussionen verändern. Danach lohnt es sich, die Review-Schichten explizit zu trennen: erst Automatik, dann Tiefenanalyse, dann menschliche Freigabe.

Wichtig ist, den Prozess nicht blind zu kopieren, sondern an die eigene Codebasis anzupassen. Ein Team mit vielen kleinen Änderungen braucht andere Schwellenwerte als eines mit seltenen, großen Umbauten. Beobachte Rückläuferquote und Vorfälle über mehrere Wochen, bevor du Schlüsse ziehst. Die im Beitrag genannten Zahlen stammen aus einem bestimmten Zeitraum und einem bestimmten Team und sind kein garantierter Effekt für jede Umgebung.

Für alle, die Claude Code selbst ausprobieren wollen, gibt es auf der offiziellen Seite einen Einstieg. Ob und welche Kosten dabei entstehen, hängt vom jeweiligen Plan ab und sollte direkt auf der Seite geprüft werden. Der Blogbeitrag selbst ist ohne Anmeldung lesbar und dient als Ausgangspunkt, bevor du Änderungen an deinem eigenen Review-Prozess vornimmst.

  • Klein anfangen

    Teste die Ownership-Regel zuerst bei einem einzelnen Pull Request, bevor du den ganzen Prozess umstellst.

  • Messen statt raten

    Verfolge Rückläufer und Vorfälle über Wochen, um zu sehen, ob der Ansatz bei dir wirkt.

  • Kontext teilen

    Dokumentiere Entscheidungen so, dass Reviewer und KI-Prüfungen denselben Hintergrund kennen.

Was das für Teams, Tools und den Arbeitsmarkt bedeutet

Die Offenlegung ist Teil eines größeren Trends: KI-Assistenten übernehmen immer mehr Routinearbeit im Programmieren, während Menschen stärker steuern, prüfen und Verantwortung tragen. Für Entwicklerinnen und Entwickler verschiebt sich der Schwerpunkt vom Schreiben jeder Zeile hin zum Bewerten von Vorschlägen und zum Setzen von Rahmenbedingungen. Wer Review-Prozesse gut gestalten kann, wird dadurch eher wichtiger als unwichtiger.

Für Teams bedeutet das, dass Werkzeuge und Regeln zusammenpassen müssen. Automatische Prüfungen, klare Ownership und geteilter Kontext sind keine neuen Erfindungen, aber ihre Kombination wird entscheidend, wenn der Großteil des Codes von einer KI stammt. Vergleiche mit anderen KI-Programmierassistenten sind naheliegend, doch die genauen Zahlen lassen sich nicht einfach übertragen, weil jedes Team anders arbeitet.

Offene Fragen bleiben: Wie gut funktioniert der Ansatz in stark regulierten Branchen, in großen Legacy-Codebasen oder in Teams mit wenig Review-Kapazität? Der Beitrag liefert einen Erfahrungsbericht, keine allgemeingültige Garantie. Wer den Prozess übernehmen will, sollte die Angaben auf der offiziellen Seite prüfen und die eigenen Ergebnisse ehrlich messen, bevor daraus ein Standard wird.

  • Rollenverschiebung

    Menschen prüfen und steuern stärker, statt jede Zeile selbst zu schreiben.

  • Nicht blind übertragen

    Die genannten Zahlen gelten für ein Team und einen Zeitraum, nicht für jede Umgebung.

  • Offizielle Seite prüfen

    Details zu Claude Code und möglichen Kosten stehen auf claude.dev und können sich ändern.

Schritt-für-Schritt-Anleitung

  1. Offiziellen Blog öffnen

    Rufe claude.dev im Browser auf PC oder Smartphone auf. Der Beitrag ist ohne Anmeldung und ohne App lesbar. Verschaffe dir zuerst einen Überblick über die Abschnitte, bevor du in die Details gehst.

  2. Kernabschnitte lesen

    Arbeite die Abschnitte von der Neubewertung des Review-Zwecks über die Schichten bis zu den menschlichen Eingriffspunkten durch. Notiere dir Begriffe wie Layer by layer und You land it, you own it, weil sie die Logik des Prozesses tragen.

  3. Eigene Situation vergleichen

    Überlege, wie viele Änderungen dein Team pro Woche zusammenführt und wie oft etwas zurückgerollt wird. Diese beiden Werte sind der Ausgangspunkt, um zu beurteilen, ob der beschriebene Ansatz zu dir passt.

  4. Erste Regel testen

    Wende You land it, you own it auf den nächsten Pull Request an und beobachte, wie sich die Diskussion verändert. Achte darauf, ob Verantwortlichkeiten klarer werden oder ob zusätzliche Abstimmung nötig ist.

  5. Schichten einführen und messen

    Trenne automatische Prüfungen, Tiefenanalyse und menschliche Freigabe bewusst voneinander. Verfolge danach über mehrere Wochen Merges, Rückläufer und Vorfälle, bevor du den Prozess dauerhaft übernimmst.

Häufige Fragen

Was genau bedeutet die Aussage, dass Claude 90 Prozent des Codes schreibt?

Laut dem Claude-Code-Team von Anthropic verfasst Claude rund 90 Prozent des Codes von Claude Code selbst. Das heißt nicht, dass niemand mehr prüft oder entscheidet, sondern dass der überwiegende Teil der Codeänderungen von der KI erzeugt wird. Menschen bleiben über Review, Freigabe und Verantwortung eingebunden.

Wo kann ich den vollständigen Beitrag lesen und was kostet das?

Der Beitrag steht im offiziellen Blog auf claude.dev und ist dort kostenlos lesbar. Eine Anmeldung oder App ist für das Lesen nicht nötig. Für die Nutzung von Claude Code selbst können je nach Plan Kosten entstehen, die du direkt auf der offiziellen Seite prüfen solltest.

Was bedeuten die Zahlen zu Merges und Rückläufern konkret?

Zwischen Juni und September 2026 haben sich die zusammengeführten Änderungen mehr als verdoppelt. Im selben Zeitraum sank die Quote der zurückgewiesenen oder zurückgerollten Änderungen um mehr als 40 Prozent. Diese Werte beschreiben die Erfahrung eines Teams in einem bestimmten Zeitraum und lassen sich nicht automatisch auf andere Projekte übertragen.

Kann ich den Review-Ansatz in meinem eigenen Team übernehmen?

Ja, der Beitrag enthält einen eigenen Abschnitt zur Einführung. Sinnvoll ist ein schrittweiser Start: zuerst die Ownership-Regel testen, dann die Review-Schichten trennen und schließlich Ergebnisse über mehrere Wochen messen. Passe Schwellenwerte an deine Codebasis an, statt Zahlen ungeprüft zu übernehmen.

Ist der Ansatz auch für regulierte Branchen oder große Altprojekte geeignet?

Der Beitrag ist ein Erfahrungsbericht und keine allgemeingültige Garantie. In stark regulierten Umgebungen oder großen Legacy-Codebasen können zusätzliche Prüfpflichten und längere Freigabewege den Ablauf verändern. Prüfe die Angaben auf der offiziellen Seite und teste den Prozess zunächst in einem begrenzten Bereich.