🤖 AI

Specification-Based Code-Text-Code Reengineering for LLM-Mediated Software Evolution

Dieser Beitrag schlägt ein spezifikationsbasiertes Code2Text2Code-Reengineering-Framework vor, das semantische Abweichungen und Verhaltensinkonsistenzen in der von LLMs vermittelten Softwareevolution mindert, indem es Quellcode in eine neutrale textuelle Spezifikation zur iterativen Verifikation umwandelt, bevor der Zielcode neu generiert wird.

Ursprüngliche Autoren: Oleg Grynets, Vasyl Lyashkevych, Arsen Dolichnyi, Roman Piznak, Taras Zelenyy, Volodymyr Morozov

Veröffentlicht 2026-05-26

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Oleg Grynets, Vasyl Lyashkevych, Arsen Dolichnyi, Roman Piznak, Taras Zelenyy, Volodymyr Morozov

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, ein komplexes, handschriftliches Rezept aus der Küche eines Großelterns aus dem Ukraine der 1950er-Jahre in eine moderne, digitale Rezept-App für einen Smart-Backofen im Jahr 2024 zu übersetzen.

Wenn Sie einen Übersetzer (eine KI) einfach bitten, „dieses alte Rezept in ein neues zu verwandeln", könnten sie zwar die Wörter richtig treffen, aber beim Kochen alles verderben. Sie könnten weiterhin eine Anweisung für einen „Holzlöffel" verwenden, obwohl der neue Backofen einen „digitalen Sensor" benötigt, oder sie fügen versehentlich eine „geheime Zutat" hinzu, die im Original nicht enthalten war. Das Ergebnis sieht zwar wie ein Rezept aus, könnte aber Ihren Kuchen verbrennen.

Dieser Artikel schlägt einen intelligenteren Weg vor, diese Übersetzung nicht nur für Rezepte, sondern für Computersoftware durchzuführen. Sie nennen dies Code–Text–Code-Reengineering.

So funktioniert es, aufgeschlüsselt in einfache Schritte:

1. Das Problem: Die Falle der „direkten Übersetzung"

Normalerweise führen Menschen, wenn sie KI nutzen, um Software von einer Sprache in eine andere zu ändern (wie den Wechsel von Python zu Java), eine Code-zu-Code-Übersetzung durch.

Das Risiko: Die KI könnte den Stil des alten Codes kopieren, anstatt die Bedeutung zu erfassen. Es ist, als würde man ein Wort-für-Wort-Gedicht übersetzen und die Emotion verlieren. Der neue Code mag korrekt aussehen, sich aber anders verhalten, oder er könnte verborgene Regeln übersehen, auf die der alte Code angewiesen war.

2. Die Lösung: Der „neutrale Übersetzer" (der Zwischenhändler)

Anstatt direkt vom alten Code zum neuen Code zu springen, fügen die Autoren einen Zwischenschritt ein: Die neutrale Textspezifikation.

Stellen Sie sich dies als einen detaillierten, in einfacher Sprache verfassten Bauplan vor, der beschreibt, was die Software tut, ohne zu erwähnen, wie sie in der alten Sprache aufgebaut war.

Schritt 1 (Code zu Text): Die KI liest den alten Code und schreibt eine neutrale Beschreibung. Sie sagt Dinge wie: „Diese Funktion nimmt eine Liste von Zahlen, addiert sie und speichert das Ergebnis in einer Datenbank." Sie ignoriert die spezifischen Programmiertricks, die im alten Code verwendet wurden.
Schritt 2 (Die Prüfung): Menschen oder andere Werkzeuge prüfen diese Beschreibung, um sicherzustellen, dass sie perfekt mit dem Original übereinstimmt. Haben wir einen Schritt übersehen? Haben wir einen neuen erfunden?
Schritt 3 (Text zu Code): Die KI liest diese saubere, neutrale Beschreibung und schreibt den neuen Code in der Zielsprache. Da die KI den alten Code nicht mehr betrachtet, kopiert sie nicht versehentlich den alten Stil. Sie baut den neuen Code genau so auf, wie der Bauplan es beschreibt.

3. Die „Sicherheitsnetz"-Werkzeuge

Der Artikel erklärt, dass es hier nicht nur um das Schreiben von Text geht, sondern um den Aufbau eines Sicherheitssystems rund um den Prozess:

Der „Faktenprüfer" (Rückgewinnung): Bevor die KI etwas schreibt, sucht sie in einer Bibliothek aus Dokumenten, Diagrammen und Code-Schnipseln nach Fakten, um sicherzustellen, dass sie nicht rät. Es ist, als würde ein Koch vor dem Hinzufügen von Salz ein Kochbuch konsultieren.
Die „Chunking"-Strategie: Man kann nicht eine ganze Bibliothek von Büchern in einem Bissen lesen. Das System zerlegt den Code in kleine, logische „Chunks" (wie Kapitel), damit die KI nicht verwirrt wird oder Verbindungen verpasst.
Der „Bauplan" (Graphen und Ontologie): Das System erstellt eine Karte (einen Graphen), die zeigt, wie verschiedene Teile der Software miteinander verbunden sind. Wenn die alte Software eine Brücke zwischen zwei Inseln hatte, muss die neue Software dieselbe Brücke haben. Diese Karte hilft zu messen, ob die Übersetzung erfolgreich war.

4. Erfolg messen: Haben wir etwas verloren?

Wie weiß man, dass die neue Software dieselbe ist wie die alte? Die Autoren haben einen „Verlustrechner" entwickelt.
Stellen Sie sich vor, Sie bewegen Möbel von einem alten Haus in ein neues.

Strukturelle Erhaltung: Haben Sie alle Räume bewegt? (Ja/Nein)
Schnittstellenstabilität: Können Sie die Haustür immer noch auf die gleiche Weise öffnen? (Ja/Nein)
Gesamtähnlichkeit: Eine Punktzahl, die angibt, wie viel vom ursprünglichen „Haus" den Umzug überstanden hat.

5. Was sie fanden

Die Forscher testeten diese Methode an vielen verschiedenen Arten von Code (SQL-Datenbanken, Web-Skripte, allgemeine Programmierung).

Das Ergebnis: Die Verwendung des „neutrale Text"-Zwischenhändlers funktionierte besser als der Versuch, Code direkt zu übersetzen. Es reduzierte Fehler und ließ den neuen Code eher der ursprünglichen Absicht entsprechen.
Der Haken: Manchmal braucht die KI einen Menschen, der eingreift und einen verwirrenden Teil des alten Codes klärt. Es ist noch nicht vollständig automatisch; es ist ein „Mensch-im-Loop"-Prozess.

Das große Ganze

Dieser Artikel argumentiert, dass wir Software-Updates nicht als einfache „Kopieren-Einfügen"-Aufgabe behandeln sollten. Stattdessen sollten wir sie als Reengineering betrachten.

Alter Weg: „Hier ist der alte Code; gib mir den neuen Code." (Risikobehaftet, undurchsichtig).
Neuer Weg: „Hier ist der alte Code. Erkläre zuerst, was er in einfacher Sprache tut. Prüfe diese Erklärung. Baue dann den neuen Code basierend auf dieser Erklärung." (Sicher, transparent und kontrollierbar).

Kurz gesagt: Sie bringen der KI bei, aufzuhören, Wörter zu übersetzen, und anzufangen, Bedeutung zu übersetzen, wobei sie einen klaren, neutralen Bauplan verwenden, um sicherzustellen, dass beim Umzug nichts verloren geht.

Technische Zusammenfassung: Spezifikationsbasierte Code–Text–Code-Reverse-Engineering für LLM-vermittelte Softwareevolution

1. Problemstellung

Large Language Models (LLMs) werden zunehmend für Softwaremigration, Refaktorisierung und Code-Regenerierung eingesetzt. Direkte Code-zu-Code-Transformationsansätze stoßen jedoch auf erhebliche Grenzen. Dazu gehören:

Semantische Drift: Modelle können die oberflächliche Syntax bewahren, während sie die zugrunde liegende Geschäftslogik verändern oder versteckte Verhaltensänderungen einführen.
Nicht-idiomatische Ausgabe: Generierter Code kann Konstrukte der Quellsprache beibehalten, die für die Zielumgebung unangemessen sind.
Verlust der Nachverfolgbarkeit: Oft besteht keine klare Verbindung zwischen dem Quellcode, der Interpretation des Modells und dem regenerierten Artefakt.
Kontextlücken: Die direkte Übersetzung berücksichtigt häufig Datenabhängigkeiten, Fehlerbehandlung und nicht-funktionale Annahmen nicht.

Die Arbeit argumentiert, dass LLM-vermittelte Softwareevolution nicht lediglich als Code-Generierung betrachtet werden sollte, sondern als ein kontrollierter Reverse-Engineering-Prozess, der Zwischenschichten der Repräsentation erfordert, um semantische Konsistenz und strukturelle Erhaltung sicherzustellen.

2. Methodik: Das Code–Text–Code-Framework

Das vorgeschlagene Framework führt ein spezifikationsbasiertes Code–Text–Code-Reverse-Engineering-Modell ein. Der Kern-Transformationsfluss ist definiert als:
$C_0 \rightarrow S_n \rightarrow C_1$
Wobei $C_0$ der Quellcode ist, $S_n$ eine neutrale textliche Spezifikation und $C_1$ der regenerierte Zielcode ist.

A. Die neutrale textliche Spezifikation ( $S_n$ )

Im Gegensatz zur einfachen Code-Zusammenfassung ist $S_n$ ein strukturiertes, verifizierbares Artefakt, das Folgendes erfasst:

Programmverhalten, Bezeichner und den rechnerischen Ablauf.
Bedingungen, Nebeneffekte und Datenabhängigkeiten.
Domänenspezifische Absichten ohne sprachspezifische Syntaxverzerrung.
Sie dient als „semantischer Mediator", der trennt, was die Software tut, von wie sie implementiert ist.

B. Schicht der Wissensrepräsentation

Das Framework integriert mehrere Repräsentationsschichten zur Unterstützung der Nachverfolgbarkeit und Validierung:

AST- und Metadaten-Extraktion: Strukturierte Extraktion von Fakten (Funktionsnamen, Signaturen, Abhängigkeiten), um den Generierungsprozess zu begrenzen und Halluzinationen zu reduzieren.
Ontologie und semantische Annotation: Abbildung von Zwischenrepräsentationen auf strukturiertes Wissen (OWL/SKOS) zur Unterstützung von Schlussfolgerungen und Wiederverwendung.
Graphenrepräsentation: Nutzung von Code Property Graphs (CPG) zur Verfolgung von Abhängigkeiten (Aufrufe, Lesezugriffe, Schreibzugriffe) und zur Schätzung von Transformationsverlusten.
Hybride Suche: Kombination von Vektorsuche (für semantische Ähnlichkeit) mit Graphendurchlauf (für strukturelle Abhängigkeiten) und Metadatenfilterung, um sowohl die Phase Code2Text als auch Text2Code zu fundieren.

C. Pipeline-Architektur

Die End-to-End-Pipeline umfasst:

Extraktion faktischer Kontexte: Sammeln von Bezeichnern und Abhängigkeiten vor der Spezifikationsgenerierung.
Code2Text-Generierung: Erstellen der initialen neutralen Spezifikation unter Verwendung von RAG und faktischem Kontext.
Iterative Validierung und Verfeinerung: Vergleich der Spezifikation mit dem Quellcode, um fehlendes Verhalten oder übermäßige Annahmen zu erkennen.
Mensch im Loop: Optionale Expertenkorrektur für mehrdeutige Geschäftslogik oder versteckte Annahmen.
Text2Code-Generierung: Erstellen des Zielcodes basierend auf der validierten Spezifikation, wobei eine idiomatische Implementierung in der Zielsprache sichergestellt wird.
Zielvalidierung: Validierung der Syntax, funktionaler Äquivalenz und Schnittstellenstabilität.
DBMS-Feedback (für SQL): Nutzung einer ausführungsbasierten Validierung, um dialektspezifische Korrektheit sicherzustellen.

D. Semantikbewusstes Chunking

Die Arbeit betont, dass naives Chunking semantische Einheiten zerstört. Es wird ein „idealer Code-Chunk" vorgeschlagen, definiert durch Atomizität, Selbstparsbarkeit und semantisches Bewusstsein, bewertet mittels Metriken wie Boundary F1 und Chunk Certainty.

3. Hauptbeiträge

Die Arbeit präsentiert fünf primäre Beiträge:

Konzeptionelle Interpretation: Umdeutung von Code–Text–Code nicht als Übersetzungspipeline, sondern als spezifikationsbasierten Reverse-Engineering-Prozess, bei dem der neutrale Text ein kontrolliertes Wissensartefakt ist.
Pipeline-Architektur: Ein umfassendes System, das faktische Extraktion, iterative Validierung, menschliche Korrektur und DBMS-unterstütztes Feedback integriert.
Modell der Wissensrepräsentation: Ein einheitliches Modell, das AST-Metadaten, Ontologien, Graphenabhängigkeiten und neutralen Text kombiniert, um Quellcode, Dokumentation und regenerierte Artefakte zu verknüpfen.
Experimentelle Evaluation: Ein Datensatz, der mehrere Sprachen (Java, Python, C++, SQL-Dialekte) abdeckt, sowie ein Evaluierungsprotokoll, das Zwischenrepräsentationen (Pseudocode, Graph IR, Compiler IR, Natural Language IR) vergleicht.
Formale Verlustschätzung: Eine graphenbasierte Formalisierung zur Quantifizierung von Transformationsverlusten unter Verwendung von:
- Richtungsbezogener struktureller Erhaltung ( $\alpha$ ): Messung der Beibehaltung von Quellabhängigkeiten.
- Reverse-Kompatibilität ( $\beta$ ): Messung der Einführung unnötiger Zielabhängigkeiten.
- Schnittstellen-Erhaltung ( $\delta_{IO}$ ): Sicherstellung der Stabilität von Ein- und Ausgaben.
- Gesamte Graph-Ähnlichkeit ( $S$ ): Ein gewogenes harmonisches Mittel der oben genannten Werte.

4. Experimentelle Ergebnisse

Die Autoren führten Experimente mit einem Datensatz von 1.000 Skripten pro Sprache über neun Programmiersprachen und fünf SQL-Dialekte hinweg durch.

Vergleich der Zwischenrepräsentationen: Natural Language IR (die neutrale Spezifikation) zeigte im Vergleich zu Pseudocode, graphenbasiertem IR oder compilerähnlichem IR die stärkste praktische Eignung für LLM-vermittelte Transformationen.
Evaluierung der Suche: Die Vektorsuche erwies sich als genauer für semantische Relevanz, während die Graphensuche eine geringere Latenz für die Navigation von Abhängigkeiten bot. Ein hybrider Ansatz wurde empfohlen.
Transformation von Dokumentation: In TechDoc-zu-BusinessDoc-Experimenten bestanden 22 von 24 Chunks die Validierung. Die Misserfolge betrafen Logikverzerrungen oder das Auslassen von Geltungsbereichen und unterstreichen die Notwendigkeit von Validierungsschleifen.
Prompt-Tuning: Unter Verwendung von DSPy/MIPROv2 stellten die Autoren fest, dass der ursprüngliche, sorgfältig eingeschränkte Basis-Prompt automatisch generierte Varianten übertraf. Dies deutet darauf hin, dass bei eingeschränkten Reverse-Engineering-Aufgaben explizite Einschränkungen (Neutralität, Struktur) kritischer sind als die Komplexität des Prompts.
Graphen-Metriken: Die formalen Metriken quantifizierten erfolgreich die strukturelle Erhaltung und Schnittstellenstabilität und lieferten eine Methode, um „plausible, aber falsche" Transformationen zu erkennen.

5. Bedeutung und Behauptungen

Die Arbeit behauptet, dass die spezifikationsbasierte Code–Text–Code-Reverse-Engineering eine kontrollierte, nachverfolgbare und überwachbare Alternative zur undurchsichtigen direkten Code-Generierung bietet.

Transparenz: Durch die explizite Darstellung der Zwischenspezifikation wird die Interpretation des Modells sichtbar, überprüfbar und korrigierbar.
Qualitätskontrolle: Das Framework geht über lokale syntaktische Korrektheit hinaus, um semantische Abdeckung, Fundierung der Suche und strukturelle Erhaltung zu bewerten.
Intelligente Überwachung: Die Autoren positionieren das Framework nicht nur als Transformationswerkzeug, sondern als Objekt der „intelligenten Überwachung", bei der semantische Konsistenz und Transformationsverluste kontinuierlich bewertet werden.
Reverse-Engineering vs. Übersetzung: Die Arbeit stellt fest, dass die durch LLMs vermittelte Softwareevolution einen Wechsel von der einfachen Übersetzung zu einem mehrstufigen Repräsentationsprozess erfordert, der Code, technische Dokumentation, Geschäftsanforderungen und Graphenstrukturen umfasst.

Die Arbeit schließt, dass der Ansatz zwar vielversprechend ist, jedoch eine sorgfältige Behandlung von Chunking, Fundierung der Suche und Validierung durch den Menschen im Loop erfordert, um Risiken wie semantische Drift und Halluzinationen zu mindern, insbesondere in hochriskanten Bereichen wie Finanz- oder Gesundheitssystemen.