Come scrivere prompt per Lovable: guida in cinque fasi con esempi

Introduzione a Lovable e al concetto di prompt

Un prompt per Lovable è efficace quando comunica tre elementi fondamentali: cosa costruire, in quale punto dell’app e cosa lasciare invariato. Questa regola è riportata nella documentazione ufficiale per le modifiche e si applica anche al primo messaggio di un progetto, dove il “punto” diventa la schermata e il “non toccare” definisce il perimetro dell’app.

Lovable è un servizio che genera applicazioni web a partire da una descrizione scritta. L’utente indica le funzionalità richieste e il servizio crea interfaccia, modello dati e sistemi di autenticazione. L’app viene pubblicata con un clic su un dominio del tipo nome.lovable.app; nei piani a pagamento è possibile usare un dominio personalizzato. Il modello di pagamento è basato sui crediti, non sugli utenti, perciò la formulazione del prompt influisce sia sul risultato finale sia sulla fattura.

Le cinque fasi del metodo

Il percorso consigliato prevede cinque fasi, dal briefing iniziale alla correzione finale, con un cambiamento per volta. Le fasi si basano sulla documentazione di Lovable (guida ai prompt, libreria di prompt, modalità operative, istruzioni di progetto, crediti, sicurezza) e su un progetto di esempio: una piccola app per prenotare una sala prove musicale.

Fase 1 – Istruzioni di progetto e dati reali

Le Instructions sono un testo che Lovable conserva in ogni messaggio. Esistono a due livelli: a livello di workspace (condivise tra tutti i progetti) e a livello di progetto specifico. Ogni livello ha un limite di 10.000 caratteri; in caso di conflitto, prevalgono le istruzioni di progetto.

È consigliato scrivere le istruzioni come un onboarding per un nuovo sviluppatore: brevi, concrete e prive di narrazioni superflue. Le istruzioni contengono decisioni che non devono cambiare tra un messaggio e l’altro, come lingua, stile e regole di lavoro, seguite dal contenuto reale dell’app.

Esempio di istruzioni-progetto.txt per il progetto “Sala di prove”:

• Progetto: Sala di prove, app di prenotazione per una sala musicale di quartiere.
• Utenti: musicisti (prenotano) e un responsabile (approva, blocca fasce).
• Lingua dell’interfaccia: italiano. Orario in formato 24 h, fuso orario Europe/Madrid.
• Fasce: blocchi di 2 ore, dalle 10:00 alle 24:00, tutti i giorni.
• Stile: sobrio, sfondo chiaro, colore di accento verde foresta, nessuna animazione.
• Regole di lavoro: un cambiamento alla volta. Non modificare lo schema dati senza chiedere. Prima di toccare più di tre file, indica quali saranno modificati.
• Contenuti: testi realistici (strumenti, prezzi in euro), nessun segnaposto.

Fase 2 – Il primo prompt

Il primo messaggio stabilisce le basi e non deve essere affrettato. Deve nominare gli utenti, elencare le schermate, descrivere i dati da memorizzare e dichiarare le restrizioni. Dettagli estetici minori possono essere rimandati a fasi successive, poiché la guida ai prompt insiste su un cambiamento significativo per volta.

Esempio di primo-prompt.txt:

Crea un’app web per prenotare una sala prove musicale. Si chiama Sala di prove.\n\nChi la usa\n- Il musicista: vede il calendario, sceglie una fascia libera e invia la richiesta.\n- Il responsabile: vede tutte le richieste, le conferma o le rifiuta e blocca le fasce in cui la sala è chiusa.\n\nSchermate\n1. Calendario settimanale con fasce da 2 ore. Una fascia può essere libera, pendente, confermata o bloccata.\n2. Form di richiesta: nome della band, numero di persone, strumenti da collegare, note.\n3. Area del responsabile con le richieste pendenti, ordinate per data.\n\nDati\nUna prenotazione contiene data, fascia, nome della band, numero di persone, stato (pendente, confermata, rifiutata) e utente che l’ha creata.\n\nRestrizioni\n- Una fascia non può avere due prenotazioni confermate.\n- Il musicista vede solo le proprie richieste, il responsabile vede tutto.\n- Per ora nessun pagamento né email.\n\nPrima di costruire, fammi le domande necessarie per capire cosa voglio.

L’ultima riga è quasi letterale della documentazione: invita Lovable a porre domande prima di procedere.

Tre modalità operative di Lovable

Prima di scrivere un prompt è fondamentale sapere in quale modalità si sta operando. Lovable offre tre modalità distinte, ciascuna con uno scopo preciso.

Chat – Decidere cosa fare

La modalità Chat serve per discutere dell’app senza modificare codice, dati o file. Quando la conversazione richiede un cambiamento, appare la scheda “Start building”, che avvia la modalità Build. I messaggi in Chat hanno un costo minimo, tipicamente una frazione di credito, e la tariffa è valida fino al 31 ottobre 2026.

Plan – Definire come fare

In modalità Plan Lovable analizza il progetto e genera un piano strutturato, che può essere corretto e approvato prima di scrivere una sola riga di codice. Ogni messaggio costa 1 credito più il costo della ricerca effettuata dai sub‑agent.

Build – Modificare l’app

La modalità Build è quella predefinita. Consente di scrivere e verificare le modifiche, leggere i log, correggere errori e lavorare fino a 10 ore con un unico messaggio. Il consumo è variabile e non viene stimato prima dell’esecuzione; il pulsante di stop addebita solo il lavoro già svolto.

Il Plan è spesso sottovalutato. Per un cambiamento grande o rischioso la documentazione consiglia di passare prima da questa fase; lo stesso vale per prompt lunghi. Aggiungendo alla fine del prompt “fammi le domande necessarie prima di costruire”, Lovable risponderà con domande anziché indovinare. Ogni risposta costa un messaggio, ma evita costi più elevati derivanti da una ricostruzione su ipotesi errate.

Fase 3 – Componenti e interfaccia

Dopo aver definito il piano, si passa alla costruzione dei componenti UI. È importante usare il vocabolario specifico dell’interfaccia (card, badge, modal, toggle) anziché descrizioni vaghe. Inoltre, si specifica uno stile conciso (minimal, sobrio, premium) per guidare il modello.

Esempio di prompt per i componenti:

Crea le seguenti componenti UI per l’app Sala di prove:\n- Card per visualizzare le fasce del calendario, con badge di stato (libera, pendente, confermata, bloccata).\n- Modal per il modulo di richiesta, con campi: nome band, numero persone, strumenti, note.\n- Toggle per il responsabile per bloccare o sbloccare una fascia.\nStile: minimal, colori sobri, accento verde foresta.

Lovable risponde con il codice necessario, crea i file corrispondenti e aggiorna il progetto.

Fase 4 – Backend, sicurezza e scansione

Una volta impostata l’interfaccia, è necessario definire il backend, le regole di sicurezza e le eventuali scansioni. Lovable supporta la definizione di Row‑Level Security (RLS), la gestione di segreti e l’esecuzione di una security scan.

Esempio di prompt per il backend:

Aggiungi al backend le seguenti funzionalità:\n- Endpoint REST per creare, leggere, aggiornare e cancellare prenotazioni.\n- Regola RLS: i musicisti possono leggere e modificare solo le proprie prenotazioni; il responsabile può accedere a tutte.\n- Salva le chiavi API di eventuali servizi esterni in un secret chiamato “APIKEY”.\nEsegui una security scan e segnala eventuali vulnerabilità.

Ho riscontrato che due musicisti possono confermare la stessa fascia contemporaneamente. Per favore, correggi la logica RLS in modo che una sola prenotazione confermata sia permessa per fascia.