Il prompt engineering è la pratica di formulare istruzioni per un modello in modo che l'output sia quello desiderato: ruolo, esempi, vincoli, formato della risposta. Per due anni è stato trattato come la competenza che separa chi ottiene buoni risultati da chi no. Con gli agenti di coding la domanda utile è cambiata: non più come chiedere meglio, ma come si verifica quello che torna indietro.
Il prompt engineering è ancora il collo di bottiglia?
In gran parte no, per chi usa un agente di coding su codice vero. Una richiesta approssimativa ma chiara oggi produce quasi sempre un diff plausibile, che compila e spesso passa i test esistenti. Il rischio non sta più nella frase scritta male, sta nel diff che sembra giusto e non lo è: risolve un problema leggermente diverso, allarga un permesso, prende una scorciatoia che regge solo sui casi visti. Scrivere meglio il prompt riduce la frequenza di questi errori, non li rende visibili. Quello che li rende visibili è un criterio di accettazione scritto prima, un comando di verifica eseguito fuori dalla sessione e una traccia che resta dopo. Il collo di bottiglia, per un team che consegna codice a un cliente e ne risponde mesi dopo, è diventato la verifica: cosa si controlla, chi lo controlla e cosa resta come prova.
Perché il prompt engineering contava così tanto
Con i primi modelli conversazionali la qualità dell'output dipendeva in modo molto visibile da come si chiedeva: lo stesso compito, formulato in due modi, dava risultati lontani. Da lì sono nate le guide, i corsi e i modelli di prompt riutilizzabili, e la SERP italiana su questo termine è piena di liste di tecniche.
Quella fase ha prodotto abitudini che restano valide: dichiarare il contesto, dire cosa è fuori perimetro, chiedere un formato di risposta preciso. Il punto è che erano rimedi a un problema specifico, un modello che reagiva male a istruzioni vaghe, e che quel problema pesa meno di prima. Trattarle ancora come la parte difficile del lavoro significa ottimizzare la fase in cui oggi si perde meno tempo.
Cosa è cambiato nei modelli e cosa no?
Cambiato: gli agenti di coding leggono i file, eseguono comandi, correggono i propri errori in un loop e reggono istruzioni imperfette meglio di quanto facessero i modelli di un paio d'anni fa. Parte di quello che il prompt doveva fare, indicare dove guardare, oggi lo fa l'agente. Resta il tema di cosa il modello vede quando risponde, trattato nel pezzo sul context engineering: conta quanto quello che gli chiedi.
Non cambiato: il modello non sa se ha risolto il problema giusto. Può dichiarare il lavoro finito con la stessa sicurezza quando è corretto e quando non lo è, e nessuna formulazione del prompt gli dà un criterio esterno con cui controllarsi. Quel criterio va portato da fuori.
Dove si è spostato il punto di rottura?
A valle, in tre punti che un prompt non copre.
| Punto di rottura | Cosa fa il prompt | Cosa serve davvero |
|---|---|---|
| Il diff sembra giusto | Riduce gli errori grossolani | Un criterio di accettazione scritto prima, confrontato con il diff a freddo |
| L'agente dichiara di aver finito | Può chiedere "verifica il lavoro" | Un comando di verifica eseguito da qualcosa che non è l'agente |
| Passano i mesi | Non lascia niente: il prompt sta nella chat | Una traccia legata alla modifica: richiesta, perimetro autorizzato, esito del controllo |
La prova che il giudizio dentro la sessione non basta è misurata. Il trial randomizzato controllato di METR, pubblicato a luglio 2025, ha fatto lavorare sviluppatori open source esperti su task reali nei loro repository: con gli strumenti AI consentiti hanno impiegato il 19% in più, pur avendo previsto in anticipo di essere il 24% più veloci e credendo, a lavoro finito, di essere stati circa il 20% più veloci. METR ha precisato che il risultato riguarda quel contesto e non è un verdetto permanente sugli strumenti. Il divario tra velocità percepita e misurata resta però l'avvertimento giusto: chi è dentro la sessione giudica male il proprio lavoro, e un prompt migliore non cambia chi lo giudica.
Istruzioni e prove sono due cose diverse
Un'istruzione dice all'agente cosa fare. Una prova dice a qualcun altro cosa è successo. Confonderle è l'errore più comune: si scrive un prompt lunghissimo, con regole e vincoli, e si considera il tema chiuso perché le regole erano scritte. Ma una regola scritta in un prompt non lascia traccia di essere stata rispettata. Un file di istruzioni come AGENTS.md è un buon esempio: orienta l'agente, e non dimostra niente di quello che l'agente ha poi fatto.
Per chi lavora su commessa la differenza è concreta. Al cliente, mesi dopo, non si porta il prompt. Si porta cosa era stato richiesto, cosa l'agente poteva toccare, cosa ha toccato, e il risultato di un controllo che non ha eseguito l'agente stesso. Questo è il livello su cui lavora Detent, l'impianto di delivery end-to-end (detent-ai.com): la verifica è eseguita dal sistema, non dichiarata dal modello, e l'approvazione di un rilascio richiede una firma umana. Una dimostrazione dei numeri su task reali è nella pagina /bench.
Cosa vale ancora la pena di scrivere bene?
Il prompt non è inutile, ha solo smesso di essere il punto in cui si vince o si perde. Vale la pena scrivere bene tre cose:
- i criteri di accettazione, prima che la sessione parta, in una forma che un comando possa controllare;
- il perimetro: quali file e quali cartelle l'agente può toccare e quali no;
- il contesto stabile del progetto, scritto una volta e tenuto in un file versionato invece che ripetuto a ogni richiesta.
Tutto il resto, la formula magica, il ruolo da assegnare al modello, la lunghezza del prompt, pesa molto meno di una verifica che qualcuno esegue davvero e di una traccia che qualcuno può rileggere. Se un team ha tempo da investire, oggi rende di più lì che a rifinire la quinta versione di un prompt.