Como o VULK lida com 8 plataformas a partir de uma conversa

Atualizado a 18 de julho de 2026 — estados de pré-visualização corrigidos para a realidade multi-runtime atual (microVMs de PHP + Python ao vivo desde julho de 2026) e dados da plataforma refrescados.

Como gera o VULK para 8 plataformas a partir de uma conversa?

A resposta completa: antes de o teu prompt chegar a um modelo de IA, o sistema de deteção do VULK examina-o à procura de sinais específicos de plataforma — pesando contexto, termos co-ocorrentes e padrões de intenção, não apenas palavras-chave — e encaminha-o para um de oito pipelines de geração dedicados: React + Vite, Flutter, React Native + Expo, temas Liquid Shopify, apps Shopify (Remix + App Bridge), Shopify Hydrogen, PHP/Laravel e jogos Three.js. Cada pipeline tem o seu próprio system prompt, lógica de estrutura de ficheiros, estratégia de pré-visualização e caminho de deploy. Nunca escolhes de um dropdown; descreves o que queres e o modo certo ativa-se.

A procura é mensuravelmente multi-plataforma: em 11.355 projetos gerados, a procura acumulada de prompts inclui 381 pedidos de Flutter, 310 de backends Node, 246 de Python, 213 de React Native/Expo e 174 de PHP — a par da maioria React (dados da plataforma VULK, julho de 2026). O mundo do desenvolvimento é muito maior do que React, e o VULK foi construído para ele todo.

Porque é que mais ninguém quis resolver isto?

Quando comecei a construir o VULK, todos os construtores de código com IA no mercado geravam a mesma coisa: uma app React com Tailwind CSS. Bolt, v0, Lovable, Replit — todos. Se querias uma app mobile, um tema Shopify, um backend Laravel ou um jogo de browser, azar. A categoria inteira tinha decidido que "a IA constrói apps" significava "a IA constrói apps React".

Isso nunca fez sentido para mim. Há 1,7 milhões de merchants Shopify que precisam de temas personalizados. O Flutter tem mais de um milhão de developers ativos a construir apps mobile nativas. O PHP continua a alimentar a maior parte do lado servidor da web. O Three.js é o standard do 3D no browser. São comunidades massivas, e estavam a ser completamente ignoradas.

Por isso construí o VULK para lidar com todas. Uma conversa, 8 plataformas:

1. React + Vite — Web apps com Tailwind CSS
2. Flutter — Apps mobile nativas com Clean Architecture
3. React Native + Expo — Mobile cross-platform com NativeWind
4. Temas Liquid Shopify — Online Store 2.0
5. Apps Shopify — Remix + App Bridge + Polaris
6. Shopify Hydrogen — Storefronts de comércio headless
7. PHP / Laravel — Aplicações server-side
8. Three.js — Jogos de browser com motores de física

Como funciona a deteção realmente por baixo do capô?

Aqui está a parte que desperta mais curiosidade. Não escolhes uma plataforma de um dropdown. Descreves simplesmente o que queres, e o VULK determina que modo de geração ativar.

Antes de o prompt chegar ao modelo de IA, o nosso sistema de deteção examina-o à procura de sinais específicos de plataforma. Não são correspondências ingénuas de palavras-chave — o sistema pesa contexto, termos co-ocorrentes e padrões de intenção. Por exemplo, "constrói uma app com ecrãs e uma barra de navegação em baixo" sinaliza mobile, não web. "Constrói uma loja com variantes de produto e coleções" sinaliza Shopify, não e-commerce genérico.

A deteção segue uma ordem de prioridade rigorosa, e há uma razão: Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React (por omissão).

Porquê esta ordem? Porque a especificidade deve ganhar. Se alguém menciona "app Shopify", essa é uma intenção muito precisa — quer uma app de merchant baseada em Remix com App Bridge e Polaris, não uma web app genérica que se integra com a Shopify. Quanto mais especializada a plataforma, mais alta a prioridade. O React está no fundo porque é o apanha-tudo. Se nada mais corresponder, provavelmente queres uma web app, e React + Vite é o melhor default para isso.

Isto ativa cada modo:

• Flutter — "app mobile", "Flutter", "iOS e Android", "app nativa", "APK", "ecrãs" (não "páginas")
• React Native — "React Native", "Expo", "mobile cross-platform"
• Shopify Liquid — "tema Shopify", "loja online", "loja Shopify"
• Apps Shopify — "app Shopify", "app para merchants", "plugin Shopify"
• Shopify Hydrogen — "Hydrogen", "Shopify headless", "Storefront API"
• PHP/Laravel — "PHP", "Laravel", "WordPress", "server-side"
• Three.js — "jogo", "3D", "Three.js", "jogo de browser"
• React — Tudo o resto

Se quiseres sobrepor-te à deteção, sê explícito. "Constrói isto em Flutter" ou "Usa React para isto" ganha sempre.

O que torna cada modo realmente diferente?

Isto não é só trocar um template por outro. Cada plataforma tem o seu próprio pipeline de geração com quatro camadas distintas, e acertar cada uma levou meses de engenharia.

Engenharia de prompts — Cada plataforma tem o seu próprio system prompt que ensina ao modelo de IA as convenções, padrões e boas práticas desse stack. Só o prompt Shopify ultrapassa as 2.100 linhas. Cobre sintaxe Liquid, schemas de secções, compatibilidade com o Dawn, padrões de metafields e as dezenas de subtilezas que separam um tema funcional de um que se parte no editor de temas da Shopify. O prompt Flutter impõe Clean Architecture. O prompt Three.js trata de game loops, deteção de colisões e integração de física. Não podes dizer a um modelo "escreve código Shopify" e esperar bom output. É preciso engenharia de prompts profunda e específica de plataforma.

Estrutura de ficheiros — O React gera src/components/ e src/pages/. O Flutter gera lib/models/, lib/screens/ e lib/services/. A Shopify gera sections/, templates/ e assets/. O Laravel gera app/Http/Controllers/, resources/views/ e database/migrations/. Cada framework tem expectativas sobre onde o código vive, e violá-las torna o output inútil para developers experientes.

Estratégia de pré-visualização — É aqui que a engenharia fica genuinamente dura, e é aqui que insisto na honestidade sobre o que corre ao vivo e o que não corre. React + Vite (e Three.js) correm em microVMs Firecracker — máquinas virtuais isoladas com hot-reload, arrancadas de um pool quente. O Flutter usa um pipeline build-then-serve: o projeto é compilado com flutter build web num serviço de build dedicado e servido em ~20–60 segundos por build. Desde julho de 2026, PHP e Python também correm como runtimes microVM ao vivo — php-fpm 8.3 + nginx para apps tipo Laravel/WordPress, e servidores uvicorn/Flask/Django/Streamlit auto-detetados para Python. O React Native e os três modos Shopify não têm pré-visualização ao vivo — o RN é empacotado pelo Metro (uma pré-visualização no editor está em desenvolvimento), e o código Shopify exige o runtime da própria Shopify: o editor mostra instruções de configuração honestas em vez de um render falso.

Deployment — O React faz deploy para o Cloudflare Pages com um clique. O Flutter exporta ficheiros APK/AAB reais com andaime de submissão às lojas. Os temas Shopify são enviados via Shopify CLI. Os projetos Laravel e Python exportam como diretorias completas prontas para qualquer host.

Onde está cada plataforma hoje?

Essa tabela é a versão honesta de "8 plataformas". A geração é universal; a pré-visualização ao vivo cobre os stacks executáveis na web; os caminhos de deploy correspondem ao que cada ecossistema realmente exige.

Como se compara o VULK com outros construtores de IA?

Vou ser direto sobre o panorama competitivo, porque acredito que os developers merecem transparência:

Isto não é incremental. É categórico. A diferença existe porque a geração multi-plataforma é genuinamente difícil de construir. Cada nova plataforma multiplica o trabalho de engenharia: nova engenharia de prompts, nova lógica de estrutura de ficheiros, nova infraestrutura de pré-visualização, novo pipeline de deploy, nova superfície de testes. E cada plataforma tem de produzir output que um developer experiente desse ecossistema considere aceitável. Um developer Flutter deteta imediatamente um projeto Dart mal estruturado. Um developer Shopify saberá se os templates Liquid não seguem os padrões Online Store 2.0.

Porque é que mais ninguém faz isto?

Pensei muito nisto, e acredito que a resposta é simples: a economia não parece atraente à primeira vista.

Se estás a construir um construtor de código com IA e 80% dos teus utilizadores querem apps React, a decisão de negócio óbvia é tornar a geração React excelente e ignorar tudo o resto. Adicionar suporte Flutter são meses de engenharia para uma minoria da base de utilizadores. O ROI por plataforma decresce.

Mas essa análise falha uma coisa: essas comunidades mais pequenas têm quase zero alternativas. Um developer React pode escolher entre cinco ou seis construtores de IA. Um developer Shopify que queira gerar um tema personalizado com IA tem uma opção. Um developer Flutter que queira ir do prompt ao APK tem uma opção. O fosso competitivo nessas categorias é enorme precisamente porque mais ninguém quer investir em construí-lo. E a tabela de procura acima — 381 prompts Flutter, 246 Python, 213 RN, 174 PHP e a crescer — mostra que esses "nichos" somam uma fatia substancial do que os builders realmente pedem.