Vibe coding: cos’è, come funziona — e il capitolo che le guide saltano

Ogni strumento di vibe coding, qualunque sia il marketing, esegue una versione dello stesso ciclo: descrivi → genera → esegui → reagisci. Scrivi “una lista di cose da fare in cui le voci si ordinano per scadenza”; l’agente pianifica la modifica, scrive il codice in tutti i file che servono, compila il progetto, vede gli stessi errori che vedrebbe un programmatore, li corregge e ti mostra un risultato che gira. La frase successiva — “quelle scadute devono essere rosse” — ripete il ciclo su tutto ciò che è già costruito.

Tre cose sotto il cofano decidono se quel ciclo produce qualcosa di buono, e vale la pena conoscerle perché spiegano ogni differenza di qualità tra gli strumenti:

Contesto. L’agente può rispettare solo ciò che vede — le tue decisioni precedenti, il codice esistente, il sistema di design. Gli strumenti differiscono enormemente in quanto ricordano e in come scelgono cosa guardare.

Struttura. Chiedi le funzionalità una alla volta senza un piano e l’agente improvvisa un’architettura a ogni prompt — bene per una demo, male in un modo che si accumula fino alla funzionalità venti. Gli strumenti che decidono la struttura prima (o te la fanno decidere) producono codice che resta utilizzabile.

Verifica. I migliori strumenti non ti consegnano codice che dovrebbe funzionare: lo compilano, lo eseguono, lo testano e correggono i propri errori prima che tu veda qualcosa. La differenza tra “genera codice” e “consegna software” sta quasi tutta qui. Perfino Apple ha integrato agenti in Xcode che iterano tra build e correzioni.

Nota cosa manca da quella lista: la tua capacità di programmare. Ciò che il ciclo consuma davvero è la tua capacità di descrivere con precisione e reagire con onestà — ed è per questo che chi fa prodotto ci ha preso la mano più in fretta di chiunque altro. Scrivere cosa deve esistere, scenario per scenario, era già il lavoro.

Bravo, oggi: passare dall’idea al software funzionante in una seduta; iterare a basso costo (il “riprova” che costava il pomeriggio di uno sviluppatore ora costa una frase); le superfici standard di prodotto — schermate, moduli, liste, account, pagamenti su backend gestiti; e lasciare che la persona con il giudizio di prodotto costruisca direttamente invece di passare il messaggio attraverso strati.

Fallisce ancora, onestamente: il lavoro senza una specifica descrivibile (se non sai dire com’è “giusto”, non può saperlo nemmeno l’agente); gli algoritmi davvero nuovi e la programmazione di sistema insolita; salvare una grande base di codice vecchia che non ha costruito lui; e compensare l’assenza di pensiero di prodotto — un agente amplifica la qualità delle decisioni in entrambe le direzioni.

E un modo di fallire appartiene all’utente, non agli strumenti: confondere una demo con un prodotto. Qualsiasi strumento di questa pagina ti dà una demo impressionante in un pomeriggio. Un prodotto ha bisogno, in più, di una struttura che sopravviva alla funzionalità venti, account che funzionano, dati che restano, aggiornamenti che escono e codice che è tuo. Gli strumenti differiscono molto più in questa seconda metà che nella velocità della demo — e questo ci porta alla mappa.

La maggior parte delle liste ordina per velocità e rifinitura. Ordina invece per risultato — cosa diventa davvero ciò che descrivi — e l’intero mercato si divide in cinque gruppi. (Niente prezzi qui: cambiano, e ogni strumento pubblica i suoi. La domanda da fare è sempre la stessa: in quale piano posso pubblicare e portarmi via il codice?)

Builder web — risultato: app web. Lovable è il riferimento: app in React, sincronizzazione con GitHub, backend su Supabase. v0 di Vercel e Bolt giocano la stessa partita. Per prodotti web sono pubblicabili davvero; per prototipi di qualsiasi cosa sono eccellenti.

Strumenti di prototipazione — risultato: demo interattive usa e getta. Figma Make vive nell’ecosistema del design ed è onesto su ciò che è: fatto per esplorare, non per pubblicare.

Agenti di coding, porta la tua AI — risultato: ciò che riesci a guidare. Claude Code, Cline, Aider: agenti che lavorano in una base di codice vera con il tuo abbonamento o la tua chiave API. Massima libertà, nessun binario — ottimi per gli sviluppatori, e la strada in cui chi fa prodotto ha più bisogno della struttura che il gruppo successivo incorpora.

Builder mobile — risultato: app per telefono, con una biforcazione dentro il gruppo che quasi nessuna lista nomina. Rork, Vibecode e RapidNative generano React Native/Expo — JavaScript multipiattaforma che gira sul telefono attraverso un ponte, di solito a consumo di crediti. FlutterFlow assembla app Flutter in modo visuale. E Modaal (il nostro) genera codice nativo vero della piattaforma — Swift/SwiftUI per iPhone, Kotlin/Jetpack Compose per Android, entrambi da un solo progetto — con un piano che approvi prima di ogni funzionalità, il codice sul tuo Mac e prompt illimitati nel piano gratuito. Perché quella biforcazione conta è il capitolo successivo — perché è la parte del vibe coding che le guide continuano a saltare.

Ecco la strana lacuna in ogni guida al vibe coding pubblicata finora, in italiano come in inglese: spiegano il ciclo, elencano gli strumenti, mostrano una demo web — e si fermano al telefono. “Mobile” compare, quando compare, come “la tua app web funziona anche nel browser del telefono”. Per chi ha un prodotto che appartiene alla schermata iniziale di un telefono, quella frase nasconde i tre fatti che contano di più:

1. Un sito sul telefono non è un’app. Notifiche push, uso offline, fotocamera e sensori, widget, orologio e i pagamenti dentro gli store appartengono alle app vere. Il test rapido: i tuoi utenti arrivano cliccando un link o aprendo un’icona? Il confronto completo è nella nostra guida in inglese.

2. Impacchettare la tua app web fatta in vibe coding non attraversa il divario. La scorciatoia ovvia — infilare l’app web in un guscio a forma di app — si scontra con la revisione di Apple, che respinge con regolarità i gusci sottili intorno a un sito, e con tutti i limiti qui sopra, perché l’app resta un sito travestito.

3. Il divario ora si attraversa con la stessa competenza. Questo è ciò che è cambiato e che le guide non hanno ancora recepito: il ciclo di descrivere e iterare ora produce codice nativo vero. Nella versione di Modaal, il ciclo è di proposito più strutturato del vibe coding web — un documento di prodotto quando il progetto inizia e, per ogni funzionalità, l’agente scrive prima un piano che puoi leggere (scenari, approccio, rischi, test) e costruisce solo dopo che l’hai approvato; il risultato è Swift e Kotlin che uno sviluppatore della piattaforma riconosce, compilato e testato, sul tuo Mac. Vibe coding con l’improvvisazione sostituita dalle specifiche — esattamente la correzione che rende possibile un risultato da produzione.

La conseguenza pratica: la strada web e la strada mobile ora cominciano allo stesso modo — con una descrizione — e non devono più finire con una riscrittura. Hai validato qualcosa su Lovable che si è rivelato un’app? Il backend di solito sopravvive al trasloco; la parte davanti diventa un’app nativa vera, descritta nella stessa lingua che hai usato per il prototipo. Se invece parti da zero con un prodotto per telefono, la guida in nove passi percorre tutta la strada, vibe coding compreso, store compresi — e creare app con AI mostra il ciclo di un agente passo per passo.

La rampa d’ingresso di una seduta, nell’ordine che evita gli errori classici:

1. Scegli una cosa vera ma piccola. Non il prodotto di punta della tua azienda — uno strumento che vuoi tu. L’apprendimento sta nel ciclo, e le cose piccole girano più in fretta.

2. Scrivi cinque frasi prima di toccare qualsiasi strumento. Cosa fa; tre scenari “l’utente fa X, vede Y”; cosa la prima versione lascia fuori di proposito. È la differenza tra guidare e andare alla deriva — ed è l’abitudine che poi scala fino alla produzione.

3. Scegli lo strumento per il risultato, non per la demo. Prodotto web → builder web. Prodotto per telefono → strumento con risultato mobile (e decidi consapevolmente tra nativo e multipiattaforma). Stai solo esplorando → qualsiasi, senza sensi di colpa.

4. Reagisci con precisione. “Sbagliato” non insegna niente all’agente; “il pulsante va in basso, dove arriva il pollice” lo sistema in un passaggio. Dai istruzioni all’agente come le daresti a uno sviluppatore molto letterale e molto veloce — una competenza che chi fa prodotto ha già.

5. Itera presto su un telefono vero, se il prodotto è mobile — il simulatore è educato, il pollice è onesto.

Iniziare non costa nulla che conti: i builder web hanno piani gratuiti, e il piano gratuito di Modaal è un progetto completo con prompt illimitati; Pro costa 9 € al mese con pagamento annuale — i dettagli sono sulla pagina prezzi. Quanto costa davvero creare un’app su ogni strada, con ogni numero verificabile, è in quanto costa creare un’app. La risorsa scarsa è la stessa di sempre — sapere cosa costruire. Gli strumenti hanno solo smesso di nasconderlo.