Von KI-Musen und der Femme Fatale – warum Vibe-Coding mich begeisterte, aber Software-Engineering etwas anderes ist
- Alexander Küken
- 18. Dez. 2025
- 15 Min. Lesezeit
Aktualisiert: 20. Feb.
Samantha und ich haben es getan … wir haben gevibed. Für die Uneingeweihten: Keine Sorge, das ist nichts Unanständiges und hat nichts mit einem der Kandidaten für das Jugendwort des Jahres zu tun. Wobei. Wenn Vibe-Coding wirklich funktioniert, bleibt mehr Zeit fürs Gooning. [1]
Vibe-Coding bezeichnet vereinfacht den Ansatz, Software rein durch den Einsatz von GenAI zu erstellen, ohne sich um den generierten Quellcode zu kümmern. Der Begriff und die Methodik wurden im Februar dieses Jahres von Andrej Karpathy in einem Tweet [2] begründet und war von der Tonalität her vermutlich eher kritisch oder sarkastisch gemeint. Wahrscheinlich war ihm zu diesem Zeitpunkt nicht bewusst, dass er damit maßgeblich zur Öffnung der Büchse der Pandora beigetragen hatte.
Nehmen wir dazu die Aussage von Mark Zuckerberg Anfang des Jahres, wonach bei Facebook bis Ende 2025 ein Großteil der Software-Engineer durch KI ersetzt werden soll [3]. Das hat bei einigen Entscheidungsträgern in Kombination wohl zu jener systemischen Überreaktion geführt, die ich im letzten Artikel als geistige Inkontinenz beschrieben habe [4]: Die trügerische Annahme, wir benötigen keine Entwickler mehr, weil nun die KI alles übernimmt.
Die Euphorie hat nur nicht lange gehalten. Die Realität hat viele Firmen schmerzlich wieder eingeholt. So häufen sich die Berichte darüber, dass vermehrt gekündigte Mitarbeiter vom selben Arbeitgeber wieder eingestellt werden. [5] Aber die Technologie ist da. Sie entwickelt sich weiter und verschwindet nicht mehr. Und so kann man beobachten, dass immer mehr dedizierte Vibe-Coding-Tools aus dem Boden sprießen, sei es Replit, Lovable oder zuletzt Google AI Studio, um nur ein paar Beispiele zu nennen.
Wer meine anderen Artikel in der Samantha-Reihe [4] [6] oder meine sonstigen Postings zum AI-Thema gelesen hat, wird sich schon denken können, dass ich dem Thema kritisch gegenüberstehe. Und damit bin ich bei Weitem nicht allein. Wenn Koryphäen wie Dave Farley Vibe-Coding als die schlechteste Idee des Jahres 2025 bezeichnen [7], kann ich gar nicht so falsch liegen.
Oder vielleicht doch?
Ich kam in den vergangenen Wochen zumindest ins Grübeln. Ich habe mich viel mit anderen Menschen in der IT-Branche ausgetauscht und beim Entwurf und bei der Durchführung einer Umfrage zum Thema „AI in der Software-Entwicklung“ unter kleinen und mittelständischen IT-Beratungen unterstützt. Und immer wieder kamen mir begeisterte Geschichten über den Einsatz von Vibe-Coding zu Ohren.
Bin ich einfach der Bauer, der nicht isst, was er nicht kennt?
Ich habe AI bisher nur als Unterstützung in der Entwicklung verwendet, aber kein Vibe-Coding betrieben. Man kann das vermutlich mit dem Bereich Testautomation vergleichen: Es gibt die testgestützte Entwicklung, also schreibt man den Code und unterfüttert ihn anschließend mit automatisierten Tests. Und dann gibt es die testgetriebene Entwicklung, in der man Tests vor dem Code schreibt. Ich habe also AI-gestützt entwickelt, aber bisher nicht AI-getrieben.
Also war es an der Zeit, dies zu ändern und zu sehen, woher diese Faszination kommt.
Das Vorhaben
Ich bin ein großer Fan von kraftgerichteten Graphen. Bei dieser Art von Diagrammen wirkt eine Anziehungskraft zwischen zwei Elementen, die durch die Kantenwertigkeit zwischen ihnen definiert ist. Man kann sich das vorstellen wie ein Netz aus Kugeln, die mit unterschiedlich langen und starken Federn verbunden sind. Hat man viele voneinander abhängige Datenpunkte, erkennt man visuell rasch Clusterbildungen. Komplexität wird plötzlich greifbar.
Ich habe damit in der Vergangenheit die Abhängigkeit zwischen den Skills in Kundenanfragen visualisiert. Wenn man einen Knotenpunkt greift, in diesem Fall einen Skill, und der komplette Rest des Graphen anfängt zu wabbeln und zu wobbeln … dann verstehen auch Nicht-ITler im Management, wie komplex die Abhängigkeiten bei IT-Skills wirklich sind.
Bisher hieß das für mich: D3.js und Excel-Voodoo. Eine nervige, zeitaufwendige Arbeit. Genau deshalb erschien es mir als die perfekte Aufgabe für mein erstes Vibe-Coding-Experiment: Eine Anwendung, die mir diesen Graphen generiert, ohne die manuelle Datenaufbereitung in Excel.
Da ich für diesen Artikel keine echten Daten verwenden kann, habe ich mir ein unverfänglicheres Szenario ausgedacht: Filmschauspieler. Jeder Knoten im Graph ist ein Schauspieler. Die Verbindung zwischen zwei Schauspielern gibt an, wie oft sie gemeinsam vor der Kamera standen. Um genügend Daten zu haben und nicht unerlaubt die IMDB zu scrapen, habe ich die Daten synthetisch generiert.
Die Informationen landeten in JSON-Dateien. Bei den Schauspielern: Name und Herkunftsland. Bei den Filmen: die Castliste und die Produktionsfirma. Simpel, aber strukturiert. Damit war alles vorbereitet, um das Experiment zu starten.
Die erste Iteration
Für das Experiment wollte ich nicht auf dedizierte Vibe-Coding-Tools zurückgreifen. Stattdessen wollte ich mit meiner liebgewonnenen Pair-Programming-AI Samantha zusammenarbeiten, auch wenn unsere Beziehung nach dem letzten Experiment ein paar Risse bekommen hatte (siehe meine vorherigen Artikel [4] [6] zum Thema Development AI).
Der Unterschied dieses Mal: Ich verwendete sie nicht im Dialog, sondern im Agent-Modus. Als LLM kam im Hintergrund Sonnet 4.5 zum Einsatz.
Ich erklärte Samantha in einem einzelnen Prompt mein Ziel und ließ sie dann ihre Arbeit machen:
I want to create a Python script that analyzes the provided data on movies and their performers. The script should generate an HTML page I can run locally that shows the relationship between performers as a force-directed graph using the D3 library. The metadata for performers is stored as JSON files (one per performer) in the data/performers directory. The movies are stored in the directory data/scenes. Each scene is one JSON file. Which performer is in which scene is stored as an array in the field “performers.”Und dann hieß es, zu warten. Fast exakt vier Minuten lang. Dann bat mich Samantha um Erlaubnis, den generierten Code auszuführen. Voll gespannter, aber ehrlich gesagt geringer Erwartung ließ ich sie das Skript starten und öffnete die HTML-Datei im Browser.
Was ich sah, ließ mein Herz kurz aussetzen.
Im Browser erschien genau das, was ich von Samantha angefordert hatte. Nein. Eigentlich zeigte sich sogar mehr. Das Ergebnis war nicht nur ein vollständiger D3-Graph. Das Ganze präsentierte sich in einem netten Layout mit Überschrift und Statistiken zu den Daten. In einem zurückhaltenden, aber absolut ansprechenden Design.
Zu diesem Zeitpunkt war die Verlockung groß, den generierten Python-Code zu prüfen oder zumindest den Quelltext der HTML-Seite zu inspizieren. Sicherstellen, dass Samantha mir hier keinen Fake vorgesetzt hat. Aber beim Vibe-Coding geht es ja gerade darum, sich nicht um den Code zu kümmern. Der Zeitpunkt war gekommen, sich dem Vibe hinzugeben. Also: Spotify Dance-Pop-Mix anwerfen und mit Samantha die Anwendung weiterentwickeln.
Im Laufe der nächsten Stunde ließ ich Samantha:
Controls zur Steuerung des Zooms hinzufügen
Eine Funktion zum Isolieren eines Schauspielers mit seinen direkten Verbindungen erstellen
Eine Top-15-Liste der Schauspieler mit den meisten Filmen ergänzen
Eine Top-15-Liste der Paarungen einbauen
Die Top 15 der Paarungen durch die Top 10 der häufigsten zusammenarbeitenden Gruppen aus drei Schauspielern ersetzen
Die Größe der Knotenpunkte anhand der Anzahl der Filme anpassen
Eine zweite Variante der Seite erstellen, gefiltert nach Produktionsfirma
Die Top-10-Triples wieder zurück zur Top-10 von Paaren ändern
Im Tooltip auf den Knoten noch das Herkunftsland der Schauspieler anzeigen
Insgesamt waren es 14 Prompts, die zum Ziel führten. Das Ziel war zuvor nicht definiert. Man kommt dabei tatsächlich schnell in einen Flow. Samantha führt einen Schritt aus, man sieht sich das Ergebnis an, entwickelt die nächste Idee und der Zyklus beginnt von vorn.
Das Interessante dabei: Jeder Schritt war inhaltlich oder funktional ein Treffer. Es gab keinen Moment, in dem ich Samantha auf einen Fehler hinweisen oder sie korrigieren musste. Langsam fing ich an, die Faszination zu verstehen.
Natürlich handelt es sich bei diesem Experiment um ein recht überschaubares Vorhaben. Aber wenn wir ehrlich sind: Hätte ich das Vorhaben schriftlich spezifiziert, vielleicht noch mit einem Scribble für die Oberfläche versehen, um die Aufgabe an einen Entwickler zu übergeben, hätte ich länger gebraucht. Und funktional wäre die Lösung nicht so ausgereift gewesen, da mir viele Ideen erst während der Umsetzung kamen.
Vibe-Coding erlaubt rasche, kurze Feedbackschleifen. Man beschreibt, was man haben möchte, probiert das Ergebnis aus und definiert die nächste Anforderung. Solange, bis man zufrieden ist. Das Ergebnis wirkt dabei nicht wie ein Wegwerfprodukt oder ein klappriger Prototyp. Dazu aber später mehr.
Lag ich mit meinen Vorbehalten gegenüber Vibe-Coding vielleicht falsch?
Moment. Ich hatte mir den generierten Code noch immer nicht angesehen. Vielleicht hat Samantha doch geschummelt oder der Code ist eine reine Katastrophe unter der Haube.
Das Erste, was auffiel: Samantha hatte den CSS-Code direkt im HTML eingebettet. Ein kurzer Prompt, um den CSS-Code zu externalisieren, und das Thema war erledigt. Auch der erste manuelle Blick auf den generierten Python-Code wies keine großen Auffälligkeiten auf. Okay, hätte ich den Code geschrieben, hätte ich für die HTML-Generierung vermutlich einen Templating-Mechanismus verwendet, statt sture Print-Anweisungen zu nutzen. Ich hätte den Code wohl auch auf andere Weise strukturiert. Aber eine schnelle statische Codeanalyse fand keine dramatischen Fehler. Dass Samantha vergessen hat, einen nicht verwendeten Import zu entfernen, ist verzeihlich. Wie oft habe ich schon Sachen eingecheckt, ohne die Imports zu bereinigen?
Alles in allem keine perfekte, aber eine solide Lösung. Ich habe selbst schon in Projekten veranlasst, dass schlechtere Lösungen in die Produktion gehen.
Wird Samantha von der nächtlichen Pair-Programming-Partnerin jetzt zur Verführerin? Zumindest verführte mich das Ergebnis am nächsten Tag dazu, noch einmal tiefer ins Thema einzusteigen.
Die zweite Iteration
Wie sagt der Lockpicking Lawyer immer so schön, wenn er ein Schloss zu schnell geöffnet hat: Let’s check it wasn’t a fluke.
Ich wollte wissen, was passiert, wenn ich das Experiment wiederhole. Wie deterministisch sind die Ergebnisse? Ich setzte also ein neues, leeres Projekt auf. Gleiche Konfiguration, leerer Kontext und exakt dieselben Prompts.
Zwei Dinge fielen sofort auf.
Erstens: Samantha wirkte deutlich weniger selbstbewusst. Im ersten Experiment setzte sie den Prompt einfach um, bat kurz um Bestätigung der Ausführung und fertig. Im zweiten Anlauf hingegen begann Samantha, die generierte HTML-Seite immer wieder manuell zu testen und das Ergebnis zu hinterfragen. Die Codegenerierung dauerte sicherlich eine Viertelstunde länger, da sie immer wieder mit grep Teile der Seite extrahierte und überprüfte. Das tat sie so oft, dass ich sie später entnervt in den vollen Auto-Mode versetzte, nur um nicht ständig jede einzelne Codeausführung bestätigen zu müssen.
Zweitens: Die generierte Oberfläche war im Vergleich zum ersten Experiment enttäuschend. Die Bedienelemente und Top-Listen wirkten wie Fremdkörper, die einfach auf die anderen Elemente der Seite gelegt wurden. Das Ganze wirkte improvisiert. Das Gefühl, eine fertige, „runde“ Lösung in der Hand zu halten, fehlte diesmal komplett. Auch wenn sie rein funktional das tat, was sie tun sollte.
Abseits davon hatte Samantha wieder eine solide Lösung geschaffen. Das Review und die statische Codeanalyse brachten nichts Alarmierendes zutage. Auch der Code an sich war vergleichbar; die Lines of Code lagen nur um circa zehn Zeilen auseinander.
Dennoch stellte sich das Hochgefühl aus dem ersten Experiment nicht ein. Klar, Prompts per Copy-and-Paste auszuführen lässt keinen Flow aufkommen. Die Neugier auf das Neue war weg. Aber der Hauptpunkt war tatsächlich das Interface. Da hat Samantha einfach einen Teil ihrer Verführungskünste eingebüßt.
Die dritte Iteration
Das Grundprinzip des Vibe-Codings ist, sich nicht um den Quellcode zu kümmern. Da eine Iteration mit diesem Anwendungsfall nur knapp eine Stunde in Anspruch nimmt, wollte ich dennoch tiefer ins Thema Codequalität schauen.
In den ersten beiden Iterationen hatte ich Samantha mit Python arbeiten lassen. Eine Sprache, mit der ich mich immer mehr anfreunde, in der ich aber einfach nicht so tief drinstecke wie z. B. in Java. Das erschwert die Beurteilung der Codequalität. Zudem ist eine Skriptsprache wie Python einfacher verzeihlich.
Entsprechend wiederholte ich das Experiment mit einer kleinen Anpassung der Prompts und ließ Samantha die Anwendung in Java generieren.
Prinzipiell verlief das Experiment nahezu identisch mit der zweiten Iteration. Am Ende stand wieder eine funktionierende Anwendung, die die Anforderungen erfüllte. Aber die generierte Oberfläche wirkte erneut zusammengestückelt und weniger ansprechend als bei der ersten Iteration.
Strukturell hat Samantha den Code recht gut in Modell- und Serviceklassen aufgeteilt. Auch der interne Aufbau der Klassen war sauber und nachvollziehbar. Aber insgesamt wirkte der Code eher altbacken. Der HTML-Code wurde, wie bereits bei der Python-Lösung, per Print-Anweisungen generiert, statt ein sauberes Templating zu verwenden. Und wenn es einfach nur Velocity-Templates gewesen wären. Die Modellklassen waren statisch implementiert, statt Ansätze wie z. B. Lombok zu nutzen. An vielen Stellen hätte sich zudem ein Stream-Processing angeboten. Alles in allem würde ich den Stand des Codes auf die Ebene eines Junior-Entwicklers einstufen.
Die nachfolgende statische Codeanalyse brachte dann noch weitere Unschönheiten zutage. Jetzt keine drastischen Fehler, aber sicherlich noch mal manueller Korrekturaufwand für eine halbe Stunde, um den Code geradezuziehen. Besonders auffällig war die Menge an implementiertem Code, der nie aufgerufen wurde.
Um es auf den Punkt zu bringen: Hätte ich das Code-Review im Rahmen eines PRs in einem Projekt durchgeführt, hätte ich den Code nicht durchgehen lassen.
Während mich Samantha in der ersten Iteration noch verführt und begeistert hat, hat mich nach diesem Ergebnis die Realität schnell wieder eingeholt. Meine erste Begeisterung wich meinen ursprünglichen Vorbehalten. Production ready sieht anders aus.
Zwischenfazit
Für dieses Zwischenfazit würde ein bestimmter Soundtrack perfekt passen. Einen, den jeder innerhalb von fünf Sekunden erkennt, wenngleich man den Film nie gesehen hat. Ich rede von Ennio Morricone. The Good, the Bad and the Ugly. [8]
Denn genau das beschreibt die Realität der Trainingsdaten. Coding-AIs wurden mit Milliarden Zeilen Code gefüttert. Und so unterschiedlich die Quellen, so unterschiedlich ist die Qualität. Von hochkomplexem, brillantem Produktionscode bis hin zu stümperhaften „Hello World“-Versuchen von blutigen Anfängern ist alles dabei. The Good Code, the Bad Code and the Ugly Code.
Und sind wir ehrlich: Die Menge an schlechtem oder einfach nur hässlichem Code übersteigt die Perlen bei Weitem.
Da LLMs in ihrer grundlegenden Funktionsweise rein auf statistischen Wahrscheinlichkeiten basieren, landet man also fast zwangsläufig im Durchschnitt. Man darf nicht erwarten, dass eine KI plötzlich Referenzimplementierungen im Geiste von Joshua Blochs „Effective Java“ [9] ausspuckt. Auch der technische Stand hinkt hinterher. Der Berg an Java-8-Code im Internet ist nun mal gigantisch größer als der an Java-25-Snippets.
Sicher. Man könnte dem entgegenwirken. Man könnte der KI präzisere Spezifikationen und Constraints vorgeben. Aber das widerspricht der Grundidee des Vibe-Codings. Der Deal war ja gerade: Ich kümmere mich nicht um den Code.
Iteration 4
Ein Punkt ließ mich einfach nicht los. In den letzten beiden Runden waren die Oberflächen eher unbefriedigend. Das Problem: Die zusätzlichen Elemente wie Top-Listen und Navigation wirkten wie Fremdkörper. Nachträglich drangeflanscht.
Das Zauberwort ist hier „nachträglich“. Im Prompting-Ablauf bekam Samantha die Anforderungen häppchenweise serviert. Das erklärt zwar nicht vollständig, warum es beim allerersten Versuch besser klappte, aber es liefert eine Erklärung für das Chaos in den Iterationen 2 und 3.
Die Frage, die sich aufdrängte: Was macht Samantha, wenn sie alle Karten sofort auf den Tisch bekommt? Wenn sie alle Anforderungen von Anfang an kennt? Zugegeben, das entfernt sich wieder vom puristischen Vibe-Coding und riecht verdächtig nach klassischem Upfront-Design. Aber der Versuch war es wert.
Also nahm ich die 14 Prompts, kopierte sie zusammen und konsolidierte sie sprachlich und inhaltlich. Das Ergebnis war ein Prompt, der eine komplette DIN-A4-Seite füllte.
Und siehe da. Nach knapp 15 Minuten präsentierte mir Samantha wieder eine voll funktionsfähige Anwendung. Und wie man auf dem Screenshot sieht: Die Anwendung hatte plötzlich ein sauberes Layout. Das Frankenstein-Gefühl war weg, nichts wirkte mehr willkürlich zusammengestückelt. Über das Design selbst kann man trefflich streiten, aber handwerklich war das Ergebnis deutlich runder.
Es zeigt sich mal wieder: Je mehr Kontext die KI bekommt, desto besser werden die Ergebnisse.
Iteration 5
Mit diesem Ergebnis wollte ich noch eine weitere Sache ausprobieren. Auch wenn wir uns damit noch weiter vom eigentlichen Grundgedanken des Vibe-Codings entfernen.
In vielen Artikeln und Tutorials liest man, die Anforderungen als Prompt nicht direkt in die Coding-AI zu geben. Stattdessen solle man eine andere KI, etwa ChatGPT, nutzen, um aus den eigentlichen Prompts ein Product Requirements Document (PRD) zu generieren. Dies dient dann als Eingabe für den Coder.
Also fütterte ich ChatGPT mit meinem konsolidierten Prompt aus Iteration 4. Die Bitte: Generiere ein PRD für eine Coding-AI. Das Ergebnis war ein drei-seitiges, semi-strukturiertes Dokument. Und eines fiel sofort ins Auge.
Während mein Prompt rein fachlich beschrieb, was die Anwendung tun sollte, lieferte das PRD ein halbtechnisches, grobes Lösungsdesign. Das gab mir kein gutes Gefühl.
Ein paar Tage zuvor hatte ich ein ähnliches Phänomen beobachtet. Ich hatte für ein kommendes Experiment ein fachliches Grobkonzept verfasst. Ich hatte mir Mühe gegeben, den Prozess „lösungsneutral“ zu beschreiben. Also unabhängig davon, ob man ihn manuell, in Excel oder über eine App umsetzt. Anschließend bat ich ChatGPT um ein Lektorat, um das Konzept als Anforderung an eine KI zu formulieren.
ChatGPT generierte daraufhin seitenweise Anmerkungen und Textvorschläge, die in mir nur ein Verlangen weckten: meinen Kopf wiederholt auf die Tischplatte zu schlagen.
Die Ironie dabei: Die KI ist inzwischen so weit entwickelt, dass sie sich exakt wie 90 % der menschlichen Projektbeteiligten verhält. Unfähig, in Anforderungen zu denken, und verliebt in Lösungen.
Da es kurz vor Weihnachten ist, liegt eine Analogie nahe.
Stellen wir uns vor, Samantha ist eine Köchin, die ich für das Weihnachtsessen engagiert habe. Im Prompt definiere ich meine Anforderungen für das Familienfest. Es gilt, die Bedürfnisse von 20 Personen zu berücksichtigen. Aus Erfahrung wissen wir: Oma Trude vergisst gerne ihr Gebiss zu Hause. Onkel Peter reagiert allergisch auf Rosmarin. Nichte Jaqueline hat gerade den Veganismus für sich entdeckt. Und Neffe Olaf isst nichts, was grün ist oder vorher keinen Namen hatte.
Die Köchin stellt auf Basis dieser Informationen ein Menü zusammen und bereitet es zu. Alles gut.
ChatGPT hingegen hat in diesem Szenario halbfertige Rezepte generiert und an die Köchin weitergeleitet. Das Ergebnis? Oma Trude ist den ganzen Abend mürrisch. Sie ist nicht sie selbst, wenn sie Hunger hat, aber alle Speisen sind zu hart für sie. Tante Inge fährt Onkel Peter in die Notaufnahme, da er einen allergischen Schock hatte. Jaqueline verbringt die Bescherung im Bad und steckt sich den Finger in den Hals, da die Suppe keine Gemüsebrühe war, sondern Rinderfond. Nur Olaf ist zufrieden. Er konnte nach seinem Rinderfilet auch noch das von Oma Trude verputzen.
Exakt so sah das Ergebnis aus, als ich Samantha die Anwendung auf Basis des PRDs generieren ließ. Es sah gut aus, funktionierte aber nicht wirklich. Etliche Korrekturschleifen waren nötig, bis wir wieder auf dem Stand der vorherigen Iterationen waren.
Ein Grund hierfür stellte sich im Nachgang, während der Fehleranalyse, als sehr interessant heraus.
In allen fünf Iterationen hatte ich als Allererstes die Eingangsdaten im Projektverzeichnis abgelegt. Samantha hatte also während des gesamten Prozesses Zugriff auf die Daten, konnte sie „anfassen“ und analysieren. ChatGPT hatte diesen Zugriff nicht und hat munter Annahmen getroffen.
Um bei der Analogie zum Weihnachtsessen zu bleiben: Samantha hatte vorab Zugriff auf den Kühlschrank und die Speisekammer. Sie wusste genau, welche Zutaten im Haus waren. ChatGPT hat nur ins Blaue hinein halluziniert.
Fazit
Wie lautet nun mein Urteil nach diesen Experimenten?
Ich muss gestehen: Langsam kann ich die Faszination nachvollziehen. Der Ansatz ist verführerisch. Er fühlte sich für mich sogar absolut natürlich an. Denn beim Vibe-Coding habe ich genau das getan, was ich in den letzten zehn Jahren in meinen Projekten getan habe: Ich erkläre Entwicklern – in diesem Fall der KI –, was sie umsetzen sollen. Das Ganze allerdings auf Steroiden.
Das Ergebnis ist nach Minuten sichtbar, nicht erst nach Tagen oder Wochen im Sprint-Review. Die Feedback-Schleifen sind unglaublich kurz. Und das Beste: Es gibt keine Diskussionen in der Retrospektive. Kein Unmut bei den Entwicklern, weil ich wiederholt meine Meinung geändert habe und implementierte Anforderungen verworfen werden mussten. Die KI widerspricht nicht. [10]
Genauso verstehe ich, dass das Thema für Menschen ohne Erfahrung in der Softwareentwicklung noch verlockender ist. Funktionierende Anwendungen entwickeln, ohne eine einzige Zeile Code zu schreiben – wer will das nicht können? Ich vermute, mit dedizierten Vibe-Coding-Tools wie Replit ist es noch einfacher und verlässlicher als mit Samantha (aka AugmentCode), die ja als Werkzeug in meiner IDE lebt. Und selbst hier funktionierte es ausgezeichnet. Dedizierte Werkzeuge senken die Einstiegshürde erneut drastisch.
Doch es gibt für mich zwei große Aber.
Erstens: Ich bin absolut bei Dave Farley [7]. Das Ganze hat nichts mehr mit Software-Engineering zu tun.
Zweitens: Mir stehen die Nackenhaare auf, wenn ich höre, dass man per Vibe-Coding Anwendungen entwickeln könne, die production-ready sind. Hier wird die Verführerin zur Femme fatale. Wobei die Betonung auf fatale liegt.
Die Experimente haben gezeigt, dass eine funktionsfähige Software entstanden ist. Aber reine Funktionsfähigkeit heißt noch lange nicht produktreif. Da gehört viel mehr dazu. Die statische Codeanalyse zeigte Fehler und Unschönheiten. Nichts Dramatisches, sicher. Aber was passiert bei komplexeren Anwendungen? Was ist mit der Sicherheit, wenn die KI unsichere Bibliotheken einbindet? Was, wenn man nicht programmieren kann, die KI ein Problem nicht lösen kann, aber Kunden bereits Geld bezahlen? Im schlimmsten Fall für die Unterstützung geschäftskritischer Prozesse. Für den Kunden ist noch nicht ersichtlich, dass es sich um KI-entwickelte Software handelt (das ändert sich zum Glück Mitte 2026 mit dem EU AI Act).
Am Ende geht es dem Anbieter wie Peter Berg in „The Last Seduction“: mittellos, gedemütigt und im schlimmsten Fall hinter schwedischen Gardinen. Während Samantha lächelnd in den Sonnenuntergang fährt.
Aber was ist mit den ganzen Success Stories? Den Millionengewinnen durch Vibe-Coding? Vermutlich gibt es die gar nicht. Bei den tausenden „Make 10k per Month with [Tool]“-Videos auf YouTube handelt es sich zumeist um Marketing oder gesponserte Inhalte. Unabhängige Reviews [11] zeichnen ein anderes Bild.
Zudem gibt es für jede Success Story mindestens fünf gescheiterte Projekte. Die sind eben nicht so populär. So kennt zwar gefühlt jeder den Tweet von Andrej Karpathy, der den Begriff „Vibe-Coding“ geprägt hat. Aber kaum jemand kennt das, was er nur knapp vier Wochen später schrieb [12]:
The reality of building web apps in 2025 is that it's a bit like assembling IKEA furniture. There's no "full-stack" product with batteries included, you have to piece together and configure many individual services: […] The second you stray just slightly from the "getting started" tutorial in the docs you're suddenly in the wilderness. It's not even code, it's... configurations, plumbing, orchestration, workflows, best practices.
Hier setzen dedizierte Vibe-Coding-Plattformen an. Sie bringen Hosting, Datenhaltung, Auth und Payment out-of-the-box mit. Das schafft dann gleich das nächste Problem: Vendor-Lock-in. Und gleichzeitig diskutiert ganz Europa über digitale Souveränität.
Heißt das jetzt, dass alles schlecht ist?
Nicht unbedingt. Die kleinen Experimente haben mich zum Umdenken gebracht. Die Geschwindigkeit und Einfachheit sind berauschend. Besonders für das Rapid Prototyping. Vibe-Coding kann ein hervorragendes Werkzeug sein, um schnell Lösungsräume zu explorieren.
Und hier kommen wir zu einem Aspekt, der mich in meiner gesamten IT-Laufbahn schon immer in die Verzweiflung getrieben hat: Prototypen werden nicht verstanden.
Prototypen sind per se Wegwerfprodukte. Es geht darum, Erkenntnisse zu sammeln. Attribute wie Korrektheit, Vollständigkeit, Robustheit und Stil spielen keine Rolle. [13] Diese Attribute bilden jedoch das Fundament für produktreife Software. Da Software immateriell ist, ist die Versuchung riesig: „Naja, die Anwendung macht doch halbwegs das, was sie soll. Nehmen wir sie doch erst einmal so.“ Und schneller als man sich versieht, läuft ein aufgehübschter Prototyp in Produktion.
In anderen Branchen ist das greifbarer. In der Automobilindustrie werden Design-Prototypen aus Balsaholz und Gaffa-Tape gefertigt. Oder Tonmodelle für den Windkanal. Da käme niemand auf die Idee, mit diesen Dingern auf die Autobahn zu fahren.
Genau hier sehe ich die Stärke von Vibe-Coding: Schnell und risikofrei mögliche Lösungsräume durch Prototyping explorieren. Und mit der aktuellen Entwicklung könnte es zukünftig Wege geben, den Pfad vom Vibe-Coding-Prototyp hin zum professionellen Entwicklungsteam zu vereinfachen.
Das werden wir uns aber erst nächstes Jahr gemeinsam ansehen. Dann besuchen wir einen von Samanthas Freunden: Casper, den freundlichen Geist.
