Il tuo primo buon prompt

Un prompt non sostituisce una decisione di prodotto: la rende visibile perché un'altra persona o un'intelligenza artificiale (IA) possa agire. La pratica consigliata da OpenAI e Google parte da istruzioni chiare, contesto rilevante, esempi quando portano uno schema, e cicli di revisione. Qui applicherai quello schema a un modulo per creare compiti.

Il caso è piccolo di proposito. Il modulo richiede titolo, responsabile, scadenza e priorità; deve rifiutare dati incompleti e confermare il salvataggio. Questo perimetro permette di osservare se ogni istruzione cambia un comportamento concreto.

Trasforma l'idea in un compito verificabile

«Fai un gestore di attività» descrive un prodotto, ma non definisce la prossima modifica. Un compito verificabile indica che cosa deve comparire, che cosa può fare una persona e come saprai che funziona. Nel nostro caso, il primo obiettivo è compilare un modulo e salvare un compito valido.

Formula la richiesta con un verbo e un risultato osservabile. Per esempio: «Crea il modulo per registrare un compito con titolo, responsabile, scadenza e priorità; all'invio aggiungi il compito all'elenco». Quella frase ha ancora bisogno di contesto e validazione, ma impedisce già all'IA di inventare un pannello, un calendario o un sistema di permessi.

Se vuoi imparare il ciclo completo attorno a quella richiesta, leggi che cos'è il vibe coding. Il prompt avvia un'iterazione; revisione, test e decisione di accettare la modifica restano tuoi.

Porta solo il contesto che cambia la soluzione

Il contesto utile riduce le decisioni nascoste. Nomina il framework, se esiste già, i componenti da riutilizzare, la lingua dell'interfaccia e il punto in cui è conservato lo stato. Indica anche quali file o aree non devono cambiare.

Per il modulo dei compiti, il contesto potrebbe dire che l'applicazione ha già un elenco e un componente pulsante, che i testi sono in italiano e che lo stato resta in memoria. Non serve spiegare l'intera storia del progetto. Includi l'informazione che cambierebbe l'implementazione o il modo di controllarla.

Quando non conosci lo stack, dillo in modo diretto. Chiedi prima una proposta breve con le sue conseguenze e approvala prima di autorizzare modifiche. Questa pausa evita che una scelta tecnica accidentale diventi una dipendenza difficile da rimuovere.

Descrivi il risultato prima di chiedere codice

L'uscita attesa comprende struttura e comportamento. Nell'esempio ti servono quattro campi etichettati, un pulsante di invio, errori accanto al campo interessato e una conferma dopo il salvataggio. Puoi chiedere anche l'elenco dei file modificati e i test eseguiti.

Un esempio concreto aiuta quando conta la forma del risultato. Scrivi un compito valido, come «Preparare la demo, responsabile Ana, scadenza 20 luglio, priorità alta», e un ingresso non valido con il titolo vuoto. Così il modello ha uno schema per lo stato corretto e un altro per l'errore.

Non usare l'esempio al posto della regola. Se mostri solo una data valida, l'IA può accettare qualsiasi testo simile. Spiega anche che la data deve essere reale e non precedente al giorno corrente.

Fissa criteri di accettazione osservabili

I criteri di accettazione trasformano «sembra pronto» in una revisione ripetibile. Per questo modulo, ogni criterio deve essere verificabile nell'interfaccia o con una prova. Evita frasi come «che sia intuitivo», perché non dicono quale comportamento debba cambiare.

Puoi definire i risultati seguenti. Ognuno corrisponde a una prova visibile:

1. Titolo, responsabile e data sono obbligatori.
2. Una data passata mostra un messaggio accanto al campo e non salva il compito.
3. Un invio valido aggiunge un solo compito con tutti i suoi valori.
4. Il modulo si svuota solo dopo un salvataggio riuscito.
5. La navigazione da tastiera raggiunge campi, opzioni e pulsante in un ordine logico.

Questi criteri limitano anche il perimetro. Se l'IA aggiunge filtri, autenticazione o sincronizzazione remota, ha lavorato fuori dal compito, anche se il risultato appare curato.

Migliora il risultato con un riscontro specifico

La prima versione può fallire anche con un prompt chiaro. Riproduci il problema e rispondi con tre dati: che cosa hai fatto, che cosa è successo e che cosa ti aspettavi. Per il modulo: «Ho scelto ieri come data, l'invio è stato accettato e mi aspettavo un errore accanto al campo».

Aggiungi una prova che impedisca la regressione. Chiedi di coprire una data passata e una futura, di eseguire la suite esistente e di mostrare il risultato. Questa pratica trasforma il riscontro in prova ed evita una correzione visiva che lascia intatta la logica.

Non mescolare più correzioni scollegate. Se vuoi cambiare anche i colori e aggiungere etichette, lascia quei compiti a iterazioni separate. Così puoi attribuire ogni risultato a un'istruzione e tornare indietro solo dove serve.

Riconosci i limiti e i difetti del prompt

Un prompt dettagliato non garantisce una soluzione corretta. Il modello può assumere un fuso orario, ignorare una convenzione del repository, inventare un'API o scrivere una prova che conferma soltanto la propria implementazione. Leggi il codice ed esegui il flusso reale.

I dati sensibili richiedono un'altra cautela. Non incollare credenziali, dati personali o contenuti privati «per dare contesto». Se il lavoro richiede accessi esterni o azioni irreversibili, definisci autorizzazioni minime e approvazione umana; la guida agli agenti IA spiega quel contratto.

La raccomandazione di dividere i compiti e dare un riscontro concreto è un'euristica pratica, non una legge universale. Una migrazione coordinata può richiedere un piano ampio, mentre una correzione locale sta in una richiesta breve. Adatta la profondità al rischio e mantieni sempre un modo indipendente di controllare il risultato.

Rivedi il prompt prima di inviarlo

Usa questo elenco come porta d'ingresso del compito. Ogni casella deve corrispondere a una frase o a un criterio visibile nella tua richiesta.

• L'obiettivo nomina una sola modifica conclusa.
• Il contesto contiene solo dati, file e decisioni rilevanti.
• Il risultato atteso descrive stati validi e stati di errore.
• I criteri di accettazione si controllano senza interpretare intenzioni.
• Il perimetro esclude modifiche e azioni che non hai autorizzato.
• Il compito contiene una prova o un percorso per validare il risultato.

Se non riesci a spuntare una casella, correggi il prompt prima di allargarlo. Nel modulo dei compiti l'obiettivo finale non è ricevere molto codice: è riuscire a creare un compito valido, rifiutarne uno non valido e dimostrare entrambi i comportamenti.