Modernisierung und UI-Design

Unsere Position. Wir sind überzeugt: KI-getriebene Modernisierung funktioniert, nur nicht als Eins-zu-eins-Übersetzung des Codes (öffnet in einem neuen Tab). Zuerst entscheiden wir die Architektur und legen diese Entscheidungen als Kontext ab. Dann beschleunigt der Agent die repetitiven Teile.

Was macht ein System zum Legacy-System?

Legacy bemisst sich an den Kosten einer Änderung, nicht am Alter. Ein System ist in dem Maß Legacy, in dem sein Team es nicht mehr schnell und sicher ändern kann (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)). Das Video geht von der Definition aus Working Effectively with Legacy Code aus: Code ohne Tests. Es ergänzt die Fassung eines Continuous-Delivery-Praktikers, nach der Legacy ein System mit hohen Kosten für geschäftliche Änderungen ist. Nach diesem Maßstab ist ungetesteter Code, der heute Morgen committet wurde, schon Legacy. Ihn schützt nur das Gedächtnis der Person, die ihn geschrieben hat, bis Leute das Team wechseln (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)).

Das Video nennt drei Verluste, die ein System dorthin treiben. Geht das Feedback verloren, wird jede Änderung zum Glücksspiel. Teams schreiben dann neuen Code neben den alten, statt ihn zu reparieren, und kopieren, statt zu refactoren. Geht das Verständnis verloren, bleiben Module zurück, die das Team nicht erklären kann. Der Verlust des Ökosystems heißt: ein Compiler auf einer einzigen Maschine, eine Bibliothek eines pleitegegangenen Herstellers, eine Pipeline, die das System nicht mehr bauen kann. Das Alter gibt diesen Verlusten nur Zeit, sich festzusetzen. Ein altes System mit schnellen Tests, reproduzierbarem Build und einem Team, das es kennt, ist weniger Legacy als ein ungetesteter neuer Service, dessen Autor:in gegangen ist (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)).

Der Verlust des Verständnisses geht auf Peter Naurs Essay Programming as Theory Building (öffnet in einem neuen Tab) von 1985 zurück. Er argumentiert, das Programm sei die Theorie, die seine Entwickler:innen im Kopf haben. Code und Dokumentation sind nur zweitrangige Produkte. Ein Programm stirbt, wenn sich das Team auflöst, das diese Theorie trägt. Die Theorie allein aus der Dokumentation neu aufzubauen, nennt der Essay strikt unmöglich. Danach gehen die beiden Quellen auseinander. Der Essay wirft den alten Programmtext lieber weg und lässt ein neues Team das Problem frisch lösen. Das Video hält einen Big-Bang-Rewrite fast nie für den richtigen Anfang (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)). Uneins sind sie auch darin, ob sich die Theorie aufschreiben lässt. Laut Essay lässt sie sich nicht ausdrücken. Laut Video halten Akzeptanztests in der Sprache der Problemdomäne genug davon fest, damit eine Maschine es prüfen kann.

Das Video versteht Legacy als Richtung, in die jedes System driftet, solange niemand dagegen arbeitet. Die Ursache sind vernünftige lokale Entscheidungen, etwa den Test später zu schreiben oder für eine Demo etwas fest zu verdrahten. Das Ökosystem schützt es mit einer Deployment-Pipeline. Sie baut, testet und deployt bei jeder Änderung neu aus der Versionskontrolle. Eine sterbende Abhängigkeit scheitert dann heute, statt Jahre später aufzufallen, wenn das Team nicht mehr weiß, wie man das System baut (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)).

Für ein geerbtes System ergänzt es einen Triage-Schritt. Gefährlich sind Systeme, bei denen hohe Änderungskosten auf hohen Änderungsbedarf treffen. Ein hässliches System, das das Geschäft nicht ändern muss, kann bleiben, wie es ist. Ein Rewrite sollte eine Entscheidung mit beziffertem Aufwand sein und als Neubau laufen, weil das Team nicht genau weiß, was das alte System tut. Fachexpert:innen arbeiten dann über lange Zeiträume mit Entwickler:innen zusammen, um die Theorie wiederzuentdecken. Sonst gilt der taktische Weg: Characterization Tests, kleine Refactoring-Schritte, ein Anti-Corruption Layer und schrittweise Ablösung, wo der Nutzen die Kosten deckt (Modern Software Engineering - Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab)).

Wie helfen Agenten, Legacy-Systeme zu modernisieren?

Der Talk Modernisierung mit AI nennt die Größenordnung, bei der sich das lohnt: hunderttausend Zeilen undokumentierter Code, die ein Agent ohne zu ermüden liest (Modernisierung mit AI (öffnet in einem neuen Tab)). Thoughtworks hat gezeigt, dass sich eine funktionale Spezifikation allein von außen rekonstruieren lässt. KI-gesteuertes Browsing und Datenerfassung bauten dort ein Legacy-System ohne Zugriff auf den Quellcode von Grund auf neu. Change Data Capture auf der Datenbank erwies sich als aufwandsarmer Weg, das Backend-Verhalten zu zerlegen. Trigger protokollierten pro Klick die Inserts und Updates, dazu kam ein eigener MCP-Server (Thoughtworks - Blackbox reverse engineering with AI (öffnet in einem neuen Tab)). Läuft der Discovery-Agent mehrmals und führt ein separater Schritt die Läufe zusammen, zeigen sich Verzweigungen, die ein einzelner Durchlauf übersieht. Baut das Modell aus der Spec einen Prototyp, werden Mehrdeutigkeiten sichtbar, die auf dem Papier verborgen bleiben. Prototyping prüft so zugleich die Spec (Thoughtworks - Blackbox reverse engineering with AI (öffnet in einem neuen Tab)).

Darunter liegt ein Vorbehalt. Foundation Models werden mit idealisiertem öffentlichem Code trainiert, mit aufgeräumten Tutorials und vorzeigbaren Open-Source-Projekten. Echte Legacy-Systeme liegen deshalb außerhalb ihrer Trainingsverteilung, und das Tooling muss das ausgleichen (INNOQ - Softwaremodernisierung mit GenAI (YouTube) (öffnet in einem neuen Tab)).

Das verlässliche Muster grenzt das Modell mit deterministischem Tooling ein, statt es auf die ganze Codebasis loszulassen. TNG verwarf bei seiner Migration von PL/I nach Java die Übersetzung ganzer Module in einem Schritt. Sie ließ sich nicht verifizieren und gefährdete die Integrität der Datenbank. Stattdessen trug ein deterministischer Parser die Struktur, und das LLM übernahm nur kleine lokale Übersetzungen. So bleiben Halluzinationen im direkten Vergleich mit dem Original erkennbar (TNG - AI-assisted PL/I to Java migration (öffnet in einem neuen Tab)). Der INNOQ-Talk grenzt mit Tree-sitter zuerst die genauen Codebereiche ein und gibt dem Modell nur winzige Fragmente. Das lässt ihm möglichst wenig Raum für Fehler (INNOQ - Softwaremodernisierung mit GenAI (YouTube) (öffnet in einem neuen Tab)). Dieselbe Disziplin erklärt eine Feinheit beim Refactoring. Soll ein Agent Code verbessern, entwirft er innerhalb eurer Vorgaben ein neues Design, statt sichere Transformationen am Parse-Tree auszuführen. Echtes Refactoring braucht deshalb weiterhin ein deterministisches Refactoring-Tool (Modern Software Engineering - This Mental Model Changed How I Design Software FOREVER (öffnet in einem neuen Tab)).

Bei der Struktur hat TNG anders abgewogen als wir. Das Team blieb nah an der Quelle und verzichtete beim Übersetzen bewusst aufs Refactoring. Das hielt die Korrektheit prüfbar, kostete aber Boilerplate. Sein Bericht vom 19. August 2025 schätzt, dass die Zeit bis zur ersten lauffähigen Version gegenüber manueller Arbeit um 30 bis 75 % sinkt (TNG - AI-assisted PL/I to Java migration (öffnet in einem neuen Tab)).

Dieser Ablauf aus Spec und Neubau ist eine moderne, KI-beschleunigte Form von Clean-Room-Design. Dabei untersucht ein Team ein System und schreibt eine Spezifikation, ohne auf den Originalcode zurückzugreifen. Ein zweites, davon getrenntes Team implementiert allein aus dieser Spezifikation. Gegen Urheberrechtsansprüche lässt sich damit eine Verteidigung auf die unabhängige Schöpfung stützen, gegen Patente nicht (Clean-room design (Wikipedia) (öffnet in einem neuen Tab)). Zwei praktische Warnungen kehren wieder. LLMs planen inkrementelle Builds schlecht. Ihr Instinkt ist, das ganze komplexe Feature auf einmal zu bauen statt mit dem Einfachsten zu beginnen, also verantwortet der Mensch die Reihenfolge (Thoughtworks - Blackbox reverse engineering with AI (öffnet in einem neuen Tab)). Außerdem wollen verschiedene Nutzer:innen unterschiedlich viel Autonomie. Das spricht für einen Autonomie-Regler statt einer festen Stufe: Methode für Methode für alle, die Kontrolle suchen, im Batch für alle, die delegieren (TNG - AI-assisted PL/I to Java migration (öffnet in einem neuen Tab)).

Paritätstests in natürlicher Sprache (“Click the + icon to create a new opportunity”) laufen gegen das alte System und gegen einen anders gebauten Ersatz. Das geht, weil sie an keine DOM-Struktur gebunden sind (Thoughtworks - Blackbox reverse engineering with AI (öffnet in einem neuen Tab)). Für parallele Modernisierungsarbeit lässt sich jeder Agent in einem eigenen Git-Worktree und Container isolieren. Ist alles grün, wird automatisch gemergt, bei einem Fehlschlag automatisch gelöscht. So arbeiten die Agenten ohne Konflikte (Modernisierung mit AI (öffnet in einem neuen Tab)).

Modernisierung in abgegrenzten Schritten

Anthropics Code Modernization Playbook (öffnet in einem neuen Tab) ergänzt eine nützliche Abfolge, um von der Untersuchung zur wiederholbaren Migration zu kommen.

1. Bereitschaft prüfen. Erfasst Geschäftsregeln, Abhängigkeiten, Datengrenzen, vorhandene Tests, den Deploy-Weg und die bekannten Risiken des Systems. Wählt eine abgegrenzte Komponente, deren Verhalten sich beobachten und vergleichen lässt.
2. Baseline festlegen. Haltet das aktuelle Verhalten fest, bevor ihr Ersatzcode generiert. Baut Characterization Tests, zeichnet repräsentative Ein- und Ausgaben auf und kartiert die Abhängigkeiten, die den ersten Slice einschränken.
3. Einen Slice migrieren. Haltet die erste Änderung so klein, dass ihr sie direkt neben dem Original validieren könnt. Bewahrt das Verhalten, bevor ihr die Struktur neu entwerft. Lasst alten und neuen Pfad parallel laufen, wo das Risiko es rechtfertigt.
4. Die wiederholbaren Teile skalieren. Übernehmt die Tests, Konvertierungsregeln, Abhängigkeitskarten und Review-Kriterien, die den ersten Slice überstanden haben. Weitet erst aus, wenn die nächste Migration dieselben Belege und Gates nutzen kann.

In dieser Abfolge kommt das Prüfen vor dem Generieren. Agenten können Regeln extrahieren, Spezifikationen entwerfen und lokale Fragmente übersetzen. Deterministische Parser, Tests und Vergleiche mit der Produktion entscheiden, ob das Ergebnis gleichwertig genug ist, um weiterzumachen.

Wie verhindert ihr, dass generierte UI generisch aussieht?

Anthropics Arbeit zum Frontend-Design benennt das Kernproblem generierter UI: Distributional Convergence. Modelle sagen Tokens aus statistischen Mustern ihrer Trainingsdaten vorher, und dort dominieren sichere Designentscheidungen. Ohne Steuerung greift das Modell deshalb zum Wahrscheinlichsten aus der Mitte der Verteilung. Heraus kommt eine generische Ästhetik, die die Markenidentität untergräbt und sofort als KI-Ausgabe erkennbar ist (Claude - Improving frontend design through Skills (öffnet in einem neuen Tab)).

Dagegen hilft es, gezielt auf der richtigen Flughöhe zu steuern: weder mit fest codierten Hex-Werten noch mit vagen Geschmackswörtern. Gemeint sind Vorgaben zu Typografie, Themes, Motion und Hintergründen, die sich sauber in umsetzbaren Frontend-Code übertragen lassen. Anthropic hat das in einem Skill für Frontend-Ästhetik mit rund 400 Tokens verdichtet. Er verbessert die Ausgabe in diesen Dimensionen messbar und lädt nur bei Bedarf, sodass andere Aufgaben keinen Design-Kontext mittragen (Claude - Improving frontend design through Skills (öffnet in einem neuen Tab)). Für Teams folgt daraus: Designvorgaben gehören in versionierte, ladbare Artefakte wie Skills und Design-System-Dokumente, nicht in Ad-hoc-Prompts. Die Komponentenbibliotheken und Design-Tools auf Architektur und Design geben diesen Vorgaben konkrete, prüfbare Ziele.

Designvorgaben gehören in ein eigenes Artefakt. Eine eigene Design-Datei bleibt getrennt von der CLAUDE.md, die in jeder Sitzung geladen ist und den Agenten sonst bei Arbeit ohne Designbezug ablenken würde. Mit dieser Datei als Übergabe kann jeder Agent das visuelle System rekonstruieren (AI Labs - Three levels of AI UI design (YouTube) (öffnet in einem neuen Tab)). Auf der Ebene der Design-Tokens liefern Farben in OKLCH (Helligkeit, Chroma, Farbton) statt in Hex oder HSL Ergebnisse, die das Auge als gleichmäßiger wahrnimmt, und weichere Verläufe (AI Labs - Three levels of AI UI design (YouTube) (öffnet in einem neuen Tab)). Und Design lässt sich testgetrieben entwickeln. Mit der Design-Datei als Source of Truth wird jedes Anti-Pattern, jede Farbregel, jede Abstandsvorgabe und jede Typografie-Entscheidung zu einer programmatischen Prüfung. Statische Anti-Pattern-Tests laufen dabei zusammen mit Visual-Regression-Läufen in Playwright (AI Labs - Three levels of AI UI design (YouTube) (öffnet in einem neuen Tab)).

Eine weit verbreitete Open-Source-Skill-Familie macht dieselbe Steuerung einstellbar statt fest. Ihr Standard-Skill beginnt mit drei numerischen Reglern: Layout-Varianz, Motion-Intensität und visuelle Dichte, jeweils auf einer Skala von eins bis zehn. Wie weit ein Design gehen soll, legt ein Team damit als Parameter pro Projekt fest, statt in Prosa darüber zu streiten. Ein Skill bedient so eine luftige Marketingseite ebenso wie ein dichtes Dashboard. Welche Bildsprache ein Design verfolgt, bestimmt der geladene Skill, nicht eine längere Instruktion. Dafür gibt es eigene Varianten für redaktionellen Minimalismus, Brutalismus und weichen High-End-Schliff, dazu eine strengere Variante für eine andere Modellfamilie. Zwei Trennungen im Workflow sind auch unabhängig von der Ästhetik nachahmenswert. Eine Image-first-Pipeline erzeugt Referenzentwürfe, analysiert sie und setzt erst danach das passende Frontend um. Die Art Direction wird so zu einem Artefakt, das sich reviewen lässt, bevor Code existiert. Ein Audit-first-Protokoll für bestehende Oberflächen prüft die aktuelle UI, bevor es etwas ändert. Das ist dieselbe Baseline-Disziplin, die die Modernisierungsabfolge oben auf Legacy-Code anwendet. Weil die Regeln auf die Designabsicht zielen statt auf eine Framework-API, gelten sie für React, Vue und Svelte gleichermaßen (Taste Skill (öffnet in einem neuen Tab)).

Ein Design-Canvas kann auch innerhalb der Agenten-Schleife sitzen statt davor. pen.dev, früher pencil.dev, beschreibt sich als agentisches Canvas: Agenten gestalten direkt auf dem Canvas. Claude Code, Codex, Cursor und andere Agenten erreichen es über MCP, WebMCP oder eine Headless-CLI. Es importiert Figma-Dateien und Live-Webseiten als editierbare Ebenen. Jeden Frame exportiert es als HTML mit CSS oder Tailwind, sodass Design und Code von einem Artefakt ausgehen (pen.dev (öffnet in einem neuen Tab), Stand September 2026).

Impeccable, ein Skill für Coding-Agents unter Apache 2.0, macht aus der testgetriebenen Idee ein Tool und ergänzt zwei Kontextdateien. PRODUCT.md hält fest, wer die Nutzer:innen sind, wofür das Produkt da ist und welche Prinzipien gelten. Die Design-Befehle lesen diese Datei, bevor sie handeln. DESIGN.md hält das visuelle System fest. Der Befehl document schreibt diese Datei aus dem, was schon ausgeliefert ist, statt sie einem Team abzuverlangen. Der Detektor prüft Quelldateien oder eine gerenderte URL auf zu geringen Kontrast, überlaufenden Text und gängige KI-Designmuster. Er erkennt auch Abweichungen von den Schriften, Farben, Eckenradien und Schriftgrößen, die DESIGN.md dokumentiert. Er läuft im Code, ohne Modell und ohne API-Key. Als Agent-Hook eingebunden, prüft er jede UI-Änderung und gibt die Befunde an den Agenten zurück. In der CI endet er mit 0, wenn alles sauber ist, mit 2 bei Befunden und mit 1, wenn sich ein Ziel nicht scannen ließ (Impeccable (öffnet in einem neuen Tab); Run a detector scan (öffnet in einem neuen Tab), Stand Oktober 2026). Sein Anti-Pattern-Katalog behandelt die Erkennungszeichen von KI-Design als bewegliches Ziel, das sich mit der Ära und dem Modell verschiebt. Die Reihe reicht von lila Verläufen und Glas-Panels über beige Editorial-Layouts bis zu einem neobrutalistischen Look, den eine Modellfamilie bevorzugt. Eine Liste verbotener Muster braucht deshalb Pflege, einmal schreiben reicht nicht. Stand Oktober 2026 listet die Katalogseite 68 Regeln, während die Startseite mit 62 Prüfungen wirbt (Slop (öffnet in einem neuen Tab)).

Dasselbe Projekt hat einen Kampagnenbericht darüber veröffentlicht, wie man einem Design-Modell Vielfalt entlockt. Die Kampagne lief im Juli 2026 auf dem eigenen Skill, mit rund 200 gesampelten Konzepten und etwa 2.600 $ für Evaluationen (The Model Can’t Roll Its Own Dice (öffnet in einem neuen Tab)). Nach Kreativität zu fragen, verbreiterte die Bandbreite nicht. Über sechzehn kreative Rahmungen hinweg schlugen 30 von 35 Antworten dasselbe Konzept vor. Die Instruktion, die ersten Ideen zu verwerfen, landete zuverlässig beim zweiten Standard des Modells. Und wählte ein Modell aus seiner eigenen vielfältigen Shortlist, nahm es in 27 von 30 Fällen Option eins. Funktioniert hat, die Aufgaben zu trennen. Das Modell schlägt Richtungen vor, die in der Zielgruppe gründen. Ein Skript lost aus, welche davon gebaut wird, und bewahrt einen Schlüssel auf, der die Ziehung reproduziert. Zwei weitere Befunde tragen über Design hinaus. Warnende Instruktionen machten die Ausgabe zaghaft. Den größten Qualitätsgewinn der Kampagne brachte es, den Prompt umzuordnen: zuerst auf das Konzept festlegen, danach an der Klarheit feilen. Außerdem fügte ein Builder, der seine eigene Struktur mitten im Bau bewertete, Arbeit hinzu und senkte die Qualität. Ein separater Reviewer-Agent dagegen verglich die gerenderte Seite mit einem schriftlichen Richtungsvertrag und fand die Lücken. Das zentrale Ergebnis ist eine Selbstauskunft des Anbieters mit benanntem Geltungsbereich. Auf den vertieft untersuchten Aufgaben gewann der finale Workflow jedes entscheidende Screenshot-Paar gegen den stärksten Vergleichs-Skill. Bewertet hat ein Modell, in beiden Reihenfolgen der Präsentation. Laut Bericht ist das keine Gewinnquote über alle Aufgaben oder Modelle (The Model Can’t Roll Its Own Dice (öffnet in einem neuen Tab)).

Verwandte Seiten

• Specs, Tests und Kontext: wie eine rekonstruierte Spezifikation und ihre Tests entscheiden, was als korrekt gilt.
• Architekturarbeit im agentischen Zeitalter: warum die Architekturentscheidung fällt, bevor der Agent Code schreibt.
• Videos mit Coding-Agents erstellen: dasselbe Problem von Steuerung und Review, für Bewegtbild statt Bildschirme.
• Das Qualitätssystem rund um den Coding-Agenten: die Gates, die verhindern, dass generierter Code eine Codebasis verschlechtert.
• Skills schreiben: wie ihr Designvorgaben als Artefakt schreibt, das der Agent bei Bedarf lädt.

Quellen

Legacy-Systeme

• Why Good Codebases Go Bad (And How to Stop It) (öffnet in einem neuen Tab) - Video von Modern Software Engineering aus dem Oktober 2026. Es definiert Legacy über die verlorene Fähigkeit, sicher zu ändern, statt über das Alter, und zeigt einen Weg zurück.

Leitlinien für UI-Design

• Impeccable (öffnet in einem neuen Tab) - Design-Skill für Coding-Agents unter Apache 2.0, mit zwei Dutzend Befehlen, den Kontextdateien PRODUCT.md und DESIGN.md und einem Anti-Pattern-Detektor ohne Modell für Hooks und CI.
• Taste Skill (öffnet in einem neuen Tab) - Skill-Familie unter MIT-Lizenz für KI-generierte Frontends, mit numerischen Reglern für Varianz, Motion und Dichte, Varianten pro Ästhetik und einer Image-first-Pipeline von der Referenz zum Code.
• pen.dev (öffnet in einem neuen Tab) - Agentisches Design-Canvas, das Coding-Agents über MCP oder eine CLI steuern, mit Figma-Import und Export nach HTML und Tailwind.