Wie ihr Legacy-Software in einen KI-SDLC bringt

Jedes Gespräch über KI-gestützte Entwicklung trifft irgendwann dieselbe Wand: „Schön für neue Apps, aber unser Geschäft läuft auf einem zwölf Jahre alten Rails-Monolithen und einem Java-Abrechnungssystem, das niemand ganz versteht.“ Die Wand ist real, das meiste KI-Entwicklungstooling nimmt ein Greenfield an, aber der Schluss, den Teams daraus ziehen, dass Legacy-Systeme auf einen Rewrite warten müssen, bevor KI helfen kann, ist exakt verkehrt herum. Legacy-Systeme sind der Ort, an dem sich KI-gestütztes Engineering am meisten auszahlt. Denn dort leben die Wartungslast, das Wissensrisiko und der Backlog tatsächlich.

Ein Legacy-System in einen KI-SDLC zu bringen heißt nicht, ein Modell zu bitten, es neu zu generieren. Es heißt, dem bestehenden Code denselben Delivery-Loop zu geben, den eine neue KI-gebaute App genießt: eine Umgebung, in der das System reproduzierbar läuft, damit Agenten sicher daran arbeiten können; eine Karte, welcher Code zu welcher Geschäftsfunktion gehört; Richtlinien, die die gefährlichen Zonen schützen; eine Baseline automatisierter Tests um Verhalten, das sich nicht ändern darf; und ein kontrollierter Pfad von der Änderung zum Deployment. Sobald dieser Loop existiert, können KI-Agenten die Arbeit tragen, vor der sich Menschen drücken, Abhängigkeits-Upgrades, Bug-Backlogs, kleine Features, Dokumentation, unter Governance, während das System weiter die Produktion bedient.

Der strategische Neurahmen: Modernisierung hört auf, ein Ziel zu sein (der große Rewrite, ewig achtzehn Monate entfernt) und wird eine Eigenschaft davon, wie das System ab jetzt gewartet wird. Systeme im Loop werden mit jeder kontrollierten Änderung inkrementell gesünder. Systeme außerhalb verfallen nach Fahrplan.

Ein nützliches Denkmodell: Behandelt das Legacy-System wie einen Patienten bei der Aufnahme, nicht wie ein Gebäude vor dem Abriss. Aufnahme heißt zuerst Beobachtung, reproduzieren, kartieren, das Verhalten als Baseline festhalten, dann Behandlung in steigenden Dosen, während sich Belege ansammeln. Nichts an der Aufnahme verlangt zu glauben, das System sei gut; es verlangt nur, dass das System tragend ist, und genau deshalb verdient es Maschinerie statt Heldentaten. Die Stufen unten sind dieses Aufnahmeverfahren, in Reihenfolge, mit dem Risiko nach vorn auf umkehrbare Schritte verlagert.

Der Schmerz ist strukturell, nicht zufällig. Die Engineers, die das System verstanden, sind gegangen oder weitergezogen, also beginnt jede Änderung mit Archäologie. Die Testabdeckung ist dünn oder rituell, also ist jedes Deploy ein kleiner Akt des Mutes, also sind Deploys selten, also stauen sich Änderungen, also werden Deploys riskanter. Der klassische Teufelskreis. Währenddessen wächst der Backlog an Business-Anfragen, und die Leute, die das System anfassen können, verbrauchen ihre Kapazität damit, es am Leben zu halten, statt es zu verbessern. Das ist präzise ein Kapazitätsproblem, und präzise das, was KI-gestütztes Engineering adressiert, sofern die Sicherheitsmaschinerie existiert, in der Agenten arbeiten können.

Die traditionelle Notluke, der Big-Bang-Rewrite, hat eine Fehlerbilanz, die jeder CIO kennt: mehrjährige Zeitpläne, das alte System, das sich unter dem neuen weiterentwickelt, die letzten 20 % des Verhaltens, undokumentiert, tragend, die den Großteil des Budgets fressen. Rewrites scheitern, weil sie von der Organisation verlangen, das gesamte System auf einmal zu verstehen. Genau das Wissen, das verloren ging. Inkrementelle Ansätze gelingen, weil sie nur das Verständnis einer Änderung zur Zeit verlangen, und eine Änderung zur Zeit ist exakt die Granularität, die KI-Agenten plus Governance gut beherrschen.

Dazu kommt eine Talent-Realität. Niemand will den Wartungssitz auf einem Legacy-System, und die Besetzung wird jedes Jahr schwerer. Das System in einen KI-SDLC einzubetten verwandelt diesen Sitz von Vollzeit-Archäologie in Richtung und Review. Eine Rolle, die Senior-Leute tatsächlich übernehmen.

Der Backlog selbst verrät, wie viel Wert eingeschlossen ist. Die meisten alternden Systeme tragen Jahre aufgeschobener Anfragen, kleine Features, Integrationswünsche, Report-Änderungen, die einzeln nie das Deploy-Risiko wert waren. Das ist die grausame Arithmetik des Teufelskreises: Je riskanter Deploys werden, desto höher die Latte für den Versuch, desto länger wächst die Schlange. Brecht den Kreis, billige, sichere, kontrollierte Änderungen, und die Schlange verwandelt sich von einer Verbindlichkeitenliste in eine Wert-Pipeline. Deshalb ist der Backlog-Abbau die überzeugendste frühe Metrik dieser Programme.

Diese Auffahrt ist auf Ciao ein erstklassiger Pfad, keine Anpassung. Individuelle Sandbox-Images verpacken KI-gestütztes Engineering um Rails, Java, Go, Python, Node und Multi-Prozess-Backends. Stufe zwei des Frameworks als Plattform-Fähigkeit. Guardrails übernimmt dann das Kartieren und Schützen: Es ordnet Code Geschäftsbereichen zu, erkennt riskante Änderungen, wendet Richtlinien in einfacher Sprache an, protokolliert menschliche Prüfung und hinterlässt einen Audit-Trail hinter jedem Merge. Exakt die Governance-first-Haltung, die Legacy-Systeme verlangen. QA baut und fährt die Baseline. Deterministische Browser-Replays, selbstheilende Tests, Smoke-Gates vor der Veröffentlichung, Produktionsprüfungen danach, und Doctor prüft die Live-App, DNS und CDN, um die Ursache zu diagnostizieren, wenn sich etwas falsch verhält.

Für Portfolios statt Einzelsysteme gibt Conductor einen Bildschirm für Hunderte, manchmal Tausende, von Projekten mit Live-Health und Sichtbarkeit geschützter Zonen. Genau das, was ein rollierendes Modernisierungsprogramm braucht, um von einem kleinen Team gemanagt zu werden. Das Deployment kann bleiben, wo Compliance es verlangt: euer eigenes AWS-, Azure- oder GCP-Konto, private VPC oder On-Prem unter separaten Bedingungen. Ernsthafte Entwicklungsprogramme starten bei 10.000 USD pro Jahr. Das Gespräch mit dem Vertrieb ist konkret: Bringt ein alterndes System und seinen Backlog mit, und steckt ab, wie Stufe eins dafür aussieht.

Setzt die Erwartungen in eurer Organisation ehrlich: Die ersten Wochen produzieren Infrastruktur, keine Features. Eine reproduzierbare Umgebung, eine Geschäftsbereichs-Karte, eine Test-Baseline, und das kann für Stakeholder, denen KI-Geschwindigkeit versprochen wurde, nach Schneckentempo aussehen. Das Kompoundieren beginnt danach: Jede folgende Änderung fährt auf denselben Schienen, und die hundertste kontrollierte Änderung kostet einen Bruchteil der ersten. Programme, die diese Form vorab kommunizieren, behalten ihre Sponsoren; Programme, die sofortige Geschwindigkeit auf einer zwölf Jahre alten Codebasis versprechen, verbringen Monat drei mit Entschuldigungen.