Phase 1: Die eigene Situation realistisch einschätzen
Der Fahrplan beginnt nicht mit einer Tool-Entscheidung, sondern mit einer ehrlichen Einordnung: Die zentrale Erkenntnis aus „Der Produktivitäts-Mythos: Was KI-Coding-Tools wirklich bringen“ – Nutzen hängt stark vom Kontext ab, nicht von Branchenversprechen. Die drei Kontextfaktoren aus „Wo KI-Coding-Tools wirklich helfen — und wo nicht“ (Aufgabentyp, Codebasis, Erfahrungsstand) liefern dafür den konkreten Prüfrahmen.
Phase 2: Review-Modus als Standard etablieren
Aus „Warum über die Hälfte des KI-Codes eine Sicherheitslücke enthält“ folgt die zweite Phase: jeden generierten Codeabschnitt in einem expliziten zweiten Schritt auf die sechs bekannten Schwachstellenklassen prüfen lassen, statt dem ersten Ergebnis blind zu vertrauen.
Phase 3: Die Lieferkette absichern
Die dritte Phase setzt „Slopsquatting: Wenn KI Software-Pakete erfindet“ um: jeden vorgeschlagenen Paketnamen verifizieren, Versionen pinnen, Hash-Prüfungen durchführen – bevor eine erfundene Abhängigkeit zur echten Schwachstelle wird.
Phase 4: Governance statt Einzelfall-Entscheidungen
Die vierte Phase verankert die ersten drei Phasen strukturell, wie in „Governance statt Wildwuchs: Eine Policy für KI-Coding-Tools“ beschrieben: Nutzungsrichtlinien, ein Freigabeprozess wie bei jedem anderen Vendor-Tool, ein Review-Schwellenwert, automatisierte Scans und eine Schulungspflicht – statt jede Entscheidung einzeln und ohne Dokumentation zu treffen.
Praxis-Teil: Phase 5 – der Sicherheits-Check vor jedem Go-Live
Die letzte Phase gilt nicht nur einmalig, sondern für jeden einzelnen Prototyp-zu-Produktion-Übergang: die Vier-Punkte-Checkliste aus „Vom Prototyp zur Produktion: Der Sicherheits-Check vor dem Go-Live“ – Dependency-Audit, Sicherheits-Scan, Review-Schwellenwert, Datenfluss-Check. Der Fahrplan endet deshalb nicht mit einem einmaligen Projekt-Abschluss, sondern mit einem wiederkehrenden Prüfschritt, der bei jeder neuen Veröffentlichung erneut durchlaufen wird.