Il prompt engineering per programmare è la differenza tra un agente che consegna una pull request funzionante e uno che rompe silenziosamente qualcosa in produzione. Lo abbiamo imparato nel modo costoso: un'istruzione vaga nella nostra stessa pipeline ha generato 54 pagine live duplicate prima che qualcuno se ne accorgesse. Oggi una configurazione di 16 agenti Claude Code scrive, traduce e pubblica i nostri contenuti, e i prompt che la guidano non somigliano per niente alle liste di 50 template che trovi in prima pagina su Google. Ecco i 7 pattern che digitiamo ogni giorno, ciascuno con un vero prima-e-dopo.
Risposta rapida: I prompt di coding efficaci condividono una forma. Dichiari l'obiettivo e la definizione di "fatto", nomini esattamente i file coinvolti, imponi un piano prima di qualsiasi modifica, consegni i test e pretendi prove invece di un "sembra a posto". Fallo, e un agente moderno (Claude Code, Cursor, GitHub Copilot) scrive codice che supera la review al primo colpo molto più spesso. Saltalo, e otterrai codice apparentemente corretto ma inaffidabile, spacciato con sicurezza.
I 7 pattern, nell'ordine in cui li usiamo:
- Task framing: obiettivo, vincoli e "fatto" dichiarati subito
- Selezione del contesto: nomina i file, isola il resto
- Plan-first: fallo proporre prima che modifichi
- Test-first: metti i test di accettazione nel prompt
- Debugging: errore più riproduzione più atteso, causa radice prima della fix
- Refactor: cambia la struttura, mantieni il comportamento, mostra il diff
- Review: una checklist da verificare, più le prove
Prompt Engineering per Programmare vs. File di Configurazione: Cosa Va Dove
I file di configurazione e i prompt per singolo task fanno lavori diversi, e confonderli è l'errore più comune in questo campo. Un file CLAUDE.md o .cursor/rules è la policy permanente che l'agente legge a ogni sessione: il tuo stack, le tue convenzioni di naming, il comando dei test. Un prompt è il compito specifico che gli affidi in questo momento. Le regole durature vanno nella configurazione, il task va nel prompt.
La maggior parte delle raccolte di "prompt per il coding" confonde questo punto e ti dice di incollare un gigantesco prompt di persona dentro .cursorrules. Questo appesantisce la configurazione che l'agente carica a ogni singolo task e comunque non riesce a inquadrare il lavoro specifico che ha davanti. Tieni le due cose separate:
| File di configurazione (CLAUDE.md, .cursor/rules) | Prompt per singolo task | |
|---|---|---|
| Contiene | Regole permanenti: stack, stile, comando dei test, guardrail | Il task specifico: cosa costruire o correggere, adesso |
| Si carica | Automaticamente, a ogni sessione | Una volta, quando lo digiti |
| Cambia | Raramente, revisionato come codice | A ogni task |
| Esempio | "Esegui pnpm test prima di dichiarare fatto" | "Correggi l'arrotondamento delle tasse in cart.ts per ordini oltre $1,000" |
Se vuoi curare bene il lato configurazione, lo trattiamo in dettaglio nella nostra guida CLAUDE.md best practice e nella guida alle Cursor rules. Questo articolo è l'altra metà: i prompt che scrivi da zero ogni volta. Entrambi rientrano nella nostra guida al prompt engineering più ampia, se vuoi prima i fondamentali.
Prompt Engineering per Programmare: I 7 Pattern che Usiamo Ogni Giorno
Ogni pattern qui sotto ha la versione debole che le persone digitano davvero e la versione forte che produce codice funzionante. Il salto da debole a forte è quasi sempre la stessa mossa: sostituire un desiderio con una specifica.
1. Task Framing: Dichiara l'Obiettivo, i Vincoli e il "Fatto"
Il task framing significa scrivere l'obiettivo, i vincoli e come appare il "fatto" prima che l'agente tocchi una riga. Un agente ottimizza esattamente per quello che gli hai chiesto alla lettera, quindi una richiesta vaga produce una patch vaga. Nomina il file, il comportamento che vuoi, il controllo di accettazione e le cose che non deve cambiare.
Questo è il pattern che ci è costato 54 pagine. La nostra vecchia istruzione di traduzione era sostanzialmente un desiderio:
Debole: Ritraduci questo post in tedesco e mantieni i nomi dei brand.Non c'è scritto da nessuna parte cosa può fare lo slug. Così, a una nuova esecuzione, l'agente ha "migliorato" lo slug dell'URL, e siccome un nuovo slug significa un nuovo documento, ci siamo ritrovati con due pagine tedesche live per lo stesso post. Moltiplica su tutte le lingue e i post vecchi e ottieni 54 duplicati e un mucchio di esclusioni per contenuto duplicato. La correzione è stata una specifica, non un desiderio più educato:
Forte: Ritraduci questo post in tedesco.
- Se esiste già un file tedesco, copia il suo slug esistente parola per
parola. Non ri-derivarlo né "migliorarlo" mai.
- Prima di creare qualsiasi documento, cerca quello esistente tramite il suo
riferimento canonico e riusa quel record.
- Se lo slug che genereresti è diverso da quello live, FERMATI e dimmelo.
Uno slug cambiato crea un secondo URL live per la stessa pagina.Il prompt forte nomina ad alta voce la modalità di fallimento. Questa singola abitudine, dire cosa non deve succedere e perché, è il cambiamento più prezioso che la maggior parte dei team può fare. Chiudiamo anche ogni task prompt con un contratto di output esplicito ("il tuo messaggio finale deve riportare il conteggio parole, il punteggio di validazione e i file toccati") così l'agente sa cosa produce il "fatto", non solo cosa fare.
2. Selezione del Contesto: Nomina i File, Isola il Resto
La selezione del contesto significa dire all'agente esattamente quali file leggere e quali lasciare stare, invece di lasciarlo vagare con grep e riempire la sua finestra di rumore. La guida di Anthropic è diretta sul perché: la finestra di contesto si riempie in fretta e la qualità cala man mano che si riempie, quindi la maggior parte delle best practice esiste per proteggerla (Claude Code best practices).
Debole: Correggi il bug nel flusso di checkout.
Forte: Leggi solo src/checkout/cart.ts e src/checkout/tax.ts. L'arrotondamento
delle tasse è sbagliato per ordini oltre $1,000 (arrotonda ogni riga invece
del totale ordine). Correggi l'arrotondamento. Non toccare nulla al di fuori
di src/checkout/.Isoliamo il contesto con rigore. Una riga vera presa dai nostri prompt per agenti dice: "non scrivere su url-mapping.json, pipeline.md o config.json, e non toccare mai nessun file al di fuori della tua directory scratchpad." Quella singola frase ha evitato più danni accidentali di qualsiasi pulizia fatta a posteriori. Quando il task ha davvero bisogno di documenti live o strumenti extra, li aggiungiamo deliberatamente tramite server MCP invece di sperare che l'agente inciampi nel file giusto. E se parte di quel contesto arriva da fuori il tuo repository, trattalo come non affidabile: guarda la nostra nota sulla prevenzione del prompt injection prima di incollare una pagina raschiata dal web in un agente di coding.
3. Plan-First: Fallo Proporre Prima che Modifichi
Il prompting plan-first fa sì che l'agente ti consegni un approccio prima di modificare qualsiasi cosa. In Claude Code, la Plan Mode è uno stato di sola lettura rigido e imposto, non un educato "pensaci prima" che il modello può aggirare, quindi letteralmente non può scrivere finché non approvi il piano. Separare ricerca e pianificazione dall'esecuzione è la pratica su cui Anthropic punta di più per evitare di risolvere il problema sbagliato.
Debole: Aggiungi il rate limiting all'API.
Forte: Prima di scrivere qualsiasi codice, dammi un piano numerato: quale
middleware, dove vivono i contatori, come gestisci la risposta 429 e gli
header, e quali test aggiungerai. Aspetta la mia approvazione prima di
modificare.Perché funziona: il piano costa poco da leggere e poco da correggere. Correggere un piano sbagliato costa una frase; correggere codice sbagliato costa un ciclo di review. Questo si abbina naturalmente con il chiedere al modello di ragionare passo dopo passo (vedi chain-of-thought prompting), ed è la spina dorsale dei workflow multi-step di Claude Code che usiamo per qualsiasi cosa non banale.
4. Test-First: Metti i Test di Accettazione nel Prompt
Il prompting test-first mette i criteri di accettazione nel prompt come input e output concreti, così l'agente scrive codice contro un obiettivo che hai definito tu e non uno che ha indovinato lui. Incolla il test che fallisce, o una piccola tabella di risultati attesi, e dì "fai passare questo senza modificare il test".
Debole: Scrivi una funzione per il parsing di date ISO 8601.
Forte: Fai passare questo test che fallisce senza modificare il test:
parseIso("2026-07-20T15:00:00Z") -> Date esattamente a quell'istante UTC
parseIso("2026-07-20") -> Date a 2026-07-20T00:00:00Z
parseIso("not-a-date") -> lancia RangeError
parseIso("") -> lancia RangeError
Restituisci solo la funzione e i suoi import.Gli esempi concreti battono gli aggettivi ogni volta. "Gestisci i casi limite" è una speranza; quattro righe input-output sono una specifica che il modello può davvero soddisfare, e puoi eseguirle nel secondo in cui il codice arriva.
5. Debugging: Errore, Riproduzione, Atteso, Causa Radice Prima della Fix
Un prompt di debugging dà all'agente il testo dell'errore, l'input che lo innesca e cosa ti aspettavi, poi chiede la causa prima di qualsiasi fix. Saltalo e l'agente ripara il sintomo, così il bug si sposta semplicemente in un posto più silenzioso.
Debole: Questo genera un errore, correggilo.
Forte: Questo genera un errore al checkout. Ecco lo stack trace: [incolla].
Succede solo quando il carrello ha un codice sconto E una gift card (per
riprodurlo: aggiungi entrambi, poi fai il checkout). Atteso: entrambi si
applicano, la gift card per ultima. Trova la causa radice e spiegala in una
frase prima di cambiare qualsiasi cosa. Non avvolgerla in un try/catch che
nasconde l'errore.La frase "spiega la causa in una frase prima" fa un lavoro vero. Costringe il modello a impegnarsi in una diagnosi che puoi verificare al volo, invece di consegnare una fix la cui logica non vedi mai. La frase "non nasconderla in un try/catch" chiude la via di fuga più comune.
6. Refactor: Cambia la Struttura, Mantieni il Comportamento, Mostra il Diff
Un prompt di refactor vincola lo scope con rigore: cambia la struttura, mantieni il comportamento identico e mostra il diff. Senza un recinto, gli agenti "sistemano" cose che non hai mai chiesto, e perdi la capacità di revisionare il cambiamento che contava davvero.
Debole: Ripulisci questo file.
Forte: Estrai la logica di validazione da submitOrder() in una funzione pura
validateOrder(). Mantieni identiche tutte le firme pubbliche e tutto il
comportamento. Non cambiare nient'altro in questo file. Mostrami un diff
prima/dopo e una riga sul perché ogni cambiamento preserva il comportamento.Questo è il rovescio della divisione configurazione-contro-prompt di prima: le tue regole di stile permanenti vivono nelle regole di Cursor, ma lo scope di questo refactor appartiene al prompt. "Non cambiare nient'altro" è la frase che mantiene i refactor revisionabili.
7. Review: Una Checklist da Verificare, più le Prove
Un prompt di review consegna all'agente una checklist da verificare e pretende prove, non un verdetto. "Sembra a posto" non vale niente; il comando che ha eseguito e l'output che ha ottenuto sì. Anthropic lo dice chiaramente: fai mostrare all'agente le prove (l'output del test, il comando e il suo risultato) invece di dichiarare il successo, perché leggere le prove è più veloce che riverificare tutto da solo.
Debole: Fai la review della mia PR.
Forte: Verifica questo diff rispetto esattamente a questi cinque punti:
1. Nessun segreto o chiave API aggiunta
2. Ogni nuova funzione ha un test
3. Nessun cambiamento di comportamento fuori da src/checkout/
4. I percorsi d'errore restituiscono errori tipizzati, non stringhe
5. Nessun console.log dimenticato
Per ogni punto, cita la riga che lo soddisfa o lo viola. Poi esegui la
suite di test e incolla l'output. Non dire "fatto"; mostramelo.Il nostro gate di review interno è costruito esattamente così. Prima che un agente possa dichiarare un post come pubblicato, verifica la bozza contro una lista di parole vietate (un blocco rigido, tolleranza zero) ed esegue una query per confermare che il corpo del documento non sia vuoto. All'agente non è permesso dichiarare il successo; deve produrre l'output del controllo. Per i ruoli di reviewer che riusi spesso, promuovi la checklist a persona salvata, ed è qui che entrano in gioco gli esempi di system prompt.
Claude Code vs. Cursor vs. Copilot: Dove Vive Ogni Pattern
Tutti e tre i principali agenti del 2026 supportano ogni pattern qui sopra, ma la superficie cambia. Claude Code si appoggia su Plan Mode e i subagent, Cursor sulla Agent mode e la sua finestra Agents, e GitHub Copilot sulla agent mode più i file di istruzioni. Scegli lo strumento in cui vive il tuo team; i pattern si trasferiscono senza problemi.
| Pattern | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| Regole permanenti | CLAUDE.md | .cursor/rules | .github/copilot-instructions.md, AGENTS.md |
| Plan-first | Plan Mode (sola lettura imposta) | Fase di piano in Agent mode | Anteprima del piano prima di applicare |
| Lavoro isolato/parallelo | Subagent, ognuno con contesto proprio | Finestra Agents, worktree per agente | Task su agenti cloud |
| Regole per percorso | CLAUDE.md annidati per directory | Glob delle regole | .instructions.md con applyTo |
Alcuni dettagli attuali che vale la pena conoscere. La Plan Mode di Claude Code è un vero e proprio blocco di sola lettura, e i suoi subagent girano ciascuno in un contesto isolato con i propri strumenti (documentazione dei subagent). La linea 2026 di Cursor ha aggiunto una finestra Agents che avvia agenti paralleli, ciascuno nel proprio git worktree (Cursor 2.0). La agent mode di GitHub Copilot legge istruzioni personalizzate da .github/copilot-instructions.md, più i file .instructions.md con scope per percorso e un campo applyTo (istruzioni personalizzate di Copilot). Se Cursor è il tuo strumento quotidiano, guarda il nostro post su come usare Cursor in modo più efficiente.
Come Diamo i Prompt ai Nostri Agenti di Coding in Techsy
Gestiamo una pipeline di contenuti come un team di 16 agenti Claude Code: un researcher, un brief writer, un content writer, nove traduttori, un validator e un publisher, coordinati tramite messaggi di task. Due convenzioni di quel sistema si applicano a qualsiasi team di coding.
Primo, ogni task prompt finisce con un contratto di output. L'ultima riga è sempre una qualche versione di "il tuo messaggio finale deve riportare X, Y e Z". Un agente che conosce la forma esatta del "fatto" si perde molto meno di uno a cui viene detto solo cosa iniziare.
Secondo, non lasciamo mai che un agente si dia un voto da solo a parole. Generazione e verifica sono passi separati, e la verifica è un comando con un output, non un'opinione. Questa separazione tra costruire e controllare è centrale nel modo in cui Anthropic descrive la costruzione di agenti affidabili, ed è il motivo per cui il nostro gate di review verifica con grep e query invece di fidarsi di un "sembra a posto".
Questo è anche il nostro lavoro quotidiano. In Techsy costruiamo agenti IA e automazioni per team B2B, e una disciplina di prompt come questa è gran parte di ciò che separa una demo da qualcosa che puoi mostrare a un cliente. Se vuoi un workflow di coding o di agenti configurato a dovere, il nostro servizio di integrazione IA fa esattamente questo, e puoi prenotare una consulenza gratuita per parlare del tuo stack.
Un Template di Prompt Copia-Incolla che Puoi Adattare
Ecco lo scheletro da cui partiamo per qualsiasi task di coding non banale. Elimina le sezioni che non ti servono, ma mantieni l'ordine, perché rispecchia i sette pattern.
OBIETTIVO
Una frase: cosa dovrebbe essere vero quando hai finito.
CONTESTO
Leggi solo: <file esatti>. Ignora tutto il resto.
Fatti rilevanti: <vincoli, versioni, cosa innesca il bug>.
PIANO PRIMA
Prima di modificare, dammi un piano numerato e aspetta l'approvazione.
TEST / FATTO
Fatto significa: <incolla il test che fallisce o le righe input->output>.
Non modificare i test.
VINCOLI
Mantieni identiche tutte le firme pubbliche e il comportamento salvo
diversa indicazione. Non toccare <file/aree>. Nomina ogni assunzione
che fai.
RISULTATO
Mostra un diff prima/dopo, esegui i test e incolla l'output.
Non dire "fatto"; mostra le prove.Salvalo come snippet, o meglio, dividilo: i vincoli permanenti vanno nel tuo file di configurazione, e l'obiettivo, il contesto e i test vanno nel prompt. Questa divisione è tutto il punto.
Sull'Autore
Mert Batur Gurbuz è co-fondatore di Techsy.io, dove il team consegna agenti IA, sistemi di automazione e pipeline voice/SDR per clienti B2B. Studia alla University of Birmingham e scrive dello stack di strumenti LLM che il team Techsy usa davvero in produzione.
Credenziali: Co-Fondatore, Techsy.io, University of Birmingham. Connettiti su LinkedIn.
Domande Frequenti
Cos'è il prompt engineering per programmare?
Il prompt engineering per programmare è la pratica di scrivere istruzioni che portano un agente IA a produrre codice corretto e revisionabile. In pratica significa dichiarare l'obiettivo e la definizione di "fatto", nominare i file coinvolti, imporre un piano prima delle modifiche, fornire i test e pretendere prove. È più vicino a scrivere una specifica che a scrivere una frase a effetto.
In cosa è diverso dallo scrivere un file CLAUDE.md o .cursor/rules?
I file di configurazione contengono la policy permanente che l'agente legge a ogni sessione: il tuo stack, le convenzioni, il comando dei test. Un prompt per singolo task è il compito specifico che gli affidi in questo momento. Metti le regole durature nella configurazione e il task nel prompt. Incollare interi task prompt in un file di configurazione appesantisce ogni sessione e comunque non riesce a inquadrare il singolo task.
Qual è la migliore struttura di prompt per gli agenti IA di coding?
Usa sezioni etichettate invece di un unico paragrafo: OBIETTIVO, CONTESTO, PIANO, TEST, VINCOLI e RISULTATO. Gli agenti interpretano i prompt strutturati in modo più affidabile rispetto ai muri di testo. Dichiara subito i criteri di successo, dai da uno a tre esempi concreti invece di aggettivi, e specifica il formato esatto dell'output che vuoi ricevere.
Come scrivo un buon prompt di debugging?
Dai all'agente quattro cose: l'errore esatto o lo stack trace, l'input che lo riproduce, cosa ti aspettavi e una richiesta della causa radice prima di qualsiasi fix. Aggiungi "spiega la causa in una frase prima di cambiare qualsiasi cosa" così puoi verificare la diagnosi, e "non nasconderla in un try/catch" così ripara il bug invece di mascherarlo.
Dovrei includere i test nei miei prompt di coding?
Sì, ogni volta che puoi. Incollare il test che fallisce o una piccola tabella di righe input-output trasforma una richiesta vaga in un obiettivo che il modello può davvero colpire, e puoi eseguire il risultato immediatamente. Di' all'agente di far passare i test senza modificarli, così non può spostare il traguardo per far sembrare corretto il proprio codice.
Questi prompt funzionano anche in Cursor e GitHub Copilot?
Sì. I pattern sono agnostici rispetto allo strumento. Claude Code li espone tramite Plan Mode e i subagent, Cursor tramite Agent mode e la sua finestra Agents con un worktree per agente, e GitHub Copilot tramite agent mode più .github/copilot-instructions.md. La superficie cambia; il task framing, la selezione del contesto, il plan-first e la review basata su prove no.
Quanto dovrebbe essere lungo un prompt di coding?
Abbastanza lungo da essere una specifica, abbastanza corto da restare focalizzato. La qualità del ragionamento peggiora man mano che il contesto si riempie, quindi preferisci la struttura al volume: un prompt etichettato di 150-300 parole con i file e i test giusti batte uno divagante. Sposta nel tuo file di configurazione tutto ciò che si applica a ogni task, invece di ripeterlo.
Come impedisco a un agente IA di cambiare codice che non ho chiesto?
Isola lo scope nel prompt. Di' esattamente quali file può modificare, aggiungi "non cambiare nient'altro" e richiedi "mantieni identiche tutte le firme pubbliche e il comportamento salvo diversa mia indicazione". Per i refactor, chiedi un diff prima/dopo con una riga sul perché ogni cambiamento preserva il comportamento, così qualsiasi modifica non richiesta risulta evidente in review.
Vale la pena usare librerie di prompt copia-incolla?
Come punto di partenza, a volte. Come strumento finito, raramente. Una libreria di 50 prompt ti dà la formulazione, ma non può conoscere i tuoi file, i tuoi test o i tuoi vincoli, che è dove vive davvero la correttezza. Impara i pattern, tieni un template adattabile e riempi le specifiche del task che hai davanti.