Anthropic hat ein neues Multi-Agent-System für automatisierte Code-Reviews vorgestellt, das Entwicklerinnen und Entwickler insbesondere beim Prüfen von durch KI erzeugten Pull Requests (PRs) entlasten soll. Es steht als Research-Preview für Team- und Enterprise-Kunden bereit.

Wie Anthropic im Blog beschreibt, startet das Tool bei Eröffnung eines Pull Request mehrere Agenten, die parallel unterschiedliche Aufgaben abarbeiten. Die einen suchen gezielt nach logischen Fehlern, andere verifizieren die Funde, um False Positives herauszufiltern. Ein finaler Agent aggregiert die Ergebnisse, entfernt Duplikate und priorisiert die gefundenen Probleme nach Schweregrad. Das Tool nutzt dabei die Modelle der Claude-4-Serie, darunter Claude Sonnet 4 und Sonnet 4.6, die sich über CLI bedienen lassen.

Das System skaliert mit der Größe der PRs: Ab tausend geänderten Zeilen setzt Code Review mehr Agenten ein und analysiert den gesamten Codebasis-Kontext. Bei kleineren Aufgaben beschränkt es sich auf einen einfachen Durchlauf. Im Schnitt dauert eine Analyse laut Anthropic rund zwanzig Minuten. Intern hat die Firma das System bereits seit Monaten im Einsatz: Vor der Einführung des KI-Reviews erhielten dort nur 16 Prozent der PRs substanzielle Review-Kommentare, mit KI 54 Prozent. Bei großen PRs liegt die Quote nun sogar bei 84 Prozent, mit durchschnittlich 7,5 gefundenen Problemen. Die False-Positive-Rate gibt Anthropic mit unter einem Prozent an – gemessen daran, wie oft Entwickler einen Fund als falsch markierten.

Actions als Open-Source weiter verfügbar

Die Abrechnung erfolgt tokenbasiert. Im Durchschnitt veranschlagt Anthropic ein Review mit 15 bis 25 US-Dollar, die bisherigen, alternativen Open-Source-Actions auf GitHub will Anthropic weiterhin anbieten. Administratoren erhalten ein Dashboard mit einer Übersicht von überprüften PRs, Akzeptanzraten und Kosten sowie der Möglichkeit, monatliche Obergrenzen festzulegen.

Der Output von Code ist mit künstlicher Intelligenz stark angestiegen, sodass das Sichten in vielen Unternehmen, aber auch in Open-Source-Projekten, zum Engpass wird. Anthropic spricht beispielsweise von einer Zunahme von 200 Prozent mehr Output pro Entwickler im vergangenen Jahr.

(who)

In vielen Softwareteams läuft die Entwicklung wie geschmiert. Entwicklerinnen und Entwickler sammeln Anforderungen, setzen Features um, schließen Sprints ab und liefern Releases aus. Es wird gebaut, getestet, deployt, immer und immer wieder. Und doch bleibt häufig ein diffuses Gefühl zurück. Warum diese Arbeit, warum der ganze Code? Selbst wenn man mit KI-Unterstützung noch schneller mehr Code erzeugen kann, heißt das noch lange nicht, dass am Ende viel Wert entsteht.

Darin liegt das Problem, das viele Produktteams haben: Der Fokus liegt auf Output. Die Teams setzen mehr und mehr Features um und messen den Fortschritt anhand der erledigten Arbeit. Produkte sammeln immer mehr Funktionalität an und wachsen kontinuierlich. Viele Produktverantwortliche glauben, dass das nötig ist, um sich vom Wettbewerb zu differenzieren und bestehenden Nutzerinnen und Nutzern ständig etwas Neues zu bieten. Dabei ist nicht immer „mehr“ die Lösung, sondern manchmal sogar ein Problem. Je mehr Features das Produkt umfasst, umso mehr Arbeit muss in Bugfixing und Wartung fließen. Und genau hier setzt der Gedanke an, sich mehr auf Outcome statt Output zu konzentrieren.

Output ist nicht gleich Wert

Wo liegt der Unterschied zwischen Output und Outcome? Output beschreibt, was produziert wird. Outcome ist das, was das Produzierte bewirkt. Jede Funktion, jede neue Dokumentation, jeder neue Test ist erst einmal nur Output. Je mehr ein Team davon liefert, desto „produktiver“ ist es. Dabei bleibt zunächst unklar, was sich durch den erzeugten Output verändert. Was wird sich für Nutzerinnen und Nutzer ändern?

Zum Beispiel hat ein Onlineshop mit häufig wiederkehrenden Einkäufen (etwa für den Wocheneinkauf oder die Bestellung bei der Lieblingspizzeria) eine Funktion, die User beim Einkauf daran erinnern soll, dass sie ein oft gekauftes Produkt diesmal vergessen haben (zum Beispiel „Du nimmst normalerweise Pizzabrötchen dazu. Hast du sie vielleicht vergessen?“). Das Feature für diese Erinnerung ist erst einmal nur der Output. Wenn Kundinnen und Kunden das Feature aber nutzen und es dafür sorgt, dass sie mehr einkaufen, ist das der Outcome. In anderen Kontexten kann das dann auch eine schnellere Einarbeitung, glücklichere Kunden oder Ähnliches bedeuten. Outcome ist aber am Ende immer die Antwort auf die Frage, was sich durch den Output verbessern soll.

Das Konzept von Outcome und Output bei einem komplexen Produkt lässt sich gut am Beispiel des Essens für eine Feierlichkeit verdeutlichen. Jedes einzelne Gericht, jeder Dip, jede Soße und jede Beilage ist Output. Misst man den Erfolg der eigenen Arbeit an Output, so geht es in erster Linie darum, dass möglichst viel Essen auf dem Tisch steht. Geht es aber um Outcome, dann sind die Freude beim Essen, das Lächeln der Gäste und das Genießen des Essens von Bedeutung. Man geht demnach anders an die Arbeit, wenn man sich andere Fragen stellt. Braucht es möglichst viel Essen oder geht es darum, die Personen kulinarisch zufrieden zu stellen? Geht es um schlichte Sättigung oder um Begeisterung beim Essen? Bezogen auf Software: Nutzerinnen und Nutzer freuen sich nicht über zusätzliche Features an sich. Vielmehr freuen sie sich darüber, wenn sie ein Problem einfacher lösen, eine Arbeit schneller durchführen oder eine Funktion leichter bedienen können.

Output-Orientierung lässt sich in vielen Produktteams beobachten. Sie streben dann oft danach, die Arbeitszeit von Entwicklerinnen und Entwicklern maximal auszulasten. Eine hohe Anzahl an Arbeitsergebnissen erzeugt das Gefühl von Produktivität. Langfristig führt das aber nicht nur zu Produkten mit begrenzter Wirkung, sondern auch zu Frustration im Team. Gerade Developer erleben häufig, dass sie technisch anspruchsvolle Lösungen umsetzen, ohne zu wissen, ob diese überhaupt sinnvoll sind.

Outcome ist auch Entwickleraufgabe

Jetzt kann man es sich relativ einfach machen. Die Entscheidung, was gebaut wird, liegt häufig beim Produktmanagement oder der Konzeption. Als Entwicklerin oder Entwickler muss man „nur noch“ die Anforderungen umsetzen beziehungsweise in Code konvertieren. Dieses Übersetzen setzt jedoch einiges an Expertise voraus, denn gute Software zu bauen ist alles andere als trivial. Aber sich auf die Umsetzung von Features zurückzuziehen, entbindet Entwickler nicht von der Verantwortung, sich um die eigene Wirksamkeit zu kümmern. Sich nur als Umsetzende zu sehen, ist zu kurz gedacht, denn gerade Entwicklerinnen und Entwickler sitzen an zentraler Stelle. Sie übersetzen Ideen in Realität, treffen dabei aber wichtige Architekturentscheidungen und kennen die technischen Möglichkeiten und Grenzen am besten. Wenn sie in diesem Prozess Fragen zum angestrebten Outcome stellen, hilft Ihr Wissen dabei, gute Lösungen zu finden, statt nur Anforderungen umzusetzen.

Der stärkste Hebel sind die richtigen Fragen

Developer müssen aber nun keine neuen Rollen übernehmen. Häufig hilft es schon, an den richtigen Punkten die richtigen Fragen zu stellen (siehe Textkasten). Insbesondere in Terminen, in denen es um Anforderungen geht, entstehen oft wertvolle Diskussionen und somit auch Gelegenheiten, den Grund (den gewünschten Outcome) eines Features zu erfragen und durch das Gespräch gegebenenfalls den Fokus der Entwicklung zu verschieben. Warum soll das jeweilige Feature gebaut werden? Warum benötigen die User das Feature? Woran erkennt man hinterher, dass es sich gelohnt hat, das Feature zu entwickeln?

Natürlich ist es für diejenigen, die die Anforderungen stellen, einfacher, direkt eine bestimmte Funktion zu bestellen. Aber es ist überraschend, wie oft sich auch diese Menschen noch nicht so richtig Gedanken dazu gemacht haben, warum die Welt dieses Feature benötigt und welche Wirkung es eigentlich genau erzielen soll.

Sicherlich sollte jemand aus dem Produktmanagement oder anderen Bereichen die obigen Fragen beantworten können, aber zwei wichtige Aspekte darf man dabei nicht vergessen. Zum einen arbeiten auch dort nur Menschen. Vielleicht finden sie die Idee für das Feature einfach spannend oder haben einfach Lust darauf, es im Produkt zu sehen. Welche Wirkung es bei den Usern auslöst, wurde vielleicht nicht bedacht. Zum anderen passiert es jeder und jedem hin und wieder einmal, dass man sich sehr in einer Lösungsidee verfängt und aus den Augen verliert, dass die gleiche Wirkung auch auf einem anderen Weg erreichbar wäre.

Entwicklerinnen und Entwickler haben als vollwertige Teammitglieder auch die Aufgabe, dafür zu sorgen, die richtigen Dinge zu tun. Manche Teammitglieder wollen aber nicht als Widerstand empfunden werden. Vor allem wer noch nicht viel Arbeitserfahrung hat, stellt mitunter die eigene Perspektive hinten an und geht davon aus, dass der Rest schon wissen wird, warum es sinnvoll ist, das Feature zu bauen. Aber Fragen bremsen nicht, sie schärfen. Sie helfen Teams, bewusster Entscheidungen zu treffen.

Outcome in der täglichen Arbeit verankern

Eine verstärkte Outcome-Orientierung darf aber nicht vom Engagement einzelner Teammitglieder abhängen. Sie muss vielmehr Teil der Arbeitsroutine werden, und auch dazu gibt es wirksame Hebel. Einige Produktteams nutzen beispielsweise eine Definition of Ready (DoR), die beschreibt, welche Eigenschaften erfüllt sein müssen, damit eine Anforderung umgesetzt werden kann. Eine DoR kann dann unter anderem aufführen, dass bestimmte Fragen zum angestrebten Outcome beantwortet sein müssen. Zu diesen Fragen gehören beispielsweise die im Textkasten genannten. Durch die Einbindung solcher Fragen in die DoR müssen einzelne Entwicklerinnen und Entwickler nicht mehr jedes Mal nachfragen und gefühlt stören, sondern ein Team verpflichtet sich als Ganzes dazu, die Fragen abzuarbeiten. Wenn beim Überprüfen der DoR unklar ist, wofür eine Anforderung umgesetzt werden soll oder woran Erfolg erkennbar sein soll, ist es sinnvoll, die Umsetzung zu verschieben und erst einmal das angestrebte Ziel oder die angestrebte Wirkung zu klären.

Die Ergebnisse der Umfrage „State of Rust Survey 2025“ liegen vor: Immer mehr Entwicklerinnen und Entwickler setzen Rust in ihrem Arbeitsumfeld ein, können zunehmend produktiver damit arbeiten und verwenden dafür fast immer das aktuelle, stabile Release. Allerdings ist nur eine knappe Mehrheit der Teilnehmer mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Befürchtungen gibt es auch dahingehend, dass Rust zu komplex wird, Developer wie Maintainer zu wenig Unterstützung erhalten und sich die Programmiersprache im Unternehmensumfeld nicht durchsetzen kann.

Produktives Arbeiten am liebsten mit dem stabilen Release

Mehr als die Hälfte der Befragten meint, dass es sich mit Rust produktiv arbeiten lässt (56,8 Prozent). Damit setzt sich ein Trend fort, denn bei der Vorjahresumfrage stimmten noch 53,5 Prozent dieser Aussage zu, während es im Jahr 2023 nur 47 Prozent waren. Leicht gestiegen, auf 55,1 Prozent, ist auch der Anteil der Entwicklerinnen und Entwickler, die Rust täglich einsetzen. Unter den am häufigsten genannten Alltagsproblemen stehen dabei langsames Kompilieren (27,3 Prozent) und hoher Speicherbedarf für Zielverzeichnisse (22,2 Prozent) an vorderster Stelle.

Mit 89,2 Prozent setzt die große Mehrheit der Rust-Developer auf das aktuelle stabile Release. Sorge vor einem Upgrade hat dabei fast niemand, denn 97,1 Prozent stimmen der Aussage zu, dass der Wechsel auf eine neue stabile Compiler-Version sehr einfach ist und höchstens geringe Code-Anpassungen erfordert.

Vorsichtiger ist man bei Nightly-Upgrades, denn 56,9 Prozent erwarten hier Probleme wie Compiler-Fehler. Warum man diese trotzdem nutzt, beantworten knapp 31 Prozent damit, dass sie ein bestimmtes Feature nutzen wollen, das noch nicht in der stabilen Version zur Verfügung steht. Die Nightly-Version wird auch eingesetzt, weil ein bestimmtes Tool sie erfordert (10,8 Prozent) oder weil eine Crate-Abhängigkeit besteht (8,5 Prozent).

Hauptsorgen: Hohe Komplexität und mangelnder Support

Knapp 60 Prozent sind mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Einem Viertel geht es indes zu langsam und 41,6 Prozent meinen sogar, dass Rust zu komplex wird. Die ausbleibende Unterstützung für Developer und Maintainer sehen 38,4 Prozent als Problem an, ein Punkt, der gegenüber dem Vorjahr (35,4 Prozent) sogar in der Umfrage gestiegen ist. Hier spiegelt sich offensichtlich eine allgemeine Überforderung, die viele Projektverantwortliche bemängeln, oft neuerdings auch im Zusammenhang mit zunehmendem AI-Slop.

Den Spitzenplatz unter den Zukunftssorgen nimmt aber die Befürchtung ein, dass Rust in der Technologiebranche zu wenig Einsatz findet (42,1 Prozent). Die Umfrage macht allerdings auch einen gegenläufigen Trend sichtbar. Im Unternehmensumfeld wird Rust häufiger für den produktiven Einsatz herangezogen (48,8 Prozent), ein klares Plus gegenüber den Jahren 2023 und 2022, in denen noch 45,5 Prozent beziehungsweise 38,7 Prozent der Befragten diese Beobachtung gemacht haben. Zudem gibt ein Viertel der Teilnehmer an, dass ihr Unternehmen Rust-Developer einstellen will. Vergangenes Jahr waren es 22 Prozent und 2021 noch 19,6 Prozent.

Beliebteste Stable-Features und eine Wunschliste

Unter den Stable-Features, die in den letzten 12 Monaten dazugekommen sind, verwenden Entwicklerinnen und Entwickler Let Chains (71,4 Prozent) und Async Closures (55,5 Prozent) am häufigsten. Auf dem dritten Platz landet Trait Upcasting mit 28,1 Prozent. Im Gegensatz dazu werden Features wie Naked Functions, Strict Provenance API und diagnostic::do_not_recommend kaum benötigt.

Für das nächste stabile Release wünschen sich die Teilnehmer, dass noch nicht implementierte oder den Nightly-Versionen vorbehaltene Features wie Generic Const Expressions, Const Trait Methods, Stable ABI und Portable SIMD Aufnahme finden.

VS-Code-Nutzung sinkt

Die beliebteste Entwicklungsumgebung für Rust bleibt Visual Studio Code, allerdings mit weiter sinkendem Anteil. Im Jahr 2022 war es für 61,7 Prozent der Entwicklerinnen und Entwickler der Editor der Wahl, jetzt nur noch für 51,6 Prozent. Bei den genutzten Paketmanagern und Crate-Quellen sind die Sympathien klar verteilt. Rust-Developer verwenden fast ausschließlich Cargo (97,5 Prozent) und beziehen ihre Crates überwiegend von crates.io (96,6 Prozent). Einen großen Anteil machen mittlerweile auch die Git-Repositories aus, die 46,2 Prozent der Teilnehmer nutzen.

Linux ist als Rust-Entwicklungsplattform weiterhin das OS der Wahl (75,2 Prozent). macOS und Windows bringen es zusammen auf einen Anteil von 61,4 Prozent. Ein ähnliches Bild zeigt sich bei den Zielplattformen. Hier liegt Linux mit 88,4 Prozent vorn, gefolgt von Windows mit 43,3 Prozent und macOS mit 30,7 Prozent.

Mehr als 7000 Umfrage-Teilnehmende

Die vom Rust Survey Team durchgeführte Online-Umfrage „State of Rust Survey 2025“ lief 30 Tage lang vom 17. November bis zum 17. Dezember 2025 und war in zehn Sprachen verfügbar. Den kompletten Fragebogen beantworteten 7156 Entwicklerinnen und Entwickler, von denen sich eine Mehrheit von 23,4 Prozent in den USA verortete. Mit 13,4 Prozent folgten Teilnehmer aus Deutschland auf Platz zwei. Frankreich, Großbritannien und China machen mit zusammen etwa 16 Prozent die Plätze drei bis fünf unter sich aus.

Insgesamt unterscheiden sich die Antworten zum großen Teil nur geringfügig von der Umfrage aus dem Jahr 2024, so ihre Urheber. Die gegenüber den Vorjahren leicht gesunkene Beteiligung führt das Survey-Team auf die größere Anzahl von Umfragen zurück, die 2025 über den Rust-Blog lanciert wurden.

Sämtliche Ergebnisse der Umfrage stehen im Rust-Blog bereit. Die Auswertung gibt es auch als 59-seitigen PDF-Report.

(who)