Vom Prototyp zur produktionsreifen Anwendung

01

Ein Prototyp beweist wenig von dem, was später zählt.

Ein Prototyp beweist, dass eine Idee trägt. Die Oberfläche funktioniert, die Daten fließen, die ersten Nutzer verstehen den Ablauf auf Anhieb. Was er nicht beweist: dass sich die Anwendung sicher, wiederherstellbar, änderbar und rechtlich zulässig betreiben lässt. Diese Eigenschaften entstehen nicht nebenbei. Sie werden bewusst gebaut und geprüft, bevor sich irgendjemand darauf verlässt.

Ob mit Lovable, Bolt oder Replit erzeugt, mit Cursor oder Claude Code geschrieben oder als n8n-Workflow zusammengesteckt: Prototypen entstehen heute in Stunden, nicht Wochen. Für diese Arbeitsweise hat sich der Begriff Vibe Coding eingebürgert, Software, die im Dialog mit einem Sprachmodell wächst, oft ohne dass eine einzige Zeile gelesen wird. In unseren Projekten sehen wir den kritischen Moment fast immer an derselben Stelle: nicht beim ersten Test, sondern sobald eine zweite Abteilung, ein Kunde oder ein echter Geschäftsprozess sich auf das Ergebnis stützt.

Genau dort setzt diese Serie an: bei der IT, die ein Fachbereichs-Werkzeug übernehmen soll (Der Fachbereich hat eine App gebaut), bei Automatisierungen und Datenskripten (Vom n8n-Workflow oder Streamlit-Skript zur betreibbaren Anwendung) und bei App-Buildern (Mit Lovable, Bolt oder Replit gebaut).

02

Warum reicht es nie, dass etwas einfach läuft?

Schneller ist nicht dasselbe wie stabiler. Der DORA-Bericht State of AI-assisted Software Development (Google Cloud, 2025) befragte fast 5.000 Technologie-Fachleute, 90 Prozent von ihnen nutzen KI bereits bei der Arbeit. Neu gegenüber dem Vorjahr: KI-Nutzung hängt jetzt positiv mit dem Auslieferungsdurchsatz zusammen, aber weiterhin negativ mit der Stabilität. Die Kernthese der Autoren ist unbequem: KI verstärkt, was in einem Team schon vorher da war, gute Praxis wie schlechte.

Der unsichere Weg ist oft die Voreinstellung. Für den 2025 GenAI Code Security Report (Veracode, 2025) lösten über 100 Sprachmodelle 80 Programmieraufgaben in Java, Python, C# und JavaScript. Stand eine sichere neben einer unsicheren Lösung zur Wahl, griffen die Modelle in 45 Prozent der Fälle zur unsicheren und brachten dabei Schwachstellen aus den OWASP Top 10 mit. Am schlechtesten schnitt Java ab, mit einer Fehlerquote von 72 Prozent. Größere und neuere Modelle waren dabei nicht sicherer als kleinere, ältere.

In unseren Projekten deckt sich das mit dem, was uns beim Lesen von generiertem Code auffällt: Die Logik stimmt fast immer, die Behandlung von Rand- und Fehlerfällen fehlt fast genauso oft. Methodik und Grenzen der beiden Studien ordnet Was Studien über die Qualität KI-generierten Codes zeigen ein, die Abwägung dazu Vibe Coding: wo es hilft, wo es beißt.

03

Sieben Fragen, eine Prüfliste, kein Zufall.

Jede der sieben Dimensionen hat eine typische Voreinstellung, die im Test genügt und im Betrieb zum Risiko wird. Die Tabelle stellt alle sieben nebeneinander, die Abschnitte danach nehmen jede einzeln auseinander.

KI-GENERIERTKI-GENERIERT

04

Identität und Berechtigungen: Wer darf eigentlich was?

Wer angemeldet ist, sieht meistens alles. Rollen gibt es oft nur an der Oberfläche: ein ausgeblendeter Knopf, während die Schnittstelle dahinter jede Anfrage brav beantwortet. Bei Supabase entscheidet die Row Level Security der Datenbank, ob der öffentlich ausgelieferte Schlüssel nur erlaubte Zeilen erreicht oder gleich ganze Tabellen. Wer im Browser mitliest, tauscht eine Kennung aus und bekommt fremde Datensätze zurück. Kein Angriff im klassischen Sinn, nur eine geänderte Zahl in der Adresse.

Zwei Testkonten mit unterschiedlichen Rollen anlegen, eine Anfrage des ersten Kontos aus den Entwicklerwerkzeugen des Browsers kopieren und mit der Anmeldung des zweiten Kontos erneut senden. Kommt der Datensatz trotzdem zurück, fehlt die serverseitige Prüfung, egal was die Oberfläche zeigt. Wie dieser Mechanismus konkret in App-Buildern aussieht, erklärt Mit Lovable, Bolt oder Replit gebaut.

05

Datenhaltung und Migrationen: Wie entwickeln sich die Daten weiter?

Tabellen entstehen per Klick im Dashboard, oder ein Coding-Agent legt sie direkt an, ohne Migrationen, also ohne eine versionierte Abfolge von Schemaänderungen. Häufig teilen sich Test und echte Daten dieselbe Datenbank. Die Folge: Stände driften auseinander, eine fehlerhafte Änderung lässt sich nicht gezielt zurücknehmen, und ein harmlos umbenanntes Feld kann echte Daten kosten.

Bauen Sie versuchsweise eine leere Datenbank ausschließlich aus dem Repository auf. Braucht das Handarbeit, fehlt die Migrationshistorie, und genau das ist der Befund. Wie ein solches Datenmodell zur technischen Schuld wird, beschreibt Technische Schulden in KI-generiertem Code erkennen.

06

Geheimnisse und Schlüssel gehören nicht in den Browser.

Der Schlüssel für ein Sprachmodell oder einen Zahlungsdienst landet im Frontend-Code oder in einer .env-Datei, die versehentlich ins Repository gewandert ist. Alles im Browser kann jeder lesen. Ein sichtbarer Schlüssel lässt sich mit Ihren Rechten nutzen, auf Ihre Rechnung. Selbst eine gelöschte Datei bleibt in der Git-Historie abrufbar, oft jahrelang.

Durchsuchen Sie das ausgelieferte JavaScript nach Begriffen wie key, secret oder token und die Git-Historie mit dem folgenden Befehl. Jeder Schlüssel, der je dort stand, muss ersetzt werden. Verschieben allein reicht nicht.

git log -p --all | grep -inE 'api[_-]?key|secret|token|passw|sk-[a-z0-9]'

Leitplanken für Schlüssel und Kundendaten in KI-Werkzeugen beschreibt KI-Werkzeuge im Entwicklungsteam freigeben, Sicherheitsfragen von KI-Anwendungen selbst die Seite KI-Sicherheit.

07

Lässt sich im Nachhinein rekonstruieren, was passiert ist?

Fehler blitzen in der Browserkonsole oder im Terminal auf und sind danach weg. Wo protokolliert wird, landen häufig ganze Datensätze samt E-Mail-Adresse im Log, während nirgends steht, wer einen Eintrag wann geändert hat. Fehlt einer Nutzerin ein Datensatz, gibt es keine Spur. Das Log selbst wird zu einem schützenswerten Datenbestand.

Ein Betriebslog zeigt, was technisch passiert ist, ein Auditlog, wer was wann fachlich geändert hat. Machen Sie die Probe: Wer hat gestern diesen Datensatz geändert, und was stand vorher darin? Wie Automatisierungen fehlgeschlagene Läufe sichtbar machen, vertieft Vom n8n-Workflow oder Streamlit-Skript zur betreibbaren Anwendung.

08

Wer bemerkt einen Ausfall, und wie kommt die Anwendung zurück?

Die Anwendung läuft im Standardtarif einer Plattform oder auf dem Rechner der Person, die sie gebaut hat. Einen Ausfall bemerken meist die Nutzer zuerst, die Sicherung erledigt vermutlich der Anbieter. Die erste echte Wiederherstellung findet dann im Ernstfall statt, unter Zeitdruck, ohne Übung. Ohne benannte Zuständigkeit hängt der Betrieb an einer einzelnen Person und deren Urlaubsplanung.

Spielen Sie eine Sicherung einmal in eine getrennte Umgebung zurück und starten Sie die Anwendung damit. Legen Sie fest, wie viel Datenverlust und Ausfallzeit tragbar sind (in der Fachsprache RPO und RTO) und wer benachrichtigt wird. Mehr dazu in Eine Anwendung im eigenen Haus betreiben, die nötigen Übergabe-Unterlagen in Vom Proof of Concept in den Regelbetrieb.

09

Änderungen sollten möglich sein, ohne dass jemand zittert.

Änderungen gehen direkt live, in einer einzigen Umgebung, ohne automatisierte Tests. Ein Coding-Agent schreibt auf eine kleine Bitte hin gleich ganze Dateien neu, niemand vergleicht vorher, was sich wirklich verändert hat. Die Folge kennt jedes Team, das das einmal erlebt hat: Jede Änderung kann Unbeteiligtes brechen, das Team meidet Änderungen, die Anwendung erstarrt, genau dort, wo der DORA-Befund ansetzt.

Gibt es eine Testumgebung mit eigener Datenbank? Wird jede Änderung vor dem Zusammenführen von einem Menschen gelesen? Decken Tests die wichtigsten Abläufe ab? Lässt sich eine Auslieferung zurücknehmen, ohne Daten zu verlieren? Vertiefung bieten Technische Schulden in KI-generiertem Code erkennen und KI-Werkzeuge im Entwicklungsteam freigeben.

10

Darf die Anwendung so überhaupt betrieben werden?

Eingaben gehen an die Schnittstelle eines Sprachmodells, die Datenbank liegt in der vorausgewählten Region, ein Analysewerkzeug lädt beim ersten Aufruf mit, aufgeschrieben hat das niemand. Technisch funktioniert die Anwendung tadellos, scheitert aber an der Freigabe durch Datenschutz, IT-Sicherheit oder Einkauf, meist kurz vor dem geplanten Rollout.

Erfassen Sie jeden Datenfluss als eine Zeile: welche Daten, welcher Dienst, welches Land, welcher Zweck, und ob ein Vertrag zur Auftragsverarbeitung besteht. Die Rechtslage beschreibt Wer haftet, wenn KI-generierter Code Schaden anrichtet?, die Kennzeichnung Muss ich KI in meiner Anwendung kennzeichnen?. Zum Datenschutz: DSGVO-konforme KI, zur Einordnung: EU AI Act Check.

11

Wie produktionsreif ist Ihr Prototyp?

Die Prüfliste fasst die sieben Dimensionen in 21 Punkten zusammen, jeder mit Ja oder Nein beantwortbar und kurz begründet. Ein offener Punkt ist kein Urteil über den Prototyp, sondern ein Eintrag auf der Arbeitsliste für den Weg in den Betrieb. Haken Sie nur ab, was heute nachweisbar zutrifft, nicht was geplant ist.

In welcher Reihenfolge Sie offene Punkte schließen

1. Von außen Ausnutzbares zuerst

   Schlüssel aus dem Client entfernen und ersetzen, Berechtigungen serverseitig durchsetzen.

2. Datenflüsse klären

   Bevor mehr echte Daten hineinkommen.

3. Sicherung und Wiederherstellung

   Erst mit geübtem Rückweg sind Umbauten am Datenmodell vertretbar.

4. Migrationen, Umgebungen und Tests

   Grundlage kontrollierter Änderungen.

5. Nachvollziehbarkeit und Überwachung

   Auditlog, zentrale Fehlererfassung und Benachrichtigung.

6. Übergabe

   Dokumentation, Zuständigkeiten und Einweisung.

12

Wann darf ein Prototyp einfach Prototyp bleiben?

Wenn er keine sensiblen Daten verarbeitet, kein Geschäftsprozess von ihm abhängt, ein Mensch jedes Ergebnis liest, bevor es wirkt, und sein Ende absehbar ist. Dann steht der Härtung kein Gegenwert gegenüber. Wichtig ist, dass diese Grenze bewusst gezogen wird, nicht still überschritten.

• Kleiner, bekannter Nutzerkreis: das eigene Team, nicht Kunden oder andere Abteilungen.
• Keine sensiblen Daten: Test- oder öffentliche Daten statt Personendaten oder Geschäftsgeheimnisse.
• Kein abhängiger Prozess: Fällt die Anwendung aus, arbeitet das Team auf dem alten Weg weiter.
• Mensch vor Wirkung: Ergebnisse werden gelesen, bevor sie eine E-Mail auslösen, eine Buchung ändern oder einen Kunden erreichen.
• Absehbares Ende: Die Anwendung beantwortet eine Frage und wird danach abgeschaltet oder ersetzt.

13

Nachbessern oder neu bauen?

Nachbessern lohnt sich, wenn der Code in Ihrer Hand ist, das Datenmodell die Fachlichkeit trägt, Berechtigungen an einer Stelle durchgesetzt werden und eine fremde Person den Code lesen kann. Fehlen mehrere dieser Punkte, ist ein Neuaufbau oft der geradere Weg. Der Prototyp dient dann als lebende Spezifikation.

Ein Neuaufbau heißt nicht, dass Arbeit verloren ist. Oberflächen, Abläufe, Texte und Sonderfälle sind die beste Spezifikation, die ein Entwicklungsteam bekommen kann.

Beide Wege enden bei einer Übergabe mit Quellcode, Dokumentation und benannter Verantwortung. Wer dafür Unterstützung sucht, klärt vorab die Auswahlfragen, auch die, wann kein externer Dienstleister nötig ist.

14

Welcher Beitrag der Serie passt zu Ihrer Frage?

• Haftung und Rechtslage

  Recht

  Wer haftet, wenn KI-generierter Code Schaden anrichtet?

• Freigabe durch die IT

  Übernahme

  Der Fachbereich hat eine App gebaut: was die IT vor der Übernahme prüft.

• App-Builder

  Werkzeuge

  Mit Lovable, Bolt oder Replit gebaut: typische offene Punkte, selbst prüfbar.

• Studienlage

  Belege

  Was Studien über die Qualität KI-generierten Codes zeigen, mit ihren Grenzen.

• Übergabe in den Regelbetrieb

  Übergabe

  Vom Proof of Concept in den Regelbetrieb: die Unterlagen am Tag der Übergabe.

• Softwareschätzung

  Aufwand

  Wie genau ist eine Schätzung?: der Schätzkorridor und was ihn verengt.

• Technische Schulden

  Wartbarkeit

  Technische Schulden in KI-generiertem Code erkennen, auch ohne Entwicklerrolle.

• Eigenbetrieb

  Betrieb

  Eine Anwendung im eigenen Haus betreiben: Überwachung, Sicherung, Aktualisierung.

• KI-Kennzeichnung

  Transparenz

  Muss ich KI in meiner Anwendung kennzeichnen?

• Workflows und Skripte

  Automatisierung

  Vom n8n-Workflow oder Streamlit-Skript zur betreibbaren Anwendung

• Leitplanken für KI-Werkzeuge

  Team

  KI-Werkzeuge im Entwicklungsteam freigeben: Berechtigungen, Prüfung, Geheimnisse.

• Dienstleister auswählen

  Auswahl

  Prototyp weiterentwickeln lassen: Fragen an Anbieter und wann Sie keinen brauchen.

iiterate Technologies GmbH, Sitz Adenau, Arbeitsort Remagen, entwickelt KI-Anwendungen und Individualsoftware, einschließlich Retrieval-Augmented Generation und lokalen, On-Premise betriebenen Sprachmodellen, mit Übergabe von Quellcode und Dokumentation. Überblick: Leistungen.