Vom Vibe Coding zur Web-App für den Praxiseinsatz: Ein Erfahrungsbericht aus dem Testmanagement

Generative KI senkt die Einstiegshürde in die Softwareentwicklung deutlich. Menschen mit Fach-, Prozess- und Qualitätswissen können Anwendungen heute über natürliche Sprache entwerfen, verändern und in kurzer Zeit nutzbar machen. Genau darin liegt die Stärke von Vibe Coding: Ideen werden früh sichtbar, fachliche Annahmen lassen sich direkt erproben und der Weg vom Problem zur ersten funktionierenden Lösung verkürzt sich erheblich.

Ausgehend von papierbasierten Prüfungsprotokollen entstand schrittweise eine Mehrbenutzer-Anwendung, die technisch umgesetzt, auf der vorgesehenen Infrastruktur bereitgestellt und für den produktiven Einsatz vorbereitet wurde. Sie umfasst zentrale Datenhaltung, Echtzeitsynchronisierung, Zugriffsschutz über einen gemeinsamen Zugangscode, Zuordnung der Prüfer zu Prüfgruppen und eine responsive Benutzeroberfläche. Die Anwendung wurde weitgehend mit Unterstützung von KI-Coding-Werkzeugen entwickelt - aus der Perspektive eines Testmanagers und Business Analysten, nicht aus der eines klassischen Softwareentwicklers.

Die zentrale Erkenntnis lautet: KI kann sehr viel Code erzeugen, aber keine Verantwortung übernehmen. Sobald eine Anwendung dauerhaft betrieben, von mehreren Personen genutzt wird und schützenswerte Daten verarbeitet, reichen spontane Prompts und visuelle Erfolgskontrollen nicht mehr aus. Aus Vibe Coding muss ein strukturierter Entwicklungsprozess werden - mit klaren Anforderungen, Architekturentscheidungen, Akzeptanzkriterien, Tests, Versionskontrolle, Sicherheitsmaßnahmen und menschlicher Freigabe.

Warum das Thema jetzt relevant ist

Der Begriff Vibe Coding wurde im Februar 2025 von Andrej Karpathy geprägt. Gemeint war zunächst eine bewusst lockere Form des Programmierens: Die gewünschte Funktion wird in natürlicher Sprache beschrieben, die KI erzeugt den Code, Fehlermeldungen werden zurückgegeben und Änderungen häufig übernommen, ohne jede Codezeile im Detail zu prüfen. Dieses Vorgehen war ursprünglich ausdrücklich eher für experimentelle oder kurzlebige Projekte gedacht.

Inzwischen haben sich die Werkzeuge deutlich weiterentwickelt. Moderne Coding-Agenten können Repositories analysieren, mehrere Dateien verändern, Terminalbefehle ausführen, Tests starten, Fehler auswerten und ihre Umsetzung iterativ korrigieren. Damit verschiebt sich KI-Unterstützung vom reinen Codevorschlag in Richtung eigenständiger Bearbeitung zusammenhängender Entwicklungsaufgaben. Gleichzeitig wird der Begriff Vibe Coding oft unscharf für nahezu jede Form KI-gestützter Programmierung verwendet.

Diese Unschärfe ist problematisch. Zwischen einem schnell erzeugten Prototyp, einem kontrolliert entwickelten Produkt und einem autonom arbeitenden Coding-Agenten bestehen erhebliche Unterschiede. Für Unternehmen ist deshalb nicht entscheidend, ob KI beim Programmieren eingesetzt wird. Entscheidend ist, wie Anforderungen, Verantwortung, Qualität und Betrieb organisiert werden. Der DORA-Bericht zur KI-gestützten Softwareentwicklung beschreibt KI entsprechend als Verstärker: Gute technische und organisatorische Grundlagen werden wirksamer, bestehende Schwächen können sich jedoch ebenso beschleunigen.

Was Vibe Coding wirklich bedeutet

Vibe Coding ist mehr als das Formulieren eines guten Prompts. Kennzeichnend ist eine ergebnisorientierte Interaktion mit der KI: Der Mensch beschreibt eine gewünschte Wirkung, betrachtet das sichtbare Ergebnis, meldet Abweichungen zurück und lässt die Lösung in schnellen Schleifen verändern. Der Quellcode tritt dabei zumindest zeitweise in den Hintergrund. Gesteuert wird über Verhalten, Oberfläche und unmittelbares Feedback.

Dieser Ansatz erzeugt einen besonderen Arbeitsfluss. Anforderungen müssen nicht erst vollständig dokumentiert, an ein Entwicklungsteam übergeben und später anhand einer fertigen Umsetzung validiert werden. Idee, Umsetzung und fachliche Prüfung rücken eng zusammen. Gerade bei kleinen Anwendungen, internen Werkzeugen, Machbarkeitsstudien oder frühen Produktideen kann das sehr wirksam sein.

Nicht jede Nutzung eines KI-Coding-Assistenten ist deshalb automatisch Vibe Coding. Wer den erzeugten Code versteht, Änderungen bewusst reviewt, Tests ausführt und technische Entscheidungen nachvollziehbar dokumentiert, betreibt eher KI-gestützte Softwareentwicklung. Vibe Coding bezeichnet im engeren Sinn gerade den Zustand, in dem die Funktionswirkung wichtiger wird als das vollständige Verständnis der Implementierung.

Die Stärke: Fachlichkeit wird unmittelbar ausführbar

Die größte Stärke liegt nicht darin, dass Menschen ohne Programmiererfahrung plötzlich jede technische Aufgabe lösen können. Sie liegt darin, dass Fachwissen erheblich direkter in funktionierende Software übersetzt werden kann. Ein Business Analyst, Testmanager oder Fachexperte muss eine Idee nicht mehr ausschließlich über Dokumente, Tickets und Abstimmungen transportieren. Er kann sie interaktiv konkretisieren und unmittelbar erproben.

Dadurch sinkt der Übersetzungsverlust zwischen fachlicher Absicht und technischer Umsetzung. Unklare Abläufe, fehlende Funktionen oder ungeeignete Bedienkonzepte werden sichtbar, bevor große Budgets gebunden sind. Auch Anforderungen verändern ihre Qualität: Wer eine Funktion tatsächlich bedienen kann, erkennt Lücken häufig schneller als in einer rein textuellen Spezifikation.

Für das Testmanagement entsteht ein zusätzlicher Vorteil. Akzeptanzkriterien, Testideen und fachliche Risiken können nicht erst nach der Implementierung, sondern bereits während ihrer Entstehung überprüft werden. Die Anwendung wird zum ausführbaren Gesprächsgegenstand. Das ist ein erheblicher Fortschritt - solange frühe Sichtbarkeit nicht mit technischer Reife verwechselt wird.

Praxisbeispiel: Vom Prüfungsprotokoll zur Web-App

Der Ausgangspunkt des Projekts war kein KI-Experiment, sondern ein konkretes organisatorisches Problem. Gürtelprüfungen in einem Sportverein wurden mit papierbasierten Prüfungsprotokollen durchgeführt. Mehrere Prüfer bewerteten unterschiedliche Inhalte, Ergebnisse mussten zusammengeführt und anschließend ausgewertet werden. Das Verfahren funktionierte, war jedoch aufwendig und fehleranfällig.

Die fachliche Zielsetzung war schnell umrissen. Prüflinge und Prüfungsinhalte sollten zentral verwaltet werden. Mehrere Prüfer sollten gleichzeitig auf denselben Datenbestand zugreifen und Änderungen unmittelbar sehen können. Die Bedienung musste auf Notebook, Tablet und Smartphone funktionieren. Hinzu kamen ein geregelter Zugriff über einen gemeinsamen Zugangscode, die Zuordnung von Prüfern zu Prüfgruppen, dauerhafte Speicherung, nachvollziehbare Bewertungen sowie die Vorbereitung eines verlässlichen Produktivbetriebs.

Die ersten Oberflächen und Funktionen entstanden sehr schnell über natürliche Sprache. Statt Komponenten selbst zu programmieren, wurden fachliche Ziele beschrieben, Ergebnisse geprüft und schrittweise angepasst. Dieser unmittelbare Zyklus war entscheidend, um die Bedienlogik zu entwickeln. Viele Details ließen sich erst anhand einer nutzbaren Oberfläche wirklich bewerten: Welche Informationen benötigen Prüfer in einer Situation? Welche Eingaben müssen besonders schnell erreichbar sein? Wie bleibt die Ansicht trotz vieler Bewertungskriterien übersichtlich?

Aus dem ersten Funktionsentwurf entwickelte sich eine für den realen Prüfungsbetrieb vorbereitete Anwendung. Neben der sichtbaren Oberfläche wurden zentrale Datenhaltung, Mehrbenutzerfähigkeit, Echtzeitsynchronisierung, Zugriffsschutz über einen gemeinsamen Zugangscode und die Zuordnung von Prüfern zu Prüfgruppen umgesetzt. Der entscheidende Schritt bestand jedoch nicht darin, immer mehr Funktionen hinzuzufügen. Er bestand darin, die Arbeitsweise zu verändern, sobald die Anwendung komplexer und betriebsrelevant wurde.

Ein typisches Beispiel: Eine scheinbar kleine Änderung an einer Ausgleichsregel für Bewertungen – etwa welche Kombination unterdurchschnittlicher Einzelnoten noch zulässig ist – betraf gleichzeitig Datenmodell, Bewertungslogik im Frontend, bestehende Testfälle und die Live-Synchronisation zwischen Geräten. Genau an solchen Stellen zeigte sich früh, wann Vibe Coding an seine Grenzen stößt.

Warum sichtbare Funktionalität trügerisch sein kann

KI-Coding-Werkzeuge erzeugen sehr schnell überzeugende Benutzeroberflächen. Dadurch entsteht früh der Eindruck, eine Anwendung sei nahezu fertig. Aus Qualitätssicht ist das gefährlich. Die sichtbare Oberfläche ist nur ein Teil des Systems und häufig derjenige Teil, den generative Modelle besonders überzeugend herstellen können.

Ob Daten korrekt und dauerhaft gespeichert werden, ob parallele Änderungen konsistent bleiben, ob Berechtigungen an allen relevanten Stellen greifen oder ob Fehlerzustände sauber behandelt werden, ist an einer funktionierenden Schaltfläche nicht erkennbar. Auch eine responsive Darstellung auf einem Gerät beweist nicht, dass Bedienung, Performance und Zustandsverwaltung auf allen Zielgeräten stabil funktionieren.

Die zentrale Qualitätsfrage lautet daher nicht: Funktioniert die Anwendung bei meiner aktuellen Eingabe? Sie lautet: Funktioniert sie unter den relevanten fachlichen, technischen und betrieblichen Bedingungen reproduzierbar? Genau an diesem Punkt endet die Aussagekraft des reinen Ausprobierens. Ein funktionierender Happy Path ist ein wichtiger Fortschritt, aber kein Nachweis für Produktionsreife.

Der Wendepunkt: Von einzelnen Prompts zu agentischer Entwicklung

Mit wachsendem Funktionsumfang veränderte sich die Art der Aufgaben. Eine vermeintlich kleine Anpassung betraf plötzlich Datenmodell, Frontend, Backend, Validierung, Zuordnungslogik und bestehende Tests zugleich. Der Code war nicht mehr nur eine Sammlung sichtbarer Funktionen, sondern ein System mit Abhängigkeiten. Spontanes Weiterprompten führte in dieser Phase schnell zu Instabilität: Ein Fehler wurde behoben, während unbemerkt ein anderer entstand.

Die Aufgaben mussten deshalb anders formuliert werden: Analysiere zunächst die bestehende Implementierung, identifiziere alle betroffenen Komponenten, beschreibe den geplanten Lösungsweg, erhalte bestehende Schnittstellen, ergänze Fehlerbehandlung und Tests, prüfe die Auswirkungen auf bestehende Funktionen und dokumentiere relevante Entscheidungen. Aus improvisiertem Vibe Coding wurde so schrittweise eine strukturierte, agentische Form der Softwareentwicklung.

Vibe Coding und Agentic Coding werden häufig gleichgesetzt, sind aber nicht dasselbe. Vibe Coding beschreibt die Interaktionsweise des Menschen: dialogorientiert, schnell, ergebnisbezogen. Agentic Coding beschreibt die Fähigkeiten des KI-Systems - ein Coding-Agent kann eine Aufgabe planen, den Projektkontext untersuchen, Dateien ändern, Tests ausführen und auf Rückmeldungen reagieren. Ob der Mensch diesen Agenten mit einem vagen Wunsch oder mit klaren Anforderungen und Akzeptanzkriterien steuert, ist eine separate Frage. Mehr Autonomie erzeugt nicht automatisch mehr Qualität, sondern erhöht zunächst nur die Reichweite möglicher Entscheidungen.

Damit verschiebt sich die Kommunikation von einzelnen Codeänderungen zu vollständigen Arbeitsaufträgen: Der Mensch definiert das fachliche Ziel, die Randbedingungen und die Qualitätskriterien, der Agent übernimmt einen größeren Teil der Analyse und Implementierung. Gute Repository-Dokumentation, klare Entwicklungsregeln und automatisierte Prüfungen werden damit selbst zum Qualitätsmechanismus - Build-Regeln, Linter, Test-Suites und CI-Pipelines bilden den Rahmen, innerhalb dessen ein Agent arbeiten und seine Ergebnisse überprüfen kann.

Die besondere Perspektive des Testmanagements

Als Testmanager wurde die Anwendung anders betrachtet als aus einer rein implementierungsorientierten Perspektive. Die erste Frage lautete selten: Wie muss diese Funktion programmiert werden? Sie lautete: Woran erkennen wir, dass sie fachlich korrekt, robust und für den vorgesehenen Nutzungskontext geeignet ist?

Daraus entstanden früh Fragen nach Rollen, Berechtigungen, Vorbedingungen, Negativfällen, Randwerten und konkurrierenden Änderungen. Was passiert, wenn zwei Prüfer denselben Wert nahezu gleichzeitig verändern? Wie verhält sich die Anwendung bei einer unterbrochenen Verbindung? Welche Daten dürfen nach einer abgeschlossenen Prüfung noch geändert werden? Wie werden unvollständige Bewertungen sichtbar? Was geschieht bei einer abgelaufenen Sitzung?

Diese Fragen sind keine nachgelagerten Testdetails. Sie prägen Datenmodell, Benutzerführung und Architektur. Werden sie erst am Ende gestellt, müssen Lösungen häufig teuer korrigiert werden. Werden sie bereits in die Aufgabenbeschreibung für die KI aufgenommen, verbessern sie nicht nur den Testumfang, sondern die Umsetzung selbst.

Akzeptanzkriterien werden damit zur Schnittstelle zwischen fachlicher Absicht und agentischer Implementierung. Sie beschreiben nicht, wie Code aussehen soll, sondern welches überprüfbare Verhalten erreicht werden muss. Für KI-gestützte Entwicklung ist das besonders wertvoll, weil ein plausibel formulierter Wunsch sonst sehr schnell in eine ebenso plausible, aber unvollständige Lösung übersetzt wird.

Ein praxistaugliches Qualitätsmodell

Ein belastbarer Prozess muss die Geschwindigkeit KI-gestützter Entwicklung erhalten, ohne kritische Prüfungen zu überspringen. Dafür eignet sich ein mehrstufiges Qualitätsmodell, das je nach Risiko unterschiedlich tief angewendet wird.

Die erste Ebene ist die fachliche Klarheit. Vor der Umsetzung müssen Ziel, Nutzerrollen, Geschäftsregeln, Datenobjekte und Akzeptanzkriterien ausreichend präzise sein. Offene Annahmen werden sichtbar gemacht, statt sie der KI zu überlassen. Ein Domänenmodell oder eine einfache fachliche Struktur verhindert, dass Begriffe im Verlauf des Projekts wechselnd interpretiert werden.

Die zweite Ebene ist die technische Konsistenz. Änderungen müssen zur bestehenden Architektur, zum Datenmodell und zu den Schnittstellen passen. Der Agent soll betroffene Komponenten analysieren, bestehende Konventionen berücksichtigen und relevante Entscheidungen dokumentieren. Große Änderungen werden in kontrollierbare Einheiten zerlegt und über Versionskontrolle nachvollziehbar gemacht.

Die dritte Ebene ist die systematische Prüfung. Neben dem Happy Path werden Negativfälle, Randfälle, Zugriffsprüfungen, Regressionen, Mehrbenutzerverhalten und Zielgeräte berücksichtigt. Automatisierte Tests liefern schnelles Feedback, ersetzen aber nicht die fachliche Abnahme. Wenn dieselbe KI Anwendungscode und Tests erzeugt, ist eine unabhängige Bewertung besonders wichtig: Beide können auf derselben falschen Annahme beruhen.

Die vierte Ebene betrifft Sicherheit und Betrieb. Geheimnisse gehören nicht in Prompts oder ungeschützte Dateien. Agenten erhalten nur die Berechtigungen, die sie für ihre Aufgabe benötigen. Eingaben und KI-Ausgaben werden validiert, bevor sie in nachgelagerte Systeme gelangen. Backup, Wiederherstellung, Logging, Deployment und Fehlerbehandlung werden als Produktbestandteile behandelt - nicht als spätere Ergänzung.

Die fünfte Ebene ist die Freigabe. KI kann analysieren, implementieren, testen und Verbesserungsvorschläge liefern. Die Entscheidung, ob eine Änderung fachlich akzeptabel und für den vorgesehenen Betrieb freigegeben ist, bleibt beim Menschen. Umfang und Tiefe des Reviews richten sich nach Kritikalität und möglichem Schaden: Eine Anwendung für einen klar begrenzten Vereinsprozess hat andere Anforderungen als ein Finanzsystem, eine medizinische Anwendung oder eine unternehmenskritische Plattform. Je höher Schadenspotenzial, Datenkritikalität und regulatorische Relevanz, desto stärker müssen Architekturreview, Threat Modeling, Penetrationstests, Trennung von Verantwortlichkeiten und dokumentierte Freigaben ausgeprägt sein.

Typische Fehler beim Vibe Coding

Der häufigste Fehler ist, sichtbaren Fortschritt mit technischer Reife gleichzusetzen. Eine Oberfläche kann vollständig wirken, obwohl Datenhaltung, Fehlerbehandlung oder Berechtigungen nur teilweise umgesetzt sind. Im konkreten Projekt zeigte sich das an einer fehlenden Datenbank-Sicherheitsregel für Schreibzugriffe auf eine zentrale Tabelle (Row Level Security): Die Eingabemaske funktionierte einwandfrei, das Speichern von Änderungen schlug jedoch still fehl - ohne sichtbare Fehlermeldung. Deshalb sollte jede größere Funktion nicht nur vorgeführt, sondern gegen definierte Akzeptanzkriterien und Risiken geprüft werden.

Ein zweiter Fehler ist das zufällige Weiterprompten, bis ein Fehler scheinbar verschwindet. Dieses Vorgehen kann kurzfristig funktionieren, verschleiert aber Ursachen und erzeugt schwer nachvollziehbare Änderungen. Besser ist ein reproduzierbarer Fehlerbericht mit Ausgangszustand, Schritten, erwartetem und tatsächlichem Ergebnis sowie einer gezielten Analyse der Ursache.

Ein dritter Fehler ist die Annahme, generierte Tests seien ein unabhängiger Qualitätsnachweis. Tests sind nur so gut wie die zugrunde liegenden Anforderungen und Orakel. Prüft die KI lediglich ihre eigene Interpretation, kann eine fachlich falsche Umsetzung vollständig grün sein. Kritische Szenarien benötigen daher menschlich geprüfte Akzeptanzkriterien und risikobasierte Ergänzungen.

Ein vierter Fehler ist zu großer Handlungsspielraum. Agenten mit uneingeschränktem Zugriff auf Dateien, produktive Systeme oder Zugangsdaten können Fehlentscheidungen sehr wirksam ausführen. OWASP beschreibt mit "Excessive Agency" genau dieses Risiko. Rechte sollten minimal, Umgebungen getrennt und produktive Änderungen kontrolliert freigegeben werden.

Ein fünfter Fehler ist fehlende Versionskontrolle. Wenn Änderungen nicht in kleine, nachvollziehbare Schritte zerlegt werden, gehen funktionierende Zustände und Entscheidungswege verloren. Gerade bei schneller KI-gestützter Entwicklung sind Commits, Branches, Reviews und reproduzierbare Builds kein bürokratischer Zusatz, sondern die Grundlage für beherrschbare Geschwindigkeit.

Was ich heute anders machen würde

Rückblickend würde ich bei einem vergleichbaren Projekt noch früher mit dem Domänen- und Datenmodell beginnen und die Qualitätsbasis von Anfang an als Teil des Repositories behandeln: Entwicklungsregeln, Architekturhinweise, Testbefehle, Definition of Done und Sicherheitsvorgaben. Eine gute Benutzeroberfläche hilft, Anforderungen zu verstehen - dauerhafte Stabilität entsteht jedoch aus klaren fachlichen Objekten, Beziehungen und Regeln, die stehen sollten, bevor die Zahl der Funktionen stark wächst.

Änderungen würde ich außerdem konsequenter in kleinere Einheiten schneiden und die Trennung zwischen Entdecken und Stabilisieren bewusster gestalten. In der Ideenphase darf Vibe Coding schnell, kreativ und unvollständig sein. Sobald eine Lösung übernommen werden soll, wechselt der Modus: Anforderungen werden fixiert, technische Schulden bewertet, Tests ergänzt, Sicherheitsfragen geklärt und der Betrieb vorbereitet. Beide Modi sind wertvoll - problematisch wird nur, wenn unbemerkt im Experimentiermodus produktive Software entsteht.

Ein Qualitätsverständnis für KI-gestützte Softwareentwicklung

KI-gestützte Softwareentwicklung sollte nicht als isolierte Tool-Frage betrachtet werden. Entscheidend ist das Zusammenspiel aus Business Analyse, Entwicklung, Testmanagement, Informationssicherheit und Governance. KI kann Umsetzung und Analyse erheblich beschleunigen. Verbindliche Qualität entsteht jedoch erst durch klare Verantwortlichkeiten und überprüfbare Ergebnisse.

Für einen belastbaren Einsatz sollte KI-generierter Code als Änderungsvorschlag behandelt werden, nicht als automatisch freigegebenes Produkt. Fachliche Ziele und Akzeptanzkriterien werden vor der Umsetzung geklärt. Coding-Agenten erhalten Projektkontext, technische Leitplanken und definierte Prüfwege. Änderungen bleiben über Versionskontrolle nachvollziehbar und werden abhängig vom Risiko automatisiert sowie menschlich geprüft.

Testmanagement sollte dabei nicht an das Ende verschoben werden. Es sollte bereits die Formulierung der Aufgaben begleiten, Risiken identifizieren, Akzeptanzkriterien schärfen und den erforderlichen Testnachweis definieren. So kann die Geschwindigkeit von Vibe Coding und Agentic Coding genutzt werden, ohne fachliche Belastbarkeit, Sicherheit und Nachvollziehbarkeit zu verlieren.

Fazit

Das ursprüngliche Ziel war überschaubar: Ein papierbasiertes Prüfungsprotokoll sollte durch eine digitale Lösung ersetzt werden. Entstanden ist eine technisch umgesetzte und für den Praxiseinsatz vorbereitete Web-Anwendung - und zugleich ein praktischer Einblick in eine veränderte Form der Softwareentwicklung.

Vibe Coding hat den Einstieg ermöglicht. Es machte die Idee früh sichtbar, reduzierte technische Hürden und erlaubte schnelle fachliche Lernschleifen. Für die Weiterentwicklung zur dauerhaft nutzbaren Mehrbenutzer-Anwendung war jedoch ein anderer Modus notwendig: klare Anforderungen, bewusst getroffene Architekturentscheidungen, kontrollierte Agentenaufträge, systematische Tests, Zugriffsschutz und ein geplanter Betrieb.

Die entscheidende Kompetenz liegt deshalb nicht allein im Schreiben von Code und auch nicht im Formulieren möglichst geschickter Prompts. Sie liegt darin, ein Problem präzise zu verstehen, überprüfbare Ziele zu definieren, Risiken zu erkennen und Verantwortung für das Ergebnis zu übernehmen.

KI verschiebt die Grenze dessen, wer Software entwickeln kann. Sie hebt die Regeln professioneller Softwareentwicklung aber nicht auf. Je leichter Code erzeugt werden kann, desto wichtiger werden Architektur, Testmanagement und Governance. Genau daran entscheidet sich, ob KI lediglich schneller Software produziert - oder tatsächlich bessere Software entstehen lässt.sere Software entstehen lässt.