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 dein 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. Du wählst nie aus einem Dropdown; du beschreibst, was du willst, 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. Wolltest du eine Mobile-App, ein Shopify-Theme, ein Laravel-Backend oder ein Browser-Spiel, hattest du 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. Du wählst keine Plattform aus einem Dropdown. Du beschreibst einfach, was du willst, und VULK ermittelt, welcher Generierungsmodus zu aktivieren ist.

Bevor dein 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, willst du 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

Willst du die Erkennung überschreiben, sei 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.

React + Vite und Three.js nutzen Live-Web-Vorschauen. Flutter nutzt eine kompilierte Web-Vorschau. PHP und Python laufen in ihren eigenen Laufzeitumgebungen. React Native + Expo nutzt Expo Go für Vorschauen und Tests auf iOS und Android. Shopify-Themes und -Apps laufen in der Shopify-Umgebung mit den dafür vorgesehenen Werkzeugen.

Deployment – React veröffentlicht mit einem Klick auf dein-projekt.vulk.space. 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 zeigt, was „8 Plattformen" in der Praxis bedeutet: Generierung ist universell, und Vorschau- und Deploy-Pfade entsprechen dem, was jedes Ökosystem erwartet.

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 du einen KI-Code-Builder baust und 80 % deiner 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 deiner 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.