Wie VULK 8 Plattformen aus einer Konversation bedient

Aktualisiert am 18. Juli 2026 — Preview-Status auf die aktuelle Multi-Runtime-Realität korrigiert (PHP + Python microVMs live seit Juli 2026) und Plattformdaten aufgefrischt.

Wie generiert VULK für 8 Plattformen aus einer Konversation?

Die vollständige Antwort: Bevor Ihr Prompt ein KI-Modell erreicht, scannt VULKs Erkennungssystem ihn auf plattformspezifische Signale — es gewichtet Kontext, gemeinsam auftretende Begriffe und Absichtsmuster, nicht nur Keywords — und routet ihn zu einer von acht dedizierten Generierungs-Pipelines: React + Vite, Flutter, React Native + Expo, Shopify-Liquid-Themes, Shopify-Apps (Remix + App Bridge), Shopify Hydrogen, PHP/Laravel und Three.js-Spiele. Jede Pipeline hat ihren eigenen System-Prompt, ihre eigene Dateistruktur-Logik, Preview-Strategie und ihren Deployment-Pfad. Sie wählen nie aus einem Dropdown; Sie beschreiben, was Sie wollen, und der richtige Modus aktiviert sich.

Die Nachfrage ist messbar multi-plattform: Über 11.355 generierte Projekte hinweg umfasst die All-Time-Prompt-Nachfrage 381 Anfragen für Flutter, 310 für Node-Backends, 246 für Python, 213 für React Native/Expo und 174 für PHP — neben der React-Mehrheit (VULK-Plattformdaten, Juli 2026). Die Entwicklerwelt ist weit größer als React, und VULK wurde für sie alle gebaut.

Warum wollte das sonst niemand lösen?

Als ich VULK zu bauen begann, generierte jeder KI-Code-Builder auf dem Markt dasselbe: eine React-App mit Tailwind CSS. Bolt, v0, Lovable, Replit — alle. Wollten Sie eine Mobile-App, ein Shopify-Theme, ein Laravel-Backend oder ein Browser-Spiel, hatten Sie Pech. Die gesamte Kategorie hatte entschieden, dass „KI baut Apps" bedeutet: „KI baut React-Apps."

Das ergab für mich nie Sinn. Es gibt 1,7 Millionen Shopify-Händler, die eigene Themes brauchen. Flutter hat über eine Million aktive Entwickler, die native Mobile-Apps bauen. PHP treibt weiterhin den Großteil der Server-Seite des Webs an. Three.js ist der Standard für browserbasiertes 3D. Das sind riesige Communities — und sie wurden komplett ignoriert.

Also baute ich VULK für sie alle. Eine Konversation, 8 Plattformen:

1. React + Vite — Web-Apps mit Tailwind CSS
2. Flutter — Native Mobile-Apps mit Clean Architecture
3. React Native + Expo — Cross-Platform-Mobile mit NativeWind
4. Shopify Liquid Themes — Online Store 2.0
5. Shopify Apps — Remix + App Bridge + Polaris
6. Shopify Hydrogen — Headless-Commerce-Storefronts
7. PHP / Laravel — Server-seitige Anwendungen
8. Three.js — Browser-Spiele mit Physik-Engines

Wie funktioniert die Erkennung tatsächlich unter der Haube?

Hier ist der Teil, der die meisten Menschen interessiert. Sie wählen keine Plattform aus einem Dropdown. Sie beschreiben einfach, was Sie wollen, und VULK ermittelt, welcher Generierungsmodus zu aktivieren ist.

Bevor Ihr Prompt das KI-Modell erreicht, scannt unser Erkennungssystem ihn auf plattformspezifische Signale. Das sind keine naiven Keyword-Matches — das System gewichtet Kontext, gemeinsam auftretende Begriffe und Absichtsmuster. Beispiel: „Baue eine App mit Screens und einer Bottom-Navigation-Bar" signalisiert Mobile, nicht Web. „Baue einen Store mit Produktvarianten und Collections" signalisiert Shopify, nicht generisches E-Commerce.

Die Erkennung folgt einer strikten Prioritätsordnung, und dafür gibt es einen Grund: Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React (Default).

Warum diese Reihenfolge? Weil Spezifität gewinnen sollte. Erwähnt jemand „Shopify app", ist das eine sehr präzise Absicht — er will eine Remix-basierte Händler-App mit App Bridge und Polaris, keine generische Web-App mit Shopify-Anbindung. Je spezialisierter die Plattform, desto höher ihre Priorität. React sitzt am Ende, weil es der Catch-all ist. Matcht nichts anderes, wollen Sie vermutlich eine Web-App, und React + Vite ist dafür der beste Default.

Das triggert die einzelnen Modi:

• Flutter — „mobile app", „Flutter", „iOS und Android", „native app", „APK", „screens" (nicht „pages")
• React Native — „React Native", „Expo", „cross-platform mobile"
• Shopify Liquid — „Shopify theme", „online store", „Shopify store"
• Shopify Apps — „Shopify app", „app for merchants", „Shopify plugin"
• Shopify Hydrogen — „Hydrogen", „headless Shopify", „Storefront API"
• PHP/Laravel — „PHP", „Laravel", „WordPress", „server-side"
• Three.js — „game", „3D", „Three.js", „browser game"
• React — Alles andere

Wollen Sie die Erkennung überschreiben, seien Sie explizit. „Baue das in Flutter" oder „Nutze React dafür" gewinnt immer.

Was macht jeden Modus tatsächlich anders?

Das ist nicht bloß der Tausch eines Templates gegen ein anderes. Jede Plattform hat ihre eigene Generierungs-Pipeline mit vier eigenständigen Ebenen, und jede richtig hinzubekommen kostete Monate an Engineering.

Prompt Engineering — Jede Plattform hat ihren eigenen System-Prompt, der dem KI-Modell die Konventionen, Muster und Best Practices dieses Stacks beibringt. Allein der Shopify-Prompt umfasst über 2.100 Zeilen. Er deckt Liquid-Syntax, Section-Schemas, Dawn-Kompatibilität, Metafield-Muster und die Dutzenden Eigenheiten ab, die ein funktionierendes Theme von einem trennen, das im Shopify-Theme-Editor bricht. Der Flutter-Prompt erzwingt Clean Architecture. Der Three.js-Prompt behandelt Game-Loops, Kollisionserkennung und Physik-Integration. Man kann einem Modell nicht einfach „schreib Shopify-Code" sagen und guten Output erwarten. Man braucht tiefes, plattformspezifisches Prompt Engineering.

Dateistruktur — React generiert src/components/ und src/pages/. Flutter generiert lib/models/, lib/screens/ und lib/services/. Shopify generiert sections/, templates/ und assets/. Laravel generiert app/Http/Controllers/, resources/views/ und database/migrations/. Jedes Framework hat Erwartungen, wo Code lebt — sie zu verletzen macht den Output für erfahrene Entwickler nutzlos.

Preview-Strategie — Hier wird das Engineering richtig hart, und hier bestehe ich auf Ehrlichkeit darüber, was live läuft und was nicht. React + Vite (und Three.js) laufen in Firecracker-microVMs — isolierte virtuelle Maschinen mit Hot-Reload, aus einem Warm-Pool gestartet. Flutter nutzt eine Build-then-Serve-Pipeline: Das Projekt wird mit flutter build web auf einem dedizierten Build-Service kompiliert und in ~20–60 Sekunden pro Build serviert. Seit Juli 2026 laufen PHP und Python ebenfalls als Live-microVM-Runtimes — php-fpm 8.3 + nginx für Laravel/WordPress-artige Apps, und automatisch erkannte uvicorn/Flask/Django/Streamlit-Server für Python. React Native und die drei Shopify-Modi haben keine Live-Vorschau — RN ist Metro-gebündelt (eine In-Editor-Vorschau ist in Entwicklung), und Shopify-Code braucht Shopifys eigene Runtime; der Editor zeigt ehrliche Setup-Anleitungen statt eines gefälschten Renders.

Deployment — React deployt mit einem Klick zu Cloudflare Pages. Flutter exportiert echte APK/AAB-Dateien mit Store-Submission-Gerüst. Shopify-Themes werden per Shopify CLI gepusht. Laravel- und Python-Projekte exportieren als vollständige Projektverzeichnisse für jeden Host.

Wo steht jede Plattform heute?

Diese Tabelle ist die ehrliche Version von „8 Plattformen". Generierung ist universell; Live-Vorschau deckt die web-lauffähigen Stacks ab; Deploy-Pfade entsprechen dem, was jedes Ökosystem tatsächlich verlangt.

Wie schneidet VULK gegen andere KI-Builder ab?

Ich bin direkt dazu, wie die Wettbewerbslandschaft aussieht, weil ich glaube, dass Entwickler Transparenz verdienen:

Das ist nicht inkrementell. Es ist kategorisch. Die Lücke existiert, weil Multi-Plattform-Generierung genuin schwer zu bauen ist. Jede neue Plattform multipliziert die Engineering-Arbeit: neues Prompt Engineering, neue Dateistruktur-Logik, neue Preview-Infrastruktur, neue Deployment-Pipeline, neue Testfläche. Und jede Plattform muss Output produzieren, den ein erfahrener Entwickler dieses Ökosystems akzeptabel findet. Ein Flutter-Entwickler erkennt ein schlecht strukturiertes Dart-Projekt sofort. Ein Shopify-Entwickler merkt, ob die Liquid-Templates nicht den Online-Store-2.0-Mustern folgen.

Warum macht das sonst niemand?

Darüber habe ich viel nachgedacht, und ich glaube, die Antwort ist simpel: Die Ökonomie sieht auf den ersten Blick unattraktiv aus.

Wenn Sie einen KI-Code-Builder bauen und 80% Ihrer Nutzer React-Apps wollen, ist die offensichtliche Geschäftsentscheidung, React-Generierung richtig gut zu machen und alles andere zu ignorieren. Flutter-Support bedeutet Monate Engineering für eine Minderheit Ihrer Nutzerbasis. Der ROI pro Plattform sinkt.

Aber diese Analyse übersieht: Diese kleineren Communities haben fast null Alternativen. Ein React-Entwickler kann zwischen fünf oder sechs KI-Buildern wählen. Ein Shopify-Entwickler, der ein eigenes Theme mit KI generieren will, hat eine Option. Ein Flutter-Entwickler, der von Prompt zu APK will, hat eine Option. Der Wettbewerbsgraben in diesen Kategorien ist enorm — genau weil niemand sonst investieren will. Und die Nachfragetabelle oben — 381 Flutter-, 246 Python-, 213 RN-, 174 PHP-Prompts und steigend — zeigt: Diese „Nischen" summieren sich zu einem substanziellen Anteil dessen, was Builder tatsächlich verlangen.