KI-gestützte Entwicklung verändert gerade die Geschwindigkeit, mit der erste Anwendungen entstehen. Oberflächen, Formulare, Dashboards, kleine Workflows oder API-Ideen lassen sich heute oft in Stunden oder Tagen sichtbar machen.
Das ist beeindruckend - und es ist nützlich.
Aber in der Praxis entsteht dadurch ein neues Missverständnis: Ein funktionierender Prototyp ist noch kein belastbares Produktivsystem.
In einem anonymisierten Projekt aus unserer Agenturpraxis wurde genau dieser Unterschied sehr deutlich. Eine KI-gestützte Entwicklungsumgebung half dabei, in kurzer Zeit eine funktionierende Anwendungsidee sichtbar zu machen. Aus Sicht der Fachlogik war erstaunlich schnell viel erkennbar: Masken, Abläufe, Datenfelder, Nutzerführung, erste Interaktionen.
Der eigentliche Aufwand begann aber nicht beim ersten sichtbaren Ergebnis. Er begann danach.
Bei Hosting.
Bei Rechten.
Bei Datenflüssen.
Bei Deployment.
Bei Sicherheit.
Bei Betrieb.
Bei Verantwortung.
Was Vibe Coding heute sehr gut kann
Unter „Vibe Coding“ verstehe ich hier nicht einfach nur „Code mit KI generieren“. Gemeint ist eher ein Arbeitsmodus, in dem Idee, Prompt, Fachverständnis und iteratives Ausprobieren sehr eng zusammenrücken.
Das kann enorm produktiv sein.
Ein Fachanwender oder technischer Berater beschreibt, was passieren soll. Die KI schlägt Strukturen, Komponenten, Funktionen oder Schnittstellen vor. Der nächste Schritt wird ausprobiert, korrigiert, erweitert. Aus einem groben Gedanken entsteht schnell etwas, das man zeigen, testen und diskutieren kann.
Für frühe Phasen ist das sehr wertvoll:
- Anforderungen werden greifbarer.
- Fachbereiche können schneller Feedback geben.
- Abläufe werden sichtbar.
- Varianten lassen sich ohne große Vorlaufzeit testen.
- Diskussionen drehen sich nicht mehr nur um abstrakte Konzepte.
Gerade für kleine und mittlere Unternehmen ist das ein echter Fortschritt. Viele digitale Projekte scheitern nicht an der finalen Technik, sondern schon daran, dass Anforderungen zu lange abstrakt bleiben.
Ein schneller Prototyp kann hier helfen.
Wo der Prototyp endet
Der kritische Punkt ist: Ein Prototyp darf unvollständig sein.
Er darf mit Testdaten arbeiten.
Er darf technische Abkürzungen enthalten.
Er darf noch kein vollständiges Rechtekonzept haben.
Er darf noch keine perfekte Fehlerbehandlung besitzen.
Er darf noch nicht sauber skaliert sein.
Er darf auch wieder verworfen werden.
Ein Produktivsystem darf das nicht.
Sobald echte Nutzer, echte Daten, echte Prozesse oder echte Kunden betroffen sind, ändert sich der Maßstab. Dann reicht nicht mehr die Frage:
Funktioniert es grundsätzlich?
Dann kommen andere Fragen dazu:
- Wer darf sich anmelden?
- Welche Daten sieht welcher Nutzer?
- Wird die Rechteprüfung nur im Frontend angezeigt oder serverseitig durchgesetzt?
- Wo werden Daten gespeichert?
- Welche Logs entstehen?
- Wie werden Secrets verwaltet?
- Wie laufen Updates?
- Wie wird ein Fehler erkannt?
- Wie wird ein Backup wiederhergestellt?
- Wer ist im Störungsfall verantwortlich?
Genau an dieser Stelle zeigt sich der Unterschied zwischen „es läuft auf meinem Bildschirm“ und „es kann zuverlässig betrieben werden“.
Deployment ist nicht der letzte Klick
In vielen Diskussionen wirkt Deployment wie der letzte Schritt:
Code fertig, hochladen, läuft.
In der Realität ist Deployment oft der Beginn der ernsthaften technischen Arbeit.
Ein Produktivsystem braucht mindestens:
- eine klare Laufzeitumgebung,
- nachvollziehbare Konfiguration,
- getrennte Umgebungen für Entwicklung und Produktion,
- sichere Secrets,
- kontrollierte Datenbankmigrationen,
- SSL/TLS,
- Monitoring,
- Logging,
- Backup- und Restore-Konzept,
- Update-Prozess,
- Rollback-Möglichkeit,
- dokumentierte Verantwortlichkeiten.
Gerade KI-gestützte Prototypen erzeugen manchmal Code, der für eine Demo ausreichend ist, aber für den Betrieb nachgeschärft werden muss. Das ist kein Versagen der KI. Es ist schlicht eine andere Projektphase.
Ein LLM kann helfen, schneller zu starten.
Es nimmt aber nicht automatisch die Verantwortung für Architektur und Betrieb ab.
Authentifizierung ist nicht gleich Berechtigung
Ein klassisches Beispiel: Login.
Viele Prototypen haben schnell eine Anmeldung. Das sieht nach Sicherheit aus. Aber ein Login allein beantwortet noch nicht die entscheidende Frage:
Was darf ein eingeloggter Nutzer wirklich?
Ein produktives System braucht ein Rollen- und Berechtigungskonzept. Und dieses Konzept muss serverseitig greifen.
Typische Fragen:
- Gibt es Admins, interne Nutzer, externe Nutzer, Kunden oder Partner?
- Darf ein Nutzer nur eigene Datensätze sehen?
- Werden Objektzugriffe einzeln geprüft?
- Sind API-Endpunkte geschützt?
- Können IDs manipuliert werden?
- Gibt es Audit-Logs für kritische Aktionen?
- Was passiert bei deaktivierten Benutzern?
Viele Sicherheitsprobleme entstehen nicht dadurch, dass kein Login vorhanden ist. Sie entstehen dadurch, dass nach dem Login zu viel erlaubt ist.
Kundendaten verändern alles
Solange ein Prototyp mit Dummy-Daten arbeitet, ist vieles relativ unkritisch. Sobald echte Kundendaten verarbeitet werden, ändern sich die Anforderungen.
Dann geht es nicht mehr nur um technische Machbarkeit. Dann geht es um:
- Datenschutz,
- Auftragsverarbeitung,
- Zweckbindung,
- Datenminimierung,
- Zugriffsschutz,
- Löschkonzepte,
- Exportmöglichkeiten,
- Dokumentation,
- Risikoabwägung,
- technische und organisatorische Maßnahmen.
Besonders kritisch sind nicht nur offensichtlich sensible Daten. Auch scheinbar normale Daten können relevant sein:
- Namen,
- E-Mail-Adressen,
- Telefonnummern,
- Anfragen,
- Termine,
- Bestellhistorien,
- Kundennummern,
- Freitextfelder,
- Uploads,
- interne Notizen,
- Logdaten.
Gerade Freitextfelder werden häufig unterschätzt. Dort landen in der Praxis oft Informationen, die ursprünglich niemand vorgesehen hatte.
Deshalb sollte der Wechsel von Testdaten zu Echtdaten ein bewusster Meilenstein sein. Nicht etwas, das nebenbei passiert.
Was KI beim Entwickeln nicht automatisch löst
KI kann beim Erstellen von Code helfen. Sie kann Vorschläge machen, Strukturen erzeugen, Fehler erklären, Tests vorbereiten oder Dokumentation anstoßen.
Aber KI löst nicht automatisch:
- die fachliche Verantwortung,
- die Architekturentscheidung,
- das Datenschutzkonzept,
- die Rechte- und Rollendefinition,
- die Betriebsverantwortung,
- die Sicherheitsprüfung,
- die Qualitätssicherung,
- die langfristige Wartbarkeit.
Diese Punkte müssen weiterhin von Menschen bewertet werden, die den Kontext verstehen.
Das gilt besonders im Mittelstand. Dort sind digitale Systeme oft eng mit realen Prozessen verbunden: Kundenkommunikation, interne Abläufe, Abrechnung, Service, Dokumentation, Produktion, Logistik oder Support.
Ein schneller Prototyp kann hier sehr hilfreich sein.
Ein ungeprüfter Produktivbetrieb kann riskant werden.
Eine praktische Checkliste vor dem Go-live
Bevor ein KI-gestützt entwickelter Prototyp produktiv wird, sollte mindestens diese Liste geprüft werden:
1. Zweck und Nutzerkreis
- Welches Problem löst die Anwendung?
- Wer nutzt sie?
- Welche Rollen gibt es?
- Welche Prozesse werden verändert?
2. Daten
- Welche Daten werden verarbeitet?
- Sind personenbezogene Daten betroffen?
- Gibt es Uploads oder Freitextfelder?
- Welche Daten sind wirklich notwendig?
- Wie lange werden sie gespeichert?
3. Authentifizierung und Berechtigungen
- Wie melden sich Nutzer an?
- Welche Rechte haben sie?
- Werden Berechtigungen serverseitig geprüft?
- Gibt es Admin-Funktionen?
- Können Nutzer fremde Datensätze sehen?
4. Infrastruktur und Deployment
- Wo läuft die Anwendung?
- Wo liegt die Datenbank?
- Wie werden Umgebungsvariablen und Secrets verwaltet?
- Wie erfolgen Updates?
- Gibt es getrennte Test- und Produktivumgebungen?
5. Sicherheit
- Sind API-Endpunkte geschützt?
- Gibt es Rate Limits?
- Werden Eingaben validiert?
- Sind Logs geschützt?
- Gibt es Backup und Restore?
- Wurde der Restore getestet?
6. Betrieb
- Wer betreibt das System?
- Wer reagiert bei Fehlern?
- Wie werden Updates eingespielt?
- Wie wird Monitoring umgesetzt?
- Gibt es einen Incident-Prozess?
7. Dokumentation
- Sind Datenflüsse dokumentiert?
- Sind Dienstleister und Schnittstellen bekannt?
- Ist der Zweck der Verarbeitung klar?
- Sind Verantwortlichkeiten geregelt?
Diese Liste ist nicht vollständig. Aber sie trennt sehr schnell einen Demo-Stand von einem System, das in Richtung Produktion gehen kann.
Was ich aus solchen Projekten mitnehme
Meine wichtigste Beobachtung ist:
KI-gestützte Entwicklung verkürzt den Weg zum sichtbaren Ergebnis. Sie verkürzt aber nicht automatisch den Weg zum verantwortbaren Betrieb.
Das ist kein Widerspruch.
Im Gegenteil: Je schneller Prototypen entstehen, desto wichtiger wird es, den Übergang zur Produktion bewusst zu gestalten.
Für mich lautet die sinnvolle Linie daher nicht:
KI ersetzt Entwicklung.
Sondern eher:
KI beschleunigt frühe Entwicklungsphasen. Architektur, Sicherheit, Datenschutz und Betrieb bleiben entscheidend.
Gerade für KMU ist das eine gute Nachricht. Unternehmen können schneller ausprobieren, ob eine Idee trägt. Sie müssen dafür nicht mehr jede Denkbewegung in langen Konzeptphasen vorbereiten.
Aber sie sollten wissen, wann aus einem Experiment ein Verantwortungsbereich wird.
Fazit
Vibe Coding ist stark, wenn es um Tempo, Ideenfindung und Prototyping geht.
Real Deployment beginnt dort, wo echte Nutzer, echte Daten und echte Verantwortung ins Spiel kommen.
Der eigentliche Aufwand liegt dann nicht mehr nur im Schreiben von Code, sondern in der Frage, ob das System dauerhaft, sicher, nachvollziehbar und wartbar betrieben werden kann.
Oder kurz gesagt:
Prototypen dürfen schnell sein. Produktivsysteme müssen belastbar sein.
Einen ausführlicheren deutschsprachigen Beitrag dazu habe ich hier veröffentlicht:
https://www.internetagentur-scherer.de/aktuelles/vibe-coding-2026-prototyp-produktivsystem
Ich bin Jürgen Scherer, Inhaber der Internetagentur Scherer in Dachau. Wir begleiten KMU seit 1998 bei Webentwicklung, technischer SEO, Performance, Infrastruktur, Datenschutz und pragmatischem KI-Einsatz.
Top comments (0)