Ein Gründer schickt mir seinen Code. Er hat ein internes Tool in drei Tagen gebaut — mit Cursor, Claude, und einem guten Gefühl dafür, was er wollte. Die App funktioniert. Die Nutzer sind zufrieden. Das Problem: Niemand im Unternehmen kann erklären, was in den 14.000 Zeilen Code passiert.
Das ist kein Einzelfall. Seit AI-gestützte Coding-Tools die Produktionsgeschwindigkeit um den Faktor fünf bis zehn erhöht haben, entsteht Software schneller als je zuvor. Was nicht mitgewachsen ist: das Verständnis dafür, was dabei entsteht.
Das Bild mit dem Hausbau
Stellen Sie sich vor, jemand baut ein Haus in drei Tagen statt in drei Monaten. Die Wände stehen, das Dach ist dicht, alles sieht solide aus. Aber ob die Statik stimmt, ob die Leitungen richtig verlegt sind, ob der Keller bei Starkregen volläuft — das weiß nur, wer unter die Oberfläche schaut. Genau das passiert gerade flächendeckend in der Softwareentwicklung.
Vibe-Coding — der Prozess, bei dem ein Entwickler natürlichsprachlich beschreibt, was er will, und ein AI-Tool den Code generiert — ist bemerkenswert gut geworden. Cursor, GitHub Copilot und ähnliche Werkzeuge produzieren funktionierenden Code, der auf den ersten Blick sauber aussieht. Die Oberfläche stimmt. Aber darunter liegen Entscheidungen, die niemand bewusst getroffen hat.
Was wirklich schief geht
In den letzten Monaten habe ich etwa ein Dutzend solcher Codebases geprüft — von Startups, von internen IT-Teams, von Agenturen. Die Muster wiederholen sich mit bemerkenswerter Regelmäßigkeit.
Das häufigste Problem ist nicht schlechter Code. Es ist inkonsistenter Code. Wenn ein LLM Funktionen generiert, optimiert es jede einzelne Funktion für sich. Es gibt keine übergreifende Architekturentscheidung, keinen roten Faden. Authentifizierung wird an drei Stellen unterschiedlich implementiert. Datenbankzugriffe folgen zwei verschiedenen Patterns. Error Handling existiert in manchen Modulen penibel, in anderen gar nicht.
Das zweite Muster betrifft Security. AI-generierter Code ist erstaunlich gut darin, die „Happy Path"-Funktionalität abzudecken — also den Normalfall, bei dem alles wie erwartet läuft. Was fehlt, ist die Absicherung der Randfälle. SQL-Injection-Schutz, der in 80% der Queries greift, aber in 20% vergessen wurde. API-Endpunkte, die existieren, aber keiner Autorisierungsprüfung unterliegen. Environment Variables, die im Code statt in Secrets liegen.
Das dritte Muster ist subtiler: Abhängigkeiten. LLMs lösen Probleme gerne, indem sie Bibliotheken importieren. Jedes generierte Modul zieht seine eigenen Dependencies — und niemand hat geprüft, ob drei verschiedene Libraries jetzt dasselbe tun, ob Versionen kompatibel sind, oder ob eine davon seit zwei Jahren nicht mehr gewartet wird.
Warum das keine Kritik an den Tools ist
Die Pointe ist nicht, dass Cursor oder Copilot schlecht sind. Im Gegenteil — diese Tools sind außergewöhnlich leistungsfähig, und die Geschwindigkeit, die sie ermöglichen, ist real. Die Pointe ist, dass schnelles Bauen und solides Bauen zwei verschiedene Fähigkeiten sind, die sich nicht automatisch bedingen.
Ein erfahrener Entwickler, der ein AI-Tool nutzt, produziert exzellente Ergebnisse, weil er jeden generierten Block im Kontext des Gesamtsystems bewertet. Ein weniger erfahrener Entwickler — oder ein Gründer, der zum ersten Mal Code schreibt — bewertet den Output danach, ob er funktioniert. Das ist ein fundamentaler Unterschied.
Die Frage ist nicht, ob der Code funktioniert. Die Frage ist, ob er noch funktioniert, wenn etwas Unerwartetes passiert.
Was ein Audit eigentlich prüft
Ein Vibe-Coded Software Audit schaut auf genau die Schichten, die beim schnellen Bauen übersprungen werden. Architekturkohärenz: Folgt die Codebase einem erkennbaren Muster, oder ist sie eine Sammlung isolierter Lösungen? Security Posture: Wo sind die offenen Flanken, die ein Angreifer — oder ein Datenschutzauditor — finden würde? Dependency Health: Welche externen Bibliotheken laufen mit, was davon ist notwendig, was ist Ballast, was ist ein Risiko? Und schließlich: Wartbarkeit. Kann jemand, der diesen Code in sechs Monaten anfasst, verstehen, was passiert?
Das Ergebnis ist kein 80-seitiges Dokument, sondern eine priorisierte Liste: Was muss jetzt passieren, was kann warten, und was ist in Ordnung so, wie es ist.
Die eigentliche Frage
Die interessanteste Entwicklung ist vielleicht, dass „Vibe-Coded Software Audit" bald kein Nischen-Service mehr sein wird, sondern eine Standardkategorie. Wenn ein wachsender Anteil aller Software AI-generiert ist, verschiebt sich die Wertschöpfung: weg von der Erstellung, hin zur Validierung. Die Fähigkeit, Code zu bewerten, wird wertvoller als die Fähigkeit, ihn zu schreiben.
Das verändert auch, was technische Kompetenz in Unternehmen bedeutet. Die Frage an den eigenen Entwickler — oder an den externen Dienstleister — lautet nicht mehr „Kannst du das bauen?" Bauen kann mittlerweile fast jeder. Die Frage lautet: „Kannst du mir erklären, warum es so gebaut ist?"
Wer diese Frage nicht beantworten kann, hat ein Problem. Nicht weil der Code schlecht ist — sondern weil niemand weiß, ob er gut ist.