Vibe-Coded Software
Eine überwiegend von KI-Tools generierte App, deren sicherheitskritische Pfade kein Mensch gelesen hat. Sie demot sauber und bricht vorhersehbar.
Vibe-coded Software ist das Ergebnis von Vibe Coding : eine überwiegend von KI-Tools gebaute Anwendung, deren sicherheitsrelevante Teile kein Mensch gelesen hat. Sie definiert sich nicht dadurch, KI-generiert zu sein. Sie definiert sich durch das Fehlen eines menschlichen Reviews auf den Pfaden, wo ein Fehler echtes Geld, echte Daten oder einen echten Breach kostet. Viel KI-generierter Code ist reviewed, gehärtet und vollkommen sicher. Vibe-coded Software ist die Teilmenge, bei der das nicht passiert ist.
Das prägende Merkmal: Sie demot sauber und bricht vorhersehbar. Sauber, weil das Modell sehr gut darin ist, den Happy Path funktionieren zu lassen, den Pfad, den man im Demo abläuft. Vorhersehbar, weil die Fehler jedes Mal an derselben Handvoll Stellen clustern: Autorisierung, die prüft ob du eingeloggt bist, aber nicht ob du diesen Datensatz sehen darfst, Input dem vertraut statt der validiert wird, hartcodierte oder an den Browser ausgelieferte Secrets, kein Rate Limiting, kein Error Handling jenseits eines generischen Catch. Wer ein vibe-coded App auditiert hat, kann die Findings des nächsten erraten, bevor er es öffnet.
Beispiel, das kanonische. Eine Buchungs-App hat einen sauberen Login. Einmal drin holt die App deine Buchungen von /api/bookings/1234. Ändere 1234 auf 1235 und du siehst die Buchung von jemand anderem, dessen Name, dessen Adresse, dessen Zahlungsreferenz. Der Login fühlte sich sicher an, also prüfte niemand. Der Server hat nie verifiziert, dass der eingeloggte User die Buchung 1235 besitzt. Das nennt man einen Broken-Object-Level-Authorization-Bug, und er ist der mit Abstand häufigste schwere Defekt in vibe-coded Software, weil das Demo nie den Fall durchspielt, dass ein User nach den Daten eines anderen greift.
Der ehrliche Trade-off: Vibe-coded Software ist tatsächlich billiger und schneller zu produzieren, und für einen Prototyp ist das genau richtig. Der Preis ist, dass die Ersparnis vorgezogen ist und die Rechnung später kommt, als Breach, als DSGVO-Vorfall oder als Rewrite. Das zu benennen ist kein Anti-KI-Snobismus. Der Code kann vollkommen gut sein, sobald die fehlenden 10 % ergänzt sind. Der Fehler ist, die 90 % auszuliefern und anzunehmen, das Demo habe die übrigen 10 % bewiesen.
Wavect auditiert vibe-coded Software auf genau dieses Profil unter Software Quality Assurance . Wir lesen zuerst die Autorisierungspfade, weil dort der schlimmste und häufigste Bug lebt, dann Input-Validierung, Secrets und Error Handling, dann ergänzen wir die Regressions-Suite und das CI/CD -Gate, das die nächste Änderung daran hindert, das Loch wieder aufzureißen. Es ist kein Rewrite. Es ist, die von den Tools hinterlassene Technical Debt sichtbar zu machen und dann den Teil abzuzahlen, der dir schaden kann.
Wann das im Softwareprojekt zählt. Wenn du eine sauber demoende App hast und niemand die Autorisierungspfade gelesen hat. Das definierende Risiko ist nicht schlechter Code, sondern das Fehlen einer menschlichen Prüfung dort, wo ein Fehler Geld, Daten oder einen Breach kostet.
Was Founder meistens falsch machen. Sie shippen die 90 Prozent, die die Demo bewiesen hat, und nehmen an, die Demo habe auch die anderen 10 Prozent bewiesen. Die fehlenden 10 Prozent, Auth, Validierung, Secrets, sind genau der Teil, den die Demo nie ausführt.
Wie Wavect damit umgeht. Wir auditieren auf das vorhersehbare Fehlerprofil, Autorisierung zuerst, weil dort der schlimmste Bug lebt, und ergänzen dann die Regressions-Suite und das CI/CD-Gate, das das Loch am Wiederaufreißen hindert. Der Leitfaden vom vibe-coded Prototyp zur Production zeigt, was übernommen und was neu gebaut wird.