Vibe Coding – also die Beschreibung der eigenen Wünsche und die Akzeptanz des vom Modell generierten Codes ohne eingehende Prüfung – liefert zwar Prototypen in Stunden, aber auch in Monaten fehleranfällige Systeme. Die Technik ist nicht unzulässig: Sie eignet sich hervorragend zur Ideenfindung, birgt aber Risiken für die Entwicklung von Systemen, auf die ein Unternehmen angewiesen ist.
Die Verwechslung der beiden ist das Problem. Was aus einer nutzergenerierten Produktsitzung hervorgeht, sieht einem fertigen Produkt sehr ähnlich: Es hat eine Benutzeroberfläche, reagiert und erfüllt die Anforderungen des Nutzers. Der Unterschied zu einem realen Produkt liegt nicht in den Funktionen, sondern in allem, was noch nicht entschieden ist: Was passiert bei Fehlern? Wer hat Zugriff auf welche Informationen? Wie wird es sich in einem Jahr verändern? Und wer versteht, warum es so programmiert wurde?.
|
Dimension |
Prototyp generiert |
System in Produktion |
|---|---|---|
|
Ziel |
Um zu zeigen, dass die Idee möglich ist |
Funktioniert jahrelang zuverlässig. |
|
Fehler |
Sie werden durch Regeneration korrigiert. |
Sie wurden repariert, ohne den Rest zu beschädigen. |
|
Daten |
Geprüft, sauber |
Real, unvollständig, widersprüchlich |
|
Sicherheit |
Außer Reichweite |
Berechtigungen, Verschlüsselung, Überwachung |
|
Wartung |
Nicht zutreffend |
Die 60-70% der Gesamtkosten |
|
Besitz des Kriteriums |
Das Modell bestimmte die Struktur |
Jemand hat das entschieden und weiß, warum. |
Die letzte Zeile ist mittelfristig am wichtigsten. Solange sich niemand auf eine Struktur geeinigt hat, kann sie auch niemand verteidigen oder weiterentwickeln. Sie wird zu einem Text, der bei jeder Änderung neu interpretiert werden muss, und diese Interpretation braucht mit jeder Veränderung Zeit.
Dies ist nicht nur eine Branchenvermutung. GitClear analysierte 211 Millionen Codezeilen zwischen 2020 und 2024 und stellte fest, dass die Refactoring-Arbeit – die Umstrukturierung bestehenden Codes, um ihn verständlicher zu machen – von rund 251 Tsd. BTU an Gesamtänderungen im Jahr 2021 auf weniger als 101 Tsd. BTU im Jahr 2024 zurückging, während das Kopieren und Einfügen von 8,31 Tsd. BTU auf 12,31 Tsd. BTU anstieg und doppelte Codeblöcke sich verachtfachten.
Der DORA-Bericht 2024 von Google Cloud, basierend auf einer Umfrage unter rund 39.000 Fachkräften, untersuchte die Auswirkungen auf die Bereitstellung: Ein Anstieg der KI-Nutzung um 251 Tsd. 300 Einheiten korrelierte mit einem Rückgang des Durchsatzes um 1,51 Tsd. 300 Einheiten und einer geringeren Stabilität um 7,21 Tsd. 300 Einheiten. In derselben Studie gaben 39,21 Tsd. 300 Entwickler an, wenig bis gar kein Vertrauen in den generierten Code zu haben.
Das von beiden beschriebene Muster ist konsistent: Es wird mehr produziert, die gleiche Menge wird überprüft und weniger wird umstrukturiert. Die Konsequenz zeigt sich nicht in der ersten Woche, sondern erst, wenn etwas geändert werden muss.
Es wäre töricht, auf ein Werkzeug zu verzichten, das die Erkundungsgeschwindigkeit deutlich erhöht. Dies sind die Anwendungsfälle, in denen Vibe Coding eindeutig die richtige Wahl ist:
Alle vier Fälle weisen eine Gemeinsamkeit auf: Das Ergebnis muss nicht überleben. Sobald jemand sagt: «Das funktioniert fast, lasst es uns in Produktion nehmen», hat sich die Anwendungskategorie geändert und die Kriterien sollten sich entsprechend ändern.
Bevor man etwas, das auf diese Weise generiert wurde, in die Produktion überführt, ist es ratsam, folgende Frage zu beantworten:
Ein Prototyp, der fünf Fragen beantwortet, ist kein Prototyp mehr: Es ist ein System, das schnell entwickelt wurde – genau das, was wir anstreben. Geschwindigkeit war nie das Problem.
Das Muster, das wir bei Audits beobachten, ist immer dasselbe: Ein kleines Team entwickelt in drei Wochen, wofür man sonst drei Monate gebraucht hätte. Das Management schließt daraus, dass die Entwicklungskosten gesenkt wurden. Weitere Initiativen werden nach denselben Kriterien genehmigt.
Sechs Monate später dauert jede Änderung länger als die vorherige, niemand will zwei bestimmte Module anfassen, und die Kostenschätzungen sind nicht mehr verlässlich. Dies ist das klinische Bild technischer Schulden, das wir ausführlich besprochen haben in Der Flaschenhals ist wieder einmal die Architektur.
Auffällig ist, dass die Diagnose nur selten auf den Ursprung hinweist, denn die anfängliche Geschwindigkeit war real und jeder erinnert sich daran als Erfolg.
Das Muster, das wir bei Audits beobachten, ist immer dasselbe: Ein kleines Team entwickelt in drei Wochen, wofür man sonst drei Monate gebraucht hätte. Das Management schließt daraus, dass die Entwicklungskosten gesenkt wurden. Weitere Initiativen werden nach denselben Kriterien genehmigt.
Sechs Monate später dauert jede Änderung länger als die vorherige, niemand will zwei bestimmte Module anfassen, und die Kostenschätzungen sind nicht mehr verlässlich. Dies ist das klinische Bild technischer Schulden, das wir ausführlich besprochen haben in Der Flaschenhals ist wieder einmal die Architektur.
Auffällig ist, dass die Diagnose nur selten auf den Ursprung hinweist, denn die anfängliche Geschwindigkeit war real und jeder erinnert sich daran als Erfolg.
Man muss sich nicht zwischen schneller Generierung und qualitativ hochwertiger Entwicklung entscheiden. Die beiden Phasen müssen getrennt werden, und man muss klar angeben, in welcher Phase man sich gerade befindet.
Explorationsphase. Generieren Sie, was Sie wollen, ohne gründliche Überprüfung, mit gefälschten Daten und ohne an die Wartung zu denken. Das Ziel ist, zu lernen.
Entscheidungspunkt. Jemand erklärt die Idee für gültig. Hier wird die Entscheidung getroffen, die fast niemand trifft: Was erforscht wurde, wird verworfen.. Was erhalten bleibt, ist das Wissen, nicht der Code.
Bauphase. Die Architektur ist definiert, das Datenmodell ist festgelegt, die Verträge sind aufgestellt, und dann wird die unterstützte Datengenerierung eingesetzt, nun innerhalb einer von einer Person festgelegten Struktur.
Den Prototyp wegzuwerfen mag wie Verschwendung erscheinen, ist es aber nicht: Er hat seinen Zweck erfüllt, nämlich eine Frage zu beantworten. Ihn aufzubewahren, macht aus einem Erkundungswerkzeug das Fundament eines Gebäudes.
Diese Trennung ist der Grund, warum in TCG-SAF™ die Architektur dem Bau vorausgeht. Nicht aus formalen Gründen, sondern weil es die einzige Möglichkeit ist, die Generierungsgeschwindigkeit zu nutzen, ohne die damit einhergehende Unordnung zu übernehmen.
Es handelt sich dabei um die Praxis, Software zu generieren, indem man beschreibt, was man möchte, und den von einem Modell erzeugten Code ohne gründliche Überprüfung akzeptiert. Dies ist sehr effektiv, um Ideen zu entwickeln und Prototypen zu erstellen, aber problematisch, wenn das Ergebnis ohne Überarbeitung in der Produktion eingesetzt wird.
Nur wenn es fünf Fragen beantwortet: Kann jemand erklären, warum es so strukturiert ist? Gibt es Tests, die Regressionen aufdecken? Ist definiert, welche Daten es berührt und wer sie einsehen kann? Gibt es ein Protokoll und einen Mechanismus zur Rückkehr zum Normalbetrieb? Und gibt es jemanden, der es innerhalb eines Jahres warten kann?.
Die Daten deuten eher auf eine Verschiebung der Muster als auf eine direkte Verschlechterung hin. GitClear dokumentierte, dass das Refactoring von etwa 251 TP3T Gesamtänderungen im Jahr 2021 auf unter 101 TP3T im Jahr 2024 zurückging und die Duplikation um das Achtfache zunahm. DORA maß im Jahr 2024 mit zunehmender KI-Nutzung einen Rückgang des Durchsatzes und der Stabilität.
Um eine Idee vor einer Investition zu validieren, sollten Sie alternative Schnittstellen erkunden, temporäre interne Tools erstellen oder sich in ein neues Gebiet einarbeiten. Gemeinsames Merkmal ist, dass das Ergebnis nicht dauerhaft benötigt wird.
Trennen Sie die Phasen: Bewahren Sie das Wissen und verwerfen Sie den Code. Definieren Sie anschließend die Architektur, das Datenmodell und die Verträge und nutzen Sie die unterstützte Generierung innerhalb dieser von einer Person festgelegten Struktur wieder.
Weil die anfängliche Geschwindigkeit real ist und als Erfolg in Erinnerung bleibt, während die Kosten erst dann deutlich werden, wenn etwas geändert werden muss: Änderungen dauern immer länger, es gibt Module, die niemand anfassen will, und Schätzungen werden unzuverlässig.
Haben Sie ein Produkt in der Serienproduktion, das als Prototyp begonnen hat? Unser technisches Audit zeigt Ihnen innerhalb von 10 Werktagen zu einem Festpreis, was beibehalten werden kann, was umstrukturiert werden muss und was monatlich Kosten verursacht. Audit anfordern →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
