Come far evolvere un'app creata con l'AI senza romperla

Per far evolvere un'app creata con l'AI senza romperla, cambia una cosa per prompt, verificala nell'anteprima e salva un checkpoint prima di passare oltre. Descrivi ciò che vedi invece di ciò che pensi faccia il codice, pianifica le modifiche grandi prima di costruirle e, quando una modifica va storta, torna all'ultima versione funzionante invece di chiedere all'AI di correggere la propria correzione.

La prima versione di un'app spesso prende forma in pochi minuti. La parte difficile è la cinquantesima modifica, quando ogni nuovo prompt rischia di rompere qualcosa che già funzionava. Questa guida descrive il ciclo che lo evita.

Il ciclo di iterazione

1. Scegli una modifica. Una funzione, un bug, una pagina.
2. Descrivila in termini di ciò che l'utente vede e fa.
3. Per le modifiche grandi, pianifica prima. Chiedi un piano, leggilo, poi costruisci.
4. Verifica il risultato nell'anteprima: la modifica e i flussi vicini.
5. Salva un checkpoint o un commit.
6. Ripeti.

Ogni passaggio serve a mantenere le modifiche piccole e reversibili.

Passo 1: tieni una lista breve

Prima di scrivere il prompt, annota cosa vuoi cambiare, in ordine di importanza. Ti evita di inviare un paragrafo con dieci desideri in un solo messaggio, e ti dà modo di dire "non adesso" alle idee che arrivano a metà lavoro.

Se una modifica è grande, scomponila. "Aggiungi account di team" diventa: creare team, invitare un membro, passare da un team all'altro, limitare i dati al team corrente. Ognuna è un prompt a sé. Scrivere le user story è un buon modo per farlo.

Passo 2: descrivi ciò che vedi

L'AI non vede il tuo schermo finché non glielo dici. Indica cose specifiche e spiega cosa dovrebbe succedere:

Nella pagina dei prezzi da telefono, il pulsante della card Pro è tagliato sul bordo destro. Mantieni invariato il layout desktop; sotto i 640px, impila le card e rendi i pulsanti a tutta larghezza.

Confrontalo con "la pagina dei prezzi su mobile non va bene". Il primo si può fare e verificare in una sola volta; il secondo invita a una riprogettazione che non hai chiesto.

Le schermate aiutano. Se il tuo builder accetta immagini, allegane una e cerchia il problema.

Passo 3: pianifica prima delle modifiche grandi

Per tutto ciò che tocca più parti dell'app (un nuovo modello di dati, pagamenti, ruoli utente), chiedi un piano prima di qualsiasi modifica al codice:

Non cambiare ancora il codice. Voglio che gli utenti appartengano ai team e vedano solo i progetti del proprio team. Pianifica la modifica: quali tabelle, pagine e route API cambiano, cosa succede ai dati degli utenti esistenti e in che ordine costruiresti tutto.

Leggi il piano. Se è sbagliato, correggere un piano costa molto meno che disfare una costruzione.

Passo 4: dichiara cosa non deve cambiare

Gli strumenti AI a volte "sistemano" cose che non hai chiesto. Proteggi ciò che funziona:

Aggiungi un filtro per data alla tabella degli ordini. Non cambiare le colonne della tabella, lo stile o il pulsante di esportazione.

Per le regole che valgono ovunque (colori del brand, tono di voce, "non eliminare mai dati senza conferma"), mettile in un file di note del progetto o in un'impostazione di conoscenza che l'AI legge ogni volta, invece di ripeterle.

Passo 5: verifica più della sola modifica

Dopo ogni prompt, controlla:

• La modifica stessa. Fa ciò che hai chiesto, su desktop e su telefono?
• I suoi vicini. Gli elementi della stessa pagina e i flussi che usano gli stessi dati.
• Il percorso critico. Registrazione, accesso, l'azione principale, il pagamento. Un controllo di trenta secondi dopo ogni modifica importante individua presto la maggior parte dei problemi.

Se qualcosa non va, segnalalo in modo preciso: vedi come scrivere una buona segnalazione di bug.

Passo 6: torna indietro invece di accumulare

Quando una modifica rompe qualcosa e la prima correzione non funziona, fermati. Ogni "correzione" in più si appoggia a uno stato rotto, e i problemi si sommano.

Invece:

1. Torna all'ultima versione funzionante (un checkpoint o un commit Git).
2. Capisci cosa non era chiaro nel prompt.
3. Riprova con una richiesta più piccola o più chiara.

Quella modifica ha rotto il salvataggio delle bozze. Sono tornato indietro. Questa volta: aggiungi solo l'indicatore di salvataggio automatico, come testo nell'intestazione. Non cambiare il modo in cui vengono salvate le bozze.

Passo 7: sai quando ricostruire è giusto

Ricostruire da zero butta via molti dettagli funzionanti. Vale la pena solo quando:

• L'idea del prodotto è cambiata completamente.
• La struttura di base non può sostenere ciò che ora serve: per esempio, è stata costruita come sito statico e ora ha bisogno di account e di un database.
• Il progetto è ancora quasi vuoto.

Quando ricostruisci, elenca cosa conservare: nome, colori, testi, le parti che gli utenti hanno apprezzato.

Prompt di esempio

Prima di continuare, riassumi come funziona ora l'app: pagine, dati che memorizza e ciò che ritieni fragile.

Voglio aggiungere prenotazioni ricorrenti. Qual è la versione più piccola che sarebbe utile? Suggeriscila come tre modifiche separate che possiamo fare una alla volta.

Controlla le ultime tre modifiche per capire se potrebbero aver rotto il flusso di checkout. Non modificare ancora nulla.

Errori comuni

• Dieci richieste in un solo prompt. Alcune vengono fatte, altre a metà, e non puoi capire quali.
• Feedback vago. "È rotto" o "miglioralo" producono supposizioni.
• Non controllare i vicini. Una modifica a un componente condiviso rompe altre tre pagine.
• Correggere le correzioni. Se sei a quattro prompt di distanza da un bug, torna indietro.
• Ripetere il contesto ogni volta invece di tenere le regole permanenti nelle note del progetto.
• Ricostruire quando sei bloccato. La maggior parte dei momenti "ricominciamo da capo" significa in realtà "torna indietro di due passi".

Checklist

• Un obiettivo per prompt.
• Descrivo ciò che vedo e ciò che dovrebbe succedere.
• Le modifiche grandi hanno un piano prima di qualsiasi codice.
• Dichiaro cosa non deve cambiare.
• Dopo ogni modifica verifico la modifica, i suoi vicini e il percorso critico.
• Salvo un checkpoint o un commit dopo ogni modifica che funziona.
• Quando una correzione fallisce, torno indietro invece di accumulare correzioni.
• Le regole permanenti stanno nelle note del progetto che l'AI legge ogni volta.

Far evolvere un'app su Mythex

Mythex è costruito attorno a questo ciclo:

• Modalità Plan, Build e Ask. Plan discute l'approccio prima di modificare; Ask risponde senza cambiare il codice; Build esegue la modifica. Vedi Chat.
• Checkpoint. Dopo ogni turno riuscito, Mythex salva un checkpoint git; Revert to this point riporta indietro. Puoi anche modificare un messaggio precedente e usare Discard & resend per provare un prompt diverso da quel punto. Vedi Iterare senza ricostruire.
• Conoscenza. Impostazioni del progetto → Knowledge contiene le note permanenti che l'agente segue in ogni messaggio.
• /test fa cliccare l'agente nell'anteprima come un utente, dopo una modifica importante.

Richieste più piccole costano anche meno crediti. Per scrivere i prompt, vedi come scrivere prompt per i builder AI; quando qualcosa si rompe davvero, vedi come fare debug di un'app creata con l'AI.

Domande