Ship Fast, Stay Safe: KI-Prototyping, das die Produktion übersteht

Vom vibe-coded Demo bis produktionsreif — die Disziplin dazwischen. Basierend auf dem Supabase-Webinar mit Zimo (Brthrs Agency), Harry (Imaginary Space) und Victor (Performanze).

Es gibt ein GIF, mit dem Zimo von Brthrs Agency seine Demo eröffnet hat. Ein Zug, der mit voller Geschwindigkeit fährt — aber nicht auf Schienen. Einfach quer über offenes Gelände, funktional und chaotisch. So sehen die meisten vibe-coded Prototypen nach sechs Wochen in Produktion aus.

Die KI-Build-Welle ist real. Zeiten, die früher sechs Monate und ein echtes Ingenieurteam bedeuteten, bedeuten jetzt einen Nachmittag und einen Lovable-Account. Das ist kein Hype — es ist die operative Realität für Agenturen, Gründer und CTOs aus diesem Webinar. Aber Geschwindigkeit ohne Architektur ist nur stillschweigend ansammelnde Schuld, bis etwas vor einem Kunden bricht.

Dasselbe Muster zeigt sich im KI-gestützten Kundenservice. Fin oder irgendeinen KI-Agenten auf einer fragmentierten Wissensdatenbank zu deployen, produziert dasselbe Ergebnis — schneller Start, frühes Plateau, wachsende Frustration. Die Tools sind unterschiedlich. Der Fehlermodus ist identisch.

Hier ist, was diejenigen anders machen, die KI-Systeme tatsächlich in Produktion liefern.

Die 80/20-Regel, von der niemand spricht

Zimos Framework war direkt: "Ich verbringe 80 % meiner Zeit mit Planen. Die restlichen 20 % mit Implementierung."

Das ist das Gegenteil der Art, wie die meisten Gründer KI-Tools angehen. Sie öffnen Lovable, tippen eine Feature-Anfrage ein, und akzeptieren das Ergebnis. Das Ergebnis ist das, was er die "durchschnittliche Intelligenz" nennt — das Modell macht Pattern-Matching gegen seine Trainingsdaten und gibt Ihnen die generischste Version von dem, worum Sie gebeten haben.

Der Beschleuniger ist Context Engineering, nicht Prompt-Kunst. Der Unterschied zählt. Prompting ist die Formulierung. Context Engineering ist, die KI mit dem richtigen Umfeld zu laden — Benutzerabsicht, technische Dokumentation, Geschäftsbeschränkungen — bevor sie eine einzige Codezeile berührt.

Sein spezifischer Workflow: relevante Supabase-Dokumentation vor der-herausziehen, das Modell die richtige Implementierungsansatz suchen lassen, einen strukturierten Plan generieren, dann einen zweiten Durchlauf machen mit "Sie sind ein Junior-Ingenieur, beauftragt, diesen Plan zu implementieren — überprüfen Sie die Dokumentation und melden Sie jede Frage, die Sie haben." Diese Schleife fängt architektonische Probleme, bevor sie Produktionsprobleme werden.

Der Schlüssel-Erkenntnis: Dokumentation ist Kontext. Die Supabase-Doku ist für Menschen lesbar, aber auch für KI. Sie in die Planungsphase zu füttern, bedeutet, dass das Ergebnis die wahren Best Practices widerspiegelt, nicht statistische Durchschnitte.

"Langsam ist flüssig, flüssig ist schnell. Es dauert lange, darüber nachzudenken, was wir wirklich bauen wollen — aber wenn wir all das als Kontext an die KI geben, können wir in der Implementierung sehr schnell sein."

Lovable hat das inzwischen zum Standard gemacht. Der Plan Mode (Februar 2026) zeigt Ihnen einen strukturierten Bauplan, bevor überhaupt Code generiert wird. Der Chat Mode (Juni 2026) geht weiter — Sie starten jedes neue Projekt in einer Planungs-Conversation, und Lovable stellt klärende Fragen zu Ihrer Zielgruppe, Ihren Features und technischen Einschränkungen, bevor es eine Codezeile berührt. KI-Fehler, die die meisten Credits kosten, gehen fast immer auf einen vagen Prompt zurück. Das Tool nudges Sie jetzt, das von Anfang an zu korrigieren.

Projekte, die hängenbleiben, sind fast immer die, die die Planungsphase übersprungen haben. Lovable hat diese Reibung jetzt per Design eingebaut.

Sicherheit ist kein späteres Problem

Jeder Panelist kam unabhängig darauf zurück: Sicherheitsarbeit nach dem Launch ist zehnmal schwieriger als Sicherheit, die in den Plan eingebaut ist.

Wir haben jetzt eine dokumentierte Fallstudie dafür, was passiert, wenn das nicht der Fall ist. CVE-2025-48757, Mitte 2025 offengelegt, hat über 170 Lovable-Apps in Produktion aufgrund fehlender RLS-Policies exponiert. Der Supabase-Anonymous-Key ist by Design im clientseitigen JavaScript eingebettet — ohne RLS kann jeder, der die Browser-DevTools öffnet, direkt Ihre gesamte Datenbank abfragen. E-Mails, Zahlungsaufzeichnungen, API-Keys, persönliche Daten — alles zugänglich ohne Authentifizierung. Eine Q1-2026-Evaluation von über 200 vibe-coded Apps fand, dass 91,5 % mindestens eine auf KI-generierten Code zurückzuführende Schwachstelle enthielten. "Das S bei Vibe Coding steht für Security" ist in jedem Entwicklerforum zum Running Gag geworden. Der Vorfall ist kein Argument gegen die Nutzung von Lovable — es ist ein Argument dafür, die Sicherheits-Checkliste als nicht verhandelbar zu behandeln, bevor eine App echte Nutzer berührt.

Die OWASP Top 10 bleiben die Baseline. Vor KI-Tools lieferten 80 % der Apps eine Form von Rollen-basiertem Zugriffskontroll-Schwachstelle. Diese Zahl hat sich mit KI nicht verbessert — sie ist schwieriger zu erkennen geworden, weil der Code richtig aussieht, bis man ihn adversarial befragt.

Drei Dinge kamen ständig auf:

RLS-Policies sind Ihre letzte Verteidigungslinie. Supabase Row Level Security ist kein Nice-to-Have — es ist der Mechanismus, der verhindert, dass Ihr KI-Agent versehentlich Kundendaten zurückgibt, auf die er nicht zugreifen sollte. Lovable konfiguriert grundlegende RLS-Policies automatisch, aber Sie müssen sie vor dem Go-Live überprüfen und verschärfen. Es ist viel einfacher, Policies zu ändern, bevor echte Daten existieren.

Speichern Sie niemals Secrets im Frontend-Code. Das ist grundlegend, aber es erwischt mehr vibe-coded Projekte als jedes andere Problem. API-Keys, Stripe-Secrets, alles Sensibles — das gehört in Server-Funktionen, nicht in Ihre React-Komponenten, wo jeder Browser-Inspektor sie lesen kann. Secrets im Frontend-Code sollten als kompromittiert betrachtet werden.

Prompt Injection ist ein KI-spezifischer Angriffsvektor, den die meisten übersehen. Wenn Sie einen Chatbot oder ein KI-Interface bauen — sei es in einer Lovable-App oder einem Fin-Deployment — versuchen Sie aktiv, es zu brechen. Finden Sie Listen adversarialer Prompts, fügen Sie sie ein, und beobachten Sie, was Ihre KI zurückgibt. Die Frage ist nicht nur, ob Ihre Datenbank sicher ist — sondern ob Ihre KI manipuliert werden kann, um Daten zu extrahieren oder Aktionen auszuführen, die sie nicht sollte.

"Es ist nicht, dass Vibe Coding von Natur aus unsicher ist. Es ist der Reflex, sich daran zu erinnern zu überprüfen — und nicht einfach zu vibe coden und die Sicherheit zu vergessen."

KI-unterstützte Sicherheits-Reviews sind mittlerweile so zugänglich, dass es keine Entschuldigung gibt, sie zu überspringen. Lovable startet jetzt bei jedem Publish automatisch einen Baseline-Security-Scan — abdeckend RLS-Policies, Datenbank-Configs und bekannte Fehlkonfigurationen in etwa 10–15 Sekunden. Ein Deep Scan ist auf Anfrage verfügbar und analysiert Ihre gesamte Codebase in etwa 3 Minuten. Workspace-Admins auf Business- und Enterprise-Plänen können Publishing bei kritischen Findings blockieren. Der Supabase Security Advisor hebt Datenbank-Level-Probleme direkt im Dashboard hervor. Keines dieser Tools ersetzt Pentests für ernsthafte Produktionssysteme — aber sie haben den Boden seit dem CVE deutlich angehoben.

Die Selfware-Verschiebung

Victors Framework bei Performanze führte ein Konzept ein, das einer näheren Betrachtung wert ist: Selfware — Software, die um die Workflows, Daten und Betriebsabläufe eines Unternehmens herum gebaut wird, statt von einem generischen SaaS angepasst zu werden.

Der Pitch für Kunden ist einfach. Sie benutzen ein Menü in Salesforce. Sie zahlen für das vollständige Produkt, locked in ihreren Roadmap, ausgeschlossen von Features, die sie für Enterprise-Tiers reservieren. Mit der aktuellen KI-Build-Umgebung gibt es eine lebensfähige Alternative: Ihren Stack besitzen, Ihre Daten besitzen, die Roadmap besitzen.

Die Einwand schreibt sich von selbst — Sie können Salesforce nicht ersetzen. Victor stimmt zu. Das ist nicht der Anspruch. Der Anspruch ist, dass für eine wachsende Zahl von Workflows die Kosten-Nutzen-Rechnung sich geändert hat. Sie kaufen keinen Salesforce-Konkurrenten. Sie kaufen ein Tool, das genau das tut, was Ihr Unternehmen tut, mit Ihren Daten in Supabase, skalierbar in Ihrem Tempo.

Sein Beispiel: Eine HR-Plattform mit konfigurierbaren KI-Assessments, gebaut als vollständige Alternative zu einem generischen Enterprise-Copiloten, mit integriertem SharePoint- und Outlook-Kontext. Die Kundendaten bleiben in PostgreSQL-Tabellen, die er kontrolliert. Features werden in Wochen geliefert. Keine Lizenz-Eskalation.

Die Infrastruktur-Wahl ist zentral für dieses Modell. Alles konsolidiert in Supabase — strukturierte Daten in PostgreSQL, Embeddings im Vector Store, Dateien in Storage-Buckets, Auth out-of-the-box. Die Konsolidierung ist keine ästhetische Präferenz. Es ist das, was text-to-SQL-Queries und RAG-Retrieval tatsächlich konsistent funktionieren lässt.

"KI ist ein Spiegel von uns selbst. Wenn Sie guten Kontext einspeisen, bekommen Sie gute Ergebnisse. Wenn Sie schlechten Kontext einspeisen, wird sie tendieren, den Durchschnitt — oder darunter — zu bilden."

Die gleiche Logik gilt für KI-Agenten im Kundenservice. Fins Auflösungsrate wird nicht davon bestimmt, wie Sie es an Tag eins konfigurieren — sie wird von der Qualität und Struktur der zugrunde liegenden Wissensdatenbank bestimmt. Die Content-Architektur muss immer vor der KI-Konfiguration kommen.

Was sich ändert, wenn man für echte Nutzer baut

Die Produktionslücke ist größtenteils unsichtbar, bis sie es nicht mehr ist. Einige spezifische Fehlermuster, die wiederholt auftraten:

Degradation des Kontextfensters. Über Konversationen hinweg sinkt die Qualität der Modell-Anweisungen. Deshalb nutzt Victors Team nicht dasselbe Modell für jede Aufgabe — komplexe Planungsaufgaben bekommen Opus, einfachere Operationen kleinere, günstigere Modelle. Die Grenzen Ihres Kontextfensters zu kennen ist eine grundlegende Infrastrukturüberlegung, die die meisten Vibe-Coder komplett überspringen.

Erwartungsdrift bei Skalierung. Ein Prototyp, der für einen Nutzer gut performt, verhält sich anders bei hunderten gleichzeitigen Anfragen auf eine schlecht indizierte Datenbank. Der Supabase Performance Advisor hebt diese Probleme vor dem Launch hervor. Die meisten Leute schauen nicht hin.

Das Sichtbarkeitsproblem. Harry formulierte es am besten: "Kunden sehen am Anfang schnellen, sichtbaren Fortschritt. Wenn wir zum Backend-Sicherheitsarbeit übergehen, hören sie auf, Ergebnisse zu sehen. Sie denken, Sie hätten verlangsamt." Explizit zu sein über die unsichtbare Arbeit und warum sie nicht verhandelbar ist, gehört zur Lieferung dazu.

Das Prinzip dahinter

Die Build-Zeit hat sich komprimiert. Die architektonischen Anforderungen nicht. Die Teams, die gerade gewinnen, sind die, die KI als Kraftverstärker für sorgfältiges Denken behandeln, nicht als Ersatz dafür.

Das ist dasselbe Prinzip, das beide Seiten dessen prägt, was wir bei dot2.solutions tun. Wenn wir Produktions-Apps mit Lovable bauen, kommt die Planungsphase — Datenmodell, Nutzertypen, Integrationsbeschränkungen, Sicherheitsposture — vor dem ersten Prompt. Wenn wir Fin für Kundenservice-Teams deployen, kommt die Wissensarchitektur vor der KI-Konfiguration. Ein Lovable-Projekt ohne ein kohärentes Datenmodell blockiert genauso wie ein Fin-Deployment ohne strukturierte Wissensdatenbank. Es ist auch erwähnenswert, dass seit Mai 2026 neue Lovable-Projekte standardmäßig auf TanStack Start mit SSR umsteigen — dieselbe Stack wie diese Seite, und das richtige Fundament für alles, was crawlbar, schnell und produktionsbereit vom ersten Tag sein muss.

Content vor Konfiguration. Architektur vor Code. Die Tools haben sich radikal geändert. Dieser Teil, nicht.

Verwandte Lektüre: Lovable SEO Reality Check, Intercom Fin vs. maßgeschneiderte KI-Chatbots, und mit einem Intercom-Berater in der Schweiz arbeiten.