Als Software-Entwickler ist man es gewohnt, Probleme durch das Schreiben von Code zu lösen. Man plant Architekturen, liest Spezifikationen und tippt Zeile für Zeile den Code um die Anforderungen in ein Produkt zu übersetzen. Doch seit letztem geistert ein neuer Begriff durch die KI-Tech-Bubble: „Vibe-Coding“.
Die Idee dahinter? Anstatt den Code selbst zu schreiben, „dirigiert“ man eine KI durch natürliche Sprache. Man gibt den „Vibe“, die Richtung und die Anforderungen vor, und die KI generiert den Code. Eigentlich ist es nicht viel anders als heute. Man entwickelt den Code in einer Programmiersprache wie C, Java, Go, Python etc. und der Compiler bzw. Interpreter übersetzt den Code in Maschinencode. Der Unterschied ist. dass der „Übersetzer“ kein deterministischer Compiler mehr ist, sondern ein probabilistisches KI basiertes System. Statt einer exakt definierten Syntax wird mit Bedeutung, Kontext und Intention gearbeitet. Fehler äußern sich nicht mehr als klare Compiler-Meldungen, sondern als semantische Abweichungen vom Erwarteten. Entwicklung verschiebt sich damit von „korrekt formulieren“ hin zu „richtig spezifizieren“: Wer präzise denkt, sauber abstrahiert und gute Spezifikationen schreibt, bekommt brauchbaren Code – wer das nicht tut, bekommt etwas, das zwar mit ein wenig Glück funktioniert, aber möglicherweise das falsche Problem löst. Programmieren wird weniger Handwerk im klassischen Sinne und mehr Systemdesign, Review und Steuerung. Ich wollte wissen, ob das wirklich funktioniert, oder ob es nur das nächste Buzzword ist. Also habe ich mich ins Google AI Studio begeben und ein kleines Projekt namens LyricLens gebaut. Hier sind meine Erfahrungen.
Das Projekt: LyricLens
Die Idee für LyricLens war simpel, aber praktisch: Eine Web-App, in die man Songtexte (Lyrics) einfügen oder als .txt-Datei hochladen kann. Eine KI analysiert dann den Text auf seine Kernbotschaft, den emotionalen Bogen, literarische Stilmittel und die Struktur.
Technologie-Stack:
- Frontend: React (Vite), Tailwind CSS, Framer Motion (für ein bisschen „Vibe“ im UI)
- Backend/API: Ursprünglich die Gemini API, später umgebaut auf eine lokale Ollama-Instanz.
- Datenbank: Erst LocalStorage, dann SQLite (Node.js), am Ende MySQL mit PHP.
Der Start: Von Null auf UI in Minuten
Der Einstieg ins Vibe-Coding im Google AI Studio war beeindruckend. Mein erster Prompt war im Grunde nur eine sehr simple Beschreibung der App.
Prompt:
I want to create a Webseite. A user can upload song lyrics and the website creates a anaylsis of the song lyrics
Die KI (in diesem Fall das Gemini-3.1 Pro Modell) hat nicht nur ein vollständiges React-Gerüst mit Tailwind-Klassen generiert, sondern auch direkt sinnvolle Platzhalter und Animationen mit framer-motion eingebaut. Abgesehen von Tailwind habe ich keines der Frameworks jemals genutzt.
Erkenntnis #1: Der Start ist extrem schnell. Wo ich normalerweise Zeit mit dem Aufsetzen von Vite, dem Konfigurieren von Tailwind und dem Suchen nach passenden Icons (Lucide-React wurde automatisch gewählt) verbracht hätte, hatte ich nach wenigen Minuten ein funktionierendes, gut aussehendes Frontend dass ich selbst so vermutlich nach stundenlanger Arbeit nur halb so gut hinbekommen hätte.
Features hinzufügen per Chat
Nachdem das Grundgerüst stand, wollte ich Features hinzufügen. Zum Beispiel eine Sprachauswahl für die Analyse.
Mein Prompt: „Ergänze noch eine Select Box, mit der der User die Sprache der Analyse wählen kann, sodass man die Songtext-Analyse in verschiedenen Sprachen erzeugen kann.“
Gemini-3.1 Pro hat:
- Den State in React erweitert (
const [language, setLanguage] = useState('English')). - Das UI um ein schickes Dropdown-Menü ergänzt.
- Den Prompt für die KI-Analyse dynamisch angepasst (
Write the entire analysis in the following language: ${language}).
Erkenntnis #2: Kontext-Verständnis ist King. Die KI wusste genau, an welchen Stellen im Code Änderungen nötig waren, ohne dass ich ihr die Dateinamen oder Zeilennummern nennen musste. Das ist der eigentliche „Vibe“ beim Vibe-Coding: Man beschreibt das Was, die KI kümmert sich um das Wie. Auch das wechseln der Sprache von Englisch zu Deutsch hat das Gemini 3.1 Pro Modell nicht gestört.
Iteration 2: Architektur-Wechsel on the fly
Jetzt wurde es spannend. Ich wollte weg von der Google Gemini API und stattdessen mein eigenes, lokales LLM über Ollama nutzen.
Ich bat die KI: „Please use an ollama service gpt-oss:20b from my ollama service running at 192.168.8.1“.
Die KI hat daraufhin:
- Die Datei
geminiService.tsinollamaService.tsumbenannt. - Den Code von der Nutzung des
@google/genaiSDKs auf einen Standard-fetch-Call gegen die Ollama-REST-API umgeschrieben. - Die Umgebungsvariablen (
.env.example) angepasst. - Die Imports in der
App.tsxaktualisiert.
Später habe ich die URL und das Modell manuell im Code auf https://ollama.jentsch.io/ und gemma3n:latest geändert. Das funktionierte reibungslos. Mit dem gemma3n habe ich in den letzten Tagen schon ein paar Songtext-Analysen durchgeführt und war bisher immer ganz zufrieden mit den Ergebnissen – obwohl es sich hier um eine sehr kleines Modell mit gerade mal 4 Milliarden Parametern handelt.
Erkenntnis #3: Refactoring geht erstaunlich gut. Einen kompletten Service auszutauschen, ist normalerweise fehleranfällig. Die KI hat das sauber und konsistent über alle betroffenen Dateien hinweg erledigt.
Die Grenzen des Systems
Ich wollte eine History-Funktion, die die letzten Analysen speichert. Zuerst baute die KI das mit localStorage. Das funktionierte super.
Dann wollte ich das Ganze serverseitig speichern. Die KI baute mir einen Node.js/Express-Server mit einer SQLite-Datenbank (better-sqlite3). Das funktionierte in der Vorschau des AI Studios hervorragend. Doch dann wollte ich das Backend auf PHP und MySQL umstellen, um es auf meinem eigenen Server zu hosten.
Die KI generierte die passenden PHP-Dateien (db.php, history.php) und das SQL-Schema. Gemini 3.1 Pro passte auch das React-Frontend an, um die neuen PHP-Endpunkte aufzurufen.
Aber hier ich an eine Grenze: Das Google AI Studio ist eine Node.js/Vite-Umgebung. Es kann kein PHP ausführen. Die KI wies mich freundlich, aber bestimmt darauf hin: „Die Vorschau-Umgebung hier im AI Studio kann kein PHP oder MySQL ausführen. […] bis du die Dateien auf deinem eigenen Webserver hostest.„. Aber auf meinem Server ist PHP kein Problem also habe ich einfach das komplette Projekt heruntergeladen und unter https://lyriclens.jentsch.io/ deployt. Nachdem ich die MySQL Datenbank angelegt habe und in der db.php die Zugangsdaten eingetragen habe lief alles wie geschmiert.
Erkenntnis #4: Vibe-Coding braucht die richtige Umgebung. Die KI kann Code für jede Sprache generieren, aber wenn die Ausführungsumgebung (in diesem Fall der Container im AI Studio) die Sprache nicht unterstützt, kann man den Code nicht direkt testen. Hier muss man als Entwickler wieder übernehmen, den Code exportieren und lokal testen oder einen entsprechenden Container aufsetzen. Das ist wesentlich umständlicher als einfach im Google AI Studio zu Vibe-Coden, aber auch möglich.
Ein fieser Bug: Wenn npm streikt
Während ich versuchte, das Projekt lokal auf meinem Ubuntu-Server zu bauen, stieß ich auf einen Blocker: Einen Fehler beim Build-Prozess im Zusammenhang mit Tailwind CSS v4 und fehlenden nativen Bindings (Oxide-Engine).
Ich kopierte die Fehlermeldung einfach in den Chat mit der KI. Die KI erkannte sofort, dass es sich um einen bekannten Bug in npm im Umgang mit „optional dependencies“ handelte. Sie schlug mir mehrere Lösungswege vor:
- Cache leeren und neu installieren.
- Zu
pnpmwechseln (was das Problem oft löst). - Node.js auf Version 22 updaten.
Ich entschied mich für das Node-Update. Auch hier lieferte die KI direkt die passenden Terminal-Befehle für Ubuntu.
Erkenntnis #5: Die KI ist ein hervorragender Debugging-Partner. Anstatt Stackoverflow zu durchsuchen, bekam ich maßgeschneiderte Lösungsansätze für mein spezifisches System.
Nächste Schritte
Beim Vibe-Coding habe ich gelegentlich auf meinem Server Änderungen an Sourcecode vorgenommen, die ich dann im Google AI Studio nachziehen musste. Das ist sehr unschön und stört den Flow erheblich. Ich habe aber gesehen, dass man die Sourcen mit github synchronisieren kann.
So kann man die „lokal“ geänderten Dateien mit dem Google AI Studio synchronisieren. Das werde ich bei meinem nächsten Vibe-Coding Experiment mal probieren – ich gehe stark davon aus, dass es den Flow unterstützt und das hin und her kopieren der Dateien beendet.
Fazit: Ist Vibe-Coding die Zukunft?
Nach meinem Experiment mit LyricLens lautet meine Antwort: Ja, aber…
Vibe-Coding ist kein Ersatz für Software-Entwickler. Es ist ein extrem mächtiges Werkzeug, das mich hoffentlich von Boilerplate-Code, lästigem Setup und Standard-Refactorings befreit.
Was super funktioniert:
- Prototyping und UI-Entwicklung (React, Tailwind).
- Hinzufügen von isolierten Features.
- Austausch von APIs oder Services.
- Debugging von bekannten Fehlermeldungen.
Wo man als Entwickler noch gebraucht wird:
- Architektur-Entscheidungen: Die KI baut, was man ihr sagt. Wenn man eine schlechte Architektur verlangt, bekommt man sie auch.
- Deployment & Infrastruktur: Sobald man den „sicheren Hafen“ der KI-Umgebung verlässt (wie bei meinem PHP/MySQL-Versuch), muss man wissen, wie man Server konfiguriert, Datenbanken aufsetzt und CORS-Probleme löst.
- Code-Review: Man muss den generierten Code lesen und verstehen können. Blindes Vertrauen ist gefährlich.
Für mich war LyricLens eine interessante Erfahrung. Ich habe in einem Bruchteil der Zeit eine funktionierende Full-Stack-Applikation gebaut. Vibe-Coding wird meinen Arbeitsalltag definitiv verändern – nicht indem es mich ersetzt, sondern indem es mich schneller und fokussierter macht.
Probiert es selbst aus! Das Google AI Studio ist ein toller Spielplatz, um die ersten Schritte im Vibe-Coding zu machen. https://aistudio.google.com
Das Ergebnis „LyricsLens“ kann man unter https://lyriclens.jentsch.io/ bewundern 🙂 . Ich lasse das Projekt erst mal laufen, kann aber nicht garantieren, dass es dauerhaft online bleibt. Das Modell „gemma3n“ läuft direkt auf dem Server und je nachdem, wie viel es genutzt wird, muss ich mir eine andere Lösung einfallen lassen oder das Projekt wieder einstampfen 🙁 da gemma3n meinen Server bei intensiver Nutzung ganz schon beansprucht. Ich werde das beobachten und hoffe mein Server kann mit der Last umgehen. Sollte das Interesse an dem Projekt größer werden, müsste das Modell entweder limitiert, ausgelagert oder durch eine ressourcenschonendere Alternative ersetzt werden.
Ach ja, die Historie Funktion habe ich auch erst mal wieder entfernt, da mir ChatGPT davon abgeraten hat, Copyright geschützte Liedtexte auf meiner Webseite zu veröffentlichen – schade, aber besser als Post vom Anwalt zu bekommen :-(.