Wie ein Vibe-Coding-SWAT-Team entscheidet, was es baut
Vibe Coding senkt nicht die Maßstäbe für gute Use Cases. Es senkt die Kosten, belastbare Evidenz zu erzeugen. Ein Lifecycle für Teams, die Prototypen kontrolliert in Wert oder eine klare Stop-Entscheidung überführen wollen.
TL;DR: Vibe Coding senkt nicht die Kriterien für einen guten Use Case. Es senkt die Kosten, belastbare Evidenz zu erzeugen. Wenn ein realitätsnaher Build weniger kostet als die nächste Abstimmungsrunde, muss ein SWAT-Team anders arbeiten: Case qualifizieren, die riskanteste Annahme mit einem kleinen echten Artefakt testen, eine begrenzte Version in den Workflow bringen und dann bewusst stoppen, lokal behalten, erweitern, richtig finanzieren oder an die IT übergeben. Der Maßstab ist nicht die Zahl der Prototypen. Es sind die Entscheidungen, die sie verbessern.
Wenn die Kosten für Evidenz sinken, ändert sich das Betriebsmodell
Vibe Coding kann aus einem engen Workflow funktionierende Software machen, bevor der nächste Lenkungskreis tagt. Für den ersten realistischen Prototypen setzen wir 1–2 Stunden an.
Klassische Portfolio-Prozesse gehen davon aus, dass ein realistischer Build teuer ist. Kostet ein funktionierender Ausschnitt weniger als die nächste Abstimmungsrunde, ist Coding nicht mehr der Engpass. Knapp werden Nutzerzugang, Review, Security-Urteil und Ownership.
Continuous Discovery nutzt schon lange Prototypen. Vibe Coding verändert ihre Kosten, ihre Realitätsnähe und die Frage, wer sie bauen kann. Ein kleines Team kann Oberfläche, Datenlogik und Deployment in einem Loop verbinden. Die Workflow-Expert:innen sitzen direkt am Artefakt.
Der Prototyp wird dadurch zum Gesprächsinstrument. Menschen reagieren auf einen echten Flow, zeigen fehlenden Kontext und legen Vertrauensprobleme offen, die ein Feature-Brief selten sichtbar macht.
In einem zweitägigen Workshop bei einem großen Versicherungsunternehmen arbeiteten mehr als 20 Personen in sechs Gruppen an sechs internen Problemen. Mit vorbereiteter Infrastruktur und Dummy-Daten entstand pro Gruppe ein eigener Full-Stack-Prototyp: echtes Frontend, echtes Backend und Code, der als Ausgangspunkt wiederverwendbar ist.
Das waren keine Produktionsanwendungen. Security, Support, Integration und Ownership waren bewusst noch offen. Günstiger Full-Stack-Output braucht deshalb schnelle Reviews und explizite Stop-Entscheidungen.
Das SWAT-Team-Betriebsmodell erklärt Teamzuschnitt und IT-Übergabe. Dieser Artikel betrachtet einen einzelnen Use Case.
Phase 1: Den Case qualifizieren
Am Anfang stehen fünf konkrete Dinge:
- Ein benannter Workflow-Owner und die Personen, die die Arbeit erledigen und den Build testen werden.
- Ein wiederkehrender Schmerz in diesem Workflow, nicht nur ein Feature-Wunsch ohne Bezug zur Arbeit.
- Eine Business-Value-Hypothese: Was soll schneller, sicherer, günstiger oder verlässlicher werden?
- Ein beobachtbares Erfolgssignal: Welches Verhalten oder Ergebnis würde zeigen, dass der Case besser geworden ist?
- Ein Fatal-Blocker-Screen für kritische Daten, Regulierung, Berechtigungen und Integrationen.
Business Value beginnt als Hypothese. Desire ist meist der erste empirische Test: Nutzen Menschen einen greifbaren Flow? Tiefere Feasibility folgt, wenn dieses Signal sie rechtfertigt. Ein harter technischer oder regulatorischer Blocker kann früher einen Technical Spike nötig machen. Das ist ein enger Build, der nur eine Feasibility-Frage beantwortet.
Phase 2: Den Evidence Loop durchlaufen
Der Loop hat fünf Schritte:
Frame → Slice → Build → Show → Re-score
Zuerst wird die riskanteste Annahme formuliert. Dann wird der kleinste nützliche Flow geschnitten, der sie sichtbar macht. Für echtes Verhalten bauen, ihn den Menschen zeigen, die die Arbeit erledigen, den Case neu bewerten und die nächste Unsicherheit auswählen.
Für den ersten realistischen Prototypen ist 1–2 Stunden ein Operating Target: ein Happy Path, synthetische oder freigegebene Daten und keine Produktionsauthentifizierung oder Integration. Ist die Integration selbst die Unsicherheit, gehört sie in den Slice. Dort real bauen, wo Verhalten zählt; an anderer Stelle bewusst unvollständig bleiben. Die Zeitbox ist ein Zwang zur Klarheit, kein Benchmark. Braucht der Ausschnitt eine Woche, müssen entweder seine Annahmen kleiner werden oder die Arbeit heißt Technical Spike.
Nimm einen internen Proposal Checker als Beispiel. Er braucht nicht mit CRM-Integration, Rollen und Reporting zu starten. Vielleicht nimmt er zunächst einen Antrag an, prüft ihn gegen drei vereinbarte Kriterien und gibt eine Review-Queue zurück. Das reicht, um Vertrauen, Overrides und fehlenden Kontext zu beobachten.
Jeder AI-generierte Ausschnitt muss klein genug bleiben, um ihn zu verstehen, zu reviewen und zu testen. Generierte Abhängigkeiten, geprüfte Annahmen und der Owner gehören ins Protokoll. Kann niemand Datenpfad und wahrscheinlichen Fehlermodus erklären, hat Geschwindigkeit nur Risiko versteckt.
Jeder Loop endet mit einer Entscheidung: stoppen, neu framen, einen Technical Spike durchführen oder den nächsten fokussierten Ausschnitt bauen. Ein Prototyp, der keine Annahme, Bewertung oder nächste Aktion verändert, ist nur eine Demo.
Was der Loop testet und was nicht
Der Evidence Loop kann Problem-Solution-Evidenz schärfen, frühes Desire sichtbar machen, fokussierte Feasibility testen und die Business-Value-Hypothese verbessern.
Er kann keinen realisierten ROI, keinen verlässlichen Betrieb, keine Support-Ökonomie, keine Ownership, keine vollständige Security und keine IT-Akzeptanz beweisen. Eine polierte Oberfläche kann schwache Berechtigungen, brüchige Daten und manuellen Recovery-Aufwand verdecken. Das Team bringt den Ausschnitt mit expliziten Kontrollen in eine begrenzte Nutzung. Oder es stoppt.
Phase 3: Eine begrenzte Version in den Workflow bringen
Ein Small Deployment folgt erst, wenn die Prototype-Evidenz rechtfertigt, Value im echten Workflow zu testen und die Exposition begrenzbar ist. „Klein“ beschreibt Nutzergruppe, Datenumfang, Integrationen und Schadensradius. Nicht eine unvollständige Experience.
Jetzt werden Adoption und ein Workflow-Outcome gemessen. Edge Cases, Zuverlässigkeit, Support, Change Approval und der notwendige Security-Pfad werden sichtbar. Go-, Stop- und Rollback-Bedingungen stehen vor dem Deployment fest.
Die Grenzen bleiben explizit: eine begrenzte Gruppe, freigegebene Daten, gedeckelte Berechtigungen, ein definierter Laufzeitraum und ein Fallback auf den alten Workflow. Jeder Batch muss eigenständig nutzbar und testbar bleiben.
Das Endprodukt darf offen bleiben, während ein Owner den eingesetzten Ausschnitt verantwortet.
Phase 4: Die Production-Entscheidung treffen
Microsofts BXT trennt Business, Experience und Technology. Ich ergänze Betrieb und Verantwortung, weil technische Reife noch keine operative Accountability zuweist. Die finale Entscheidung verbindet vier Evidence Measures:
- Business Value: schätzen → präzisieren → messen → finanzieren oder stoppen
- Desire: benannter Schmerz → Verhalten im Prototyp → Adoption → anhaltende Nachfrage
- Feasibility: Blocker-Screen → kritischer Spike → Zuverlässigkeit in Nutzung → Production Readiness
- Betrieb und Verantwortung: Workflow-Owner → Owner des Ausschnitts und Review-Pfad → Support-Owner und Fallback → Betriebs-Owner, Budget und IT-Akzeptanz
„Betrieb und Verantwortung“ fragt, was passiert, wenn das Prototyp-Team den Case verlässt: Wer besitzt Zugriffe, Incidents, User Support, Änderungen und Kosten? Eine Anwendung kann nützlich, gewünscht und technisch solide sein und trotzdem keine tragfähige Zukunft im Betrieb haben.
Dann wird ein primärer Betriebszug gewählt:
- Stoppen: Die Evidenz rechtfertigt keine weitere Arbeit.
- Lokal behalten: Das Tool bleibt bei einem benannten Business-Owner, mit begrenzten Nutzer:innen, freigegebenen Daten und gedeckelten Integrationen.
- Erweitern: Ein weiterer fokussierter Ausschnitt kann eine wesentliche Unsicherheit auflösen.
- Richtig finanzieren: Der Value rechtfertigt Produktbudget, Engineering und Härtung.
- An die IT übergeben: Die IT übernimmt explizit Ownership, Budget und Support. Das kann trotzdem Finanzierung oder einen Rebuild erfordern.
Das SWAT-Team ist eine Evidence Engine
Im Workshop verschoben die funktionierenden Prototypen das Gespräch von Feature-Ideen zu Berechtigungen, Integrationen, Support und Ownership. Die Artefakte machten die nächsten Unsicherheiten sichtbar, solange sie noch günstig zu bearbeiten waren.
Der nächste Build wird nur finanziert, wenn er der günstigste Weg ist, die wichtigste Unsicherheit aufzulösen.
Quellen
Dr. Ronny Schüritz
Co-Founder von Build With Vibe. Technical Lead und AI-Enthusiast.
Bereit, Vibe Coding selbst auszuprobieren?
Lerne in unseren Vor-Ort-Workshops in Berlin, wie du durch KI zum Product Engineer wirst. Keine Vorkenntnisse nötig.
Workshop buchen