KI-Code-Review-Tools Benchmark
Mit dem zunehmenden Einsatz von KI-Coding-Tools sind Codebases anfälliger für Schwachstellen geworden, was den Bedarf an effektiven Code-Reviews erhöht hat. Um dem zu begegnen, stellen wir RevEval (KI Code Review Eval) vor, das die vier führenden KI-Code-Review-Tools über 309 Pull Requests aus Repositories unterschiedlicher Größe benchmarkt und ihre Leistung anhand von Beiträgen von 10 Entwicklern und einem LLM-as-a-judge bewertet.
Benchmark-Ergebnisse
CodeRabbit erwies sich als das erfolgreichste Code-Review-Tool in 51 % von 309 PRs:
Zur Messung des Rankings verwendeten wir die LLM-as-a-judge-Bewertungen. Wir untersuchten, welches KI-Code-Review-Tool in jedem PR die höchste Punktzahl erzielte (bewertet mit unserem LLM-as-a-judge) und berechneten anschließend den Prozentsatz aller PRs, in denen jedes Tool den ersten Platz belegte.
CodeRabbit erzielte sowohl bei manuellen menschlichen Bewertungen als auch bei LLM-as-a-judge-Bewertungen die höchsten Punktzahlen, gefolgt von Greptile und GitHub Copilot:
Bei der Berechnung der Durchschnittsbewertung wurden alle drei Bewertungskategorien gleich gewichtet. Die Bewertungen großer und kleiner Repositories wurden durch LLM-as-a-judge bewertet, und die Entwicklerbewertungen wurden manuell durchgeführt, um die LLM-as-a-judge-Bewertungen gegenzuprüfen.
Menschliche Bewertungen
Wir fragten die an den Bewertungen beteiligten Entwickler, welches KI-Code-Review-Tool sie bevorzugt in ihre Workflows integrieren würden. Da CTOs eine zentrale Entscheidungsrolle in der Softwareentwicklung spielen, haben wir ihre Antworten in einem separaten Diagramm hervorgehoben:
Detaillierter Vergleich
Wir berechneten die durchschnittliche Anzahl von Bugs pro PR, indem wir alle von jedem Code-Review-Tool gemeldeten Bugs/Probleme zählten und durch die Gesamtzahl der PRs (309) dividierten. Nicht alle PRs in unserer Codebasis enthalten Bugs oder Probleme. GitHub Copilot meldet nicht explizit, wenn es einen Bug in einem PR erkennt; daher wurde es aus diesem Vergleich ausgeschlossen.
Sie finden unsere Methodik unten.
Funktionen
* Es wird von CodeRabbits Funktion „agentic pre-merge checks“ bereitgestellt. Es validiert Pull Requests automatisch anhand von Qualitätsstandards und individuellen organisatorischen Anforderungen vor dem Merge und liefert Bestanden/Nicht-bestanden-Ergebnisse mit Erklärungen direkt im PR-Durchlauf. Jede Prüfung kann so konfiguriert werden, dass sie Entwickler entweder warnt oder Merges vollständig blockiert. Während GitHub Copilot, Cursor BugBot und Greptile PR-Review-Funktionen bieten, fungieren sie als beratende Systeme, die Feedback und Vorschläge liefern, statt als systematische Validierungs-Frameworks.
** Cursor und GitHub Copilot bieten möglicherweise über ihre Code-Review-Komponenten hinaus weitere Funktionen; in unseren Vergleich wurden nur die Funktionen von Cursor Bugbot und GitHub Copilot Code Review einbezogen.
Die Funktionen variieren je nach Abonnementplan, daher sind einige der oben als verfügbar markierten Funktionen in Ihrem Abonnement möglicherweise nicht verfügbar.
Bei automatisierten Code-Reviews waren CodeRabbit, GitHub Copilot und Cursor Bugbot einfacher zu konfigurieren als Greptile, da sich automatisierte Code-Reviews in Greptile nicht für ein leeres Repository aktivieren lassen.
Funktions-Detailanalyse
CodeRabbit
- 40+ integrierte Linter und Sicherheitsscanner.
- Benutzerdefinierte Anweisungen basierend auf AST-Mustern.
- Passt sich im Laufe der Zeit an das Feedback der Entwickler an.
- Entwickler können @coderabbitai markieren, um Nachfragen zu stellen, Korrekturen anzufordern oder Empfehlungen zu hinterfragen.
- Unterstützt benutzerdefinierte MCP-Server für zusätzlichen Kontext.
GitHub Copilot Code Review
- Die Schaltfläche „Vorschlag implementieren“ übergibt an den Copilot-Coding-Agenten.
- Enge Integration in das GitHub-Ökosystem.
- Benutzerdefinierte Anweisungen über copilot-instructions.md.
Greptile
- Lernt die Codierungsstandards des Teams aus dem PR-Kommentarverlauf.
- Mit Pattern-Repos können Entwickler verwandte Repos in greptile.json referenzieren, sodass sie zusätzlichen Kontext liefern können.
- Entwickler können mit @greptileai antworten, um Folgefragen zu stellen oder Korrekturvorschläge zu erhalten.
- Greptile lernt aus Daumen-hoch/Daumen-runter-Feedback.
- Sequenzdiagramme automatisch-generiert für alle PRs.
Cursor BugBot
- Nachdem ein Bug von BugBot identifiziert wurde, können Entwickler die Schaltfläche „In Cursor beheben“ verwenden, um Cursor schnell zu öffnen und den Bug zu beheben.
- Entwickler können ihre Code-Review-Regeln in BUGBOT.md-Dateien anpassen.
Wir hatten außerdem vor, Graphite zu benchmarken; aufgrund eines Bugs in deren Dashboard konnten wir jedoch keine automatisierten Code-Reviews für neue Repositories aktivieren. Wir kontaktierten ihr Support-Team am 25. Oktober 2025, doch die Antwort löste das Problem nicht. Trotz Follow-up-E-Mails und einer Nachricht in ihrem Slack-Kanal blieb das Problem ungelöst.
Komponenten und Integrationen
* Alle diese Lösungen unterstützen GitHub.
Methodik
Wir erstellten für jedes Tool separate Benchmark-Repositories innerhalb unserer dedizierten GitHub-Organisation.
Nachdem wir automatische Code-Reviews für jedes Tool in seinem zugewiesenen Repository aktiviert hatten, öffneten wir Pull Requests nacheinander, warteten, bis das Tool seine Überprüfung abgeschlossen hatte, und schlossen die PRs anschließend, um die Ergebnisse zu erfassen. Wir haben keine Tool-Einstellungen verändert oder angepasst. Jedes Tool wurde mit seiner Standardkonfiguration bewertet, genau wie installiert.
Unser Workflow beginnt damit, das Quell-Repository so zu klonen, wie es zu einem ausgewählten Stichtag existierte, und anschließend die nach diesem Datum eingereichten Pull Requests einzeln erneut abzuspielen, wobei die ursprüngliche Repository-Struktur erhalten bleibt.
Wir verwendeten die Versionen aller Produkte vom November 2025. Unser Benchmark bestand aus zwei verschiedenen Quell-Repository-Bereichen:
1. Bekannte, mittelgroße bis große Repositories
Wir wollten sehen, wie gut KI-Code-Review-Tools Repositories mit großen und komplexen Strukturen verstehen. Insgesamt haben wir 289 PRs über 7 Repositories hinweg überprüft.
2. Kleine und neue Repositories
Wir sind uns bewusst, dass wir unserem LLM-as-a-judge nicht das
gesamte Repository bei den großen Repositories zur Verfügung stellen können, da deren Kontextfenster dafür nicht ausreichen. Um dies zu überwinden, haben wir daher auch die ersten 3-5 PRs neuer und kleiner Repositories bewertet. MCP-Server passten perfekt zu unseren Anforderungen. Folglich wählten wir 8 offizielle MCP-Server und ließen 20 PRs darauf überprüfen.
Unser Datensatz enthält Code, der von erfahrenen Entwicklern geschrieben wurde. Wir haben die Leistung nicht auf vollständig KI-generierten Codebases bewertet.
Entwicklerbewertungen
Wir wählten zufällig 35 PRs aus und wiesen sie 10 Entwicklern zu, wobei jeder PR fünfmal von Entwicklern bewertet wurde. Unser Ziel bei der Wiederholung der Bewertung war es, die Voreingenommenheit der Entwickler zu minimieren. Die Entwickler bewerteten die Ergebnisse herstellerunabhängig.
Die meisten kamen zu denselben übergeordneten Erkenntnissen:
- Die detaillierten Reviews von CodeRabbit sind hilfreich, und es ist erfolgreich bei der Bug-Erkennung.
- Greptile lieferte erfolgreiche Zusammenfassungen, aber die generierten Sequenzdiagramme sind für einige PRs nicht notwendig.
- GitHub Copilot ist sehr erfolgreich darin, Tippfehler im Code zu finden, und macht treffsichere Vorschläge; seine Analyse ist kürzer als die von CodeRabbit und Greptile.
- Cursor Bugbot liefert eine weniger detaillierte und weniger genaue Analyse.
Nach den Bewertungen gaben sie außerdem an, dass sie in ihren eigenen Repositories als Unterstützungstool für Entwickler einsetzen werden.
LLM-as-a-Judge
Wir verwendeten GPT-5, um die Reviews zu bewerten. Nach der Bewertung verwendeten wir GPT-4o, um die Ausgabe im JSON-Format zu strukturieren.
Unser Bewertungsworkflow umfasst:
- Für große Repositories: den ursprünglichen PR-Body, Diff und die Kommentare/Reviews der Tools.
- Für kleine Repositories: die gesamte Codebasis, den ursprünglichen PR-Body, Diff und die Kommentare/Reviews der Tools.
Hier ist der vollständige Prompt, den wir verwendet haben:
Bewerten Sie jedes Tool anhand dieser Dimensionen (Skala 1–5):
1. Korrektheit
Sind die gefundenen Probleme tatsächlich echte Probleme/Bugs/Fixes im Code?
– 5 (Hervorragend): Alle gefundenen Probleme sind echte Probleme
– 4 (Gut): Die meisten Probleme sind real, geringfügige Fehlidentifikationen
– 3 (Akzeptabel): Mischung aus echten und fragwürdigen Problemen
– 2 (Schwach): Die meisten gefundenen Probleme sind keine tatsächlichen Probleme
– 1 (Gescheitert): Kann keine echten Probleme erkennen, alle Befunde sind falsch
2. Vollständigkeit
Hat es wichtige Probleme erkannt? Wie umfassend ist die Überprüfung?
– 5 (Hervorragend): Erkennt alle kritischen Probleme und die meisten wichtigen.
– 4 (Gut): Erkennt größere Probleme, übersieht einige kleinere
– 3 (Akzeptabel): Erkennt einige wichtige Probleme, weist jedoch deutliche Lücken auf
– 2 (Schwach): Übersieht mehrere kritische Probleme
– 1 (Gescheitert): Übersieht alle oder fast alle kritischen Probleme
3. Umsetzbarkeit
Sind die Vorschläge klar und umsetzbar? Enthalten sie Patches/Fixes? Wenn der Code keine Bugs enthält, schreiben Sie bei der Umsetzbarkeit für alle Tools „null“ und vergeben Sie für diesen PR keine Punkte für irgendein Tool.
– 5 (Hervorragend): Alle Vorschläge enthalten klare Patches/Fixes und sind direkt umsetzbar
– 4 (Gut): Die meisten Vorschläge bieten klare Anleitung, einige enthalten Patches
– 3 (Akzeptabel): Vorschläge sind einigermaßen klar, enthalten aber für einige Probleme keine Patches
– 2 (Schwach): Vorschläge sind meist unklar oder nicht umsetzbar
– 1 (Gescheitert): Keine klaren Vorschläge oder Anleitungen vorhanden
4. Tiefe
Zeigt es ein Verständnis für die Logik und den Zweck des Codes?
– 5 (Hervorragend): Zeigt ein tiefes Verständnis von Code-Logik, Architektur und Zweck
– 4 (Gut): Zeigt gutes Verständnis mit geringfügigen Lücken
– 3 (Akzeptabel): Oberflächliches Verständnis, übersieht etwas Kontext
– 2 (Schwach): Oberflächliche oder falsche Erklärungen des Code-Verhaltens
– 1 (Gescheitert): Kein Verständnis der Logik und des Zwecks des Codes
Ausgabeformat
Geben Sie für jedes Tool Folgendes an:
1. Detaillierte Begründung: Was hat es gefunden? Hat es wichtige Probleme übersehen? Sind Patches enthalten? Tiefes Verständnis der Codebasis? Konkrete Beispiele.
2. Einzelbewertungen (1–5 für jede Dimension, unter Verwendung der obigen Skalierung)
Beispielausgabe
Tool A:
Begründung: Tool A zeigte eine hervorragende Korrektheit, indem es ein echtes Speicherleck in der Verbindungspooling-Logik in Zeile 145 identifizierte und einen konkreten Patch mit einem Context Manager lieferte. Es bemerkte auch die fehlende Fehlerbehandlung im API-Endpunkt mit umsetzbarem Code. Die Vollständigkeitsbewertung spiegelt wider, dass es zwar größere Probleme fand, aber die Race Condition im asynchronen Handler übersah, die Produktionsprobleme verursachen könnte. Alle 4 Kommentare waren substanziell und direkt umsetzbar. Die Tiefe war stark und zeigte ein Verständnis der Ressourcenverwaltungsmuster und Fehlerpropagierung in der Codebasis.
Korrektheit: 5
Vollständigkeit: 4
Umsetzbarkeit: 5
Tiefe: 4
Tool B:
Begründung: Tool B identifizierte die Eingabevalidierungsschwachstelle in Zeile 89 korrekt und lieferte eine klare Korrektur mittels Parameter-Sanitisierung. Die Vollständigkeit litt jedoch erheblich, da es die kritische Sicherheitslücke im Authentifizierungsablauf übersah, die Wiederverwendung von Token ermöglicht. Die Umsetzbarkeit war überwiegend gut – die Vorschläge enthielten Code-Snippets. Die Tiefe war akzeptabel, aber oberflächlich und konzentrierte sich auf oberflächliche Prüfungen, anstatt das Sicherheitsmodell oder die Auswirkungen auf den Datenfluss zu verstehen.
Korrektheit: 4
Vollständigkeit: 1
Umsetzbarkeit: 4
Tiefe: 2
Zu bewertende Tools: CodeRabbit, Cursor Bugbot, Github Copilot, Greptile
Seien Sie objektiv und gründlich. Verwenden Sie konkrete Beispiele aus den Reviews, um Ihre Bewertungen zu untermauern.
Als bevorzugte Quelle hinzufügenWas ist KI-Code-Review?
KI-Code-Review ist die automatisierte Analyse von Quellcode mithilfe von Machine-Learning-Modellen, vor allem großen Sprachmodellen (LLMs), um Bugs, Ineffizienzen und potenzielle Schwachstellen zu identifizieren. Zusätzlich zur Erkennung von Problemen können diese Systeme kontextabhängige Erklärungen liefern, konkrete Korrekturen vorschlagen und Patches generieren, die Entwicklern helfen, sowohl die Codequalität als auch die Wartbarkeit zu verbessern. Viele KI-Review-Tools unterstützen auch die Dokumentation, indem sie Änderungen zusammenfassen und beschreibende Kommentare oder Erklärungen für neu hinzugefügten Code erstellen.
Da KI-Modelle Code schnell und in großem Umfang bewerten können, beschleunigen sie den Review-Prozess erheblich und erleichtern es, Probleme frühzeitig zu erkennen, während über große oder schnelllebige Projekte hinweg konsistente Codierungsstandards eingehalten werden.
In modernen KI-gestützten Entwicklungsumgebungen wie Cursor oder Claude Code können Entwickler unbeabsichtigt den Überblick darüber verlieren, wie sich ihre Codebasis entwickelt, wenn sie „vibe coding“ betreiben oder sich stark auf automatisch-generierte Vorschläge verlassen. Dies kann versteckte Schwachstellen oder logische Inkonsistenzen einführen. KI-Code-Review-Tools helfen, diese Risiken zu mindern, indem sie eine zusätzliche Ebene strukturierter und systematischer Analyse bieten, um KI-generierten Code zu validieren und zu verbessern.
Vorteile des KI-Code-Reviews
Effizienz und Geschwindigkeit
KI-Code-Review-Tools können Code in Echtzeit analysieren, sofortiges Feedback geben und potenzielle Probleme melden, während Entwickler arbeiten. Sie sind in der Lage, Fehler und Sicherheitslücken zu erkennen, die menschliche Prüfer möglicherweise übersehen, insbesondere in großen oder sich schnell weiterentwickelnden Codebases. Durch die Automatisierung von Routineprüfungen ermöglichen diese Tools es Entwicklern, sich auf übergeordnetes Denken, komplexe Problemlösungen und Architekturentscheidungen zu konzentrieren.
Verbesserte Codequalität
KI-Code-Review-Tools tragen dazu bei, teamübergreifend konsistente Codierungsstandards einzuhalten, indem sie stilistische Inkonsistenzen und Abweichungen von Best Practices identifizieren. Sie bieten außerdem detailliertes Feedback und Empfehlungen zu einer Vielzahl von Coding-Problemen, von kleinen Verbesserungen bis hin zu erheblichen Bugs. Im Laufe der Zeit können Entwickler aus diesem Feedback lernen, ihre Codiergewohnheiten verfeinern und neue Techniken übernehmen, die Gesamtqualität ihrer Arbeit stärken.
Grenzen und Herausforderungen
Übermäßige Abhängigkeit von KI-Tools
Ein häufiges Problem beim KI-Code-Review ist die übermäßige Abhängigkeit von automatisiertem Feedback. Obwohl KI eine wertvolle Quelle für Erkenntnisse sein kann, sollte sie nicht als vollständiger Ersatz für menschliches Fachwissen betrachtet werden. Automatisierte Reviews können Workflows beschleunigen, aber menschliche Prüfer bleiben unerlässlich, um Korrektheit, Kontextbewusstsein und Ausrichtung an den Projektzielen sicherzustellen. In unserem Benchmark gaben die Entwickler durchgängig an, dass sie sich nicht blind auf diese Tools verlassen würden. Sie betrachteten sie als Assistenten, die das menschliche Urteilsvermögen ergänzen, anstatt es zu ersetzen.
Umgang mit falsch-positiven und falsch-negativen Ergebnissen
Falsch-positive Ergebnisse treten auf, wenn das Tool funktionierenden Code fälschlicherweise als problematisch einstuft, während falsch-negative Ergebnisse auftreten, wenn echte Probleme übersehen werden. In unserer Bewertung waren falsch-negative Ergebnisse das größte Problem. Die Tools übersahen wichtige Probleme eher, als dass sie falsche Warnungen ausgaben. Dies unterstreicht die Notwendigkeit einer kontinuierlichen Verbesserung der zugrunde liegenden Modelle und Algorithmen.
Um diese Herausforderungen zu bewältigen, müssen sich KI-Code-Review-Tools durch besseres Training, verbesserten Umgang mit Kontext und genauere Argumentationsfähigkeiten weiterentwickeln.
Bewährte Verfahren für den Einsatz von KI-Code-Reviews
Tipps von Experten
Kombinieren Sie KI-Reviews mit menschlichen Erkenntnissen: Nutzen Sie KI-Code-Reviews parallel zu menschlichen Reviews, um sicherzustellen, dass der Code sowohl technisch einwandfrei ist als auch mit den Projektzielen übereinstimmt.
Passen Sie Regeln an Ihr Projekt an: Passen Sie die Regeln des KI-Tools an die Codierungsstandards Ihres Projekts an, um unnötige Warnungen zu reduzieren.
Nutzen Sie KI-Feedback als Lernwerkzeug: Betrachten Sie KI-Vorschläge als Möglichkeit zu lernen und sich zu verbessern, und besprechen Sie mit Ihrem Team, um zu verstehen, warum und wie Sie ähnliche Probleme in Zukunft vermeiden können.
Danksagungen
Wir möchten den Entwicklern, die ihre Zeit und ihr Fachwissen für die manuellen Bewertungen zur Verfügung gestellt haben, unseren aufrichtigen Dank aussprechen:
Aziz Durmaz (CTO bei einem Transport- und Logistikunternehmen)
Berk Kalelioğlu (Mitgründer eines Spieleentwicklungsstudios)
Elif Ece Örnek (Softwareentwicklerin bei einer Reise-Website)
Haydar Külekçi (Berater bei einem Unternehmen für Suchtechnologien & KI)
Mehmet Şirin Can (Leiter der Entwicklung bei AIMultiple)
Mehmet Korkmaz (CTO bei einem Medienunternehmen in der E-Sport- und Videospielbranche)
Murat Orno (ehemaliger CTO bei einer regionalen Zahlungsplattform mit 500+ Mitarbeitern)
Orçun Candan (Full-Stack-Entwickler bei AIMultiple)
Yalçın Börlü (Senior-Softwareentwickler bei einem Gesundheits- und Wellnessunternehmen)
Yiğit Dinç (Mitgründer eines Legal-Tech-Unternehmens)
Wir danken außerdem den Entwicklern und Maintainern der in unserem Benchmark enthaltenen Open-Source-Repositories für ihre Arbeit und ihre wertvollen Beiträge zur Community.
Anonymisierung der Identitäten der ursprünglichen Entwickler
Um den Benchmark verantwortungsvoll durchzuführen, haben wir beim erneuten Abspielen von Pull Requests aus Upstream-Repositories alle ursprünglichen Entwicklernamen und E-Mail-Adressen anonymisiert. Da die Benchmark-Repositories öffentlich sind, könnte die Beibehaltung der ursprünglichen Autoreninformationen unbeabsichtigt personenbezogene Daten offenlegen und das Risiko bergen, Entwickler jedes Mal zu benachrichtigen, wenn ein nachgebildeter Pull Request geöffnet oder aktualisiert wird. Obwohl GitHub Autoren normalerweise nicht benachrichtigt, wenn ihre Commits in einem separaten Repository erneut abgespielt werden, hielten wir es für Best Practice, jegliche Möglichkeit unerwünschter Benachrichtigungen, Zuordnungsprobleme oder Datenschutzbedenken zu vermeiden.
Die Anonymisierung stellt Folgendes sicher:
- Entwickler werden nicht durch Tausende automatisierter PR-Ereignisse gestört.
- Personenbezogene Informationen werden nicht in einem anderen öffentlichen Repository erneut veröffentlicht.
- Benchmarks bleiben unvoreingenommen, wodurch verhindert wird, dass Tools oder LLM-Bewerter durch erkennbare Autorennamen beeinflusst werden.
- Ethische und Datenschutzstandards werden bei der Arbeit mit Open-Source-Beiträgen eingehalten.
Nur die Identitätsmetadaten wurden verändert; sämtlicher Code, alle Diffs, die Commit-Reihenfolge und die Dateistrukturen wurden exakt beibehalten, um die Authentizität und Reproduzierbarkeit des Benchmarks zu gewährleisten.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Alper, Şevval},
title = {{KI-Code-Review-Tools Benchmark}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/ai-code-review-tools}},
note = {AIMultiple. Abgerufen am 13. März 2026}
}Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.
Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.
Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.
Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab und hat einen MBA von der Columbia Business School.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.