Technische Schulden durch Vibe Coding: Das neue Legacy-Problem
Ein Mitarbeiter zeigt Ihnen ein neues Werkzeug. Gebaut an einem Nachmittag, ohne Entwicklerteam. Es funktioniert. Alle sind begeistert.
Sechs Monate später hängt ein Geschäftsprozess daran. Und niemand im Haus weiß, wie es innen aussieht.
Technische Schulden durch Vibe Coding entstehen genau auf diese Weise. Leise, schnell und ohne böse Absicht. Der Code läuft ja.
Technische Schulden sind der Aufwand, den Sie später zahlen, weil Sie heute schnell waren. Eine ausführliche Definition finden Sie in unserem Glossar zu technischen Schulden.
Dieser Artikel zeigt, wie diese neue Form von Schulden entsteht. Und woran Sie sie erkennen, bevor sie gefährlich werden.
Was Vibe Coding anders macht
Beim Vibe Coding beschreiben Sie ein Ziel in normaler Sprache. Eine KI schreibt den passenden Programmcode. Sie prüfen das Ergebnis, nicht den Code.
Genau darin liegt der Unterschied. Klassische Entwicklung enthält eingebaute Denkpausen.
Ein Entwickler, der eine Funktion selbst schreibt, stolpert unterwegs über Fragen. Wo gehört dieser Code hin? Gibt es das schon woanders? Was passiert bei fehlerhaften Eingaben? Wer pflegt das in drei Jahren?
Diese Fragen kosten Zeit. Sie sind aber kein Ballast. Sie sind die Qualitätssicherung, die im Kopf stattfindet.
Die KI stellt diese Fragen nicht. Sie liefert eine Lösung für genau das, was Sie gefragt haben. Nicht mehr, nicht weniger.
Die fehlende Denkpause
Ein Beispiel aus der Praxis. Sie bitten die KI um eine Funktion, die Kundendaten exportiert. Sie bekommen sie in zwanzig Sekunden.
Was Sie nicht bekommen: den Hinweis, dass es bereits drei ähnliche Exportfunktionen gibt. Oder die Frage, ob personenbezogene Daten hier ungefiltert raus dürfen.
Ein erfahrener Entwickler hätte gefragt. Die KI liefert.
Warum KI-Code besonders schnell Schulden ansammelt
Nicht jeder KI-generierte Code ist schlecht. Vieles davon ist sauber geschrieben. Das Problem liegt selten in der einzelnen Zeile.
Es liegt in dem, was zwischen den Zeilen fehlt.
Jede Anfrage erzeugt eine eigene Welt
Die KI kennt meist nur den Ausschnitt, den Sie ihr zeigen. Bei der nächsten Anfrage beginnt sie oft von vorne.
Das Ergebnis: fünf Funktionen, die dasselbe tun, auf fünf verschiedene Arten. Andere Namen, andere Struktur, andere Fehlerbehandlung.
Für die Maschine ist das kein Problem. Für den Menschen, der das später ändern muss, schon. Jede Anpassung muss an fünf Stellen erfolgen. Eine davon wird vergessen.
Abhängigkeiten, die niemand geprüft hat
KI-Werkzeuge greifen gern auf fertige Bibliotheken zurück. Eine Bibliothek ist fremder Code, den Ihre Anwendung mitbenutzt. Der Fachbegriff dafür lautet Dependency.
Die KI wählt oft die Bibliothek, die in ihren Trainingsdaten häufig vorkam. Nicht die aktuellste. Nicht die am besten gepflegte.
So landen Pakete im Projekt, die seit Jahren niemand mehr aktualisiert. Manche existieren gar nicht mehr. Andere haben bekannte Sicherheitslücken.
Tests und Dokumentation fehlen fast immer
Automatisierte Tests prüfen nach jeder Änderung, ob die Software noch korrekt arbeitet. Sie sind die Versicherung gegen unbeabsichtigte Schäden.
Wer die KI nicht ausdrücklich nach Tests fragt, bekommt keine. Dasselbe gilt für Dokumentation.
Ein Prototyp ohne Tests ist völlig in Ordnung. Ein Produktionssystem ohne Tests ist ein Risiko. Der Übergang zwischen beiden passiert oft unbemerkt.
Niemand kann erklären, warum
Das ist die unangenehmste Form dieser Schulden. Bei klassischem Code gibt es meist jemanden, der eine Entscheidung erklären kann.
Bei KI-Code oft nicht. Die Frage "Warum ist das so gelöst?" hat dann keine Antwort. Nur ein Achselzucken.
Damit fehlt die Grundlage für jede Änderung. Wer nicht weiß, warum etwas so gebaut wurde, traut sich nicht, es anzufassen.
Was passiert, wenn Sie nichts tun
Zuerst passiert gar nichts. Das macht diese Schulden so tückisch.
Die Anwendung läuft. Die Nutzer sind zufrieden. Der Aufwand zeigt sich erst bei der ersten größeren Änderung.
Dann dauert eine Anpassung plötzlich zwei Wochen statt zwei Tage. Weil erst jemand verstehen muss, was da eigentlich passiert.
Bei Sicherheitsvorfällen wird es unangenehmer. Veraltete Bibliotheken sind ein bekanntes Einfallstor. Angreifer scannen das Internet automatisiert nach solchen Lücken.
Dazu kommt das Personalrisiko. Der Kollege, der das Werkzeug gebaut hat, wechselt die Abteilung. Zurück bleibt ein System, das produktiv läuft und das niemand versteht.
Das ist die klassische Legacy-Situation, nur viel schneller erreicht. Früher brauchte Software zehn Jahre bis zu diesem Punkt. Heute reichen zehn Monate. Wie sich das auf die laufende Betreuung auswirkt, beschreiben wir im Beitrag zu Vibe Coding und Legacy-Software.
Woran Sie Vibe-Coding-Schulden erkennen
Diese Warnsignale lassen sich ohne technisches Fachwissen prüfen. Fragen Sie einfach nach.
Kann jemand den Code erklären? Bitten Sie den Verantwortlichen, eine zentrale Funktion zu beschreiben. Kommt keine klare Antwort, fehlt das Verständnis.
Gibt es Tests? Eine einfache Ja-oder-Nein-Frage. Bei "das brauchen wir nicht" lohnt sich ein zweiter Blick.
Wann wurden die Abhängigkeiten aktualisiert? Liegt das über einem Jahr zurück, sammeln sich dort Sicherheitslücken an.
Wie viele Personen können das System ändern? Bei der Antwort "eine" haben Sie ein Klumpenrisiko.
Existiert eine Dokumentation? Auch eine einfache Textdatei reicht. Gar nichts ist ein Warnzeichen.
Weitere Anhaltspunkte finden Sie in unserem Beitrag zu den Warnsignalen technischer Schulden.
Was Sie konkret tun können
Die gute Nachricht: Sie müssen nichts abreißen. Die meisten Probleme lassen sich schrittweise beheben.
Schritt 1: Bestandsaufnahme
Erfassen Sie, welche KI-generierten Werkzeuge produktiv im Einsatz sind. Oft ist die Liste länger als erwartet.
Notieren Sie zu jedem Werkzeug drei Punkte. Wer hat es gebaut? Wer pflegt es? Welcher Geschäftsprozess hängt daran?
Schritt 2: Nach Risiko sortieren
Nicht jedes Werkzeug braucht dieselbe Aufmerksamkeit. Ein internes Skript für Urlaubsanträge ist unkritisch.
Eine Anwendung mit Kundendaten ist es nicht. Beginnen Sie dort, wo ein Ausfall wirklich wehtut.
Schritt 3: Abhängigkeiten prüfen und aktualisieren
Das ist meist die schnellste Verbesserung. Ein Werkzeug listet veraltete Bibliotheken automatisch auf. Die kritischen Aktualisierungen dauern oft nur wenige Stunden.
Wie eine solche Prüfung abläuft, zeigen wir im Sicherheits-Audit.
Schritt 4: Regeln für die Zukunft festlegen
Vibe Coding zu verbieten wäre der falsche Weg. Die Geschwindigkeit ist ein echter Vorteil.
Legen Sie stattdessen eine Grenze fest. Für Prototypen und interne Experimente gilt freie Fahrt. Alles, was Kundendaten berührt, durchläuft ein Review durch einen erfahrenen Entwickler.
Diese eine Regel verhindert die meisten Folgekosten.
Schritt 5: Wartung einplanen
Software, die läuft, braucht trotzdem Aufmerksamkeit. Regelmäßige Aktualisierungen sind günstiger als ein Notfall. Wie das in der Praxis aussieht, lesen Sie unter Software-Wartung.
Fazit: Schnell gebaut ist nicht fertig gebaut
Vibe Coding ist gekommen, um zu bleiben. Es senkt die Hürde, eine Idee auszuprobieren. Das ist ein Gewinn.
Der Haken liegt im Übergang. Ein Prototyp wird zum Werkzeug. Das Werkzeug wird zum System. Und irgendwann hängt das Geschäft daran.
Technische Schulden durch Vibe Coding entstehen nicht durch schlechte KI. Sie entstehen, weil niemand den Moment bemerkt, in dem aus einem Experiment Ernst wird.
Wer diesen Moment bewusst festlegt, behält die Kontrolle. Wer wartet, bis die erste Änderung schiefgeht, hat sie nicht mehr.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre KI-generierten Anwendungen an und sagen Ihnen ehrlich, wo Sie stehen.