Scrivere prompt è programmare

La maggior parte degli sviluppatori si avvicina al prompting come i non-sviluppatori si avvicinano alle formule dei fogli di calcolo: si scrive qualcosa, si vede cosa esce, si aggiusta finché funziona più o meno, e ci si ferma lì. Il risultato sono prompt fragili, difficili da ragionare e impossibili da migliorare in modo sistematico.

Questo è il modello mentale sbagliato. Fare prompt è programmare. Non è una metafora — si applica la stessa disciplina di fondo. I cicli di feedback sono più brevi, la sintassi è il linguaggio naturale, ma i principi ingegneristici sono identici.

Il mindset del debugging

Quando il codice produce un output sbagliato, non lo riformuli e speri per il meglio. Formi un'ipotesi sul perché sia sbagliato, la testi e rivedi la tua comprensione di cosa sta realmente succedendo. Il prompting funziona allo stesso modo.

Il failure mode comune è l'iterazione casuale: cambia una parola, aggiungi una frase, ristruttura i paragrafi, riprova. Questo produce risultati alla fine, ma non insegna nulla e ti lascia con un prompt che non riesci a spiegare. Se il modello comincia a darti risposte diverse domani — perché il contesto è cambiato, o sei in una conversazione diversa, o hai aggiunto qualcosa a monte — non saprai cosa correggere.

L'approccio migliore: tratta l'output inatteso come un bug. Chiedi cosa il modello "sa" nel momento in cui genera quella risposta. Cosa gli hai detto? Cosa non gli hai detto? Cosa potrebbe aver dedotto in modo errato da quello che hai fornito? Di solito il bug è uno di tre cose: contesto mancante, istruzione ambigua, o una contraddizione tra quello che hai detto prima e quello che stai chiedendo adesso.

Il contesto è lo scope

In un programma, una variabile ha uno scope — la regione di codice in cui è definita e accessibile. In un prompt, il contesto funziona allo stesso modo. Tutto ciò a cui il modello ha accesso nel momento della generazione è il suo scope. Quello che hai detto tre scambi fa è ancora in scope. Quello che è nel system prompt è in scope. Quello che hai dato per scontato ma non hai scritto non è in scope.

La maggior parte dei fallimenti nei prompt sono fallimenti di scope. Il modello ti ha dato qualcosa di generico perché il tuo contesto era generico. Non ha fatto quello che volevi perché hai descritto il risultato, non i vincoli. Ha contraddetto qualcosa che hai detto prima perché hai introdotto un conflitto senza risolverlo esplicitamente.

Diventare bravi nel prompting è in larga misura diventare bravi a gestire il contesto — sapere cosa il modello deve sapere, quando deve saperlo, e cosa rimuovere quando il contesto diventa troppo rumoroso.

La specificità è tutto

I nomi delle funzioni buone sono specifici. getUsersByCreatedDateDescending è meglio di getUsers perché codifica intento e vincoli che non sono ovvi dalla struttura dei dati. I nomi vaghi producono comportamenti vaghi.

I prompt funzionano in modo identico. "Scrivimi un post del blog su X" produce un post del blog su X nel modo in cui il modello si aspetta che i post del blog appaiano — generico, sicuro, strutturato come ogni altro post su cui è stato addestrato. "Scrivi un post del blog su X per un pubblico di senior engineer scettici della premessa, in seconda persona, aprendolo con un'affermazione controintuitiva" produce qualcosa che puoi effettivamente usare o editare.

La specificità non riguarda il controllo — riguarda la comunicazione dell'intento. Lo stesso intento che codifichi in una firma di tipo o in un nome di funzione deve andare da qualche parte in un prompt. Se lo ometti, il modello riempie il vuoto con il suo default, che di solito non è quello che vuoi.

Astrazione e riuso

Se ti ritrovi a scrivere lo stesso paragrafo di contesto all'inizio di ogni conversazione, è un candidato all'astrazione. I system prompt esistono per questo motivo — ti permettono di definire un contesto fisso una volta sola e riutilizzarlo in più interazioni. Lo stesso principio si applica su scala più piccola: se una particolare formulazione migliora affidabilmente gli output, scrivila e usala deliberatamente invece di ricostruirla da zero ogni volta.

È anche qui che la disciplina ingegneristica si separa dall'approccio basato sull'istinto. Uno sviluppatore che costruisce una libreria di pattern utili — formulazioni specifiche che funzionano, tecniche di impostazione del contesto che riducono l'ambiguità, formati di output facili da analizzare ed editare — ottiene rendimenti composti. Chi fa prompting a sensazione riparte da zero ogni volta.

L'iterazione ha una direzione

L'ultima cosa che distingue la programmazione dall'indovinare è che l'iterazione ha una direzione. Quando fai debug del codice, stai andando verso un risultato specifico e verificabile. Sai quando hai avuto successo perché i test passano, l'errore scompare, il comportamento corrisponde alle specifiche.

I prompt hanno bisogno della stessa cosa: una definizione di "fatto". Come appare un buon output? Se non riesci a descriverlo prima di eseguire il prompt, accetterai qualsiasi cosa venga fuori e la chiamerai abbastanza vicina. Se riesci a descriverlo con precisione, puoi iterare con uno scopo — ogni esecuzione ti dice qualcosa di specifico su cosa il modello ha capito e cosa no.

---

Il prompting è un'abilità, e come la maggior parte delle abilità, le persone che migliorano più velocemente sono quelle che lo trattano come qualcosa da capire piuttosto che da eseguire. Il modello è un sistema con input e output. Gli input sono per lo più sotto il tuo controllo. Gli strumenti di debugging sono gli stessi che hai già: ipotesi, esperimento, osservazione, revisione.

Sai già come farlo. Lo fai ogni giorno.