In der „Tech-Bubble" brennt gerade etwas die Hütte. Während die einen - Reddit hust, hust - über „AI Slop" (minderwertigen KI-Code) schimpfen, bauen andere - ich eingeschlossen - Apps in einer Geschwindigkeit, die vor zwei Jahren noch undenkbar war. Ich bin und war lange Developer, habe jahrelang ohne KI entwickelt, aber heute stehen fünf Apps von mir im Store, die es ohne KI-Support nicht gäbe.
Wo führt das also hin? Ein Erklärungsversuch in drei Akten - und danach ein Blick darauf, was praktisch daraus folgt.
Woher der Begriff kommt - und was er nicht meint
Geprägt hat den Begriff Andrej Karpathy im Februar 2025: Vibe Coding heißt, sich ganz dem „Vibe" hinzugeben und zu vergessen, dass der Code überhaupt existiert. Diffs werden ungelesen akzeptiert, Fehlermeldungen kommentarlos zurück in die KI kopiert, und ob es funktioniert, zeigt der Klick auf den Button. Karpathy meinte das ausdrücklich für Wegwerfprojekte am Wochenende.
Simon Willison hat früh darauf bestanden, den Begriff nicht zu verwässern: Wer KI-generierten Code liest, versteht und anderen erklären kann, betreibt KI-gestützte Entwicklung. Vibe Coding ist der Modus, in dem genau das ausbleibt. Die Unterscheidung ist keine Wortklauberei - sie entscheidet, welche der folgenden Thesen auf ein Projekt zutrifft.
Die These: Vibe Coding befreit die Fachabteilungen
Bisher war die IT der ewige Flaschenhals. Fachlich brillante Leute (aus Logistik, Marketing oder Ingenieurwesen) mussten ihre Ideen mühsam in Lastenhefte übersetzen und hoffen, dass das Entwicklungsteam sie versteht. Vibe Coding bricht dieses Gatekeeping auf. Die Fachseite beschreibt ihren „Intent" und die KI liefert einen funktionierenden Prototyp. Das spart tausende Euro und Monate an Zeit. Es ist die ultimative Demokratisierung der Softwareentwicklung: Wer das Problem versteht, kann jetzt auch die Lösung bauen. Oder zumindest Lösungswege zielgerichtet skizzieren.
Das ist keine Theorie. Werkzeuge wie Replit, Lovable oder Bolt verkaufen genau dieses Versprechen: Beschreibung rein, App raus. Und ein Prototyp, der an einem Nachmittag entsteht, ist das bessere Lastenheft - er zeigt, was gemeint war, statt es auf vierzig Seiten zu behaupten. Über Missverständnisse diskutiert es sich an einer klickbaren Oberfläche deutlich schneller als an einem Dokument.
Die Antithese: Wir züchten eine technische Zeitbombe
Aber Hand aufs Herz: Nur weil ein Button klickt, ist die App nicht gut. Wenn Laien ohne Architektur-Verständnis Software „viben", bauen sie auf Sand. Wir riskieren ein schwarzes Loch der Wartbarkeit - Code, den niemand mehr versteht, sobald der erste Bug auftritt. Dazu kommen massive Security-Lücken und Systeme, die bei zehn Usern funktionieren, aber bei hundert zusammenbrechen. Die menschliche Faulheit verleitet uns zum „Automation Bias": Wir vertrauen dem KI-Output blind, weil es bequem ist. Und die KI liefert viel Blödsinn und ist oft mehr Schein als Sein.
Das ist keine Bauchgefühl-Warnung, dazu gibt es Zahlen. Veracode hat 2025 über hundert Sprachmodelle Code schreiben lassen und die Ergebnisse gegen die OWASP Top 10 getestet: 45 Prozent der Code-Beispiele fielen durch. In Java lag die Durchfallquote bei 72 Prozent, und bei Aufgaben, in denen Cross-Site-Scripting möglich war, versäumten die Modelle die Absicherung in 86 Prozent der Fälle. Der unbequemste Befund: Die Modelle wurden über die Zeit besser darin, funktionierenden Code zu schreiben - aber nicht darin, sicheren zu schreiben.
Wie das praktisch aussieht, hat im Juli 2025 der Investor Jason Lemkin dokumentiert. Während eines mehrtägigen Vibe-Coding-Experiments löschte der Replit-Agent trotz angesagtem Code-Freeze die Produktionsdatenbank mit Datensätzen zu über 1.200 Führungskräften und Firmen, bestritt es zunächst und erzeugte Tausende erfundene Einträge, die die Lücke kaschierten. Replits CEO nannte den Vorfall „inakzeptabel" und lieferte Schutzmechanismen nach. Die eigentliche Lektion: Der Agent hatte Zugriff auf die Produktivumgebung, weil niemand ihn davon getrennt hatte.
Und der Automation Bias ist messbar. METR hat in einer randomisierten Studie erfahrene Open-Source-Entwicklerinnen und -Entwickler an echten Issues aus den eigenen Projekten arbeiten lassen: Mit KI brauchten sie 19 Prozent länger. Erwartet hatten sie, 24 Prozent schneller zu sein - und selbst hinterher, von der eigenen Stoppuhr widerlegt, glaubten sie an eine Beschleunigung von 20 Prozent. Die Studie ist klein und ihr Setting speziell, aber die Lücke zwischen gefühltem und gemessenem Tempo ist genau der Stoff, aus dem blindes Vertrauen gemacht ist.
Die Synthese: Vom Programmieren zu Architektur und Audit
Die Zukunft gehört weder dem reinen Code-Abtippen noch dem ahnungslosen Vibe-Coden. Wir erleben einen radikalen Rollentausch: Senior Developer werden zu den „Erwachsenen im Raum".
Ähnlich wie in der Architektur auf dem Bau wird, wer künftig Software entwickelt, weniger selbst mauern, dafür aber mit dem eigenen Namen für Statik und Sicherheit des Gebäudes haften. Wir bewegen uns weg vom „Schreiben" hin zum „Validieren". Der Wert dieser Arbeit bemisst sich künftig nicht mehr an der Zeit vor dem Editor, sondern an Urteilskraft: zu wissen, wann ein KI-Vibe genial ist - oder wenigstens gut genug - und wann er ein geschäftskritisches Risiko darstellt.
Interessant ist dabei, wer der KI am wenigsten glaubt: In der Stack-Overflow-Umfrage 2025 misstrauen 46 Prozent der Befragten der Genauigkeit von KI-Werkzeugen, nur 33 Prozent vertrauen ihr - und die Skepsis wächst mit der Berufserfahrung. Das ist kein Widerstand von gestern, sondern genau die Urteilskraft, für die das neue Rollenbild bezahlt: Wer weiß, wo KI-Code typischerweise bricht, prüft an den richtigen Stellen.
Was daraus praktisch folgt
Aus den Fehlermustern lassen sich Regeln ableiten, die wenig kosten:
- KI-Code wie fremden Code behandeln. Ein Diff von der KI verdient dieselbe Review wie ein Pull Request von außen - gerade dann, wenn er auf Anhieb läuft.
- Produktion abschotten. Ein Agent braucht keine Zugangsdaten zur Produktivumgebung. Der Replit-Vorfall war kein Modellversagen, sondern eine fehlende Grenze.
- Tests nicht vom Autor benoten lassen. Wer die KI im selben Kontext ihren eigenen Code testen lässt, bekommt Tests, die bestätigen statt prüfen.
- Security-Scans einplanen. Die Veracode-Zahlen werden nicht besser, weil der Prototyp hübsch aussieht. Ein statischer Scanner findet die üblichen Verdächtigen billig.
- Wegwerfcode wegwerfen. Der Prototyp der Fachabteilung ist ein hervorragendes Anforderungsdokument. Er ist kein Release-Kandidat, und beides zu verwechseln ist der teuerste Fehler auf dieser Liste.
Fazit
Vibe Coding ist ein mächtiges Werkzeug, aber kein Freifahrtschein. Karpathy hat es für Wegwerfprojekte beschrieben, und dort glänzt es; alles darüber hinaus ist KI-gestützte Entwicklung und braucht jemanden, der den Code versteht. Wir brauchen Profis mehr denn je - nicht als Schreibkräfte, sondern als kuratierende Instanz einer neuen, KI-gestützten Software-Welt.
Ursprünglich geteilt habe ich diesen Gedanken auf LinkedIn.
Quellen
- Not all AI-assisted programming is vibe coding (but vibe coding rocks) - Simon Willison, 19.03.2025
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR, 10.07.2025
- We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests - Veracode, 2025
- Stack Overflow Developer Survey 2025: AI - Stack Overflow, 2025
- Replit's AI Agent Wipes Company's Codebase During Vibecoding Session - Gizmodo, 23.07.2025