Cómo VULK maneja 8 plataformas desde una conversación

Actualizado el 18 de julio de 2026 — estados de vista previa corregidos a la realidad multi-runtime actual (microVMs de PHP + Python en vivo desde julio de 2026) y datos de la plataforma refrescados.

¿Cómo genera VULK para 8 plataformas desde una conversación?

La respuesta completa: antes de que tu prompt llegue a un modelo de IA, el sistema de detección de VULK lo escanea buscando señales específicas de plataforma — ponderando contexto, términos co-ocurrentes y patrones de intención, no solo palabras clave — y lo enruta a uno de ocho pipelines de generación dedicados: React + Vite, Flutter, React Native + Expo, temas Liquid de Shopify, apps de Shopify (Remix + App Bridge), Shopify Hydrogen, PHP/Laravel y juegos Three.js. Cada pipeline tiene su propio system prompt, lógica de estructura de archivos, estrategia de vista previa y ruta de despliegue. Nunca eliges de un desplegable; describes lo que quieres y el modo correcto se activa.

La demanda es medible y multiplataforma: entre 11.355 proyectos generados, la demanda histórica de prompts incluye 381 peticiones de Flutter, 310 de backends Node, 246 de Python, 213 de React Native/Expo y 174 de PHP — junto a la mayoría React (datos de la plataforma VULK, julio de 2026). El mundo del desarrollo es mucho más grande que React, y VULK se construyó para todo él.

¿Por qué nadie más quiso resolver esto?

Cuando empecé a construir VULK, todos los constructores de código con IA del mercado generaban lo mismo: una app React con Tailwind CSS. Bolt, v0, Lovable, Replit — todos. Si querías una app móvil, un tema de Shopify, un backend Laravel o un juego de navegador, no tenías suerte. Toda la categoría había decidido que "la IA construye apps" significaba "la IA construye apps React".

Eso nunca tuvo sentido para mí. Hay 1,7 millones de comerciantes de Shopify que necesitan temas personalizados. Flutter tiene más de un millón de desarrolladores activos construyendo apps móviles nativas. PHP sigue impulsando la mayor parte del lado servidor de la web. Three.js es el estándar del 3D en navegador. Son comunidades masivas, y estaban siendo completamente ignoradas.

Así que construí VULK para manejarlas todas. Una conversación, 8 plataformas:

1. React + Vite — Web apps con Tailwind CSS
2. Flutter — Apps móviles nativas con Clean Architecture
3. React Native + Expo — Móvil multiplataforma con NativeWind
4. Temas Liquid de Shopify — Online Store 2.0
5. Apps de Shopify — Remix + App Bridge + Polaris
6. Shopify Hydrogen — Storefronts de comercio headless
7. PHP / Laravel — Aplicaciones del lado servidor
8. Three.js — Juegos de navegador con motores de físicas

¿Cómo funciona la detección realmente por debajo?

Aquí está la parte que más curiosidad despierta. No eliges una plataforma de un desplegable. Simplemente describes lo que quieres, y VULK determina qué modo de generación activar.

Antes de que tu prompt llegue al modelo de IA, nuestro sistema de detección lo escanea buscando señales específicas de plataforma. No son coincidencias ingenuas de palabras clave — el sistema pondera contexto, términos co-ocurrentes y patrones de intención. Por ejemplo, "construye una app con pantallas y una barra de navegación inferior" señala móvil, no web. "Construye una tienda con variantes de producto y colecciones" señala Shopify, no e-commerce genérico.

La detección sigue un orden de prioridad estricto, y hay una razón: Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React (por defecto).

¿Por qué este orden? Porque la especificidad debe ganar. Si alguien menciona "app de Shopify", esa es una intención muy precisa — quiere una app de comerciante basada en Remix con App Bridge y Polaris, no una web app genérica que se integre con Shopify. Cuanto más especializada la plataforma, mayor su prioridad. React está al fondo porque es el comodín. Si nada más coincide, probablemente quieres una web app, y React + Vite es el mejor default para eso.

Esto activa cada modo:

• Flutter — "app móvil", "Flutter", "iOS y Android", "app nativa", "APK", "pantallas" (no "páginas")
• React Native — "React Native", "Expo", "móvil multiplataforma"
• Shopify Liquid — "tema de Shopify", "tienda online", "tienda Shopify"
• Apps de Shopify — "app de Shopify", "app para comerciantes", "plugin de Shopify"
• Shopify Hydrogen — "Hydrogen", "Shopify headless", "Storefront API"
• PHP/Laravel — "PHP", "Laravel", "WordPress", "lado servidor"
• Three.js — "juego", "3D", "Three.js", "juego de navegador"
• React — Todo lo demás

Si alguna vez quieres anular la detección, sé explícito. "Construye esto en Flutter" o "Usa React para esto" siempre gana.

¿Qué hace realmente diferente a cada modo?

Esto no es solo cambiar una plantilla por otra. Cada plataforma tiene su propio pipeline de generación con cuatro capas distintas, y acertar cada una llevó meses de ingeniería.

Ingeniería de prompts — Cada plataforma tiene su propio system prompt que enseña al modelo de IA las convenciones, patrones y mejores prácticas de ese stack. Solo el prompt de Shopify supera las 2.100 líneas. Cubre sintaxis Liquid, esquemas de secciones, compatibilidad con Dawn, patrones de metafields y las docenas de peculiaridades que separan un tema funcional de uno que se rompe en el editor de temas de Shopify. El prompt de Flutter impone Clean Architecture. El de Three.js maneja bucles de juego, detección de colisiones e integración de físicas. No puedes decirle a un modelo "escribe código Shopify" y esperar buen output. Necesitas ingeniería de prompts profunda y específica de plataforma.

Estructura de archivos — React genera src/components/ y src/pages/. Flutter genera lib/models/, lib/screens/ y lib/services/. Shopify genera sections/, templates/ y assets/. Laravel genera app/Http/Controllers/, resources/views/ y database/migrations/. Cada framework tiene expectativas sobre dónde vive el código, y violarlas hace el output inútil para desarrolladores experimentados.

Estrategia de vista previa — Aquí la ingeniería se pone genuinamente dura, y aquí insisto en la honestidad sobre qué corre en vivo y qué no. React + Vite (y Three.js) corren en microVMs Firecracker — máquinas virtuales aisladas con hot-reload, levantadas de un pool caliente. Flutter usa un pipeline build-then-serve: el proyecto se compila con flutter build web en un servicio de build dedicado y se sirve en ~20–60 segundos por build. Desde julio de 2026, PHP y Python también corren como runtimes microVM en vivo — php-fpm 8.3 + nginx para apps tipo Laravel/WordPress, y servidores uvicorn/Flask/Django/Streamlit autodetectados para Python. React Native y los tres modos Shopify no tienen vista previa en vivo — RN usa el bundler Metro (una vista previa en el editor está en desarrollo), y el código Shopify requiere el runtime propio de Shopify, así que el editor muestra instrucciones de configuración honestas en vez de un render falso.

Despliegue — React se despliega a Cloudflare Pages con un clic. Flutter exporta archivos APK/AAB reales con andamiaje de envío a tiendas. Los temas de Shopify se suben vía la Shopify CLI. Los proyectos Laravel y Python se exportan como directorios completos listos para cualquier host.

¿Dónde está cada plataforma hoy?

Esa tabla es la versión honesta de "8 plataformas". La generación es universal; la vista previa en vivo cubre los stacks ejecutables en web; las rutas de despliegue coinciden con lo que cada ecosistema realmente requiere.

¿Cómo se compara VULK con otros constructores de IA?

Voy a ser directo sobre cómo es el panorama competitivo, porque creo que los desarrolladores merecen transparencia:

Esto no es incremental. Es categórico. La brecha existe porque la generación multiplataforma es genuinamente difícil de construir. Cada plataforma nueva multiplica el trabajo de ingeniería: nueva ingeniería de prompts, nueva lógica de estructura de archivos, nueva infraestructura de vista previa, nuevo pipeline de despliegue, nueva superficie de pruebas. Y cada plataforma tiene que producir un output que un desarrollador experimentado de ese ecosistema considere aceptable. Un desarrollador Flutter detecta al instante un proyecto Dart mal estructurado. Un desarrollador Shopify sabrá si las plantillas Liquid no siguen los patrones de Online Store 2.0.

¿Por qué nadie más hace esto?

Lo he pensado mucho, y creo que la respuesta es directa: la economía no parece atractiva a primera vista.

Si construyes un constructor de código con IA y el 80% de tus usuarios quiere apps React, la decisión de negocio obvia es hacer la generación React muy buena e ignorar todo lo demás. Añadir soporte de Flutter son meses de ingeniería para una minoría de tu base de usuarios. El ROI por plataforma decrece.

Pero ese análisis pasa por alto algo: esas comunidades más pequeñas tienen casi cero alternativas. Un desarrollador React puede elegir entre cinco o seis constructores de IA. Un desarrollador Shopify que quiera generar un tema personalizado con IA tiene una opción. Un desarrollador Flutter que quiera ir de prompt a APK tiene una opción. El foso competitivo en esas categorías es enorme precisamente porque nadie más quiere invertir en construirlo. Y la tabla de demanda de arriba — 381 prompts de Flutter, 246 de Python, 213 de RN, 174 de PHP y subiendo — muestra que esos "nichos" suman una parte sustancial de lo que los builders realmente piden.