Du siehst einen guten Effekt, eine saubere Interaktion oder eine Funktion in einer Anwendung und willst verstehen, was dahinter steckt. REA liefert dafür Belege, mit denen du die Idee sauber in dein eigenes Produkt übersetzt.
Was REA tatsächlich macht
REA, kurz für Reverse Engineer Anything, ist ein lokales Analysewerkzeug für Coding-Agenten. Der Agent bekommt über MCP eine strukturierte Möglichkeit, Artefakte zu untersuchen: JavaScript- oder Electron-Anwendungen, .NET-Assemblies, Websites sowie, wenn ein Analyseprovider eingerichtet ist, native Programme. Die entscheidende Idee: Der Agent soll nicht raten. Er soll seine Erklärung auf Fundstellen, Module, Aufrufe und beobachtbares Verhalten stützen.
Das passt zu einem professionellen Entwicklungsablauf. Eine Inspiration wird zunächst präzise beschrieben. Dann wird untersucht, welche Bausteine sie ausmachen: Zustände, Datenfluss, Übergänge, Zugriffsgrenzen und Fehlerfälle. Erst danach entsteht eine eigene Implementierung für den eigenen Stack, die getestet und gestalterisch angepasst wird.
der arbeitsweg
Frage eingrenzen
Was soll verständlich werden: Verhalten, Datenfluss oder Gestaltung?
Belege sammeln
REA untersucht das ausgelieferte Artefakt lokal und legt Fundstellen offen.
Eigenständig bauen
Die Erkenntnis wird als eigene, getestete Lösung für den eigenen Stack umgesetzt.
REA mit Claude Code und Codex einrichten
REA arbeitet mit beiden Agenten über denselben lokalen MCP-Server. Für Claude Code heißt die Client-ID claude_code, für Codex codex. Eine sichere Planung beginnt mit npx rea-agents@latest setup --client claude_code --client codex --dry-run --json. Der Befehl zeigt erst, welche Konfigurationsdateien und Skills betroffen wären.
Erst nach dieser Prüfung folgt die Freigabe für genau diese beiden Clients. REA schreibt dabei keine pauschale Konfiguration über bestehende Einstellungen. Laut Projektdokumentation sichert der Setup-Ablauf Änderungen, erhält fremde Einträge und verlangt vor dem Schreiben eine Bestätigung. Anschließend startest du Claude Code oder Codex neu, damit die MCP-Werkzeuge in der laufenden Sitzung verfügbar sind.
Der Unterschied liegt danach weniger in REA als in deinem Arbeitsauftrag. In Claude Code kann eine Untersuchung Teil eines längeren Repository-Workflows sein. In Codex passt sie in einen klar abgegrenzten Prüfauftrag. Für beide gilt: Formuliere zuerst das Verhalten, das du erklären willst. Erst dann öffnest du ein Artefakt.
Welcher Agent passt zu welchem Moment?
Nutze Claude Code, wenn die Analyse direkt in eine bestehende Codebasis, Tests und eine dokumentierte Änderung übergehen soll. Nutze Codex, wenn du eine unabhängige technische Einordnung oder einen fokussierten Nachweis brauchst. Die Qualität entsteht nicht durch den Agentennamen. Entscheidend sind ein enger Untersuchungsrahmen, überprüfbare Fundstellen und eine eigene Umsetzung.
Im Alltag lohnt sich die klare Frage vor dem Start: Reicht mir der vorhandene Quellcode? Dann ist eine normale Codeanalyse schneller und eindeutiger. REA ist für den Fall gedacht, dass die Antwort im ausgelieferten Artefakt oder im Laufzeitverhalten steckt.
Vom Effekt zur belastbaren Erklärung
Die beiden Beispiele aus den Videos zeigen zwei produktive Einstiege. Erstens: eine Desktop-Anwendung. Der Agent kann nachvollziehen, wie etwa ein Clipboard- oder Suchablauf zwischen Oberfläche, Preload und Hintergrundprozess vermittelt wird. Zweitens: eine Website. Ein Link ist kein Bauplan, aber ein konkreter Ausgangspunkt, um sichtbare Ebenen, Bewegungslogik, DOM-Struktur und Netzwerkgrenzen zu unterscheiden.
Gerade beim Website-Nachbau ist die Reihenfolge wichtig: Zuerst Wirkung beschreiben, dann die technische Ursache begrenzen, dann die eigene Lösung gestalten. Ein Farbverlauf, eine separate Wellenebene und eine scrollgebundene Bewegung können ein stimmiges Ergebnis ergeben. Der eigene Code, die eigene Marke und die eigene Accessibility bleiben dabei Pflicht.
Rechtliche und technische Grenzen
Reverse Engineering ist kein Freibrief. Prüfe nur Software, für die du Eigentum, eine Lizenz oder eine ausdrückliche Berechtigung hast. Zugangsdaten, personenbezogene Daten, Umgehung von Schutzmaßnahmen und das Kopieren geschützter Ausdrucksformen gehören nicht in diesen Ablauf. Auch technisch gilt: Eine Analyse ist ein Hinweis. REA dokumentiert Belege und Einschränkungen; die Schlussfolgerung muss im Kontext geprüft werden.
die entscheidende grenze
Eigene oder ausdrücklich freigegebene Software untersuchen, Verhalten belegen, Schnittstellen verstehen und eine eigenständige Lösung bauen.
Quellcode kopieren, Schutzmaßnahmen umgehen, fremde Zugangsdaten auswerten oder einen Dienst täuschend als Original ausgeben.
Mein Fazit
REA macht aus „Wie funktioniert das?“ eine bessere Arbeitsfrage: „Welche Belege brauche ich, um eine eigene, saubere Lösung zu bauen?“ Das ist besonders wertvoll für Teams, die mit KI-Agenten nicht nur schneller tippen, sondern nachvollziehbarer entscheiden wollen. Starte klein: ein abgegrenztes Verhalten, ein klarer Berechtigungsrahmen, eine eigene Umsetzung und ein Test, der die Idee wirklich beweist.
Quellen, Stand 13.10.2026: REA auf GitHub und Installationsdokumentation.
