Kurzfassung
BridGenta ist eine Rekonstruktionsplattform für Altsysteme, die bestehende Software analysiert und diese strukturiert auf die Integration moderner AI Builder vorbereitet. Dieses Dokument richtet sich an Systemarchitekten, Software-Ingenieure und IT-Entscheidungsträger, die Migrationsprozesse mit künstlicher Intelligenz steuern und absichern möchten.
Während moderne Codegeneratoren Benutzeroberflächen schnell erstellen können, liegt die eigentliche Herausforderung nicht im Schreiben von Code, sondern in der präzisen Aufbereitung und Verifikation des Wissens aus Altsystemen. Der Geltungsbereich dieses Berichts umfasst die architektonischen Schutzschichten (Preservation Layers), den strukturierten Rekonstruktions-Workflow sowie die quantitativen Validierungsergebnisse des Pilotprojekts.
BridGenta erstellt hierzu strukturierte Modelle und erzeugt ein Reconstruction Package, das das erfasste Systemwissen für die KI-gestützte Weiterentwicklung konsolidiert. Die Plattform demonstriert, wie Entwickler veraltete Software beschleunigt migrieren können, während gleichzeitig der Schutz sensibler Daten im Pilotprojekt gewahrt blieb.
Warum dieses Projekt entstand
Die rasante Verbreitung generativer KI-Werkzeuge verändert die Softwareentwicklung grundlegend: Obwohl einfache Logikbausteine heute in kürzester Zeit generiert werden können, stehen Entwicklungsteams vor der Hürde, diesen Code sicher in bestehende Legacy-Systeme zu integrieren.
Klassische Modernisierungsprojekte scheitern häufig an unvollständiger Dokumentation, unkalkulierbaren Migrationskosten und neu entstehenden Sicherheitsrisiken. Künstliche Intelligenz kann diese Prozesse zwar beschleunigen, erfordert jedoch eine strikte Governance, um strukturelle Probleme wie Code Bloat und Architecture Drift systematisch zu reduzieren.
BridGenta kartiert bestehende Architekturen, sichert das implizite Systemwissen und stellt dieses als strukturiertes Datenmodell für die generative KI-Entwicklung bereit.
Künstliche Intelligenz beschleunigt die Codegenerierung erheblich, erfordert jedoch präzisen Kontext. Die methodische Wissenserfassung muss daher zwingend der Codegenerierung vorgeschaltet werden.
Ausgangssituation
Viele historisch gewachsene Webanwendungen in IT-Abteilungen weisen eine unzureichende Testabdeckung auf, nutzen veraltete Bibliotheken und weichen strukturell von modernen Architekturstandards ab. Da die ursprünglichen Entwicklerteams häufig nicht mehr zur Verfügung stehen, ist das Wissen über die interne Geschäftslogik im Unternehmen meist verloren gegangen.
Ein vollständiger manueller Neubau (Greenfield) birgt erhebliche Risiken und gefährdet die Betriebsstabilität im laufenden Geschäft. Moderne Sprachmodelle sind zwar in der Lage, Altsysteme automatisiert zu analysieren, doch führt ihr Einsatz ohne strukturierte Modelle und präzisen Kontext häufig zu Fehlern und willkürlichen Architekturentscheidungen.
Problemstellung
Die Modernisierung von Altsystemen ist zeitaufwendig und fehleranfällig. Werden KI-Generatoren ohne exakten Systemkontext eingesetzt, drohen unstrukturierter Code Bloat und gravierende Sicherheitslücken. Es fehlt an einem standardisierten Prozess, der das Systemwissen vor Beginn der Rekonstruktion systematisch erfasst, um die Entwicklungsgeschwindigkeit von KI-Werkzeugen kontrolliert nutzbar zu machen.
Rahmenbedingungen
Die Realisierung von BridGenta unterliegt strengen technischen und operativen Rahmenbedingungen, die den Entwicklungsspielraum definieren:
Datensicherheit und Geheimnisschutz
Um das Risiko eines unbefugten Zugriffs von KI-Modellen auf sensible Kundendaten oder kryptografische Schlüssel zu reduzieren, wird das Frontend logisch und physisch von den Gateways isoliert.
Manuelle Qualitätssicherung (Branch-Gating)
Da generative KI fehlerhaften Code erzeugen kann, ist eine automatisierte Übernahme in den Main Branch ausgeschlossen; jede Codeänderung erfordert ein manuelles Review durch einen menschlichen Prüfer.
Architekturkonsistenz
Die Anwendung basiert auf einer konsequent modularen Architektur. Dadurch bleiben KI-generierte Änderungen lokal isoliert und haben keine unerwünschten Nebeneffekte auf andere Systemkomponenten.
Sicherheits- und Datenschutzgrenzen müssen als feste technische Schutzgrenzen implementiert werden. Sie dürfen nicht von der Zuverlässigkeit des KI-Modells abhängen, sondern müssen durch den Workflow und die Systemarchitektur erzwungen werden.
Rekonstruktionsstrategie
Die Methode von BridGenta unterteilt die Modernisierung in sechs Phasen, wodurch der gesamte Prozess kontrolliert bleibt:
Phase 1: Beobachten
Das System analysiert die alte Anwendung und protokolliert die Datenströme im laufenden Betrieb.
Phase 2: Verstehen
Der Architekt dokumentiert alle Abhängigkeiten und erfasst die Logik im isolierten Workspace.
Phase 3: Kartieren
Wir legen die Schnittstellen fest und grenzen die neuen Teile des Systems ab.
Phase 4: Rekonstruieren
Die KI generiert den neuen Code basierend auf präzisen Anweisungen in einem geschützten Bereich.
Phase 5: Validieren
Automatische Tests und menschliche Prüfer kontrollieren den generierten Code sorgfältig.
Phase 6: Übergabe
Der geprüfte Code wird kontrolliert in das Repository integriert.
Die Phasenstruktur minimiert Projektrisiken, indem sie die Analyse des Altsystems strikt von der Codegenerierung trennt und die KI auf klar definierte Vorgaben beschränkt.
Technische Überlegungen
Die Modernisierung geschäftskritischer Systeme scheitert selten an mangelnder Entwicklungsgeschwindigkeit, sondern meist an unkontrollierter Komplexität. Ein vollständiger Neubau (Greenfield-Ansatz) führt mangels ausreichender Dokumentation häufig zum Verlust historisch gewachsener Geschäftslogik. BridGenta setzt daher auf eine kontrollierte, inkrementelle Rekonstruktion statt auf eine risikoreiche Komplettablösung.
Der Prozess folgt der Leitlinie: Zuerst verstehen, danach rekonstruieren. Der Codegenerierung geht stets eine detaillierte Dekonstruktion und Modularisierung der Altsystem-Logik voraus.
Die KI fungiert als Entwicklungsbeschleuniger, nicht als Systemarchitekt: Während sie isolierte Bausteine effizient implementieren kann, fehlt ihr der globale Systemüberblick. Um Architecture Drift und Sicherheitsrisiken zu vermeiden, führt der menschliche Architekt den Prozess und setzt die Einhaltung architektonischer Vorgaben durch. Dadurch soll das Risiko minimiert werden, dass die KI fehlerhaften Code oder Sicherheitsrisiken einbaut.
Eine erfolgreiche Rekonstruktion entkoppelt die Systemanalyse von der eigentlichen Implementierung: Die Definition der Schnittstellen durch den Architekten bildet die zwingende Voraussetzung für die anschließende KI-gestützte Codegenerierung.
Fähigkeitsbereiche und Intelligence Domains
Die Plattform stützt sich auf sieben funktionale Domänen (Intelligence Domains), die den Rekonstruktionsprozess präzise steuern:
- Source Intelligence (Quellcodeanalyse): Analysiert den Altcode statisch, um technische Schulden, veraltete Bibliotheken und verdeckte Systemabhängigkeiten zu identifizieren.
- Reconstruction Intelligence (Schnittstellendesign): Modelliert zukünftige Systemschnittstellen und definiert präzise Datenflüsse auf Basis der Analyseergebnisse.
- Preservation Intelligence (Verhaltenserhaltung): Spezifiziert und konserviert das funktionale Verhalten des Altsystems über mehrere Abstraktionsebenen hinweg.
- Cross-Layer Intelligence (Schichtenverifikation): Validiert Daten- und Logikkonsistenz über alle Anwendungsschichten hinweg, um Integrationsfehler frühzeitig zu blockieren.
- Human Review (Manuelle Freigabe): Visualisiert Codeänderungen für den Systemarchitekten, um die endgültige Entscheidung und Freigabeverantwortung beim Menschen zu belassen.
- Governance (Regelwerksprüfung): Überwacht Qualitätsmetriken und erzwingt Sicherheits- sowie Compliance-Richtlinien vor der Code-Integration.
- Export Intelligence (Paket-Ausgabe): Bündelt die rekonstruierten Datenmodelle und Metadaten in ein standardisiertes Übergabepaket für nachgelagerte Entwicklungsumgebungen.
Architektur und Preservation Layers
Die Softwarearchitektur ist konsequent modular aufgebaut, wobei die Analyseumgebung physisch von den produktiven Datenbeständen isoliert ist. Die Plattform implementiert drei Abstraktionsschichten (Preservation Layers), um alle relevanten Systemeigenschaften abzubilden:
- Visibility Preservation Layer (VPL): Erfasst Schnittstellendeklarationen und strukturelle Abhängigkeiten, um die Observability des Gesamtsystems zu unterstützen.
- Experience Preservation Layer (EPL): Spezifiziert und dokumentiert das dynamische Laufzeitverhalten, Benutzerpfade und Zustandsübergänge der Anwendung.
- Design Preservation Layer (DPL): Konserviert die visuelle Identität der Benutzeroberfläche durch systematische Erfassung von CSS-Klassen, Layout-Rastern und Design-Tokens.
Die Kombination dieser drei Schichten unterstützt ein strukturiertes Abbild der im Analyseumfang erfassten Systemeigenschaften und dient als Grundlage für das Reconstruction Package.
Technische Entscheidungen
Im Vorfeld der Entwicklung wurden kritische Architekturentscheidungen getroffen, um die Stabilität und Datensicherheit der Plattform zu sichern:
Inkrementelle IT-Rekonstruktion
Minimierung des operativen Risikos im Vergleich zu einer klassischen Big-Bang-Migration.
Wir modernisieren das System schrittweise; im Pilotbetrieb traten keine Ausfälle auf.
Kontextreiche Wissensmodellierung
Vermeidung von AI Hallucinations durch Bereitstellung von strukturiertem Systemkontext.
Die Plattform liefert genaue Datenpakete als Arbeitsgrundlage.
Logische Datentrennung (Gateway)
Wir schützen sensible Daten vor dem Zugriff der KI.
Risikominimierung durch UI-Isolation: Die KI agiert ausschließlich auf der UI-Ebene.
Git-basiertes Branch-Gating
Wir verhindern, dass die KI ungeprüften Code in das System einfügt.
Jeder KI-generierte Code wird vor der Integration einem manuellen Review unterzogen.
Umsetzung
Um die Vorteile der KI-gestützten Entwicklung mit den Qualitätsansprüchen professioneller Softwareentwicklung zu vereinen, wurde ein mehrstufiger, qualitätsgesicherter Workflow innerhalb der Entwicklungsplattform etabliert:
Arbeitsbereich: Systemanalyse und Isolierung
Der Workspace bildet den Einstieg für jede Rekonstruktion: Über die Workspace-Kernmodule der privaten BridGenta-Core-Codebasis erfassen wir bestehende Systemkomponenten und kartieren deren Abhängigkeiten mithilfe interner statischer Analysewerkzeuge. Durch diese Datenflussisolierung analysieren wir die Altanwendung und definieren präzise Schnittstellen. Die visuelle Isolation im Workspace soll dazu beitragen, das Risiko unbeabsichtigter Nebeneffekte zu minimieren und eine gezielte, modulweise Modernisierung zu unterstützen.
Arbeitsablauf: Strukturierte Codegenerierung
Der kontrollierte Modernisierungs-Workflow steuert die Codegenerierung mittels interner Skripte und Prompts der privaten BridGenta-Core-Codebasis. Der generierte Code wird über dedizierte Handoff-Branches in die im CI/CD-Prüfprozess konfigurierten Pipelines eingespeist, wo automatisierte Tests und manuelle Reviews stattfinden.
Governance: Validierung und Qualitätskontrolle
Die Governance-Ebene unterzieht vorgesehene Codeänderungen vor der Freigabe definierten Prüfungen. Eine Freigabeentscheidung erfolgt erst nach den vorgesehenen Prüfungen zu Lizenzen, technischen Datenschutzvorgaben und Sicherheitsregeln sowie nach dokumentiertem Testlauf und menschlichem Review. Ein restriktives Regelwerk soll dazu beitragen, das Risiko eines Datenabflusses und KI-bedingter logischer Fehler zu reduzieren.
Validierung
Die Qualitätssicherung und Validierung der rekonstruierten Module folgt einer Teststrategie, die automatisierte Prüfschleifen mit manuellen Kontrollen kombiniert. Dies dient der Verifikation, dass der generierte Code stabil, performant und regelkonform ist.
- Automatische Verifikation: Jedes rekonstruierte Modul wird in einer isolierten Sandbox-Umgebung automatisch kompiliert und gegen vordefinierte Unit-Tests geprüft. Linter und statische Code-Analysen dienen der Überprüfung der Codequalität und der Einhaltung von Programmierstandards.
- Sicherheits-Audits: Automatisierte Scanner prüfen den Quellcode auf Schwachstellen, hartcodierte Passwörter oder unsichere API-Aufrufe.
- Manueller Review (Architecture Gate): Ein erfahrener Systemarchitekt unterzieht Quellcode und Design vor der Integration in das Repository einem manuellen Review, um das Risiko von logischen Fehlern oder Abweichungen von den Design-Vorgaben zu minimieren.
Öffentliche Projekteinblicke
Ergebnisse
Durch den strukturierten Prozess wurden im Rahmen des Testlaufs messbare quantitative Erfolge erzielt:
| Metrik | Zielwert | Erreichter Wert | Status |
|---|---|---|---|
| Modernisierungs-Beschleunigung | > 30% Zeitersparnis | 45% Zeitersparnis | Übertroffen |
| Handoff-Stabilität | 100% konfliktfreie Integration | 100% konfliktfreie Integration | Erreicht |
| Datenflussprüfung | Keine Übertragung außerhalb der definierten Gateway-Regeln festgestellt | Im Pilotumfang beobachtet | Dokumentierter Prüflauf |
| Codequalität (SonarQube Gate) | Quality Gate A (bestanden) | Quality Gate A (bestanden) | Erreicht |
Hinweis zu den Metriken: Die quantitativen Werte wurden innerhalb des dokumentierten Pilotprojekts mit zehn Modulen und rund 50.000 Zeilen Quellcode in einer kontrollierten Testumgebung ermittelt. Sie beschreiben diesen konkreten Testumfang und stellen keine allgemeine Leistungs-, Sicherheits- oder Qualitätsgarantie für andere Projekte dar. In den protokollierten Prüfungen der kontrollierten Pilotumgebung wurden keine Datenübertragungen außerhalb der definierten Gateway-Regeln festgestellt. Diese Beobachtung ist auf die erfassten Datenflüsse, Regeln und Prüfprotokolle der Pilotumgebung begrenzt.
Handoff-Stabilität
100% der Code-Übergaben im Pilotlauf wurden über isolierte Branches konfliktfrei integriert.
Sicherheit
In den protokollierten Prüfungen der kontrollierten Pilotumgebung wurden keine Datenübertragungen außerhalb der definierten Gateway-Regeln festgestellt.
Wartbarkeit
Manuelle Reviews begleiteten die Prüfung, in deren dokumentiertem Pilotlauf Quality Gate A bestanden wurde und die Modulkomplexität innerhalb des erfassten Prüfumfangs bewertet wurde.
Risiken
Die Verwendung künstlicher Intelligenz zur Rekonstruktion birgt verbleibende Restrisiken, die durch gezielte Gegenmaßnahmen minimiert werden müssen:
| Risiko | Auswirkung | Gegenmaßnahme |
|---|---|---|
| Veralteter KI-Kontext (Knowledge Cutoff) | Die KI schlägt veraltete Entwurfsmuster oder ungeeignete Bibliotheken vor. | Laufzeitintegration aktueller Framework-Spezifikationen in das Reconstruction Package. |
| Unentdeckter Code Bloat | Der generierte Code enthält ungenutzte Funktionen oder redundante Logik. | Verpflichtendes manuelles Review und automatisierte Komplexitätsprüfungen. |
| Unvollständige Testabdeckung (Test Blind Spots) | Randfälle in der Legacy-Geschäftslogik werden nicht erfasst. | Kontinuierliche Erweiterung der Integrationstests im Validierungsbereich. |
Erkenntnisse aus der Entwicklung
Die Ergebnisse der KI-gestützten Validierung zeigen, dass die Kombination aus hoher Entwicklungsgeschwindigkeit und bewährten Kontrollmechanismen stabile Softwareprodukte unterstützen kann: Während die KI Routineaufgaben beschleunigt, bleibt die Letztkontrolle durch menschliche Prüfer unerlässlich, um Qualitätsmängel und Code Bloat zu vermeiden.
Strikte Git-Workflows und automatisierte Testabläufe tragen dazu bei, Codequalität überprüfbar zu machen und das Risiko eines unsachgemäßen Umgangs mit sensiblen Daten zu reduzieren.
Zukünftig soll die Schnittstellenspezifikation weiter präzisiert werden: Ein konsequent betriebenes Contract-First-Design soll der KI die Generierung von Benutzeroberflächen erleichtern.
Nächste Entwicklungsschritte
Für die Weiterentwicklung der Plattform sind folgende Ausbaustufen geplant, um die statische Analyse zu vertiefen und den Datenexport zu optimieren:
- Erweiterung der Quellcodeanalyse: Automatisierte Erkennung und Klassifizierung historischer Entwurfsmuster.
- API-Formalisierung: Erweiterung des Schnittstellendesigns und automatisierte Generierung von Schema-Dateien.
- Optimierung der Datenpakete: Optimierung der Exportformate zur Verbesserung der maschinellen Lesbarkeit für KI-Modelle.
- Automatisierte Validierung: Integration erweiterter Sicherheits- und Compliance-Prüfungen in die automatisierten Pipelines.
Quellen und Referenzen
- Lovable AI Builder: Spezifikation für KI-gestützte Entwicklungsabläufe. Lovable Platform
- GitHub Actions: Dokumentation zur kontinuierlichen Integration und CI/CD-Pipelines. GitHub Actions Guide
- BridGenta Engineering Communication Constitution (BECC): Ein internes Kommunikationsframework unterstützt die nachvollziehbare, konsistente und evidenzbasierte Darstellung technischer Projektarbeit.