Sind wir nicht alle Programmierer?
Korrekt, wir sind eben nicht alle Programmierer. Um das gleich vorwegzunehmen: Auch wenn entsprechende Beiträge auf YouTube aktuell andere Aussagen dazu vornehmen.
Was ist Vibe-Coding überhaupt?
Per Definition ist Vibe Coding die Erstellung von Software durch Personen, die dafür keinerlei Ausbildung oder Kenntnisse in der Softwareentwicklung aufweisen müssen. Sie formulieren ihre Ideen in natürlicher Sprache an ein LLM und erhalten dann irgendwann ein Programm für einen bestimmten Zweck. Einzig das LLM, also die KI, muss entsprechend bedient – der Prompt gefüttert – werden, wobei die Anforderungen so gründlich wie nötig formuliert werden sollten. Aber auch das ist kein Muss.
Die Illusion der Einfachheit
Für das private Umfeld mag das ja noch so gut gehen, wenn keine Konventionen wie Wartbarkeit, Sicherheit und Qualität im Vordergrund stehen. Nur sofern diese Art Software dann den eigenen Rechner verlässt und über irgendwelche Kanäle geteilt wird, wird in der Regel glatt ein Problem geteilt – dessen Ausmaß der Ersteller dieser Software nicht auf dem Schirm hat, weil er schlichtweg nicht um die Funktion weiß, welche in den einzelnen Codezeilen drin steht.
Auch wenn ein LLM hierbei mitunter noch etliche Kommentarzeilen einfügt, um den Code nicht völlig undokumentiert im Raum stehen zu lassen: Diese werden dann abgenickt, „toll!“ gesprochen, und fertig ist das unfertige Programm. Als würde unsere Software-Industrie nicht selbst schon genug Mist fertigen – nein, jetzt kann das auch noch jeder selbst.
Die Gefahr der „unqualifizierten Softwareentwicklung“
Und dann gibt es natürlich auch noch YouTube-Kanäle, die zu genau diesem Vibe-Coding aufrufen mit Headlines wie „Jetzt kannst du programmieren“. Um es auf den Punkt zu bringen: Wer vorher keinen Quellcode lesen und verstehen konnte, der kann es auch jetzt nicht. Und so gelangt KI-generierter Code in der Regel ohne jede funktionelle Überprüfung in die freie Wildbahn. Vibe Coding kann man daher auch ganz simpel als die „unqualifizierte Softwareentwicklung“ bezeichnen.
Neben eingeschränkter Funktionalität und völlig falschen Funktionen sind ganz lapidar auch erhebliche Sicherheitslücken damit einhergehend.
Warum LLMs kein Sicherheitsgarant sind
Dazu rufen wir uns einmal kurz ins Gedächtnis, wie ein LLM arbeitet: Ein LLM wird trainiert, und irgendwann ist dieses Training abgeschlossen. Ausgeliefert wird dann in der Regel das LLM mit all seinen Milliarden Parametern, allerdings NICHT mit den Werten oder Quellen, mit denen es überhaupt trainiert wurde. LLMs trainieren auf öffentlichem Code, der oft veraltete oder unsichere Muster enthält (z. B. Hardcoded Secrets, SQL-Injection-Anfälligkeiten). Das ist das reale Risiko, nicht eine böswillige Hintertür des Modells.
Zum anderen ist das Ende eines jeden Trainings auch der Status Quo des Modells: Alles, was danach in der Softwarewelt neu kam, welche Sicherheitslücken bekannt wurden und wie man diese behoben hat, weiß das LLM nicht. Ein Fehler kann nur behoben werden, wenn diese Behebung Bestandteil des Trainings war.
Das führt dazu, dass heute bekannte Sicherheitslücken in einem Modell von gestern als ganz normaler Code angesehen und dem Vibe-Coder aufgetischt werden. Der Code wird mangels Verständnis dann als „gut“ befunden, man fühlt sich mit seiner App wohl und verbreitet sie möglicherweise weiter. Bei Verwendung eines Modells wie z. B. dem Qwen-Coder werden einem oftmals Platzhalter mitgeliefert, die auf die jeweilige lokale Gegebenheit angepasst werden müssen. Selbst das wird in der Regel unterbleiben; der Kommentar des LLM dazu im Code wird überlesen oder der ganze Code wird nicht einmal gelesen – und schwups, ist schon die erste Fehlerstelle eingebaut.
Der Unterschied: Kontrollierte Nutzung vs. Vibe Coding
Ich lasse mir natürlich auch von einem LLM unter die Arme greifen, wenn ich es an unterschiedlichen Stellen benötige und vor allem auch weiß, was ich mit dem Output anzufangen habe. Zum Beispiel ein einfacher Request:
{
"firstName": "",
"lastName": "",
[...]
}
Prompt: -> Bitte passe mir den Block so an, dass die Werte aus dem Input dynamisch übernommen werden, welche alle im Pfad 'originalInput.' liegen.
{
"firstName": "{{ $json.originalInput.firstName || '' }}",
"lastName": "{{ $json.originalInput.lastName || '' }}",
[...]
}
Das hat mir in dem Moment eine Menge Tipperei und Copy & Paste gespart, und ich brauche nach kurzer Sichtung nur den ganzen Block zu übernehmen. Und ich weiß vor allem, was es tut – das ist dann die kontrollierte Nutzung.
Der Qwen3-Coder umfasst 92 verschiedene Programmiersprachen. Ich habe mir den Spaß gemacht, mir diese einmal alle auflisten zu lassen – und komme auf gerade einmal 24 Sprachen, von denen ich überhaupt schon einmal etwas gehört habe. Davon sind allerdings 8 bereits gar keine richtigen Programmiersprachen, sondern eher die korrekte Syntax für Ausdruckssprachen, Formatierungen sowie Befehlsreferenzen für Shells. Bleiben mir also 16 Sprachen, von denen ich überhaupt wusste, dass es sie gibt. Davon sicher beherrschen tue ich: Null. Lass es fünf Sprachen sein, mit denen ich zu tun habe – speziell im Umfeld von Webapps, Docker und der Kommunikation dieser Apps untereinander. Aber ich entwickle auch keine Software oder code mir irgendwas zusammen, von dem ich nicht weiß, was es ist.
Der historische Kontext: Von Mailboxen zur Allgegenwart
Es ist zwar gut und schön, dass die Einstiegshürden für viele Bereiche im digitalen Leben immer weiter gesenkt werden. Vor nun rund 35 Jahren gab es kein Internet, die Software-Welt war einigermaßen überschaubar, und online warst du nur mit direkten Anrufen in Mailboxen. Vernetzt warst du entweder dort, schick im Textmodus und ohne jede Grafik – maximal noch mit dem Fidonet verbunden. Irre langsam das Ganze natürlich. Wer da online sein wollte, benötigte viel Geduld und ein wenig technisches Verständnis. Diese Zeiten sind vorbei – und jeder ist online.
Die paradoxe Sicherheitsanforderung
Mit immer weiter sinkenden Hürden bei der Nutzung von digitalen Geräten und Diensten steigen exponentiell die Anforderungen an Sicherheit, Funktionalität und Qualität der Software. Sie muss immer „idiotensicherer“ geschrieben sein – denn auch die Fehler der Bediener werden immer besser und erhalten turnusmäßig Upgrades in dem, was sie alles falsch machen könnten. Ein mittels Vibe Coding erstellter Quellcode sieht das nicht vor; er ist meistens nicht besonders gut zu warten, weil sich niemand auch nur einen klitzekleinen Gedanken um eben diese Wartbarkeit gemacht hat. Einem LLM ist das „egal“ – es setzt die Anforderungen aus dem Prompt einfach um. Dabei einen hochqualitativen Code zu erzeugen, ist gegenwärtig nicht vorgesehen.
Daher sind LLMs auch eher zur Unterstützung der Entwicklung, ja zur Abnahme einzelner Aufgaben oder zum Entwurf von Teilaspekten eines Programms geeignet – ENTWURF. Dieser kann selbstverständlich als ein guter Ansatz und evtl. sogar Leitfaden herangezogen werden.
Vibe Coding als Rapid Prototyping – aber mit Risiken
Vibe Coding ist wie früher die ersten 3D-Drucker: Diese waren für Rapid Prototyping vorgesehen, was anderes ist Vibe Coding im Grunde genommen jetzt auch nicht. Mittlerweile sind 3D-Drucker jedoch so gut geworden, dass diese wirklich von so gut wie jedem sicher bedient werden können und sich in die normale Produktion eines Unternehmens einbinden lassen. Mit Vibe Coding wird es vermutlich einen ähnlichen Verlauf nehmen, zumindest ist dieser nicht ausgeschlossen. Das gegenwärtige Problem besteht eher darin, dass massenhaft schlecht entworfene Software nicht in der Mülltonne landet – wie ein fehlgeschlagener 3D-Druck der ersten Stunden – sondern sich munter in irgendwelchen Portalen tummelt und auf Verbreitung wartet.
Ich erinnere mich da an einen Facebook-Nutzer, der einen Beitrag von heise online kommentiert hat zum Thema Vibe Coding: „Hab meine erste PC-App innerhalb von zwei Stunden fertig gehabt – jetzt baue ich gerade die APK fürs Handy“ – genau so dürfte der Code denn auch aussehen.
Fazit: Wie man Vibe Coding sicherer macht
Vibe Coding ist zwar nicht per se zu verteufeln, nur der Nutzungskontext ist oftmals falsch und damit ein Risiko. Doch wie entschärft man dies? Ein paar Ansätze und Überlegungen:
- Code-Review: Lasse den von einer KI erzeugten Code von einer anderen Person (oder einem erfahrenen Entwickler) auf Fehler und Probleme hin untersuchen.
- Automatisierte Prüfung: Nutze Tools zur automatischen Sicherheitsprüfung (SAST).
- Sandboxing: Belasse unklaren Code in deiner „Sandkiste“ und bringe diesen nicht in ein produktives Umfeld.
- Kritische Haltung: Verlasse dich also nie einfach auf den Output, sondern bleibe kritisch. Wenn Unklarheiten bestehen, frage nach oder recherchiere, bevor du den Code einsetzt.
Thinkin ‚bout
