Vibe Coding im Unternehmen: wo es endet und Softwareentwicklung beginnt

Was Vibe Coding eigentlich meint

Vibe Coding heißt: Sie beschreiben einem Sprachmodell in normaler Sprache, was eine Software tun soll, und übernehmen das Ergebnis, ohne es Zeile für Zeile zu prüfen. Geprägt hat den Begriff der KI-Forscher Andrej Karpathy. Aus einem Chatfenster entsteht so innerhalb einer Stunde ein Werkzeug, das rechnet, Listen anzeigt, Daten speichert und sogar halbwegs ordentlich aussieht.

Für Fachabteilungen ist das eine echte Veränderung. Wer früher ein halbes Jahr auf ein kleines internes Tool gewartet hat, baut es heute am Nachmittag selbst — Vertrieb, Buchhaltung, Disposition, Qualitätssicherung. Die interessante Frage ist deshalb nicht mehr, ob das funktioniert. Sie lautet: Ab welchem Punkt trägt so ein Entwurf den laufenden Betrieb, und ab welchem Punkt wird er teuer?

Wo Vibe Coding im Unternehmen wirklich hilft

Es gibt einen Bereich, in dem KI-Programmierung ohne Wenn und Aber sinnvoll ist — und der ist größer, als viele IT-Abteilungen zugeben wollen:

• Prototypen und Klickdummies. Eine Idee wird sichtbar, bevor irgendjemand ein Budget beantragt. Diskussionen über Bildschirme sind kürzer als Diskussionen über Konzeptpapiere.
• Einmalige Auswertungen. Zwei Exporte zusammenführen, Dubletten finden, eine Kennzahl für die Geschäftsführung ausrechnen. Danach wird das Skript nicht mehr gebraucht.
• Kleine Helfer für wenige Kollegen. Eine Checkliste, ein Rechner für Angebotspositionen, ein Formular, das eine Excel-Datei ablöst.
• Vorarbeit für das Lastenheft. Wer seinen Prozess einmal selbst nachgebaut hat, beschreibt ihn danach deutlich präziser — und das spart im echten Projekt mehr Zeit, als der Prototyp gekostet hat.

Das Muster hinter allen vier Fällen: wenige Nutzer, keine personenbezogenen Daten in nennenswertem Umfang, kein Kundenkontakt — und kein Schaden, wenn das Ding morgen nicht startet.

Wo es kippt

Sobald eine dieser Bedingungen wegfällt, ändern sich die Anforderungen schlagartig. Der Code sieht gleich aus, der Maßstab ist ein anderer:

Die vier Stellen, an denen solche Projekte scheitern

1. Das Datenmodell. Sprachmodelle bauen gern die Tabelle, die für den aktuellen Bildschirm reicht. Der zweite Anwendungsfall passt dann nicht mehr hinein, und jede Auswertung braucht einen Sonderweg. Datenmodelle im Nachhinein zu drehen ist die teuerste Art, Software zu ändern.
2. Rechte und Rollen. Ein Prototyp zeigt jedem alles. Im Betrieb darf der Monteur den Einkaufspreis nicht sehen und der Praktikant keine Personaldaten. Berechtigungen nachträglich einzuziehen bedeutet, jede Abfrage im System noch einmal anzufassen.
3. Fehlerfälle. Generierter Code beschreibt den guten Verlauf. Was passiert bei doppeltem Klick, abgebrochener Verbindung, zwei gleichzeitigen Änderungen an derselben Position? Genau dort entstehen die Buchungen, die später niemand erklären kann.
4. Die zweite Meinung. Ohne Test und ohne Review fällt erst im Betrieb auf, dass etwas falsch gerechnet wurde. Und zwar dann, wenn das Ergebnis bereits beim Kunden liegt.

Die Checkliste vor dem Produktivgang

Bevor ein selbst gebautes Werkzeug echte Arbeit übernimmt, beantworten Sie bitte diese Fragen schriftlich:

• Welche personenbezogenen Daten verarbeitet das Werkzeug, und auf welcher Grundlage?
• Wo liegen die Daten, wer hat Zugriff, und gibt es die nötigen Verträge mit den beteiligten Anbietern?
• Gibt es Sicherungen — und hat jemand die Wiederherstellung einmal ausprobiert?
• Wer merkt es, wenn die Anwendung nachts stehen bleibt?
• Wer ändert sie, wenn der Kollege, der sie gebaut hat, im Urlaub ist oder das Unternehmen verlässt?
• Was kostet ein Tag Ausfall — in Arbeitszeit, in Terminen, in Vertrauen beim Kunden?

Fällt schon die dritte Antwort schwer, ist das kein Grund, den Prototyp wegzuwerfen. Es ist der Zeitpunkt, ihn als Vorlage zu behandeln und die Anwendung sauber neu aufzusetzen — als Webanwendung mit Anmeldung, Rollen und Protokoll statt als Skript auf einem Notebook.

Der Prototyp ist nicht umsonst gewesen

Ein häufiger Irrtum lautet, der Entwurf aus dem Chat sei verlorene Arbeit, sobald Profis übernehmen. Das Gegenteil stimmt. Ein lauffähiger Prototyp klärt in zwei Tagen, was in Abstimmungsrunden Wochen dauert: welche Felder wirklich gebraucht werden, wie der Ablauf im Alltag aussieht, wo die Ausnahmen sitzen. Wir nehmen solche Entwürfe regelmäßig als Ausgangspunkt für die individuelle Softwareentwicklung — das Team muss den Fachbereich dann nicht mehr raten, es sieht ihn.

Wichtig ist nur die Erwartung: Der Prototyp ist die Spezifikation, nicht das Produkt. Datenmodell, Rechte, Schnittstellen und Tests entstehen neu. Die Oberfläche und der Ablauf dürfen bleiben.

KI im Entwicklungsalltag — anders als im Chat

KI-gestützte Entwicklung verschwindet dadurch nicht. Sie sieht nur anders aus als der Griff ins Chatfenster: Das Modell schreibt Entwürfe, Tests und Routinearbeit, der Entwickler verantwortet Architektur, Datenmodell und Freigabe. Jede Änderung läuft durch Review und automatische Tests, bevor sie auf ein System kommt, an dem Menschen arbeiten. So bleibt das Tempo erhalten, ohne dass am Ende niemand mehr erklären kann, warum eine Rechnung falsch berechnet wurde.

Der zweite Unterschied betrifft den Betrieb. Software, die Arbeit übernimmt, braucht jemanden, der Aktualisierungen einspielt, Sicherungen prüft und erreichbar ist, wenn etwas klemmt. Das ist kein Projekt, sondern laufende Betreuung — und der Posten, den Eigenbau-Werkzeuge fast immer vergessen.

Kurz zusammengefasst

• Vibe Coding ist für Prototypen, Auswertungen und kleine interne Helfer ein Gewinn.
• Sobald führende Daten, Rechte oder Kunden im Spiel sind, gelten die Regeln normaler Softwareentwicklung.
• Die teuren Fehler liegen im Datenmodell und in den Berechtigungen, nicht in der Oberfläche.
• Der Prototyp bleibt wertvoll — als präzise Beschreibung dessen, was gebaut werden soll.

Was wir damit machen

Wir nehmen vorhandene Prototypen auseinander, sagen Ihnen ehrlich, was davon tragfähig ist, und bauen daraus eine Anwendung mit Datenmodell, Rollen, Tests und Betrieb. Wenn Sie zuerst wissen wollen, ob sich das lohnt, klärt ein Digitalisierungs-Check Aufwand und Reihenfolge. Alles Weitere zur Umsetzung finden Sie auf der Seite Individualsoftware.