Vibe Coding im Unternehmen: wo es trägt und wo es teuer wird
In wenigen Stunden von einer Idee zu einer laufenden Anwendung: Das funktioniert inzwischen wirklich, und es verändert zu Recht, wie Teams Ideen prüfen. Der Streit beginnt an der Stelle, an der aus dem Prototyp etwas wird, das Kunden benutzen.
Schnell erzeugte Anwendungen tragen überall dort, wo etwas weggeworfen wird: Machbarkeitsnachweise, Oberflächenmuster, interne Werkzeuge, einmalige Auswertungen. Kritisch wird es ohne vier Bedingungen: einen ausdrücklichen Übergabepunkt zwischen Prototyp und Produkt, einen vorher festgelegten Architekturrahmen, automatische Prüfmechanismen statt Lesekapazität, und eine benannte Zuständigkeit. Sinnvoll ist die Definition von Zonen mit dokumentiertem Übergang statt eines Verbots.
Wo es unbestritten trägt
Bei allem, was weggeworfen wird: Machbarkeitsnachweise, Abstimmungsmuster für Oberflächen, interne Werkzeuge mit wenigen Nutzern, einmalige Auswertungen. Hier ist Geschwindigkeit der einzige relevante Maßstab, und die Fragen nach Wartbarkeit stellen sich nicht, weil nichts gewartet wird. Organisationen, die das verbieten, verlieren Tempo ohne Gegenwert.
Bedingung 1: Es gibt einen Übergabepunkt
Das Problem entsteht nicht durch schnell erzeugten Code, sondern durch fehlende Entscheidung darüber, wann er den Status wechselt. Ohne ausdrücklichen Übergabepunkt rutscht ein Prototyp in die Produktion, weil er schon funktioniert — und ab dann gelten Erwartungen, für die er nie gebaut wurde.
Bedingung 2: Der Rahmen steht vorher
Wo Modulgrenzen und Schnittstellenverträge festliegen, kann schnell erzeugter Code innerhalb dieser Grenzen entstehen, ohne Schaden anzurichten. Wo sie fehlen, verteilt sich derselbe Code über die gesamte Struktur — und ist danach nicht mehr herauszulösen. Der Unterschied liegt nicht im Code, sondern im Rahmen, in dem er entsteht.
Bedingung 3: Es gibt Prüfmechanismen statt Lesekapazität
Bei diesem Tempo ist die Prüfung durch Lesen aussichtslos. Was trägt, sind Eigenschaftstests, Vertragstests und Gates, die auf jeder Änderung laufen. Das ist kein Widerspruch zum schnellen Arbeiten, sondern seine Voraussetzung: Nur wer prüfen kann, kann es sich leisten, nicht zu lesen.
Bedingung 4: Jemand ist zuständig
Schnell entstandene Anwendungen haben eine Eigenschaft, die im Betrieb teuer wird: Sie haben oft keinen Verantwortlichen, weil sie nebenbei entstanden sind. Ein internes Werkzeug, das plötzlich vierzig Menschen benutzen, ohne dass jemand dafür zuständig ist, ist der klassische Fall — und er endet immer gleich.
Die vernünftige Haltung
Nicht verbieten, sondern Zonen definieren. Eine Zone, in der schnell und ohne Auflagen gearbeitet wird und in der nichts Kritisches liegt. Eine Zone mit Rahmen, Gates und Zuständigkeit. Und ein bewusster, dokumentierter Übergang dazwischen. Organisationen, die diesen Übergang nicht definieren, bekommen ihn trotzdem — nur unkontrolliert.
Häufige Fragen
Sollte man Prototypen-Code später wegwerfen und neu bauen?
Nicht zwingend. Wenn der Rahmen stand und die Gates greifen, kann derselbe Code weiterleben. Der Wechsel betrifft die Erwartungen — Betrieb, Zuständigkeit, Prüftiefe — nicht automatisch den Code.
Wie definiert man den Übergabepunkt praktisch?
Über eine kurze Prüfliste: Gibt es eine zuständige Person, laufen die Gates, ist die Risikoklasse zugeordnet, existiert ein Rückfallweg? Vier Fragen, fünf Minuten — der Wert liegt darin, dass der Übergang bewusst stattfindet.
Was ist mit Anwendungen, die Fachbereiche selbst bauen?
Dieselbe Logik, nur mit größerem Bedarf an Zonen. Eine klar abgegrenzte Umgebung mit unkritischen Daten, aus der nichts direkt in Produktivsysteme schreibt, ermöglicht viel und riskiert wenig. Kritisch wird es erst, wenn solche Anwendungen still zu Geschäftsprozessen werden.
Ist das nicht einfach Schatten-IT unter neuem Namen?
Der Unterschied ist das Tempo und die Menge. Schatten-IT entstand früher über Monate und war meist eine Tabelle. Heute entstehen in Tagen Anwendungen mit Datenbank und Anmeldung — die Frage nach Zonen und Übergängen ist deshalb dringender geworden, nicht neu.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
