Otto fasi tra il tuo prompt e un'app funzionante.
VULK non è una singola chiamata LLM. È una pipeline deterministica che classifica, pianifica, instrada, genera, valida, ripara, fa preview e deploy — con il modello giusto scelto per ogni fase e un loop di autofixer quando un passaggio fallisce.
- 01
Classificatore veloce
Classificare il prompt
Che superficie vuole l'utente? Web app, mobile (Flutter), tema Shopify, sito marketing, tool interno? Un classificatore piccolo e veloce sceglie la pipeline giusta prima che la generazione inizi — la superficie sbagliata è la modalità di fallimento più costosa.
- 02
Planner pesante (Claude Opus / Gemini Pro)
Pianificare l'architettura
Un planner espande il prompt in una lista di feature, schema, mappa delle rotte, decisioni di modello e criteri di accettazione. Il piano è ciò che l'utente vede per primo scrollando; nulla viene generato prima di chiudere il piano.
- 03
Router (deterministico)
Instradare i modelli per fase
Ogni passaggio successivo riceve il modello che rende meglio in esso secondo i nostri benchmark interni: un modello veloce scrive lo scaffolding, un modello pesante scrive la logica di business, un modello specializzato scrive 3D / Flutter / Liquid. Cambiamo il routing quando arriva un modello migliore.
- 04
Generatore (modello per fase)
Generare il codice
Ogni file è emesso come azione XML strutturata — VULK non fa mai semplice streaming di codice libero. L'XML ci permette di tracciare quali file esistono, validare prima della scrittura e modificare chirurgicamente dopo senza rigenerare l'intero progetto.
- 05
Validatore (regole + modello piccolo)
Validare contro il build
Type-check, risoluzione delle dipendenze, build di vite, sanity dello schema. L'analisi statica è sincrona — non ti mostriamo un preview che non compila. I fallimenti vanno all'autofixer; i successi vanno dritti al preview.
- 06
Riparatore (modello pesante)
Autofix dei fallimenti
Quando il validatore trova un errore, l'autofixer legge l'output reale dell'errore e modifica chirurgicamente i file in errore. Itera fino al verde o a un cap rigido — e segnala onestamente quando non può aggiustare qualcosa invece di fingere di averlo fatto.
- 07
Avviare il preview microVM
Una microVM Firecracker viene provisioned in pochi secondi: kernel, rootfs, dipendenze, il progetto. Il preview live è reale, non un iframe sandboxed — la tua app generata gira nello stesso modo in cui girerà in produzione.
- 08
Deploy dove l'app vive
Un click manda su Cloudflare Pages, Vercel, o la tua infrastruttura. I build mobile (Flutter) passano a EAS / pipeline native con la metadata corretta per la submission a App Store + Play.
Quale modello gira in quale fase.
Il routing è deterministico e cambia quando cambiano i benchmark. Gli identificatori specifici dei modelli si spostano settimanalmente — la policy qui sotto è stabile.
| Fase | Classe di modello | Perché |
|---|---|---|
| Classificazione | Piccolo / veloce | Economico, sub-secondo |
| Pianificazione | Ragionamento pesante | One-shot, contesto più lungo |
| Generazione (web) | Pesante, ottimizzato per codice | Regole di output più strette |
| Generazione (mobile) | Specializzato Flutter | Correttezza del widget-tree > brevità |
| Generazione (3D) | Specializzato Three.js | Richiede geometria / shader corretti |
| Edit (chirurgico) | Pesante, ottimizzato per codice | Finestra di diff più piccola, il file deve restare vivo |
| Riparazione | Ragionamento pesante | Legge errori di compilazione come input |
| Riassunto | Piccolo / veloce | Recap del piano, note finali |
Cosa succede quando la generazione va storta.
La maggior parte degli app builder IA fa streaming di codice, lo restituisce e spera. VULK assume che la prima generazione fallirà almeno una volta e tratta il recupero come un passaggio di prima classe.
- Controlli statici prima. TypeScript, regole eslint bloccanti, risoluzione delle dipendenze. Più economico che far girare il build.
- Build del progetto. Vite per il web, Flutter analyzer per il mobile, theme-check per Liquid. Il build vero, non una simulazione.
- Cattura dell'errore letterale. Il fixer legge l'output reale del compilatore, non un riassunto parafrasato.
- Edit chirurgico. Il modello di riparazione emette un'azione vulkEdit che tocca solo i file in errore — la rigenerazione completa è l'eccezione, non la regola.
- Loop fino al verde o al cap. Massimo tre passi di riparazione. Dopodiché facciamo emergere onestamente il fallimento con l'errore e un pulsante per "rigenerare da zero".
Vuoi sentirlo?
Il modo più rapido per capire la pipeline è vederla girare. Inizia con un trial pagato di 7 giorni — crediti completi del piano, cancelli quando vuoi.
Ultima revisione: 30 aprile 2026