Come scrivere prompt per gli AI app builder (con esempi prima/dopo)

Guarda due persone usare lo stesso AI app builder per un'ora. Una ha un'app funzionante; l'altra ha un pasticcio e l'opinione che "il coding con l'IA è sopravvalutato". Lo strumento era identico. I prompt no.

Scrivere prompt per un app builder è una competenza diversa dallo scrivere prompt per un chatbot. Non stai facendo domande — stai dando ordini di lavoro a un agente che prenderà decine di decisioni in base a ciò che hai detto e a ciò che non hai detto. Ecco cosa funziona davvero, con esempi prima/dopo lungo tutto l'articolo.

Il primo prompt: anticipa le decisioni, salta l'implementazione

Il tuo prompt di apertura fissa le fondamenta del progetto. L'agente riempie ogni vuoto che lasci con un'ipotesi, e anche se i buoni agenti ipotizzano sensatamente, ogni ipotesi è un lancio di moneta sul centrare la tua intenzione.

Prima:

Fammi un'app di fitness.

Dopo:

Costruisci un tracker di allenamenti per chi fa pesi. Dati: gli allenamenti hanno una data; ogni allenamento ha voci con nome dell'esercizio, serie, ripetizioni e peso. Schermate: (1) il registro di oggi con inserimento rapido, (2) lo storico raggruppato per settimana, (3) un grafico di progresso per esercizio. Un solo utente, nessun login necessario. Design scuro e minimale.

La versione "dopo" decide il pubblico, il modello dati, le schermate, il perimetro dell'autenticazione e la direzione visiva — le cinque decisioni che costano care da cambiare in seguito. Nota cosa non include: nessuno stack tecnologico, nessuna scelta di database, nessuna libreria di componenti. Una buona piattaforma prende quelle decisioni meglio di quanto possa fare un prompt, e ingombrare il tuo brief con termini tecnici capiti a metà fa danno attivo ("usa MongoDB" quando la piattaforma è costruita attorno a Postgres crea solo attrito).

Una struttura che funziona in modo costante:

1. Cos'è, in una frase, con il pubblico.
2. I dati, come semplici sostantivi e campi.
3. Le schermate, numerate.
4. Esclusioni esplicite — "niente login", "niente pagamenti". Le esclusioni prevengono funzionalità che l'agente inventerebbe altrimenti per essere d'aiuto.

Prompt di iterazione: una modifica, ancorata a un punto

Dopo la prima build, i tuoi prompt cambiano natura: dall'architettura alla chirurgia. Due regole fanno quasi tutto il lavoro.

Una modifica per messaggio. Le richieste accorpate falliscono in blocco — quando una delle cinque modifiche va storta, ti ritrovi a riformulare prompt lavorando attorno alle altre quattro.

Ancora ogni modifica a una posizione.

Prima:

Le date sembrano sbagliate.

Dopo:

Nella pagina di storico, le intestazioni delle settimane mostrano "Settimana 32". Mostra invece un intervallo di date, tipo "4 ago – 10 ago".

Nomina la schermata, cita il testo sbagliato, descrivi quello giusto. L'agente trova il punto esatto invece di andare a caccia — meno ipotesi sbagliate, meno crediti.

Descrivi risultati, non implementazioni

Sarai tentato di parlare come uno sviluppatore. Resisti, a meno che tu non lo sia.

Prima:

Aggiungi uno useEffect che rifà il fetch al mount e memoizza il rendering della lista.

Dopo:

Quando torno alla dashboard dopo aver aggiunto una spesa, il totale mostra ancora il vecchio numero finché non ricarico. Dovrebbe essere aggiornato.

La prima versione vincola l'agente alla tua diagnosi, che potrebbe essere sbagliata. La seconda gli dà il difetto reale — la cosa di cui sei sicuro — e gli lascia trovare la causa. Descrivi i sintomi con la sicurezza di un utente; lascia le diagnosi alla cosa che può leggere il codice.

Usa riferimenti — battono gli aggettivi

"Moderno e pulito" non significa nulla; ogni design dal 2010 in poi lo rivendica. I riferimenti trasportano ordini di grandezza in più di informazione:

Fai in modo che la sezione prezzi sembri la pagina prezzi di Linear: tanto spazio bianco, bordi sottili, un solo colore d'accento.

Meglio ancora, allega uno screenshot — di un'app che ti piace, di uno schizzo a mano, dello specifico layout rotto che stai descrivendo. Le piattaforme che accettano allegati immagine (Massvai lo fa) risolvono le ambiguità visive da una foto molto più in fretta che dalla prosa. Uno screenshot del bug con una didascalia di una riga è il formato di prompt dal valore più alto in assoluto.

Quando va storto: smetti di scavare

L'errore di prompting più costoso non è un prompt cattivo — è il quarto tentativo consecutivo di rattoppare una direzione fondamentalmente sbagliata.

Se due tentativi della stessa correzione non hanno funzionato, cambia strategia:

• Fai rollback. Ripristina il checkpoint precedente al pasticcio (Massvai fotografa ogni generazione) e riparti con una descrizione diversa. Tornare indietro sembra una sconfitta; di solito è la via più veloce per andare avanti.
• Allarga lo sguardo. Invece di ridescrivere la correzione, descrivi l'obiettivo: "Dimentica le istruzioni precedenti sul menu a tendina dei filtri. Ecco cosa sto cercando di far fare agli utenti: …" Gli agenti gestiscono meglio gli obiettivi freschi che le istruzioni di rattoppo accumulate.

Un bigino

Niente di tutto questo è esotico. È la stessa chiarezza che dovresti a un fornitore umano — solo che questo fornitore legge con attenzione, non si infastidisce mai per i dettagli e inizia a lavorare in pochi secondi. Dagli un brief all'altezza.