Vibe Coding ist keine Software-Entwicklung

5 Min. Lesezeit

Das Demo funktioniert. Das System nicht.

13.04.2026, Von Stephan Schwab

Vibe Coding wirkt im Demo magisch, scheitert aber an echten Systemen. Das Problem ist nicht die KI. Das Problem ist, dass Nicht-Techniker den Unterschied zwischen „es lief“ und „es wird dauerhaft laufen“ nicht zuverlässig erkennen. Hype verkauft die Fantasie, Software-Entwicklung zu überspringen. Angst verkauft die Panik, Entwickler seien erledigt. Beides ist falsch.

Vibe Coding ist keine Software-Entwicklung

„Vibe Coding“ ist nur der neueste Name für einen alten Impuls: beschreiben, was man will, Code erscheint, kurz testen, ausliefern.

Wenn es klappt, fühlt es sich wie ein Trick an. Wenn es scheitert, scheitert es laut.

Der Mechanismus ist immer derselbe: Ein Prototyp wird für ein System gehalten. Dann zeigt die Realität, warum Software-Entwicklung eine Disziplin ist.

Was Vibe Coding tatsächlich ist

„Ein Prototyp beantwortet: geht das? Ein System beantwortet: können wir damit leben?“

Vibe Coding ist prompt-getriebene Entwicklung. Man beschreibt ein Feature. Die KI schreibt Code. Man startet es. Dann wird am Prompt gedreht, bis der Bildschirm „passt“.

Das ist nicht dumm. Es ist eine schnelle Art, zu erkunden. Es ist auch eine schnelle Art, Code ohne Rückgrat zu produzieren.

Die populären Demos laufen fast immer in einer sicheren Umgebung:

  • Ein Entwicklerrechner.
  • Ein Happy Path.
  • Ein Datensatz.
  • Ein Nutzer.
  • Ein Moment.

Echte Systeme erlauben das nicht.

Warum es sich wie Magie anfühlt

KI ist gut darin, Code zu schreiben, den Entwickler täglich schreiben:

  • Klebstoff-Code.
  • CRUD-Endpunkte.
  • UI-Gerüste.
  • Tests als Startpunkt.
  • brauchbare Refactorings.

KI ist in der Praxis auch ein Werkzeug zur Mustererkennung. Sie folgt typischen Mustern aus dem Trainingsmaterial. Sie kann darüber hinaus extrapolieren, und sie wird dabei besser, aber der Standard bleibt: Code, der aussieht wie das Übliche.

Genau das ist der Knackpunkt. Der schwierige Teil ist fast nie das Tippen, sondern die Entscheidung, welches Muster zu deinem System passt. Das ist Systementwurf: Kompromisse bewusst wählen, Ausfallarten benennen, festlegen, was du optimierst. Die meisten Nicht‑Techniker haben diese Arbeit nie gemacht. Deshalb erkennen sie nicht zuverlässig, wann die KI ein plausibles, verbreitetes Muster gewählt hat, das für ihre Randbedingungen falsch ist.

Für Entwickler ist das ein Beschleuniger. Es spart Tipparbeit und verkürzt Feedback-Schleifen. Das ist echter Fortschritt.

Aber es ersetzt keine Beurteilung. Es ersetzt nur das Tippen.

Für den größeren Kontext: Why We’ve Tried to Replace Developers Every Decade.

Wo es für Nicht‑Techniker bricht

Vibe Coding bricht immer an denselben Stellen. Die Liste ist nicht sexy. Genau deshalb zählt sie.

1) Anforderungen sind kein Prompt

Ein Prompt ist ein Wunsch. Eine Anforderung ist eine Vereinbarung.

„Bau einen Login“ klingt einfach, bis die Basissachen geklärt sind:

  • E‑Mail oder Benutzername?
  • MFA?
  • Sperrregeln?
  • Passwort-Reset?
  • Sitzungsdauer?
  • Audit-Trail?

Ein Entwickler implementiert nicht nur Antworten. Ein Entwickler zwingt diese Fragen in den Raum, bevor es teuer wird.

2) Systementwurf ist unsichtbar, bis er weh tut

Prototypen funktionieren, weil sie Architektur ignorieren. Produktion bestraft das.

Datenmodell, Transaktionsgrenzen, Caching, Hintergrundjobs, Rate Limits, Idempotenz, Mandantenfähigkeit. Das sieht man in keiner UI-Demo.

Wenn du eine kurze Erinnerung willst, warum Organisationen Systeme bauen, die ihre Kommunikationsstruktur spiegeln: Melvin Conway, „How Do Committees Invent?“

Darum ist „läuft auf meinem Rechner“ ein Meme. Darum passiert es trotzdem.

3) Fehlerbehandlung ist kein Schmuck

Vibe‑Code kann den Happy Path. Randfälle werden zu stiller Korruption.

  • Der Zahlungsdienst hat einen Timeout.
  • Das Netz bricht nach der Belastung ab.
  • Zwei Nutzer speichern gleichzeitig.
  • Ein Nutzer klickt erneut, weil der Spinner hängt.

Wer nicht weiß, wie ein Retry‑Sturm aussieht, baut einen.

4) Sicherheit kündigt sich nicht an

Nicht‑Techniker können für ihr eigenes System kein Bedrohungsmodell erstellen. Nicht wegen fehlender Intelligenz. Weil die mentale Prüfliste fehlt.

SQL Injection, kaputte Zugriffskontrolle, Geheimnisse in Logs, SSRF, Abhängigkeiten als Einfallstor.

Sicherheitsfehler sehen lange wie Erfolg aus. Bis jemand mit Fähigkeiten das System zerlegt.

Ein brauchbarer Einstieg ist die OWASP Top 10:2025 Seite.

5) Wartbarkeit ist das eigentliche Produkt

Sobald ein Prototyp genutzt wird, ist er kein Spielzeug mehr. Er wird zur Haftung.

Abhängigkeiten brauchen Updates. Fehler werden priorisiert. Irgendwer hat Rufbereitschaft. Das System braucht Monitoring, Backups, Migrationen und einen Auslieferungsweg ohne Gebete.

Wenn du eine klare, harte Sicht auf Nachhaltigkeit willst: The Engine of Predictable Software Delivery.

Der Zyklus aus Hype und Angst

Anbieter verkaufen Hype, weil Hoffnung schneller kauft als Wahrheit.

Manche Führungskräfte verkaufen Angst, weil sie Kostenschnitt rechtfertigt. Manche Entwickler verkaufen Angst, weil sie Status schützt. Kurzfristig gewinnt jeder. Langfristig gewinnt das Chaos.

KI verändert den Arbeitsmarkt. Sie verändert Arbeitsweise. Sie löscht die Natur der Arbeit nicht.

Fred Brooks hat das sauber getrennt: zufällige Komplexität kann schrumpfen; wesentliche Komplexität bleibt. Das ist weiterhin der richtige Rahmen.

Wenn du das Original lesen willst: Frederick P. Brooks, „No Silver Bullet“ (PDF).

Vibe Coding nutzen, ohne das Haus anzuzünden

Wenn du die Vorteile willst, mach aus Nicht‑Technikern keine Sofort‑Entwickler. Nutze KI, um Reibung zu entfernen, nicht Verantwortung.

  • Grenze ziehen: Prototyp vs Produkt. Prototypen haben Enddaten. Produkte haben Eigentümer.
  • Prompt‑Arbeit mit Entwickler koppeln: Der Prompt wird zur Spezifikation, der Code wird prüfbar.
  • Tests als Tor: Ohne Tests keine Behauptung von Korrektheit.
  • Pipeline früh bauen: „CI später“ ist der teuerste Satz in der Software‑Entwicklung.
  • Realität instrumentieren: Logs, Metriken, Traces. Ohne Sicht keine Führung.

Das ist auch der Punkt, an dem Führung zählt. Gute Führung micromanagt Entwickler nicht. Sie macht Realität sichtbar. Siehe How to Govern Without Control.

Wenn du Führung nah an der Realität halten willst, ohne alle mit Meetings zu ertränken: Caimito Navigator übernimmt den langweiligen Teil: tägliche Logbücher, wöchentliche Synthese und Signale, auf die du handeln kannst.

Die eigentliche Aussage

Vibe Coding ist eine starke Methode zum Erkunden. Es ist eine schlechte Methode, um so zu tun, als wäre Software‑Entwicklung optional.

Nutze die Werkzeuge. Genieße die Geschwindigkeit. Behalte die Disziplin.

Kontakt

Sprechen wir über Ihre reale Situation. Möchten Sie Auslieferung beschleunigen, technische Blockaden beseitigen oder prüfen, ob eine Idee mehr Investition verdient? Ich höre Ihren Kontext und gebe 1-2 praktische Empfehlungen. Ohne Pitch, ohne Verpflichtung. Vertraulich und direkt.

Zusammenarbeit beginnen

Newsletter: Kein Methoden-Theater. Kein Fluff.
Einblicke in echte Software-Auslieferung und Führung.

×