Wir müssen aufhören, alles Vibe Coding zu nennen

Ich kehrte nach einer langen Pause zum Programmieren zurück, und Lovable war der Ort, an dem ich wieder einsteigte. Die Apps sahen großartig aus, funktionierten auf den ersten Blick und kamen in wenigen Stunden zusammen. Anfangs war das bemerkenswert. Doch das reichte nicht mehr, sobald ich wissen wollte, was der Code tut – und warum. Da begann sich meine Herangehensweise zu ändern.

Der Unterschied liegt nicht am Werkzeug oder daran, wie viel Code die KI für Sie schreibt. Es geht um den Vertrag, den Sie mit Ihrem Ergebnis eingehen: ob Sie erklären können, was Sie gerade in die Welt freigegeben haben, oder nicht.

Vibe coding bedeutet im ursprünglichen Sinne, KI‑generierte Software zu akzeptieren, ohne sie gründlich zu prüfen oder zu verstehen, was ihr zugrunde liegt. KI‑unterstützte Entwicklung ist anders. Das Modell kann weiterhin den größten Teil des Codes schreiben, doch die Person, die das System erstellt, bleibt dafür verantwortlich, sein Verhalten zu verstehen, seine Annahmen zu testen und zu entscheiden, ob es versandfertig ist.

Für ein wegwerfbares Experiment, das nie Ihren eigenen Rechner verlässt, hat die Unterscheidung kaum Konsequenzen. Sobald die Software jedoch bereitgestellt, von anderen genutzt oder mit echten Daten verbunden wird, ist sie von enormer Bedeutung.

Wie „Vibe Coding“ seine Bedeutung verlor

Der Begriff „vibe coding“ wurde im Februar 2025 von Andrej Karpathy, Mitbegründer von OpenAI, geprägt. Sein Beispiel war bewusst lässig: ein „Wegwerf‑Wochenendprojekt“, das durch automatisches Klicken auf „Alle akzeptieren“ entstand, die Unterschiede ignorierte und den Code über sein Verständnis hinaus wachsen ließ.

Wochen später bemerkte der Entwickler und Tool‑Hersteller Simon Willison, dass der Begriff sehr anders verwendet wurde: als Synonym für jede KI‑unterstützte Programmierung, was seiner Ansicht nach den Begriff verwässert und einen falschen Eindruck davon vermittelt, was verantwortungsvolle KI‑unterstützte Entwicklung leisten kann.

Erkennbar ist, dass Karpathy schließlich zustimmte. Ein Jahr später stellte er einen anderen Begriff vor für disziplinierteres Arbeiten mit Coding‑Agenten. Er beschrieb „agentic engineering“ als einen Arbeitsablauf, bei dem Entwickler Agenten steuern und überwachen, anstatt einfach das zu akzeptieren, was sie produzieren. Die Unterscheidung ist wichtig: Professionelle KI‑unterstützte Entwicklung erfordert Planung, Prüfung und Verantwortlichkeit in einer Weise, die beim lockeren Vibe Coding fehlt.

Die Grenze ist Verantwortung

Willisons Regel ist einfach und dient als Test für jeden: Committe keinen Code, den du jemand anderem nicht erklären kannst. Das bedeutet nicht, jede einzelne Zeile zu lesen: Da Agenten Hunderte von Zeilen auf einmal erzeugen, tun das selbst erfahrene Entwickler heute nicht mehr. Es bedeutet, die Kernlogik zu verstehen und begründen zu können, warum der Code genau das tut, was er tut. Wenn du das kannst, ist es egal, ob ein Modell ihn geschrieben hat oder du – das ist kein Vibe Coding, sondern die Nutzung eines Werkzeugs zum Erstellen von Software.

Die im Dezember 2025 veröffentlichte Forschung unterstützt diese Unterscheidung. Basierend auf Feldbeobachtungen und einer qualitativen Umfrage unter professionellen Entwicklern stellten die Forschenden fest, dass erfahrene Praktiker die Kontrolle über Softwaredesign und -implementierung behielten, anstatt den gesamten Prozess an KI zu übergeben. Sie behandelten Agenten als Kollaboratoren, planten ihre Arbeit sorgfältig und blieben in der Aufsicht aktiv.

Erfahrung allein erklärt das also nicht. Es geht darum, ob man bereit ist, Verantwortung für das von KI Erzeugte zu übernehmen. Das ist eine Entscheidung, die jeder Entwickler bei jedem Projekt immer wieder treffen muss.

Was passiert, wenn Kontrolle fehlt

Die Folgen, Software ohne Verständnis oder Überprüfung ihrer Sicherheit zu veröffentlichen, sind nicht abstrakt. legte zehntausende ID‑Fotos und über eine Million privater Nachrichten in zwei Sicherheitsvorfällen offen. Die Fehler umfassten einen ungesicherten Speicher‑Bucket und eine separate Datenbank, die ohne Authentifizierung zugänglich war.

Dasselbe zugrunde liegende Problem – Software, die funktionierte, während ihre Autorisierungslogik gefährlich fehlerhaft blieb – zeigte sich in einer Anwendung, die auf der Lovable‑Plattform gebaut wurde: Sicherheitsforscher stellten fest, dass die Autorisierungslogik umgekehrt war, eingeloggte Nutzer aussperrte und unauthentifizierten Angreifern freien Zugang ermöglichte, was über 18.000 Nutzer, darunter Studenten, betraf.

Dies sind keine Einzelfälle, die nur bei „schlechten“ Projekten auftreten. Laut Googles DORA‑Report 2025 verwenden 90 % der Entwickler jetzt KI bei der Arbeit, während etwa ein Drittel wenig bis gar kein Vertrauen in das hat, was sie erzeugt.

Der Einsatz von KI ist mittlerweile weit verbreitet, obwohl das Vertrauen begrenzt bleibt. Das macht eine sorgfältige Überprüfung besonders wichtig, wenn generierter Code Authentifizierung, Berechtigungen oder sensible Daten verarbeitet.

Kontrolle wird schichtweise aufgebaut, nicht auf einmal

In meinem Fall begann ich nicht mit einem formellen Sicherheit‑Audit. Ich weigerte mich einfach weiterzumachen, sobald ich nicht erklären konnte, warum etwas so funktionierte – ein natürlicher Instinkt, den ich als Analyst mitbringe. Mir ist die Syntax weniger wichtig als die Frage, ob das Ergebnis dem entspricht, was wir ursprünglich benötigten. Wenn das nicht der Fall ist, grabe ich weiter.

Mein Arbeitsablauf wurde strukturierter, je ernster die Projekte wurden. Anstatt nur auf Prompt‑Eingaben zu setzen, begann ich, Spezifikationen vorzubereiten, bevor ich irgendetwas generierte. Ich dokumentierte die geschäftlichen Anforderungen, den Technologie‑Stack und die Integrationen. Danach folgten Unit‑Tests und Playwright‑Tests für die wichtigsten Nutzer‑Journeys.

Sicherheitsprüfungen wurden auf ähnliche Weise hinzugefügt. Ich überprüfte die von der KI ausgewählten Bibliotheken und führte Malware‑Scans für hochgeladene Dateien ein. Jede Prüfung entstand aus der Frage, was als Nächstes schiefgehen könnte, anstatt einer zu Beginn erstellten Kontrollliste zu folgen.

Diese Gewohnheit entdeckte ein Problem in einem Projekt. Die KI führte eine Bibliothek ein, die mit der von mir genutzten Framework‑Version inkompatibel war. Die Anwendung war nicht sofort ausgefallen, sodass die Inkompatibilität leicht übersehen werden konnte. Ein späteres Auffinden hätte die Ursache deutlich schwerer identifizierbar gemacht.

Im Vergleich zu den Fällen von Tea und Lovable war dies ein gewöhnliches Problem. Ich fand es früh, behob es und ging weiter. So sieht eine Überprüfung in der Praxis meist aus. Meistens verhindert sie, dass kleine Probleme zu größeren anwachsen.

Ich misstraue Code nicht allein deshalb, weil er von KI erzeugt wurde. Ich vertraue ihm auch nicht nur deshalb, weil die Anwendung läuft. Tests und Überprüfungen sind für mich das Mittel, um festzustellen, ob er wie beabsichtigt funktioniert.

Vom Vibe Coding zum Agentic Engineering

Karpthys eigener Schritt vom „vibe coding“ hin zum „agentic engineering“ ist nicht nur ein Wortwechsel. „Agentic engineering“ liefert uns einen nützlicheren Namen für die Richtung, in die sich die professionelle Entwicklung bewegt. Entwickler schreiben möglicherweise weniger Zeilen selbst, doch das verringert nicht ihre Verantwortung. Es verlagert ihre Arbeit darauf, zu spezifizieren, was das System tun soll, Agenten zu steuern, deren Ausgabe zu testen und zu entscheiden, was sicher veröffentlicht werden kann.

Die Gefahr ist nicht, dass KI Code schnell generiert. Es ist, dass die Generierung schneller voranschreiten kann als das Verständnis. Wenn das passiert, verbirgt scheinbare Produktivität Risiken, die niemand richtig geprüft hat.

Eine Regel, die es wert ist, beizubehalten

Hören Sie auf, „vibe coding“ als Bezeichnung für jede Form von KI‑unterstützter Entwicklung zu verwenden – das verwässert den Begriff und verwischt eine wichtige Unterscheidung in der Kontrolle. Setzen Sie eine einfache Regel: Veröffentlichen Sie nichts, das Sie nicht erklären können. Und bauen Sie Kontrolle schichtweise in das Projekt ein, indem Sie mit dem Wachstum des Projekts Prüfungen hinzufügen, die den auftretenden Risiken entsprechen.

KI kann den größten Teil des Codes schreiben. Sie kann jedoch keine Verantwortung für die Veröffentlichung übernehmen. Das bleibt uns vorbehalten.