Introduzione a Lovable e al ruolo dei prompt

Lovable è un servizio che genera applicazioni web a partire da una descrizione scritta. L’utente fornisce una descrizione testuale e il servizio crea interfaccia, logiche di backend, login e persino la pubblicazione su un dominio del tipo nome.lovable.app. Nei piani a pagamento è possibile usare domini personalizzati.

Il modello di pricing è basato su crediti, non su utenti attivi. Per questo motivo il modo in cui si scrive il prompt influisce sia sul risultato finale sia sul consumo di crediti. Un prompt ben strutturato riduce gli errori, evita lavori inutili e, di conseguenza, spende meno crediti.

Le cinque fasi del metodo

Il metodo proposto da Pasquale Pillitteri si articola in cinque fasi, da affrontare in ordine sequenziale:

    • Fase 1 – Istruzioni di progetto: definire le regole generali e i dati reali.
    • Fase 2 – Primo prompt: descrivere utenti, schermate, dati e vincoli.
    • Fase 3 – Componenti: specificare gli elementi UI da costruire.
    • Fase 4 – Backend e sicurezza: impostare ruoli, segreti e scansioni di sicurezza.
    • Fase 5 – Correzione degli errori: testare, pianificare modifiche e, se necessario, revertire.

Ogni fase corrisponde a una singola modifica (una “modifica per volta”), evitando di sovraccaricare il modello con richieste troppo complesse.

Le tre modalità di Lovable: Chat, Plan, Build

Prima di scrivere un prompt è fondamentale capire in quale modalità si sta operando:

    • Chat: discussione concettuale, senza alterare codice o dati. Serve a definire cosa fare. I messaggi hanno un costo frazionario di credito.
    • Plan: il modello elabora un piano strutturato su come realizzare la richiesta. Costi: 1 credito per messaggio più il consumo dei sub‑agenti.
    • Build: modalità predefinita per scrivere e verificare le modifiche. Il costo è a consumo, con un limite di 10 ore per messaggio; il tasto “stop” addebita solo il lavoro già svolto.

Passare erroneamente da una modalità all’altra è la causa più comune di spreco di crediti. In particolare, la modalità Plan è sottovalutata ma cruciale per cambiamenti grandi o rischiosi.

Fase 1 – Istruzioni di progetto e dati veri

Le Instructions (istruzioni) sono un blocco di testo che Lovable legge prima di ogni messaggio. Esistono a due livelli:

    • Istruzioni a livello di workspace (condivise fra tutti i progetti).
    • Istruzioni specifiche per il singolo progetto.

Il limite è di 10.000 caratteri per livello; in caso di conflitto, prevalgono le istruzioni di progetto.

Le istruzioni dovrebbero assomigliare a un onboarding per un nuovo sviluppatore: brevi, precise, senza “lorem ipsum”. Qui si indicano lingua, stile, regole di lavoro e contenuti reali.

Esempio di istruzioni per il progetto “Sala Prove”

Progetto: Sala Prove, app di prenotazione per una sala prove musicale di quartiere.


Utenti: musicisti (prenotano) e un gestore (approva, blocca le fasce).


Lingua dell'interfaccia: italiano. Orari a 24 ore, fuso Europe/Rome.


Fasce: blocchi da 2 ore, dalle 10:00 alle 24:00, sette giorni su sette.


Stile: sobrio, sfondo chiaro, un solo colore d'accento (verde bosco), nessuna animazione.


Regole di lavoro: una modifica per volta. Non cambiare lo schema dei dati senza chiedermelo. Prima di toccare più di tre file dimmi quali.


Contenuti: nomi e testi realistici (strumenti, prezzi in euro), mai segnaposto.

Queste istruzioni forniscono a Lovable un “perimetro” chiaro: cosa può cambiare, cosa deve rimanere invariato e quali sono le convenzioni di design.

Fase 2 – Il primo prompt: le fondamenta

Il primo prompt è la pietra angolare del progetto. Deve includere:

    • Chi sono gli utenti e quali ruoli hanno.
    • Le schermate principali dell’app.
    • I dati che l’app deve memorizzare.
    • I vincoli di business.

È consigliabile utilizzare il vocabolario degli elementi UI (card, badge, modal, toggle) anziché descrizioni vaghe. Inoltre, si può indicare uno stile sintetico (minimal, sobrio, premium) per guidare il modello.

Esempio di primo prompt per “Sala Prove”

Crea un'app web per prenotare una sala prove musicale. Si chiama Sala Prove.



Chi la usa


  • Il musicista: vede il calendario, sceglie una fascia libera, invia la richiesta.
    • 

  • Il gestore: vede tutte le richieste, le conferma o le rifiuta, blocca le fasce in cui la sala è chiusa.
    • 



Schermate


1. Calendario settimanale con le fasce da 2 ore. Una fascia può essere libera, in attesa, confermata o bloccata.


2. Modulo di richiesta: nome della band, numero di persone, strumenti da collegare, note.


3. Area gestore con le richieste in attesa, ordinate per data.



Dati


Una prenotazione ha data, fascia, nome della band, numero di persone, stato (in attesa, confermata, rifiutata) e utente che l'ha creata.



Vincoli


  • Una fascia non può avere due prenotazioni confermate.
    • 

  • Il musicista vede solo le proprie richieste, il gestore vede tutto.
    • 

  • Per ora niente pagamenti e niente email.
    • 



Prima di costruire, fammi le domande che ti servono per capire che cosa voglio da questa app.

L’ultima riga è fondamentale: invita Lovable a porre domande di chiarimento, riducendo il rischio di interpretazioni errate.

Fase 3 – Definire i componenti UI

Dopo aver ottenuto le risposte alle domande preliminari, si passa alla definizione dei componenti. In questa fase si specifica, per ogni schermata, quali elementi UI devono essere presenti e come devono comportarsi.

Esempio di prompt per la schermata calendario:

Schermata: Calendario settimanale.


Componenti:


  • Card per ogni fascia da 2 ore, con stato visualizzato tramite badge (libera, in attesa, confermata, bloccata).
    • 

  • Toggle per passare alla visualizzazione del giorno successivo.
    • 

  • Modal di dettaglio fascia: mostra orario, stato e pulsante “Prenota” (solo se libera).
    • 

Stile: colori sobri, badge verde per “confermata”, rosso per “bloccata”.

Questa granularità permette a Lovable di generare codice più preciso e riduce la necessità di successive correzioni.

Fase 4 – Backend, ruoli e sicurezza

Una volta definita l’interfaccia, è il momento di impostare il backend. Si devono dichiarare:

    • Ruoli (musicista, gestore) e relative policy di accesso.
    • Segreti (API keys, token) da conservare in modo sicuro.
    • Scansioni di sicurezza (RLS – Row Level Security) per garantire che i musicisti vedano solo le proprie richieste.

Esempio di prompt per la sicurezza:

Abilita Row Level Security sulla tabella “prenotazioni”.


  • Musicista: può leggere e scrivere solo le righe dove “utente_id” corrisponde al proprio ID.
    • 

  • Gestore: può leggere e scrivere tutte le righe.
    • 

Crea un secret “JWT_SECRET” per l’autenticazione e aggiungi la verifica del token in ogni endpoint.

Esegui una scansione di sicurezza dopo la generazione del codice.

Il modello risponderà con il codice SQL necessario, i file di configurazione e, se necessario, suggerimenti per ulteriori miglioramenti.

Fase 5 – Correzione, test e revert

L’ultima fase è dedicata al debugging e al perfezionamento. Dopo ogni ciclo di Build, si controllano i log, si testano le funzionalità e si segnalano eventuali errori. Se qualcosa non funziona, si utilizza la modalità Chat per chiedere chiarimenti, oppure la modalità Plan per rivedere il piano di implementazione.

In caso di errore critico, è possibile effettuare un revert dell’intera modifica. Questa operazione consuma più crediti, perciò è consigliabile limitare le modifiche rischiose al passo Plan.

Esempio di correzione

Ho notato che il badge “bloccata” non cambia colore correttamente.


  • Controlla il CSS generato per il badge.
    • 

  • Verifica che la classe “badge-locked” sia associata al colore rosso.
    • 

  • Se manca, aggiungi la regola CSS corrispondente.
    •

Lovable risponde con le modifiche al file CSS e aggiorna la build.

Consigli pratici per ottimizzare i crediti

    • Usa la modalità Plan per richieste complesse o lunghe.
    • Inserisci sempre la frase “Fammi le domande che ti servono prima di costruire” nei prompt lunghi.
    • Limita le modifiche a una “una modifica per volta” come indicato nelle istruzioni di progetto.
    • Rivedi i log di Build prima di passare a nuove funzionalità; correggi subito gli errori.
    • Sfrutta i crediti gratuiti del piano gratuito (5 al giorno, 30 al mese) per sperimentare piccole modifiche.

Conclusioni

Scrivere prompt efficaci per Lovable richiede disciplina, chiarezza e una buona comprensione delle tre modalità di lavoro. Seguendo le cinque fasi – istruzioni di progetto, primo prompt, componenti UI, backend e correzioni – è possibile costruire applicazioni robuste, riducendo al minimo il consumo di crediti.

L’esempio della “Sala Prove” dimostra come un progetto reale possa essere gestito passo dopo passo, dalla definizione dei ruoli fino alla messa in sicurezza del backend. Con pratica e attenzione ai dettagli, il “vibe coding” su Lovable diventa un metodo affidabile per trasformare idee in app funzionanti con un investimento contenuto di risorse.