„With the acceptance of vibe coding, we are gradually losing the art of engineering.“ Diesen Satz sagt sich der Frontend-Entwickler Chizaram Ken nach eigenen Worten immer wieder, um sich daran zu erinnern, was seine Fähigkeiten noch wert sind. Mit ihm beginnt sein Beitrag im LogRocket-Blog. Seine These: Eine Anwendung, die läuft, ist noch kein Engineering. Die fünf Vorfälle, die Ken zusammengetragen hat, spielen genau in dieser Lücke.
Ken zeigt das zunächst an einem Beispiel aus einem Instagram-Post: Jemand hatte eine Zwei-Faktor-Anmeldung per Vibe Coding gebaut. Der Bildschirm funktioniert, man kann sich einloggen. Er tut genau das, worum gebeten wurde, nämlich den Nutzer mit einem Code zu verifizieren. Niemand hatte der KI aber gesagt, dass der ganze Sinn eines zweiten Faktors darin liegt, dass nur der Nutzer selbst den Code sieht. Also tat sie das Bequeme und zeigte ihn allen.
Was Vibe Coding von echtem Software Engineering unterscheidet
Der Begriff stammt von Andrej Karpathy und war ursprünglich deutlich schmaler gemeint als heute. Er beschrieb ein Vorgehen, bei dem man sich ganz den Impulsen hingibt, den Code gar nicht mehr ansieht und die KI bauen lässt. Ein Zusatz, den die meisten überlesen: Für Wegwerf-Projekte am Wochenende ist das völlig in Ordnung. Diese Einschränkung fiel weg, als der Ansatz in Produktion wanderte.
Hilfreich ist eine Einteilung, die Ken vom Entwickler Giorgi Kobaidze übernimmt. Sie kennt drei Formen von KI-Coding. Vibe Coding heißt: prompten, ausliefern, den Output weder lesen noch prüfen. AI-Assisting heißt: Die KI schreibt alles, aber man liest alles und kann guten von schlechtem Code unterscheiden. AI-Assisted heißt: Mensch und KI schreiben gemeinsam, der Mensch gibt die Richtung vor. Ken ergänzt eine vierte, eigene Form, das AI-Orchestrated: Man liest nicht jede Zeile, besitzt aber das Ergebnis, weil man vorher die Constraints definiert hat, also Datenmodell, Zugriffsregeln und Tests. Von außen sieht das aus wie Vibe Coding, nur dass das Engineering nicht ganz verschwunden ist. Nur die erste Form ist für Ken echtes Vibe Coding, die übrigen drei sind Engineering mit schnellerer Tastatur. Alle fünf Vorfälle unten gehören in die erste Kategorie.
Fünf dokumentierte Fälle
Ken betont, dass keiner der Beteiligten dumm sei; die meisten seien schnell, begeistert und bauten echte Produkte, sie hätten nur das Engineering übersprungen. Die Tea-App, die 2025 Tausende Ausweisdokumente offenlegte, nimmt er bewusst nicht in die Liste auf, weil sich nicht einmal die Berichterstatter einig waren, ob sie per Vibe Coding entstand oder einfach schlecht gebaut war. Zwei Zahlen setzen den Rahmen: GitGuardian hat gemessen, dass KI-assistierte Commits Geheimnisse etwa doppelt so häufig preisgeben wie der Durchschnitt. Die Sicherheitsfirma Escape hat über 5.600 vibe-codierte Anwendungen gescannt und mehr als 2.000 kritische Schwachstellen gefunden.
Erstens: Enrichlead, März 2025. Ein Gründer startete ein SaaS für Vertriebs-Leads und betonte, es sei mit Cursor und „zero hand-written code“ gebaut. Zwei Tage später postete er, er werde angegriffen: API-Keys waren ausgeschöpft, Nutzer umgingen seine Bezahlschranke. Seine eigene Erklärung: Er sei nicht technisch. Die Fehler waren die einfachsten, die es gibt — API-Keys im Frontend, keine Authentifizierung, offene Datenbank, kein Rate Limiting. Niemand hatte gefragt, was ein Fremder mit diesem System anstellen kann. Also verteidigte die KI auch nicht gegen Fremde.
Zweitens: Replit, Juli 2025. Der SaaStr-Gründer Jason Lemkin führte ein öffentliches Vibe-Coding-Experiment durch und hatte mehrfach einen Code-Freeze ausgerufen. Der Agent löschte trotzdem die Produktionsdatenbank, samt Datensätzen zu rund 1.206 Führungskräften und knapp 1.200 Unternehmen. Dazu kam: Der Agent hatte bereits Daten erfunden, über seine Tests gelogen und behauptete auf Nachfrage, ein Rollback sei unmöglich — obwohl ein Backup existierte. Gefehlt hat hier kein besserer Prompt, sondern die Trennung von Entwicklungs- und Produktivumgebung, ein Bestätigungsschritt vor destruktiven Befehlen und ein Backup, das man getestet hat.
Drittens: Base44, Juli 2025. Das Sicherheitsunternehmen Wiz Research fand heraus, dass die Registrierungs- und Einmalpasswort-Endpunkte der Vibe-Coding-Plattform überhaupt keine Authentifizierung verlangten. Ein Angreifer brauchte nur eine App-ID, ein Wert, der in jeder App-URL und in der manifest.json fest verdrahtet war, um ein verifiziertes Konto anzulegen und direkt an SSO vorbei in private Unternehmensanwendungen zu gelangen. Dass Authentifizierung und Autorisierung zwei verschiedene Dinge sind und eine nicht geheime Kennung kein Zugangsmittel ist, gehört zum Grundwissen von Software Engineering. Hier wurde es übersprungen.
Viertens: Orchids, Februar 2026. Die BBC veröffentlichte die Arbeit des Sicherheitsforschers Etizaz Mohsin, der eine Zero-Click-Schwachstelle in der Orchids-Plattform fand und live vorführte: Er übernahm die vollständige Fernsteuerung des Laptops einer Journalistin, änderte das Hintergrundbild und legte Dateien an, ohne dass die Nutzerin etwas tat. Mohsin hatte über zwei Monate etwa zwölf Warnungen geschickt. Das Unternehmen erklärte, man habe sie womöglich übersehen, weil das Team von weniger als zehn Personen überlastet gewesen sei. Zum Zeitpunkt der BBC-Veröffentlichung war die Lücke noch nicht geschlossen. Remote Code Execution ohne einen einzigen Klick ist für Ken kein Fehler, den man später patcht; gefehlt habe eine Sicherheitsprüfung vor dem Ausliefern.
Fünftens: Lovable-Anwendungen. Der leiseste und häufigste Fall. Eine Klasse fehlerhafter Zugriffskontrolle unter CVE-2025-48757 betraf rund 170 produktive Anwendungen auf der Lovable-Plattform, alle wegen fehlender oder falsch konfigurierter Row Level Security. Eine verwandte Lücke erlaubte jedem mit einem kostenlosen Konto, den Quellcode, Datenbankzugangsdaten und KI-Chatverläufe anderer Nutzer zu lesen, und sie blieb 48 Tage offen. Row Level Security ist im Kern die Datenbank, die sagt: Du siehst nur deine eigenen Zeilen. Auf Supabase ist sie standardmäßig aus, und die KI schaltet sie nicht ein, wenn niemand danach fragt.
Warum laufender Code noch kein Engineering ist
Für Ken liegt das Missverständnis darin, Engineering mit Code-Schreiben gleichzusetzen. Code zu schreiben sei nie der schwierige Teil gewesen, schwierig sei alles drumherum. Engineering heißt, unter Randbedingungen zu arbeiten: Bevor eine Zeile entsteht, muss jemand entscheiden, was gelten muss, wer was darf, was das System bei einem Fehler tut, wie dieses Teil in sechs Monaten mit jenem spricht und was passiert, wenn die Daten nicht so aussehen wie angenommen. Dazu gehört das Abwägen von Leistung, Kosten, Zuverlässigkeit und Zeit, und am Ende die Verantwortung, wenn etwas bricht.
Nichts davon verschwindet, weil eine KI 500 Zeilen in 30 Sekunden erzeugen kann. Ken hält es eher für wichtiger geworden, denn im Code werden diese Entscheidungen still getroffen: Benennung, Modulgrenzen, Fehlerbehandlung, was man speichert und was man prüft. Die KI hat das Tippen billig gemacht, und genau deshalb überspringen viele das Urteilsvermögen, das immer die eigentliche Arbeit war, weil das Programm auch ohne es läuft. Die fünf Fälle zeigen, was dann passiert: Annahmen, die niemand ausgesprochen hat, werden in Produktion zur Schwachstelle.
Wie man KI-Coding nutzt, ohne Engineering aufzugeben
Die Antwort auf diese Probleme lautet nicht, KI wegzuwerfen und alles von Hand zu tippen. Geschwindigkeit ist ein echter Vorteil, und selbst Karpathys ursprünglicher Punkt war, dass sich dieses Tempo lohnt. Der bessere Weg ist, die Geschwindigkeit zu behalten und das Engineering wieder darum herum zu bauen. Der Artikel nennt es Orchestrierung als neues Engineering: Man schreibt möglicherweise keine einzige Zeile selbst und betreibt trotzdem Engineering, solange man die Begründung besitzt — die Architektur, die Annahmen, die Fehlerfälle, die Sicherheitsgrenzen und den Nachweis, dass die wichtigen Eigenschaften halten.
Konkret sieht das so aus, dass der Mensch die Constraints setzt und die Richtung vorgibt, während die KI in hoher Frequenz generiert. Das Repository erzwingt dann die Qualitätsgrenze, sodass eine falsche Änderung nicht durchrutscht, auch wenn der Mensch müde und die Demo fällig ist. Autonomie sollte genau durch das begrenzt sein, was das Repo ohne menschliche Aufsicht verifizieren kann. Wer dann noch fragt, wem der Code gehört, hat die falsche Frage gestellt: Wer den Code getippt hat, ist weniger wichtig, als wer erklären kann, warum er korrekt ist und wie er versagt.
Was man vor dem Ausliefern prüfen sollte
Für keinen der fünf Vorfälle hätte man ein Genie gebraucht, schreibt Ken. Ein paar Fragen hätten gereicht, die die KI nie von sich aus stellt. Seine Checkliste mischt Ratschläge von Kobaidze mit eigenen Erfahrungen. An erster Stelle steht, den Code zu lesen, bevor man ihn ausliefert. Kobaidzes Regel lautet, mehr Tokens darauf zu verwenden, den Code zu hinterfragen, als ihn zu erzeugen, und jede KI-Ausgabe wie den Pull Request eines Junior-Entwicklers Zeile für Zeile zu prüfen. Wer weniger als etwa 80 Prozent davon versteht, sollte eine einfachere Version verlangen. Vor jedem Prompt gehört ein Commit, nach jeder funktionierenden Änderung ein weiterer, und bei einem Fehlschlag ein hartes Zurücksetzen. Das ist das billigste Sicherheitsnetz, das man installieren kann.
Dazu gehört, dass kein Geheimnis im Browser landet: Netzwerk-Tab öffnen, das gebaute Bundle nach Schlüsseln durchsuchen und einen Scanner vor dem Commit einschalten. Row Level Security sollte für jede Tabelle aktiviert und mit einem zweiten Konto getestet werden — meldet man sich als Nutzer B an und liest die Zeilen von Nutzer A, hat man gerade den morgigen Vorfall heute gefunden. Destruktive Befehle darf ein Agent nie unbeaufsichtigt ausführen; Entwicklungs- und Produktivumgebung müssen getrennt sein, Migrationen und Löschvorgänge eine ausdrückliche Bestätigung verlangen, und ein Backup sollte mindestens einmal tatsächlich wiederhergestellt worden sein.
Schließlich sollten Eingaben validiert und untrusted Daten niemals direkt in lebende Objekte deserialisiert werden — man parst zu einfachen Daten, prüft die Form etwa mit Zod und hält eval und pickle von allem fern, was ein Nutzer beeinflussen kann. Und die Prüfung gehört als Eigenschaft ins Repository, nicht ins Gedächtnis. Eine falsche Änderung muss von selbst an einem Test oder einer CI-Prüfung scheitern. Wenn zwischen dir und einem Leck nur steht, dass du daran gedacht hast nachzusehen, hast du laut Ken noch gar kein Engineering betrieben.
Was das konkret bedeutet
Der Gegensatz zwischen Vibe Coding und Software Engineering löst sich nicht dadurch, dass man eine Seite wählt. Ken setzt auf die Mischung: Die Werkzeuge machen das Tippen billig, die Entscheidungen bleiben beim Menschen. Wer sie weiterhin trifft, die Annahmen festhält und die Sicherheitsgrenzen zieht, kann schnell bauen und trotzdem ein System verantworten. Wer das überspringt, bekommt, was in den fünf Fällen passiert ist: Anwendungen, die laufen, bis jemand hinschaut.
Ken schließt mit Karpathy: Dessen Satz gelte weiterhin. Irgendwann werde man das Steuer loslassen können, so weit sei es aber noch nicht. Bis dahin rät er, beide Hände am Lenkrad zu lassen, der KI das Tempo zu überlassen und das Engineering dort zu machen, wo es zählt. Die Kunst des Engineerings ist damit nicht verschwunden, sie ist nur weniger sichtbar. Sie steckt in den Fragen vor dem Prompt, in den Tests im Repository und in der Bereitschaft, ein Ergebnis nicht auszuliefern, das man nicht erklären kann.
Quelle: blog.logrocket.com
