Vibe Coding: Der Prototyp läuft. Und jetzt?

Der Moment ist jedes Mal derselbe. Nach anderthalb Tagen läuft die Anwendung im Browser, jemand aus der Fachabteilung klickt sich durch, und im Raum wird es kurz still. Dann kommt der Satz: "Können wir das nächste Woche im Team ausrollen?"

Meine Antwort darauf ist meistens nein. Nicht weil die Anwendung schlecht wäre. Sondern weil zwischen "funktioniert" und "läuft im Betrieb" noch etwas liegt, über das in den Erfolgsgeschichten selten gesprochen wird.

Was ein Prototyp bewiesen hat, und was nicht

Ein Prototyp beantwortet eine einzige Frage: Lässt sich der Prozess so abbilden? Das ist wertvoll, weil diese Frage vorher niemand sicher beantworten konnte. Aber sie ist eben nur eine von mehreren.

Was ein Prototyp nicht beantwortet: Was passiert, wenn zwanzig Leute gleichzeitig darauf zugreifen. Was passiert, wenn jemand ein Datum im falschen Format eingibt. Was passiert, wenn die Verbindung zur Datenbank für zehn Sekunden abreißt. Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt und sein Zugang gesperrt werden muss.

Im Prototyp führt der Bauende die Software durch den einen Weg, für den sie gedacht ist. Im Betrieb machen dreißig Menschen dreißig Dinge, an die niemand gedacht hat.

Die Arbeit, die danach kommt

Aus meiner Erfahrung dauert es etwa doppelt bis viermal so lange, einen Prototyp betriebsfest zu machen, wie ihn zu bauen. Anderthalb Tage Bauzeit bedeuten also grob drei bis sechs Tage bis zum echten Einsatz. Das klingt erst mal ernüchternd. Gemessen an einem klassischen Softwareprojekt ist es immer noch außergewöhnlich schnell.

Was in dieser Zeit passiert, ist wenig glamourös.

Zugriffsrechte, die tatsächlich greifen. Im Prototyp sieht jeder alles. Im Betrieb darf der Teamleiter die Anträge seines Teams sehen und nicht die der Nachbarabteilung.

Fehlerbehandlung. Was die Anwendung tut, wenn etwas nicht klappt, entscheidet darüber, ob Ihre Leute ihr vertrauen. Eine leere weiße Seite kostet Sie mehr Akzeptanz als jede fehlende Funktion.

Ein Weg zurück. Wenn ein Antrag versehentlich genehmigt wurde, muss sich das rückgängig machen lassen, ohne dass jemand in der Datenbank herumschraubt.

Und der Punkt, den ich am häufigsten nachrüsten muss: Nachvollziehbarkeit. Wer hat wann was geändert. Ohne das können Sie nach drei Monaten keine einzige Frage beantworten, die Ihnen die Revision stellt.

Warum man diesen Teil trotzdem gehen sollte

Es wäre ein Missverständnis, daraus zu schließen, dass sich der Weg nicht lohnt. Er lohnt sich, aber aus einem anderen Grund, als die meisten annehmen.

Der Gewinn liegt nicht darin, dass Software billig wird. Er liegt darin, dass die Person, die den Prozess kennt, endlich selbst beschreiben kann, wie das Werkzeug arbeiten soll. Bei klassischen Projekten geht dieses Wissen auf dem Weg über Lastenheft, Angebot und Entwicklerteam Stück für Stück verloren. Genau da entstehen die Tools, die technisch einwandfrei sind und trotzdem niemand benutzt.

Wenn die HR-Mitarbeiterin die Urlaubsfreigabe selbst gebaut hat, sitzt in jeder Ecke der Anwendung ihr Wissen über den echten Ablauf. Diesen Vorteil bekommen Sie durch kein Lastenheft.

Wie ich es Kunden empfehle

Trennen Sie die beiden Phasen sauber und benennen Sie sie unterschiedlich. Der Prototyp ist ein Experiment mit Testdaten, ohne echte Personal- oder Kundendaten, und mit einem klaren Enddatum. Danach entscheiden Sie bewusst, ob dieses Werkzeug in Betrieb gehen soll.

Diese Entscheidung fällt bei etwa der Hälfte der Prototypen negativ aus, und das ist ein gutes Ergebnis. Sie haben in anderthalb Tagen herausgefunden, dass sich der Aufwand nicht lohnt. Früher hätte diese Erkenntnis ein halbes Jahr und ein Angebot über 40.000 Euro gekostet.

Für die andere Hälfte planen Sie die zweite Phase ein, mit jemandem, der Betriebsthemen beurteilen kann. Das muss keine Agentur sein. Aber jemand sollte die vier Fragen von oben stellen, bevor der erste echte Urlaubsantrag im System landet.