Vibe Coding: Warum "einfach mal mit KI loslegen" gefährlich ist

Ein neues Projekt steht an. Jemand im Team hat von den Möglichkeiten aktueller KI-Sprachmodelle gehört. Die Idee liegt nahe: Statt wochenlanger Anforderungsworkshops und Konzeptphasen einfach direkt loslegen. Die KI versteht ja, was gemeint ist. Nach zwei Tagen gibt es einen funktionierenden Prototyp, alle sind begeistert.

Sechs Monate später sieht die Situation anders aus. Der Prototyp wurde zur Produktivlösung, neue Anforderungen passen nicht ins bestehende Gerüst, niemand versteht mehr, warum bestimmte Entscheidungen getroffen wurden. Das Projekt braucht einen teuren Neustart.

Dieses Muster hat einen Namen bekommen: Vibe Coding. Und es wiederholt einen alten Fehler in neuem Gewand.

Was Vibe Coding bedeutet – und warum der Begriff täuscht

Der Begriff "Vibe Coding" entstand in der Entwickler-Community und beschreibt einen Arbeitsstil: Software entsteht durch iteratives Experimentieren mit KI-Sprachmodellen, ohne vorherige Definition von Anforderungen oder Architektur. Man beschreibt der KI ungefähr, was man möchte, bewertet das Ergebnis nach Gefühl und passt die Anfrage an, bis etwas Brauchbares herauskommt.

Das Versprechen klingt verlockend: Geschwindigkeit ohne die üblichen Reibungsverluste. Keine langen Abstimmungsrunden, keine Konzeptdokumente, keine Kompromisse mit der Fachabteilung. Die KI programmiert, was man meint – nicht, was in einem Pflichtenheft steht.

Der Begriff täuscht allerdings über die eigentliche Dynamik hinweg. Was wie eine neue Methode klingt, ist im Kern der Verzicht auf Methode. Die Geschwindigkeit entsteht nicht durch bessere Werkzeuge, sondern durch das Weglassen von Arbeitsschritten. Und diese Arbeitsschritte – Anforderungsklärung, Konzeption, Architekturentscheidungen – wurden nicht erfunden, um Projekte zu verlangsamen.

Das Problem ist nicht neu

KI programmieren ohne Plan ist die aktuelle Variante eines bekannten Musters. Vor den Sprachmodellen gab es Low-Code-Plattformen, davor Rapid Application Development, davor Code-Generatoren. Jede Generation dieser Werkzeuge versprach, die mühsame Vorarbeit überflüssig zu machen.

Das Ergebnis war regelmäßig dasselbe: schnelle Anfangserfolge, gefolgt von wachsender Komplexität, die mit dem gewählten Ansatz nicht mehr beherrschbar war. Nicht weil die Werkzeuge schlecht waren, sondern weil sie ein falsches Problem lösten.

Softwareprojekte scheitern selten an der Programmierung. Sie scheitern an unklaren Anforderungen, an fehlender Abstimmung zwischen Fachbereichen, an Architekturentscheidungen, die zu früh oder zu spät getroffen werden. KI-Sprachmodelle können Code schreiben. Sie können nicht entscheiden, welcher Code geschrieben werden sollte.

Die Ursache liegt in einem Missverständnis über die Natur von Software. Code ist nicht das Produkt eines Softwareprojekts – er ist die Dokumentation von Entscheidungen. Wenn diese Entscheidungen nicht getroffen wurden, dokumentiert der Code deren Abwesenheit. Besonders schnell.

Die drei häufigsten Fehleinschätzungen

"Die KI versteht den Kontext"

Sprachmodelle sind beeindruckend gut darin, plausibel klingenden Code zu generieren. Diese Plausibilität wird leicht mit Verständnis verwechselt. Tatsächlich fehlt dem Modell jeder Zugang zu dem, was nicht in der Anfrage steht: Ihre Geschäftsprozesse, Ihre bestehenden Systeme, Ihre Compliance-Anforderungen, die Eigenheiten Ihrer Branche.

Wenn Sie dem Modell sagen, es soll eine Kundenverwaltung bauen, erzeugt es eine generische Kundenverwaltung. Dass in Ihrem Unternehmen Kunden manchmal auch Lieferanten sind, dass bestimmte Daten aus regulatorischen Gründen nicht in derselben Datenbank liegen dürfen, dass die Buchhaltung ein anderes Kundenverständnis hat als der Vertrieb – das kann die KI nicht wissen. Diese Anforderungen verschwinden nicht, wenn man sie nicht formuliert. Sie tauchen später wieder auf, dann aber als Fehler im laufenden System.

"Schnell einen Prototyp, dann sehen wir weiter"

Prototypen sind ein bewährtes Mittel, um Ideen zu validieren. Das Problem mit Vibe-Coding-Prototypen liegt nicht im Prototyp selbst, sondern in dem, was danach passiert.

Ein sauber gebauter Prototyp macht seine Grenzen sichtbar. Er ist erkennbar ein Prototyp. Ein KI-generierter Prototyp ohne zugrundeliegendes Konzept sieht oft erstaunlich fertig aus. Er funktioniert im Demofall. Das erzeugt Erwartungen. "Das steht ja schon fast, wir brauchen nur noch ein paar Features."

Diese Einschätzung ist nachvollziehbar, aber falsch. Was fehlt, ist nicht "ein paar Features", sondern das architektonische Fundament, das weitere Features überhaupt erst tragbar macht. Der Prototyp wird zur Produktivlösung erklärt, weil er funktioniert. Sechs Monate später funktioniert er nicht mehr, weil er nie dafür gebaut war.

"Wir sparen die Konzeptphase"

Die Konzeptphase existiert nicht zum Selbstzweck. Sie ist der Ort, an dem widersprüchliche Anforderungen sichtbar werden, bevor sie im Code aufeinandertreffen. Sie zwingt zur Klärung von Begriffen, die verschiedene Abteilungen unterschiedlich verstehen. Sie macht Abhängigkeiten explizit, die sonst als Überraschungen im laufenden Projekt auftauchen.

Vibe Coding spart diese Phase nicht – es verschiebt sie. Die Klärung, die nicht im Workshop stattfand, findet dann während der Implementierung statt. Oder nach dem Go-Live. Oder beim Rewrite. Die Kosten dafür sind in der Regel höher als für eine ordentliche Vorarbeit, weil Änderungen an existierendem Code teurer sind als Änderungen an einem Konzeptdokument.

Warnsignale erkennen: Wann ein Projekt in die Vibe-Coding-Falle gerät

Nicht jeder Einsatz von KI-Werkzeugen ist problematisch. Die folgenden Muster deuten allerdings darauf hin, dass ein Projekt strukturelle Risiken eingeht:

Anforderungen werden aus dem Code abgeleitet. Wenn die Frage "Was soll das System können?" mit "Schau in den Code" beantwortet wird, fehlt die Dokumentation der Entscheidungsgrundlagen. Das macht jede spätere Änderung zum Risiko.

Niemand kann erklären, warum etwas so gebaut wurde. Architekturentscheidungen sollten begründbar sein. "Die KI hat das so generiert" ist keine Begründung. Es bedeutet, dass niemand die Entscheidung getroffen hat und niemand sie verantworten kann.

Änderungen führen zu unerwarteten Seiteneffekten. Ein System ohne durchdachte Architektur entwickelt schnell verborgene Abhängigkeiten. Kleine Änderungen brechen scheinbar unverbundene Funktionen. Das ist kein Pech, sondern ein Strukturproblem.

Das Projekt wird schneller, aber die Fertigstellung rückt nicht näher. Typisch für Vibe Coding: Die ersten 80 % entstehen in zwei Wochen, die letzten 20 % dauern sechs Monate. Das Verhältnis verschlechtert sich mit jeder neuen Anforderung.

Was stattdessen hilft

Die Alternative zu Vibe Coding ist nicht, auf KI-Werkzeuge zu verzichten. Die Alternative ist, die richtige Reihenfolge einzuhalten.

Anforderungen vor Technologie. Bevor die Frage nach dem "Wie" kommt, muss das "Was" geklärt sein. Was genau soll die Software tun? Für wen? Unter welchen Randbedingungen? Welche Schnittstellen zu bestehenden Systemen gibt es? Welche Daten werden verarbeitet und welchen Regeln unterliegen sie?

Konzept vor Code. Ein Software Blueprint definiert Struktur, Abhängigkeiten und Entscheidungskriterien, bevor die erste Zeile Code geschrieben wird. Nicht als Selbstzweck, sondern als Basis für alle weiteren Entscheidungen. Ein solches Konzept gehört dem Auftraggeber – unabhängig davon, wer später implementiert.

Werkzeuge an der richtigen Stelle. KI-Sprachmodelle können erfahrene Entwickler bei definierten Aufgaben unterstützen. Sie können Boilerplate-Code generieren, Syntax vorschlagen, Testfälle entwerfen. Das setzt voraus, dass jemand die Anforderungen versteht und die Ergebnisse bewerten kann. Die KI beschleunigt dann die Umsetzung – sie ersetzt nicht die Konzeption.

Die Erfahrung zeigt: Projekte, die in der Anfangsphase Zeit für Klärung investieren, sind am Ende schneller als Projekte, die diese Phase überspringen. Nicht weil Planung Selbstzweck wäre, sondern weil sie teure Umwege verhindert.

Fazit

Vibe Coding ist keine neue Methode – es ist der Verzicht auf Methode unter neuem Namen. Die Geschwindigkeit, die es verspricht, erkauft man sich durch das Weglassen von Arbeitsschritten, die aus gutem Grund existieren. LLM Coding Fehler entstehen nicht, weil die Werkzeuge schlecht wären, sondern weil sie ein Problem lösen, das nicht das eigentliche Problem ist.

Softwareprojekte scheitern an unklaren Anforderungen, nicht an mangelnder Programmiergeschwindigkeit. Wer das ignoriert – ob mit oder ohne KI – landet zuverlässig beim Rewrite. Die Werkzeuge ändern sich, das Muster bleibt.