Der Übersetzer war der schärfste Reviewer, den wir hatten

Wir hatten einen Rückstand. 26 Texte lagen auf Deutsch fertig da, Englisch und Spanisch fehlten. Kein spannender Auftrag, eher der Teil den man vor sich herschiebt. Also drei Agenten parallel, neun Bündel zu je zwei bis drei Texten, pro Text beide Zielsprachen im selben Auftrag. 52 Dateien am Ende. Reine Fleissarbeit, dachte ich. Was zurückkam, waren nicht nur Übersetzungen. Es waren rund 20 Meldungen der Sorte "im deutschen Original stimmt hier etwas nicht". Falsche Zahlen, eine Behauptung die sich zwei Absätze später selbst widerspricht, ein Pfad der so nie existiert hat. Alles in Texten, die vorher zwei Review-Runden hinter sich hatten. Das ist der Teil, über den ich seitdem nachdenke. ## Warum Übersetzen schärfer liest als Reviewen Ein Review ist eine Frage nach dem Gesamteindruck. Passt das, stimmt der Ton, ist der Aufbau logisch. Man liest schnell, weil man den Text schon kennt oder zumindest so tut. Über einer Zahl bleibt niemand hängen, wenn sie plausibel aussieht. Übersetzen erzwingt etwas anderes. Jeder Satz muss einzeln in die Hand genommen werden, sonst kann man ihn nicht übertragen. Ein vager Satz lässt sich nicht vage übersetzen, man muss sich entscheiden was gemeint war. Und genau an der Stelle fällt auf, wenn nichts gemeint war. Ich habe das nicht geplant. In den Auftrag hatte ich nur den Satz reingeschrieben, dass Fehler im Original gemeldet und nicht stillschweigend geglättet werden sollen. Ohne diesen Satz wären die 20 Funde einfach in der englischen Fassung repariert worden und im deutschen Original stehen geblieben. Das ist die eigentliche Lektion: Die Agenten hätten es sonst freundlich für mich weggebügelt. Seitdem steht der Satz in jedem Übersetzungsauftrag drin. Kostet nichts und ist der billigste zweite Review, den ich je hatte. ## Was sonst noch im Auftrag stand Der zweite Grund, warum das funktioniert hat, ist unglamourös: Ich habe den Agenten eine Prüfliste mitgegeben, die sie selbst abarbeiten, bevor sie abliefern. Fünf Punkte, alle maschinell nachvollziehbar. Anzahl der Überschriften muss zur deutschen Fassung passen. Interne Links bleiben unverändert, auch wenn die URL deutsch aussieht. Frontmatter wird nicht angefasst. Keine Em-Dashes im Fliesstext. Und Befehle in Code-Blöcken bleiben Zeichen für Zeichen gleich. Klingt nach Kleinkram. Aber jeder dieser Punkte ist eine Stelle, an der eine Übersetzung vorher schon mal still kaputtgegangen ist. Eine Prüfliste, die der Agent selbst durchgeht, fängt mehr ab als ein Mensch, der am Ende drüberschaut und müde ist. ## Der Fehler, der mir teuer kam Ein Punkt auf dieser Liste war zu grob formuliert: Code-Blöcke zeichengenau übernehmen. Klingt richtig, ein Befehl darf sich beim Übersetzen nicht verändern. Das Ergebnis waren englische Texte mit deutschen Kommentaren im Code. Wer die spanische Fassung eines Playbooks liest und dann im Beispiel `# Datei zuerst sichern` findet, ist raus. Die Regel war zu grob, und die Agenten haben sie exakt so befolgt wie sie dastand. Richtig heisst es: Befehle zeichengenau, Kommentare übersetzen. Ein Wort Unterschied, 52 Dateien Auswirkung. Der zweite Fehler war schlimmer. Ich hatte ein kleines Skript laufen lassen, das Umlaut-Ersatzschreibweisen im Bestand aufräumt, also `ue` zurück zu `ü` und so weiter. Auf deutschem Fliesstext macht das genau was es soll. Auf englischem Text wird daraus eine Abrissbirne, weil dort Buchstabenfolgen wie `ue` mitten in ganz normalen Wörtern stehen. In Quellcode ist es noch schlimmer, da zerlegt es Variablennamen. Ich habe das gemerkt, weil ein Test rot wurde. Nicht weil ich es gesehen hätte. Ein Suchen-und-Ersetzen über einen mehrsprachigen Bestand ohne Sprachfilter ist keine Aufräumaktion, sondern ein Werkzeug mit Klinge. ## Die Zahl, die mich am meisten überrascht hat Nach der Übersetzung lief noch eine adversariale Prüfrunde über den ganzen Stapel, mehrere Durchgänge hintereinander. 43 kritische Funde insgesamt. Die Kurve über die Runden: 13, dann wieder 13, dann 11, dann 6, dann null. Warum in Runde zwei nochmal genauso viele wie in Runde eins? Weil gut die Hälfte davon Folgefehler meiner eigenen Korrekturen aus Runde eins waren. Ich repariere A, dabei geht B kaputt, das vorher in Ordnung war. Ab Runde zwei habe ich deshalb ausdrücklich nach genau diesem Muster fragen lassen und die Liste der eigenen Änderungen mitgegeben. Danach fiel die Kurve. Vorher hätte ich schwören können, dass jede Korrektur den Stand verbessert. Wer mit Agenten über mehrere Durchgänge an einem Bestand arbeitet, sollte das einplanen. Die erste Runde findet die Fehler, die zweite findet die Reparaturen. ## Was ich daraus mitnehme Ein Prüfblick entsteht nicht dadurch, dass man jemanden bittet zu prüfen. Er entsteht durch eine Aufgabe, die ohne genaues Lesen gar nicht lösbar ist. Übersetzen ist so eine Aufgabe. Zusammenfassen auf eine feste Länge übrigens auch, und einen Text in eine Tabelle überführen ebenfalls. Wenn du das nächste Mal einen Text wirklich geprüft haben willst, lass ihn nicht reviewen. Lass etwas damit machen. Falls du parallel arbeitende Agenten noch nicht aufgesetzt hast, die offizielle [Subagent-Doku](https://code.claude.com/docs/en/sub-agents) beschreibt den Aufbau. Mehr als drei gleichzeitig würde ich nicht starten, danach verliert man den Überblick über das, was zurückkommt. Zum Weiterlesen passen zwei Sachen bei uns: [Halluzinationen erkennen](/levels/1/02-halluzinationen) erklärt, warum plausible Sätze der gefährlichere Fall sind als offensichtlicher Unsinn. Und das Playbook [KI-Antwort faktenchecken](/playbooks/ki-antwort-faktenchecken) ist der konkrete Ablauf, wenn du eine einzelne Aussage prüfen willst statt einen ganzen Bestand.