REA: Wenn die Anwendung zur Spezifikation wird

REA steht für Reverse Engineer Anything. Das Projekt verbindet Coding-Agenten mit Werkzeugen für die Analyse von Anwendungen, kompilierten Programmen und Laufzeitverhalten. Der Agent kann damit nachvollziehen, wie eine Funktion arbeitet, und eine eigene Umsetzung entwickeln.

Das verschiebt den Ausgangspunkt. Statt jedes Detail einer gewünschten Funktion zu beschreiben, zeigst du dem Agenten eine Anwendung und stellst eine konkrete Frage: Wie funktioniert diese Suche? Was passiert beim Kopieren? Nach welcher Regel wird dieser Wert berechnet?

Die vorhandene Software liefert Anschauungsmaterial und überprüfbare Anhaltspunkte. Daraus kann eine präzisere Spezifikation entstehen. Genau hier wird REA interessant.

Reverse Engineering gibt es seit Jahrzehnten. Auch Analysewerkzeuge wie Ghidra, Hopper und IDA sind etabliert. REA macht sie für Agenten über eine gemeinsame Schnittstelle nutzbar und verbindet sie mit strukturierten Untersuchungsabläufen.

Mich interessiert daran vor allem der Umgang mit Gewissheit. REA unterscheidet in seinen Ergebnissen zwischen Beobachtungen, abgeleiteten Erkenntnissen und Annahmen. Belege behalten ihre Herkunft, ihre Grenzen und Verbindungen zu anderen Befunden.

Das hilft gegen einen vertrauten Fehler: Der Agent findet einen plausiblen Hinweis, formuliert eine überzeugende Erklärung und baut darauf weiter. Mit nachvollziehbaren Belegen und offenen Fragen lässt sich früher erkennen, wo eine Schlussfolgerung noch überprüft werden muss.

Das stärkste Beispiel ist unspektakulär. Beim Spiel DX-Ball wurde eine Funktion rekonstruiert, die aus einer horizontalen Position die Verteilung eines Sounds zwischen links und rechts berechnet. Die veröffentlichte Fallstudie berichtet von 3’205 Vergleichen mit dem ursprünglichen Maschinencode und 63 identischen kompilierten Funktionsbytes.

Hier wurde eine klar abgegrenzte Berechnung untersucht und geprüft. Der Nachbau des spielbaren Gesamtspiels war am dokumentierten Projektstand weiterhin in Arbeit. Gerade diese Grenze macht das Beispiel brauchbar.

Ein zweites Beispiel verfolgt in Notion den Weg eines Kopierbefehls durch die verschiedenen Schichten der Electron-Anwendung bis zur Zwischenablage. Die Fallstudie zeigt, welche Code-Stellen die Verbindung belegen. So wird aus «Kopieren funktioniert irgendwie» ein nachvollziehbarer Ablauf.

Die virale Erzählung springt dagegen schnell vom funktionierenden Ausschnitt zum vollständig ersetzten Produkt. PhotoCraft wird etwa als nachgebautes Photoshop herumgereicht. Das Projekt selbst bezeichnet sich als frühe Alpha und hält ausdrücklich fest, dass es Photoshop für die tägliche professionelle Arbeit noch nicht ersetzt.

Besonders aufschlussreich: PhotoCraft unterscheidet zwischen verbundenen Menübefehlen und tatsächlich übereinstimmendem Verhalten. Ein Menüpunkt kann vorhanden sein, während Tiefe, Kompatibilität oder Qualität der Funktion noch fehlen. Wer Software beurteilt, muss genau dort hinschauen.

Für den praktischen Einsatz würde ich deshalb klein anfangen. Eine bestimmte Funktion liefert eine überprüfbare Aufgabe. «Bau mir diese ganze Anwendung nach» liefert zunächst sehr viel Spielraum.

Auch die Datenfrage bleibt konkret. REA analysiert lokal, aber der Agent erhält die Ergebnisse. Bei einem Cloud-Modell können diese Informationen dessen Anbieter erreichen. Für interne Anwendungen gehört dieser Datenfluss zur Wahl des Setups.