Iterare e correggere errori senza saper programmare

Nelle lezioni precedenti hai creato il tuo primo progetto, imparato a scrivere prompt efficaci e capito cosa genera Lovable dietro l'anteprima. Manca un ultimo tassello, forse il più temuto da chi non ha mai scritto codice: cosa fare quando qualcosa si rompe. La buona notizia, confermata dalla documentazione ufficiale, è che ogni passaggio è recuperabile.

## In breve

Su Lovable un errore non è mai definitivo: ogni modifica è salvata come versione a cui puoi tornare in qualsiasi momento. Il flusso consigliato dalla guida ufficiale al debug è: prova prima il pulsante Try to fix, poi descrivi il problema con precisione, poi, se l'errore persiste, passa alla modalità Plan per capire la causa reale prima di continuare a correggere alla cieca, e infine, se serve, torna a una versione precedente.

Che cos'è (e cosa NON è)

Iterare su Lovable significa costruire per piccoli passi, verificando ogni volta il risultato, sapendo di avere sempre una via di ritorno. Non è un processo che richiede di capire messaggi di errore tecnici o di leggere stack trace: puoi descrivere il problema come lo vede un utente ("la schermata diventa bianca quando apro questa pagina") e lasciare che sia Lovable a indagare nel codice.

Non significa nemmeno che correggere errori sia sempre immediato al primo tentativo. Alcuni bug richiedono un'indagine più profonda della causa, non solo un secondo tentativo di correzione automatica, ed è proprio per questo che esiste una modalità dedicata a investigare prima di agire.

Come funziona

Quando compare un errore di build mentre Lovable lavora, appare un pulsante Try to fix sulla scheda dell'attività: cliccandolo, Lovable analizza i log, individua il problema e tenta una correzione. L'account include 10 correzioni gratuite, condivise tra Try to fix e i suggerimenti della scansione di sicurezza, e ognuna torna disponibile 24 ore dopo l'uso. Oltre le 10, Try to fix continua a funzionare ma come un normale messaggio in chat, con relativo consumo di crediti.

Se l'errore persiste dopo uno o due tentativi con Try to fix, la guida al debug raccomanda di descrivere il problema con precisione invece di ripetere lo stesso prompt generico. Un prompt come "Non funziona niente, sistemalo!" non dà a Lovable nulla su cui lavorare; un prompt come "Lo schermo diventa bianco quando apro la pagina Progetti, e non riesco più a fare modifiche" indica sintomo e posizione esatta. Allegare uno screenshot, incollare il messaggio d'errore esatto dalla console del browser, o segnalare che "funzionava ieri" aiutano Lovable a restringere il campo.

Quando un fix "non tiene", o lo stesso errore ritorna in forme leggermente diverse, il passo successivo è passare alla modalità Plan: qui Lovable ragiona sul problema, ispeziona codice e log, ma non tocca nulla finché non approvi un piano. È il momento giusto per chiedere "qual è la causa profonda di questo errore?" invece di "come lo sistemo?", una correzione rapida può far sparire il sintomo senza risolvere la causa, e la causa può ripresentarsi altrove.

Se una serie di tentativi ha ingarbugliato il codice più di quanto lo abbia risolto, tornare indietro è spesso più veloce che continuare a districare. Ci sono due modi: Annulla ultima modifica, sotto l'ultima risposta di Lovable, che inverte in un clic solo l'ultimo cambiamento; oppure la cronologia versioni, che permette di tornare a un punto qualsiasi nel passato del progetto, o di modificare un tuo messaggio precedente e scegliere Revert and resend per ripartire da lì con un'istruzione diversa. Un dettaglio da non dimenticare: tornare a una versione precedente ripristina solo il codice, non i dati del database, record creati o cancellati dopo quella versione restano come sono.

## Perché conta

Il rischio concreto di procedere per tentativi alla cieca, un altro Try to fix, un altro prompt vago, senza capire cosa non ha funzionato la volta prima, è accumulare correzioni che nascondono il problema reale invece di risolverlo, consumando crediti a ogni giro. La documentazione lo dice esplicitamente: passare alla modalità Plan dopo uno o due tentativi falliti è di solito più veloce che riprovare ancora.

C'è anche un motivo più semplice, ma decisivo per chi non ha mai programmato: sapere che ogni passo è recuperabile toglie la paura di "rompere tutto per sempre", la stessa paura che spesso frena chi si avvicina per la prima volta a uno strumento come questo.

## Esempio lampante

### Contesto ipotetico

un'associazione culturale ha costruito su Lovable un sito con un modulo di iscrizione agli eventi. Dopo aver chiesto a Lovable di aggiungere un calendario con la disponibilità dei posti, il modulo di contatto smette di inviare le email di conferma.

INPUT. Il responsabile dell'associazione nota il problema e scrive in chat: "Da quando abbiamo aggiunto il calendario eventi, il modulo di contatto non invia più l'email di conferma. Prima funzionava. Puoi controllare cosa è cambiato?"

ANALISI. Un primo Try to fix non risolve il problema. Il responsabile passa alla modalità Plan e chiede: "Qual è la causa di questo errore? Mostrami il codice coinvolto e spiega cosa non va prima di proporre una correzione." Lovable individua che la nuova funzione del calendario condivide una configurazione con il sistema di invio email, modificata per errore durante l'ultima richiesta.

DECISIONE. Invece di chiedere una correzione rapida, il responsabile torna alla versione precedente all'introduzione del calendario tramite la cronologia versioni, e richiede la funzionalità di nuovo, questa volta in due passaggi separati: prima il calendario, poi, dopo aver verificato che il modulo contatto funzioni ancora, la sincronizzazione con la disponibilità dei posti.

OUTPUT. Il calendario viene ricostruito senza toccare la configurazione email, e il modulo di contatto torna a funzionare come prima, senza bisogno di rincorrere il sintomo una seconda volta.

Come farlo

1. Quando compare un errore, clicca Try to fix una o due volte: è gratuito nei limiti delle correzioni incluse nel tuo account.
2. Se l'errore persiste, descrivi il problema con precisione: cosa vedi, dove, cosa ti aspettavi invece. Allega uno screenshot o il messaggio d'errore se ne hai uno.
3. Se sai che qualcosa funzionava prima, dillo esplicitamente e chiedi a Lovable di controllare cosa è cambiato di recente.
4. Se il problema resiste ancora, passa alla modalità Plan e chiedi la causa profonda dell'errore prima di qualsiasi nuova correzione.
5. Se una correzione ne genera un'altra altrove, chiedi se le due cose sono collegate invece di trattarle come due bug separati.
6. Se il codice sembra ormai ingarbugliato, apri la cronologia versioni, individua l'ultimo stato funzionante e torna lì.
7. Dopo il ripristino, racconta a Lovable cosa hai fatto, così può riprendere con il contesto corretto invece di ripartire alla cieca.
8. Una volta risolto un bug complicato, chiedi a Lovable di riassumere causa e soluzione e di aggiungerlo alla knowledge del progetto: eviti di ripetere lo stesso errore in futuro.

## Errori comuni

Scrivere prompt di pura frustrazione invece che di descrizione

"Non funziona niente, sistema tutto!" non dà a Lovable alcuna informazione utilizzabile: meglio descrivere sintomo e posizione, per quanto il problema sia irritante.

Continuare a cliccare Try to fix o a riprovare lo stesso prompt vago

Dopo uno o due tentativi falliti, insistere raramente funziona meglio: è il segnale per passare alla modalità Plan e capire la causa.

Dimenticare che il ripristino di una versione non tocca il database

Tornare indietro nel codice non cancella né ripristina i dati creati nel frattempo: se il problema riguarda anche i dati, va gestito separatamente.

Fare piccole modifiche manuali al codice senza un piano chiaro

È possibile sui piani a pagamento, ma un errore introdotto a mano va corretto o revertito con la stessa attenzione di un errore generato in chat, non c'è una rete di sicurezza diversa.

Quando questo lavoro conta meno

Per un problema puramente estetico e isolato, un margine sbagliato, un colore che stona, non serve il flusso completo di debug: puoi selezionare l'elemento con la barra degli strumenti dell'anteprima e correggerlo direttamente. E se stai ancora nella primissima bozza di un progetto, rincorrere ogni piccola imperfezione con un'indagine approfondita spesso costa più tempo di quanto ne faccia risparmiare: a volte un ripristino rapido e una richiesta più chiara bastano.

## In sintesi

Su Lovable un errore non è mai un vicolo cieco: prova prima Try to fix, descrivi il problema con precisione se persiste, passa alla modalità Plan per capire la causa reale invece di correggere alla cieca, e torna a una versione precedente con la cronologia se serve ripartire da uno stato sicuro. L'unico dato che non torna indietro con il codice è quello nel database.

## Cosa imparare dopo

Con questa lezione si chiude il Modulo 2: sai creare un progetto, scrivere prompt efficaci, capire cosa genera Lovable e correggere gli errori senza saper programmare. Nel prossimo modulo entriamo in un tema diverso ma collegato: come pianificare con ChatGPT un progetto prima ancora di aprire Lovable, per arrivare al prompt iniziale con le idee già più chiare.

---

Vuoi provarlo?

Prova Lovable →

Link di affiliazione: se ti iscrivi da qui, ricevo una piccola commissione, a te non cambia nulla.