Erg\u00e4nzend erfolgt die Anbindung eines Microfrontends, das die Interaktion mit dem Service erm\u00f6glicht und die erzeugten Lernressourcen nutzbar macht. In unserem Projekt wurde der Vibe Coding Ansatz von Andrej Karpathy \u00fcbernommen, das in Kapitel 1.1 n\u00e4her beschrieben wird. Hierbei wurde bewusst auf spezialisierte Vibe-Coding-Tools oder IDEs wie Cursor verzichtet. Stattdessen wurden ausschlie\u00dflich Modelle ohne autonome Tool-Nutzung verwendet.
Die Untersuchung betrachtet die Effizienz des Vibe Coding-Ansatzes und die technischen, organisatorischen und qualitativen Herausforderungen, die beim Einsatz gro\u00dfer Sprachmodelle im Entwicklungsprozess auftreten k\u00f6nnen.<\/p>\n\n\n\n
Grundlagen & Grundbegriffe<\/h2>\n\n\n\n
Im Folgenden werden die zentralen Begriffe und theoretischen Grundlagen erl\u00e4utert, die f\u00fcr das Verst\u00e4ndnis des Gesamtprojekts erforderlich sind. Dazu geh\u00f6ren die Definition des Konzepts Vibe Coding, dessen Einordnung in die Softwareevolution, eine Darstellung des aktuellen Einsatzes von KI (K\u00fcnstliche Intelligenz) im Entwickleralltag sowie eine Beschreibung relevanter Anwendungsfelder von KI.<\/p>\n\n\n\n
Vibe Coding Definition<\/h3>\n\n\n\n
Der Begriff Vibe Coding wurde von Andrej Karpathy gepr\u00e4gt, einem Mitgr\u00fcnder von OpenAI. In einem Beitrag auf X beschrieb er den Ansatz als eine Form der Softwareentwicklung, bei der der Fokus nicht mehr auf einzelnen Codezeilen liegt, sondern auf der Beschreibung der gew\u00fcnschten Ergebnissen oder auch den Vibes [4]. Karpathys Beschreibung des Workflows ist folgende: <\/p>\n\n\n\n
1. Definition eines neuen Features <\/p>\n\n\n\n
2. Mitteilung des Features an die KI <\/p>\n\n\n\n
3. Akzeptieren der \u00c4nderungen ohne tiefgreifende \u00dcberpr\u00fcfung <\/p>\n\n\n\n
4. Ausf\u00fchrung von Tests und Behebung m\u00f6glicher Fehler, indem Fehlermeldungen wieder in die KI zur\u00fcckgespielt werden <\/p>\n\n\n\n
Dieser Zyklus f\u00fchre nach Karpathy zu einem schnellen, iterativen Wachstum des Codes und eigne sich besonders f\u00fcr Experimente sowie fr\u00fche Prototypen. Die Softwareentwicklung wird damit zu einem dialogischen Prozess, der durch nat\u00fcrliche Sprache gesteuert wird [4].
Eine alternative Betrachtungsweise ergibt sich aus der Theorie der verteilten Kognition, die Edwin Hutchins 1995 pr\u00e4gte [5]. Diese Theorie geht davon aus, dass Denken nicht ausschlie\u00dflich im Kopf einer einzelnen Person stattfindet, sondern sich auf Werkzeuge, Umgebungen und externe Darstellungen verteilt. Notizen, Skizzen oder Code fungieren dabei als aktive Speicher und Werkzeuge des Denkens. \u00dcbertragen auf Vibe Coding bedeutet dies, dass die KI zu einem kognitiven Partner wird. Die kognitive Einheit erweitert sich von der einzelnen Entwicklerperson auf ein System bestehend aus Mensch, KI-Modell, Chatoberfl\u00e4che und entstehendem Code [6].
Dieser Prozess schafft neue Abh\u00e4ngigkeiten: Sobald die KI-Anweisungen missversteht, muss der Mensch seine Prompts anpassen, klarer formulieren oder den Output manuell korrigieren. Vibe Coding wird damit zu einer Form der kooperativen Probleml\u00f6sung, bei der Mensch und KI gemeinsam ein Team bilden.<\/p>\n\n\n\n
Einordnung in die Softwareevolution<\/h3>\n\n\n\n
Historisch betrachtet reiht sich Vibe Coding in eine lange Entwicklung technischer Abstraktionsstufen ein [6]: Von fr\u00fchen Low-Level-Sprachen \u00fcber Hochsprachen, objektorientierte Paradigmen, Web-Frameworks sowie Low-Code- und No-Code-Plattformen bis hin zu KIgest\u00fctztem Programmieren. Der Fokus verschiebt sich stetig: Weg von technischer Hardware-N\u00e4he hin zu h\u00f6herer Abstraktion und Entwicklerproduktivit\u00e4t. Vibe Coding stellt in diesem Kontinuum die n\u00e4chste Stufe dar: Es verlagert den Schwerpunkt von Befehlen auf Ziele und von technischer Umsetzung auf Kreativit\u00e4t. Die nat\u00fcrliche Sprache wird zum prim\u00e4ren Interface der Softwareentwicklung. <\/p>\n\n\n\n
Diese Entwicklung spiegelt sich deutlich in aktuellen arbeitsmarktbezogenen Befunden wider. Laut PwC AI Jobs Barometer 2025 [7]: <\/p>\n\n\n\n
- \n
- w\u00e4chst die Produktivit\u00e4t in KI-intensiven Branchen seit 2022 fast dreimal so schnell wie in anderen Sektoren. <\/li>\n\n\n\n
- Skillsets in KI-nahen Berufen ver\u00e4ndern sich derzeit 66 % schneller als zuvor. Wissen verschiebt sich von technischer Syntax hin zu Aufgabenorchestrierung und dem effizienten Anleiten KI-basierter Systeme. <\/li>\n\n\n\n
- Die Eintrittsbarrieren sinken: Der Anteil an Stellenausschreibungen, die einen akademischen Abschluss verlangen, sank von 66 % auf 59 %. <\/li>\n\n\n\n
- Gleichzeitig steigen die Geh\u00e4lter f\u00fcr kompetenten KI-Einsatz im Durchschnitt um 56 % im Vergleich zu anderen Sektoren.<\/li>\n<\/ul>\n\n\n\n
Diese Entwicklungen verdeutlichen, dass Vibe Coding nicht nur ein technisches Konzept, sondern auch ein bedeutendes arbeitsmarktpolitisches Ph\u00e4nomen darstellt.<\/p>\n\n\n\n
Einsatz von KI<\/h3>\n\n\n\n
Entwickler:innen nutzen KI heute \u00fcberwiegend reflexiv, wie die DORA-Studie zeigt [8]: Rund 90 % der befragten Tech-Professionals nutzen KI im Arbeitsalltag, \u00fcber 80 % sehen Produktivit\u00e4tsgewinne, aber etwa 30 % vertrauen KI-Code wenig. Zudem verzichten 61 % auf autonome KI-Agenten, die Aufgaben selbstst\u00e4ndig ausf\u00fchren k\u00f6nnen. Dies deutet darauf hin, dass Vibe Coding zwar in der Breite angekommen ist, jedoch bislang kaum als vollautonomer Entwicklungsstil akzeptiert wird. Der Mensch bleibt somit eine zentrale Instanz im Entwicklungsprozess.<\/p>\n\n\n\n
LLM-Benchmarks<\/h3>\n\n\n\n
LLM-Benchmarks machen die Leistungsf\u00e4higkeit gro\u00dfer Sprachmodelle vergleichbar, pr\u00fcfen etwa die CodeGenerierung, sind aber meist auf isolierte Aufgaben beschr\u00e4nkt.
Ein neuartiger Ansatz ist der Vibe-Coding Benchmark von ValsAI. Er bewertet, wie gut Modelle vollst\u00e4ndige Webanwendungen aus einer einseitigen, nat\u00fcrlichsprachlichen Beschreibung erstellen [9]. Modelle arbeiten dabei in Docker-Containern mit Zugriff auf weitere Tools, und die Umsetzung wird anhand von 20\u201360 automatisierten Tests gepr\u00fcft, die Kernfunktionen, Edge Cases und User-Flows abdecken. Ma\u00dfgeblich ist der Anteil bestandener Kern-Workflows als Leistungsindikator.
In folgender Abbildung sind die Ergebnisse des Benchmarks dargestellt<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/AI-Driven-Prasii-1024x576.jpg\")
<\/a>Abbildung 1 Ergebnisse des Vals AI Vibe Coding Benchmarks [9]<\/figcaption><\/figure>\n\n\n\n Anwendungsf\u00e4lle<\/h3>\n\n\n\n
Es gibt insbesondere drei sinnvolle Anwendungsbereiche f\u00fcr Vibe Coding [6]:<\/p>\n\n\n\n
- \n
- Rapid Prototyping & MVP-Entwicklung:<\/em>
Studien berichten von einer 60\u201380 % k\u00fcrzeren Entwicklungszeit im Vergleich zum klassischen Coding.<\/li>\n\n\n\n- Repetitive Aufgaben und Boilerplate:<\/em>
Es zeigt sich eine hohe Effizienz in der Generierung von UI-Ger\u00fcsten oder API-Strukturen sowie Unit-Test Generierung und der Dokumentation von Systemen.<\/li>\n\n\n\n- Kreative Exploration:<\/em>
Durch Vibe Coding werden technische H\u00fcrden reduziert und Entwickler:innen bleiben l\u00e4nger im Flow des Entwickelns und Ausprobierens. Der Ansatz eignet sich besonders f\u00fcr explorative und strukturell einfache Szenarien.<\/li>\n<\/ul>\n\n\n\nPraktische Analyse des Vibe-Coding-Prozesses mit Fokus auf Softwarequalit\u00e4t<\/h2>\n\n\n\n
Der praktische Teil der Untersuchung analysiert die Entwicklung eines Content-Gen-Microservices innerhalb der Lernplattform Studyfai mit besonderem Fokus auf die resultierende Softwarequalit\u00e4t. Der Microservice \u00fcbernimmt die Extraktion und Transformation von PDF-Dokumenten, die Generierung von Quizfragen in unterschiedlichen Schwierigkeitsstufen sowie die Erstellung von H5P-Quizformate zur Integration in ein bestehendes Microfrontend-\u00d6kosystem.<\/p>\n\n\n\n
Auf Systemebene ist der Service in eine mehrstufige Prozesskette eingebettet: Textdaten werden zun\u00e4chst durch einen Kurs-Service in einzelnen PDF-Ressourcen \u00fcberf\u00fchrt, anschlie\u00dfend in H5P-Quizformate konvertiert und schlie\u00dflich einem Quiz-Service zur Verf\u00fcgung gestellt. Die Architektur umfasst ein Next.js-basiertes Microfrontend mit React und TailwindCSS sowie einen containerisierten Backend-Service, der \u00fcber eine API mit einem Sprachmodell interagiert und die H5P-Generierung \u00fcbernimmt.<\/p>\n\n\n\n
Ausgangslage, Setup und Rolle der KI<\/h3>\n\n\n\n
Zu Projektbeginn existierte weder eine bestehende Implementierung noch eine vorgegebene Architektur. Funktionale Anforderungen und Systemkontext wurden im Rahmen des Hochschulkurses AI Driven Software Development<\/em> an der Hochschule der Medien Stuttgart erarbeitet. Zur Pr\u00e4zisierung der Feature-Beschreibung, zur Identifikation technischer Rahmenbedingungen sowie zur Skizzierung eines initialen Architekturentwurfs wurden gro\u00dfe Sprachmodelle genutzt.<\/p>\n\n\n\n
Die Implementierung des Content-Gen-Services erfolgte anschlie\u00dfend nahezu vollst\u00e4ndig mit GPT-5.1 unter aktivierter Reasoning-\/Thinking-Konfiguration. OpenAI beschreibt GPT-5.1 als Modell f\u00fcr Coding-Aufgaben mit konfigurierbarem Reasoning-Effort, wodurch sich die Tiefe der schrittweisen Herleitung steuern l\u00e4sst [10] [11]. Erg\u00e4nzend wird GPT-5.1 Thinking als Variante beschrieben, die ihre Denkzeit adaptiver auf komplexere Aufgaben ausrichtet. Im Versuch wurde bewusst auf externe Tools, Retrieval-Mechanismen und autonome Agenten verzichtet, um ein kontrolliertes Vibe-Coding-Szenario zu erzeugen, in dem das Modell ausschlie\u00dflich auf Basis nat\u00fcrlichsprachlicher Spezifikationen und fortlaufend zur\u00fcckgespielter Fehlermeldungen agiert.<\/p>\n\n\n\n
Diese Einordnung ist auch deshalb relevant, weil Vibe-Coding-spezifische Benchmarks zeigen, dass selbst leistungsf\u00e4hige Modelle bei komplexen End-to-End-Aufgaben nur begrenzte Autonomie erreichen. Im Vibe Code Bench von ValsAI schnitt zudem GPT-5.1 als das am besten bewertete Modell ab (siehe Abbildung 2) [9].<\/p>\n\n\n\n
W\u00e4hrend der Implementierungsphase wurde die menschliche Rolle bewusst reduziert. GPT-5.1 generierte Code und leitete Korrekturen anhand von Compiler-, Build- und Runtime-Fehlermeldungen ab. Fehlermeldungen wurden nahezu ungefiltert in den Dialog zur\u00fcckgespielt, und die Vorschl\u00e4ge wurden ohne systematisches manuelles Code-Review umgesetzt. Damit fungierte der Mensch prim\u00e4r als Ausf\u00fchrungsinstanz in der Entwicklungsumgebung, was den Einfluss des Vibe-Coding-Stils auf die entstehende Softwarequalit\u00e4t vergleichsweise direkt beobachtbar machte.<\/p>\n\n\n\n
Entwicklungsprozess, Prompt-Strategien und Vibe-Coding-Fluss<\/h3>\n\n\n\n
Der Entwicklungsprozess begann mit einem promptbasierten Architekturentwurf. In mehreren Iterationen wurde ein strukturierter One-Shot-Prompt entwickelt, der Rolle, Projektziel, Systemumgebung sowie grundlegende Qualit\u00e4ts- und Architekturvorgaben festlegte. Ziel war eine konsistente Gesamtarchitektur, die \u00fcber einzelne Codefragmente hinaus tragf\u00e4hig bleibt und die Gefahr lokaler, aber strukturell inkonsistenter L\u00f6sungen reduziert.
Im weiteren Verlauf kamen drei Prompt-Typen zum Einsatz:<\/p>\n\n\n\n- \n
- High-Level-One-Shot-Prompts<\/em> zur Initialisierung gr\u00f6\u00dferer Arbeitspakete (z. B. Backend-Grundstruktur, API-Routen, Modellanbindung).<\/li>\n\n\n\n
- Iterative Debug-Prompts<\/em>, in die Fehlermeldungen aus Build- und Runtime-Prozessen eingespeist wurden, um konkrete Reparaturvorschl\u00e4ge zu erhalten.<\/li>\n\n\n\n
- Self-Refactoring-Prompts <\/em>zur Konsolidierung nach mehreren Iterationen (Entfernung redundanter Dateien, Vereinheitlichung von Namenskonventionen, Extraktion wiederkehrender Logik).<\/li>\n<\/ol>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Screenshot-2026-02-10-163700-1024x461.png\")
<\/a>Abbildung 2 Vibe-Coding-Fluss der Microservice Entwicklung<\/figcaption><\/figure>\n\n\n\n Der zugeh\u00f6rige Vibe-Coding-Fluss ist in Abbildung 2 <\/em>dargestellt. Die Abbildung modelliert zwei gekoppelte R\u00fcckkopplungsschleifen:<\/p>\n\n\n\n
- \n
- LLM-assisted Prompt Refinement:<\/em> Schleife aus Input, Prompt-Entwurf und Frage\/Validierung zur One-Shot Prompt Generierung<\/li>\n\n\n\n
- Schleife aus Codegenerierung, Ausf\u00fchrung und Fehler-R\u00fcckkopplung<\/li>\n<\/ol>\n\n\n\n
Im Versuch dominierte in der Implementierungsphase die zweite Schleife: Fehlermeldungen dienten als unmittelbare Steuerimpulse, die das Modell in Code\u00e4nderungen \u00fcbersetzte. Diese Struktur ist fachlich relevant, weil sie erkl\u00e4rt, warum Vibe Coding in standardisierten Tasks schnell zu lauff\u00e4higem Code f\u00fchrt, bei architekturbezogenen Konflikten jedoch Reparaturschleifen beg\u00fcnstigt: Das Modell optimiert kurzfristig gegen sichtbare Fehlerausgaben, ohne zwingend die systemische Ursache zu isolieren.<\/p>\n\n\n\n
Fehlerbilder und Auswirkungen auf die Softwarequalit\u00e4t<\/h3>\n\n\n\n
Im Verlauf mehrerer intensiver Arbeitssitzungen traten wiederkehrende Fehlermuster auf, die sich auf mehrere Qualit\u00e4tsdimensionen auswirkten. Besonders relevant waren Architekturinkompatibilit\u00e4ten, rekursive Fehlerketten sowie typische LLM-Artefakte in der Codebasis.<\/p>\n\n\n\n
Ein zentrales Fehlerbild betraf Inkompatibilit\u00e4ten zwischen Framework-Versionen, Webpack-Konfiguration und Module Federation. Das Modell reagierte auf Fehlermeldungen mit lokalen Reparaturvorschl\u00e4gen, ohne den zugrunde liegenden Versionskonflikt konsistent zu identifizieren. Dies f\u00fchrte zu einer schrittweisen Fragmentierung der Projektstruktur (zus\u00e4tzliche Konfigurationsdateien, alternative Build-Skripte), wodurch sich die Wartbarkeit und die Stabilit\u00e4t des Build-Prozesses verschlechterten.<\/p>\n\n\n\n
Ein weiteres Muster waren rekursive Fehlerketten: Folgefehler wurden h\u00e4ufig als unabh\u00e4ngige Probleme behandelt, wodurch Reparaturschleifen entstanden. Begleitend zeigten sich LLM-Artefakte wie wenig aussagekr\u00e4ftige Variablennamen, unn\u00f6tige Verschachtelungen und redundante Utility-Funktionen. Diese Artefakte sind funktional nicht zwingend kritisch, erh\u00f6hen aber die kognitive Komplexit\u00e4t und damit die sp\u00e4tere \u00c4nderbarkeit, Fehlersuche und Erweiterbarkeit.<\/p>\n\n\n\n
Produktive Effekte im Qualit\u00e4tskontext<\/h3>\n\n\n\n
Trotz dieser Einschr\u00e4nkungen zeigte sich ein deutlicher Produktivit\u00e4tsgewinn bei standardisierten Entwicklungsaufgaben. Das Aufsetzen von API-Routen, die Anbindung externer Schnittstellen sowie das Erzeugen struktureller Grundger\u00fcste erfolgte mit hoher Geschwindigkeit. In der Kernfunktionalit\u00e4t wurde die Pipeline von PDF-Extraktion \u00fcber Quizgenerierung bis zur H5P-Erstellung in kurzer Zeit umgesetzt. Dar\u00fcber hinaus wurde durch Containerisierung und klar definierte API-Kontrakte eine prinzipiell portable Integrationsstruktur erreicht, die die Einbettung in die bestehende Plattform erleichtert.<\/em><\/p>\n\n\n\n
ISO\/IEC 25010: Qualit\u00e4tsmerkmale, Metriklogik und Begr\u00fcndung der Operationalisierung<\/h3>\n\n\n\n
Zur Strukturierung der Qualit\u00e4tsbewertung wurde ISO\/IEC 25010 als Referenzmodell herangezogen [12]. Der Standard definiert Qualit\u00e4tsmerkmale und Submerkmale f\u00fcr Softwareprodukte, stellt jedoch kein fixes Metrik-Set bereit; Messverfahren m\u00fcssen projektspezifisch operationalisiert und empirisch abgesichert werden. Genau daraus ergibt sich die methodische Kernlogik dieses Kapitels: Die nachfolgend berichteten Kennzahlen sind als ISO-orientierte Operationalisierung zu lesen, deren Aussagekraft unmittelbar von Messabdeckung, Datenqualit\u00e4t und Validierungsgrad abh\u00e4ngt.<\/p>\n\n\n\n
Die Implementierung der Metriken und die Berechnung der Scores wurden im Projekt nicht manuell entwickelt, sondern durch Claude Sonnet 4.5 im Agentenmodus implementieren lassen [13].<\/p>\n\n\n\n
Sonnet 4.5 wird von Anthropic explizit als Modell f\u00fcr \u201ereal-world agents\u201c und Coding positioniert, inklusive Workflows, bei denen das Modell Aufgaben schrittweise ausf\u00fchrt und Artefakte erstellt. Diese Entscheidung erh\u00f6hte die Umsetzungsgeschwindigkeit der Metrikpipeline, versch\u00e4rft jedoch ein Bewertungsproblem: Die Qualit\u00e4tsbewertung wird damit von einem generativen System operationalisiert, das weder eine formale Messtheorie noch eine projektexterne Ground-Truth besitzt. Das betrifft insbesondere die Konstruktvalidit\u00e4t, die Nachvollziehbarkeit und die Reproduzierbarkeit. In der Folge sind die Scores eher als strukturierende Heuristik zu interpretieren, nicht als belastbarer Qualit\u00e4tsnachweis im Sinne klassischer Software-Qualit\u00e4tssicherung. ISO-Qualit\u00e4tsmerkmale nach ISO\/IEC 25010:2024 sind [12]:<\/p>\n\n\n\n
Functional Suitability<\/em>: Grad, in dem Funktionen festgelegte Bed\u00fcrfnisse erf\u00fcllen; operationalisiert \u00fcber Requirements-Coverage sowie Defekt- und Fehlerindikatoren.<\/p>\n\n\n\n
Performance Efficiency<\/em> Leistung im Verh\u00e4ltnis zu eingesetzten Ressourcen; operationalisiert \u00fcber Antwortzeiten, Durchsatz und Ressourcennutzung unter Last.<\/p>\n\n\n\n
Compatibility: <\/em>F\u00e4higkeit zur Koexistenz und Interoperabilit\u00e4t; operationalisiert \u00fcber Interoperabilit\u00e4tsfehler, Plattformunterst\u00fctzung und API-Konformit\u00e4t.<\/p>\n\n\n\n
Usability<\/em>: Effektive, effiziente und zufriedenstellende Nutzung durch definierte Nutzer; operationalisiert \u00fcber Nutzerbeobachtung, Task-Erfolgsma\u00dfe und Fehlerraten, daher ohne User-Testing nicht belastbar.<\/p>\n\n\n\n
Reliability: <\/em>F\u00e4higkeit, Leistung unter definierten Bedingungen aufrechtzuerhalten; operationalisiert \u00fcber Verf\u00fcgbarkeit, Fehlerraten und Wiederherstellbarkeit.<\/p>\n\n\n\n
Security:<\/em> Schutz von Informationen und Daten; operationalisiert \u00fcber Indikatoren zu Vertraulichkeit, Integrit\u00e4t und Autorisierung.<\/p>\n\n\n\n
Maintainability<\/em>: Effektive und effiziente Modifizierbarkeit; operationalisiert \u00fcber Komplexit\u00e4t, Testbarkeit (Coverage), Duplikation, technische Schuld und \u00c4nderungsaufwand.Portability<\/em>: \u00dcbertragbarkeit und Installierbarkeit in anderen Umgebungen; operationalisiert \u00fcber Installations- und Portierungsindikatoren, Containerisierung als Proxy f\u00fcr portable Deploymentf\u00e4higkeit. <\/p>\n\n\n\n
Ergebnis des praktischen Teils<\/h3>\n\n\n\n
ISO\/IEC 25010 Merkmal<\/strong><\/td> Score<\/strong><\/td> Kernergebnis (stark gek\u00fcrzt)<\/strong><\/td><\/tr> Functional Suitability<\/em><\/td> 87.5\/100<\/td> 7\/8 Anforderungen umgesetzt, 1 fehlt<\/td><\/tr> Performance Efficiency<\/em><\/td> N\/A<\/td> Keine Messung, RAM ~45 MB (Sch\u00e4tzung)<\/td><\/tr> Compatibility<\/em><\/td> 100\/100<\/td> Keine Interop-Fehler, OpenAPI-konform<\/td><\/tr> Usability<\/em><\/td> N\/A<\/td> Kein User-Testing, Accessibility als Basis erf\u00fcllt<\/td><\/tr> Reliability<\/em><\/td> 99.95\/100<\/td> Keine Ausf\u00e4lle beobachtet, Availability-Proxy<\/td><\/tr> Security<\/em><\/td> 75\/100<\/td> npm audit clean, Auth 3\/4 Endpoints<\/td><\/tr> Maintainability<\/em><\/td> 65\/100<\/td> 0% Tests, Komplexit\u00e4t ~8<\/td><\/tr> Portability<\/em><\/td> 95\/100<\/td> Docker-ready, Installation erfolgreich<\/td><\/tr><\/tbody><\/table> Table 1. Erreichte Codequalit\u00e4t anhand ISO<\/em> -orientierten Metriken<\/figcaption><\/figure>\n\n\n\n Gesamtfazit aus Qualit\u00e4tsperspektive<\/h3>\n\n\n\n
Die empirische Analyse zeigt ein konsistentes Spannungsfeld zwischen Geschwindigkeit und struktureller Qualit\u00e4t. Vibe Coding mit GPT-5.1 erm\u00f6glichte eine schnelle Realisierung gro\u00dfer Teile der Kernfunktionalit\u00e4t und beschleunigte standardisierte Implementierungsaufgaben. Gleichzeitig f\u00fchrten architekturbezogene Konflikte zu rekursiven Debugging-Schleifen und struktureller Fragmentierung, was die Maintainability und die Stabilit\u00e4t der Entwicklungsartefakte negativ beeinflusste.<\/p>\n\n\n\n
Die ISO-orientierte Metriktabelle macht dar\u00fcber hinaus eine methodische Grenze sichtbar: Mehrere Kennzahlen wie Performance und Usability beruhen auf Sch\u00e4tzungen oder nicht erhobenen Messreihen beziehungsweise auf fehlender Testabdeckung. Dadurch sind insbesondere Reliability- und Security-Aussagen nur eingeschr\u00e4nkt belastbar. Hinzu kommt, dass die Metriken durch Claude Sonnet 4.5 im Agentenmodus implementiert wurden, was den Score zus\u00e4tzlich als artefaktabh\u00e4ngig kennzeichnet. Ohne unabh\u00e4ngige, reproduzierbare Implementierung und ohne empirische Datengrundlage (Tests, Monitoring, Lastmessungen, Nutzerstudien) strukturiert das System die Bewertung formal, kann aber objektive Qualit\u00e4t nur imitieren, nicht nachweisen. Diese Konstellation beg\u00fcnstigt eine Qualit\u00e4tsillusion, wenn aggregierte Scores als Qualit\u00e4tsbeleg interpretiert werden, obwohl die Messbasis die ISO-Merkmale nicht hinreichend tr\u00e4gt.<\/p>\n\n\n\n
Systemische Auswirkungen von Vibecoding<\/h2>\n\n\n\n
Nach der Betrachtung des praktischen Fallbeispiels erfolgt nun die analytische Einordnung und Synthese der gewonnenen Erkenntnisse. Dabei wird der Fokus auf die meta-systemischen Auswirkungen erweitert. Es sollen Grenzen der Methodik, die \u00f6konomischen Realit\u00e4ten der Team-Performance sowie der Wandel in den Kompetenzprofile und Arbeitsprozesse des Software Development Life Cycle (SDLC) aufgezeigt werden.<\/p>\n\n\n\n
Risiken und Grenzen<\/h3>\n\n\n\n
Wie bereits dargestellt, kann Vibecoding eine schnelle Umsetzung von Funktionalit\u00e4ten erm\u00f6glichen. Jedoch wurde auch aufgezeigt, dass gerade diese Geschwindigkeit dazu verleitet, fundamentale Prinzipien der Softwarearchitektur und Sicherheit zu vernachl\u00e4ssigen. Daraus resultieren klare Grenzen, jenseits derer der Einsatz dieser Methodik nicht nur ineffizient, sondern risikobehaftet ist.<\/p>\n\n\n\n
Der prim\u00e4re Ausschlussbereich f\u00fcr Vibecoding liegt in Systemkomponenten, die Sicherheit und strikte Datenintegrit\u00e4t erfordern. Insbesondere Module, die finanzielle Transaktionen verarbeiten (Payment-Gateways, Billing-APIs) oder sensible personenbezogene Daten verwalten, sollten unter keinen Umst\u00e4nden ungepr\u00fcft auf Code-Generierung eines LLMs basieren. Die Tendenz von LLMs, funktionierenden, aber unsicheren Code zu erzeugen ist ein bekanntes Problem [14].<\/p>\n\n\n\n
Diese Diskrepanz zeigt sich in der Praxis oft durch fehlende Eingabevalidierungen oder unzureichende Authentifizierungsmechanismen. Berichte \u00fcber “gevibecodete” SaaS-L\u00f6sungen, bei denen Endnutzer durch triviale Manipulationen Datenbankeintr\u00e4ge ver\u00e4ndern oder Paywalls umgehen konnten, unterstreichen die Gefahr von Business Logic Flaws, die durch das blinde Kopieren von generiertem Programmcode entstehen [15].<\/p>\n\n\n\n
Zudem neigen KI-Modelle dazu, Sicherheitsl\u00fccken durch Halluzinationen aktiv einzuf\u00fchren, etwa durch den Import existierender, aber f\u00fcr den Kontext falscher Packages, oder durch Referenzieren von Phantom-Libraries [6].<\/p>\n\n\n\n
Ein weiterer kritischer Aspekt betrifft die Skalierbarkeit unter Last. Der generierte Code ist oft nicht f\u00fcr den parallelen Zugriff durch eine gro\u00dfe Nutzerbasis optimiert. Typische Defizite sind ineffiziente Datenbankabfragen oder fehlende Caching-Strategien, die in einer lokalen Entwicklungsumgebung unbemerkt bleiben. Sobald die Nutzerzahlen steigen, f\u00fchrt dies schnell zu hohen Performance-Einbr\u00fcchen, weshalb sich Vibecoding kaum f\u00fcr High-Traffic-Anwendungen eignet [6].<\/p>\n\n\n\n
Vibecoding st\u00f6\u00dft auch dort an seine Grenzen, wo der Globale Scope einer Architektur das Kontextfenster des Modells \u00fcbersteigt. In Deep-Legacy Projekten oder gro\u00dfen Multi-File-Kontexten braucht es zum heutigen Stand eine menschliche Mitarbeit, um die Abh\u00e4ngigkeiten und impliziten Architekturregeln als Kontext mit zu \u00fcbergeben. Hier zeigt sich die klare Unterscheidung des Vibecoding zum Agentic Coding. W\u00e4hrend Vibecoding prim\u00e4r als “Token-Chat” operiert, der nur Text-Ausschnitte verarbeitet und auf menschliches Copy-Paste angewiesen ist, interagieren Agenten-Systeme direkt mit der Umgebung und k\u00f6nnen so tiefere Abh\u00e4ngigkeiten in der gesamten Codebasis auch allein nachvollziehen [16].<\/p>\n\n\n\n
Zusammenfassend l\u00e4sst sich sagen, dass sobald die Kosten eines Fehlers (monet\u00e4r, datenschutzrechtlich, performance-seitig) die Kosten der manuellen Entwicklung \u00fcbersteigen, Vibecoding als alleinige Methode nicht zu empfehlen ist.<\/p>\n\n\n\n
Team Performance<\/h3>\n\n\n\n
Die zentrale \u00f6konomische Abw\u00e4gung bei der Integration von KI-gest\u00fctzten Entwicklungsprozessen ist das Verh\u00e4ltnis zwischen der Netto-Zeitersparnis durch initiale Code-Generierung und dem Brutto-Zeitverlust, der durch nachgelagertes Debugging und Refactoring entsteht. Unser Fallbeispiel verdeutlicht, dass die Performance beim Vibecoding nicht linear skaliert. Vielmehr folgt sie einem spezifischen Muster, das wir als “Vibe-Kurve” definieren.<\/p>\n\n\n\n
Diese Kurve weist \u00c4hnlichkeiten zum Verlauf des Dunning-Kruger-Effekts auf. Dies erscheint schl\u00fcssig, da aktuelle Untersuchungen nahelegen, dass LLMs selbst diesem Ph\u00e4nomen unterliegen. Sie tendieren dazu, ihre Kompetenz in komplexen Dom\u00e4nen zu \u00fcbersch\u00e4tzen und liefern plausible, aber fehlerhafte L\u00f6sungen mit hoher Zuversicht [17] [18].<\/p>\n\n\n\n
Im praktischen Verlauf \u00e4u\u00dferte sich dies zyklisch. Zu Beginn eines jeden Entwicklungsabschnitts war eine massive Beschleunigung messbar, getrieben durch die schnelle Generierung von Boilerplate-Code. Sobald die Anforderungen jedoch den generischen Bereich verlie\u00dfen und spezifische Expertise erforderten, kippte das Verh\u00e4ltnis. Der Aufwand f\u00fcr die Validierung und Korrektur subtiler Fehler, oft erschwert durch das Verstehen von fremden Code, f\u00fchrte zu einem rapiden Einbruch der Entwicklungsgeschwindigkeit. Zwar stieg die Produktivit\u00e4t nach jeder Fehlerbehebung wieder an, jedoch mit einer deutlich flacheren Steigung als in der Initialphase. Mit jedem neuen Arbeitsschritt begann dieser Zyklus von rapider Beschleunigung und anschlie\u00dfendem Einbruch von Neuem.<\/p>\n\n\n\n
Grundlegend l\u00e4sst sich trotzdem sagen, dass die Erstellung des Backends sowie des Frontends f\u00fcr unseren Service mit jeweils lediglich circa 2,5 Stunden deutlich schneller als \u00fcblich war. Im Vergleich zur manuellen Implementierung, die basierend auf Erfahrungswerten jeweils etwa einen Arbeitstag (8 Stunden) in Anspruch genommen h\u00e4tte, entspricht dies einer<\/p>\n\n\n\n
- Schleife aus Codegenerierung, Ausf\u00fchrung und Fehler-R\u00fcckkopplung<\/li>\n<\/ol>\n\n\n\n
- Iterative Debug-Prompts<\/em>, in die Fehlermeldungen aus Build- und Runtime-Prozessen eingespeist wurden, um konkrete Reparaturvorschl\u00e4ge zu erhalten.<\/li>\n\n\n\n
- Repetitive Aufgaben und Boilerplate:<\/em>
- Rapid Prototyping & MVP-Entwicklung:<\/em>
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/AI-Driven-Prasii.jpg\")
<\/a>