App-Entwicklung in natürlicher Sprache für Nicht-Entwickler (Vibe Coding / KI-Low-Code)

Fachabteilungen und kleine Firmen warten Monate darauf, dass die IT einfache Werkzeuge baut: einen Angebotsrechner, eine Prüfcheckliste, ein Kundenportal. KI-App-Builder machen aus einer Beschreibung in einfacher Sprache eine lauffähige Anwendung mit Oberfläche, Datenbank, Login und Hosting und verfeinern sie im Gespräch. Prototypen dauern Stunden statt Wochen. Der Preis ist eine neue Risikoklasse: Generierte Apps gehen oft ohne Sicherheitsprüfung, Verantwortliche und Wartung in Betrieb, daher ist Governance wichtiger als gutes Prompten.

Problem & Nutzen

• Heute: Fachanwender nutzen Tabellen, Formulare und E-Mail-Ketten oder stellen sich bei der IT an. Klassische Low-Code- Plattformen (Power Apps, Mendix, OutSystems) erfordern weiterhin Schulung, und Agenturen sind für kleine Werkzeuge teuer.
• Nutzen durch KI: Der Begriff Vibe Coding (Anfang 2025 von Andrej Karpathy geprägt) beschreibt, von KI geschriebenen Code zu akzeptieren, indem man die Absicht beschreibt, statt den Code zu lesen [1]. Builder wie Lovable, Bolt, v0 und Replit Agent ergänzen Hosting, Datenbanken und Bereitstellung per Klick. Nutzen: schnelle Prototypen zur Überprüfung von Ideen, Ablösung tabellenbasierter Prozesse, interne Werkzeuge und Schatten-IT, die sichtbar und steuerbar wird.
• Die Belege sind gemischt: Von Herstellern betriebene Scans und Sicherheitsberatungen berichten wiederkehrende Schwächen in generierten Apps, insbesondere fehlende Zugriffsregeln der Datenbank und offengelegte Geheimnisse [5][6]. Diese Zahlen stammen aus nicht begutachteten Quellen mit unterschiedlichen Methoden, behandeln Sie genaue Prozentwerte daher nur als Anhaltspunkt. Für Nicht-Entwickler sollte keine unabhängige Produktivitätsstudie unterstellt werden; messen Sie im eigenen Piloten.

Varianten

• Prototyp / MVP für Gründer und Produktteams: Wegwerf- oder Investoren-Demo-Apps; später von Entwicklern neu gebaut.
• Interne Werkzeuge für Fachabteilungen: Dashboards, Freigabe-Apps, Dateneingabeformulare auf Unternehmensdaten (die wichtigste Unternehmensnutzung, meist innerhalb von Power Platform, Retool, Appsmith oder Ähnlichem).
• KI-erweitertes Low-Code: klassische Low-Code-Plattformen mit einem Copiloten, der Bildschirme, Tabellen und Abläufe aus einem Prompt baut (Microsoft Power Apps mit Copilot, Mendix, OutSystems) [3].
• Öffentlicher Sektor: bürgernahe Formulare und Vorgangswerkzeuge; strenge Vorgaben bei Vergabe, Barrierefreiheit und Datenschutz.
• Private Nutzung: Hobby-Apps, Familienorganisatoren, kleine Websites; geringes Risiko, aber auch hier nicht unbedacht personenbezogene Daten anderer verwenden.
• Professionelles „Vibe Coding" durch Entwickler: siehe CODE-001/CODE-002; hier liest der Nutzer den Code nicht.

So funktioniert es

1. Prompt / Skizze / Spezifikation
2. Planungsagent (zerlegt die Anfrage in Seiten, Datenmodell, Authentifizierung, Integrationen)
3. Codegenerierung (Frontend + Backend + Datenbankschema, typischerweise React/Next.js + Supabase/Postgres)
4. Build in der Sandbox & Live-Vorschau (Browser-Container)
5. Feedbackschleife mit dem Nutzer ("Tabelle sortierbar machen", "Genehmigungsschritt ergänzen")
6. automatisierte Prüfungen (Typprüfung, Tests, Sicherheitsscan, Geheimnis-Scan)
7. Freigabestufe durch Menschen (IT/Sicherheit bei allem mit echten Daten)
8. Bereitstellung (verwaltetes Hosting oder eigene Cloud) + Git-Sync + Monitoring

• Zentrale KI-Komponenten: ein auf Code spezialisiertes oder Reasoning-LLM, das als Agent Dateien bearbeitet, Befehle ausführt und Fehler liest; ein Bildmodell für Screenshots und Design-Vorgaben; Werkzeugzugriff auf Datenbanken, Authentifizierungsanbieter, Zahlungen und E-Mail über Konnektoren (oft MCP).
• Typische Stack-Entscheidungen des Werkzeugs: React-Frontend, Postgres-Backend (oft Supabase), serverlose Funktionen. Die Sicherheit hängt daher von korrekten Datenbankrichtlinien wie der zeilenbasierten Sicherheit (Row-Level Security) in Postgres ab [4].
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Verantwortliche bzw. der Verantwortliche genehmigt das Verhalten in der Vorschau; ein technischer Prüfer muss Datenmodell, Authentifizierung, Zugriffsregeln, Geheimnisse und Produktivbereitstellung freigeben. Diesen letzten Schritt niemals überspringen.

Datenaufbereitung

Benötigte Daten: eine klare Beschreibung des Prozesses, Beispieldaten (CSV, Excel), Screenshots oder Skizzen und die Datenquellen, an die die App angebunden werden soll. In einem KMU liegen diese in Excel-Dateien auf Laufwerken, in E-Mail-Anhängen, in ERP-/CRM-Exporten und auf Papierformularen. Dieser Anwendungsfall ist oft die Oberfläche für Daten, die noch in Tabellen liegen.

Typische Lücken: Excel-Tabellen mit verbundenen Zellen und Freitext, doppelte Kundendatensätze, keine eindeutigen Schlüssel, fehlende Felddefinitionen, personenbezogene Daten in Testbeispielen und unklare Zugriffsrechte dazu, wer welche Datensätze sehen darf.

Schritte der Aufbereitung: - Den Prozess und die Felder in einfachen Worten beschreiben; vereinbaren, was die App ersetzt (PREP-003 für Excel-Schattensysteme). - Die Tabelle in saubere Tabellen mit einer Zeile je Datensatz umbauen (PREP-011). - Personenbezogene Daten in Beispieldateien maskieren oder ersetzen (PREP-022). - Eine Regel zur Datenklassifizierung festlegen: welche Daten in einen KI-Builder dürfen (PREP-024). - Rollen und Rechte in der Zieldatenbank einrichten (PREP-023). - Werkzeuge: Excel/Power Query, CSV-Export, Supabase oder eine ähnliche Datenbank.

Grober Aufwandsanteil: gering, etwa 10–20 Prozent; der meiste Aufwand entfällt auf Tests und Zuständigkeiten. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: A. Ausgereifte KI-App-Builder (auch mit Hosting in der EU) zu KMU-Preisen decken interne Standardwerkzeuge ab; vorher Datenstandort und Ausstiegsmöglichkeiten prüfen.
• Großunternehmen: B. Apps müssen sich in interne Identitäten, Daten und Governance einfügen; daher passt ein eigener Builder auf Cloud-KI-Diensten mit Leitplanken und Prüfung besser als frei nutzbare SaaS.
• Entwickler: C. Open-Source-Agenten mit lokalen oder selbst betriebenen Modellen geben Kontrolle über Code, Daten und Kosten.
• Privat: A. Gehostete Builder oder lokale Apps sind für persönliche Projekte einfach und günstig.
• Öffentlicher Sektor: C. Souveräne EU-/deutsche Cloud oder Selbstbetrieb; A nur für zertifizierte Produkte.

Weg A — Kaufen (Standardsoftware; für die meisten KMU empfohlen)

• Prompt-to-App-Builder: Lovable (Schweden, EU-Unternehmen), Bolt.new (StackBlitz), Vercel v0, Replit Agent, Base44 (Wix), Google AI Studio Build Mode (Firebase Studio wird eingestellt, als Enddatum wird der 22. März 2027 genannt), dazu agentische IDEs (Cursor, Windsurf/Devin Desktop, Claude Code) für Anwender mit teilweise technischem Hintergrund. Prüfen Sie bei jedem Anbieter Hosting-Region, Auftragsverarbeitungsvertrag und Richtlinie zu Trainingsdaten.
• KI-Low-Code-Plattformen: Microsoft Power Apps (Copilot, EU Data Boundary verfügbar), Mendix (Siemens), OutSystems (Agent Workbench), Retool AI, Appsmith, Bubble. Bessere Governance, Rollen, Audit und Konnektoren als reine Prompt-Werkzeuge, was zu internen Werkzeugen mit Unternehmensdaten passt.
• A wählen, wenn: die App ein Prototyp oder ein internes Werkzeug mit geringem Risiko ist, niemand Infrastruktur betreiben möchte und eine Verantwortliche bzw. ein Verantwortlicher der IT den Datenzugriff vor dem Livegang freigibt.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Ein Agenten-SDK mit einem Spitzen-Codiermodell (Claude, GPT, Gemini, Mistral Codestral/Devstral, EU-Anbieter) hinter dem eigenen Frontend nutzen und in eine Unternehmensvorlage (freigegebenes Designsystem, Authentifizierung, Logging) statt in ein leeres Projekt generieren.
• Die Generierung in Sandboxes (E2B, Daytona, Container) ausführen, in Git einchecken, CI mit SAST und Secret-Scanning auslösen, über die eigene Pipeline bereitstellen. Modelle in EU-Regionen über Azure OpenAI, Google Vertex AI, AWS Bedrock oder Mistral.
• B wählen, wenn: Sie eine interne „App-Fabrik" mit Leitplanken und gebrandeten Vorlagen wollen.

Weg C — Selbst betreiben (Open Source)

• Werkzeuge: bolt.diy (Open-Source-Bolt, eigenes Modell mitbringen) [7], Dyad (lokaler App-Builder), OpenHands, Cline/Roo Code, Open-WebUI-Artefakte; Low-Code: Appsmith, Budibase, NocoBase, ToolJet, n8n für Workflow-Apps.
• Modelle: Open-Weight-Codemodelle wie Qwen3-Coder, Devstral, DeepSeek-Coder-Familie, GLM- und Kimi-Codiermodelle, bereitgestellt mit vLLM oder Ollama. Die Qualität bei Agentenaufgaben über mehrere Dateien liegt deutlich unter den Spitzen-APIs; mehr manuelle Korrektur ist zu erwarten.
• Hardware: HW3 für Coder-Modelle der 30-Mrd.-Klasse; HW4 für die größten offenen Modelle. Für einen Aufbau mit Qualitätsvorrang kombinieren die meisten Organisationen APIs mit Hosting in der EU mit selbst betriebener Laufzeitumgebung und eigenen Daten.

Weg D — Eigenes Training

Selten sinnvoll. Bessere Ergebnisse liefern kuratierte Vorlagen, Regeldateien und Komponentenbibliotheken. Feintuning ist nur für Anbieter relevant, die einen eigenen Builder bauen, oder für sehr spezielle interne DSLs.

Stand der Technik (2026)

• Agentische Builder planen, schreiben, führen aus, testen und korrigieren in einer Schleife, mit integrierter Datenbank, Authentifizierung und Bereitstellung; die meisten bieten außerdem Git-Synchronisierung, visuelles Bearbeiten, Design-Import und eingebautes Sicherheits-Scanning (zum Beispiel der Security-Scanning-Agent von Replit und Sicherheitsscans der Anbieter in Lovable) [5].
• Typische Fehlerbilder: fehlende oder falsche zeilenbasierte Sicherheit (Daten für jeden Besucher lesbar), Geheimnisse in Client- Bundles, Server-Aktionen ohne Autorisierungsprüfung, halluzinierte oder veraltete Pakete, brüchige Logik nach vielen Prompt-Iterationen und Agentenaktionen mit zu vielen Rechten. Dokumentierte Vorfälle umfassen einen Agenten, der 2025 während eines Code-Freezes eine Produktivdatenbank löschte [6].
• Wartungslücke: Apps, die niemand versteht, sind schwer zu patchen; „Prompt-Schulden" ersetzen technische Schulden.
• Standards: OWASP Top 10 und die OWASP-Leitlinien für LLM-Anwendungen liefern die Checkliste, die Scanner verwenden [8].
• Konvergenz: Klassische Low-Code-Anbieter ergänzen Prompt-Oberflächen, während Prompt-Builder Governance ergänzen (SSO, Rollen, Audit-Logs, private Bereitstellungen).

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework): CODE-001 IDE-Assistenten und CODE-002 Coding-Agenten teilen sich Modelle und Sandboxes; CODE-008 (UI aus Entwürfen) ist oft der erste Schritt; CODE-012 und CODE-013 liefern Konnektoren und Schemaentwurf.
• Qualitätsnetz: CODE-003 (KI-Code-Review) und CODE-004 (Testgenerierung) sollten vor der Produktion für jede generierte App laufen.
• Workflow-Seite: AGENT-002 (Back-Office-Automatisierung mit n8n/Power Automate) überschneidet sich stark; viele „Apps" lassen sich besser als Abläufe lösen.

Aufwand, Kosten & Kennzahlen

• Weg A: Stunden bis Tage für einen Prototyp; Abonnement pro Nutzer oder guthabenbasierte Nutzung, die bei vielen Prompt-Iterationen unvorhersehbar wachsen kann. Aufwand für Prüfung und Hosting kommt hinzu.
• Weg B: 1–3 Monate, um eine gesteuerte App-Fabrik mit Vorlagen, CI-Prüfungen und Bereitstellung aufzubauen.
• Weg C: 1–3 Monate plus GPU-Betrieb; geringeres Datenschutzrisiko, geringere Generierungsqualität.
• Kennzahlen: Zeit von der Idee bis zum funktionierenden Prototyp, Anteil der Prototypen, die in Produktion gehen, Sicherheitsbefunde je App vor der Freigabe, Anzahl der Apps ohne benannte Verantwortliche, Anteil der Nacharbeits-Prompts, abgelöste Schatten-IT-Werkzeuge.

Menschen & Veränderung

Beginnen Sie mit der Abteilungsleitung und den künftigen Endnutzern, denn sie definieren den Prozess und testen das Ergebnis. Beziehen Sie IT und IT-Sicherheit vor der ersten Bereitstellung ein: Hosting, Login, Backups, Geheimnisse und Sicherheitsscans für generierten Code (GUIDE-013). Die Geschäftsleitung entscheidet über den Umfang und die KI-Richtlinie (GUIDE-007), damit „Schatten-Apps" vermieden werden. Datenschutzbeauftragte(r) und Recht/Compliance prüfen die Datenflüsse und Anbieterbedingungen (GUIDE-005, GUIDE-010).

Betriebsrat: abhängig. Apps für interne Prozesse können Nutzeraktionen protokollieren oder Arbeit auswerten, was nach § 87 Abs. 1 Nr. 6 BetrVG objektiv zur Überwachung geeignet ist; § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, wenn Arbeitsprozesse mit KI gestaltet werden. Planen Sie ein frühes Gespräch und eine Vereinbarung zur Protokollierung. Öffentlicher Dienst: Personalrat.

Datenschutz: Personenbezogene Daten in Apps (Kunden, Beschäftigte) benötigen eine Rechtsgrundlage, einen AVV (Art. 28 DSGVO) mit dem Builder-Anbieter und eine DSFA, wenn Beschäftigtendaten oder sensible Daten ausgewertet werden.

KI-Kompetenz: Unterstützen Sie Citizen Developer mit Schulungen zu Testen, Sicherheitsgrundlagen und den Grenzen generierten Codes (GUIDE-006). Typische Sorgen: Die IT fürchtet nicht wartbare Apps, Beschäftigte fürchten Ersatz. Begegnen Sie dem mit einem App-Register, einer benannten Verantwortlichen bzw. einem benannten Verantwortlichen je App und IT-Prüfung vor dem produktiven Einsatz. Pilotieren Sie mit einem kleinen Werkzeug und einem motivierten Team (GUIDE-009, GUIDE-008); Menschen geben frei, was live geht.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Der Builder selbst hat normalerweise ein minimales Risiko, mit Pflichten zur KI-Kompetenz (Art. 4) für die Beschäftigten, die ihn nutzen [9]. Die Einstufung richtet sich nach der generierten App: Eine App, die Bewerber vorsortiert, Kredite bewertet oder kritische Infrastruktur steuert, kann hochriskant sein (Anhang III), und eine mit Chat oder generierten Inhalten unterliegt Transparenzpflichten (Art. 50).
• DSGVO: Keine personenbezogenen Daten ohne AVV in Prompts einfügen; generierte Apps, die personenbezogene Daten speichern, benötigen ein Verzeichnis von Verarbeitungstätigkeiten, Datenschutz durch Technikgestaltung (Art. 25), Sicherheit der Verarbeitung (Art. 32) und, wo erforderlich, eine DSFA. Fehlende Zugriffsregeln können eine meldepflichtige Verletzung des Schutzes personenbezogener Daten darstellen (Art. 33).
• Cyber Resilience Act und Produkthaftung: Als Produkte verkaufte oder verbreitete Apps können unter den CRA fallen; die neue Produkthaftungsrichtlinie erfasst Software.
• Lizenzen und geistiges Eigentum: Generierter Code kann Open-Source-Code ähneln; nutzen Sie Lizenzscans und klären Sie die Regelungen zum geistigen Eigentum in den Anbieterverträgen.
• Gegenmaßnahmen: jede KI-gebaute App mit Verantwortlichen und Datenklasse registrieren; in Prototypen nur synthetische Daten zulassen; verpflichtende Sicherheitsprüfung, RLS-/Autorisierungstests und Secret-Scanning vor der Produktion; Agenten-Zugangsdaten mit minimalen Rechten; kein Agentenzugriff auf Produktivdatenbanken; Backups und Rollback; SSO über den Identitätsanbieter des Unternehmens.

Erste Schritte

1. Eine kurze Richtlinie schreiben: was gebaut werden darf (intern, keine personenbezogenen Daten in Prototypen) und was eine IT-Prüfung braucht.
2. Eine Werkzeugklasse aus Weg A auswählen und einen zweiwöchigen Piloten mit 3 echten Anwendungsfällen durchführen, mit synthetischen oder anonymisierten Daten.
3. Eine Unternehmensvorlage (Designsystem, Authentifizierung, Logging) und eine Checkliste vor der Freigabe erstellen, die RLS, Geheimnisse und Abhängigkeiten abdeckt.
4. Git, CI, SAST und Secret-Scanning anbinden; die Bereitstellung in die Produktion über die IT laufen lassen.
5. Kennzahlen verfolgen und je App entscheiden: als Low-Code behalten, an Entwickler übergeben (CODE-001/002) oder abschalten.

Quellen

1. Wikipedia: Vibe coding (term origin, Karpathy 2025) - https://en.wikipedia.org/wiki/Vibe_coding
2. Lovable documentation and security overview - https://docs.lovable.dev
3. Microsoft Learn: Overview of Copilot in Power Apps - https://learn.microsoft.com/power-apps/maker/canvas-apps/ai-overview
4. Supabase docs: Row Level Security - https://supabase.com/docs/guides/database/postgres/row-level-security
5. State of Vibe-Coded Security Q2 2026 (vendor scanner report, indicative) - https://securityscanner.dev/reports/2026-q2
6. Vibe-coded app data exposure patterns tracker (secondary) - https://pranava0x0.github.io/vibe-coding-security/advisories/ongoing-vibe-platform-exposure.html
7. bolt.diy open-source project - https://github.com/stackblitz-labs/bolt.diy
8. OWASP Top 10 - https://owasp.org/www-project-top-ten/
9. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj