Prompt per Coding: Dalla Richiesta al Codice Funzionante

L'AI può generare codice eccellente o codice spazzatura — la differenza è quasi sempre nel prompt. Dopo migliaia di richieste di codice, ho identificato i pattern che producono codice funzionante al primo tentativo versus quelli che generano codice apparentemente corretto ma pieno di bug nascosti.

Il problema principale con le richieste di codice generiche non è che il modello "non sa programmare" — è che senza contesto sceglie le assunzioni più comuni, che raramente coincidono con le tue: la libreria più popolare invece di quella che usi già, uno stile di gestione errori generico invece del pattern del tuo codebase, una versione del linguaggio non specificata. Ogni pattern qui sotto esiste per eliminare una di queste assunzioni implicite.

Il template base per il codice

Linguaggio: [Python / JavaScript / ecc.]
Contesto: [cosa fa il progetto in cui si inserisce questo codice]
Obiettivo: [cosa deve fare questa funzione/componente in modo specifico]

Input: [tipo e struttura dei dati in entrata]
Output atteso: [tipo e struttura dell'output]

Vincoli:
- [librerie disponibili / non usare X]
- [gestione degli errori richiesta]
- [performance o sicurezza specifiche]

Esempio di input: [dato di esempio]
Esempio di output atteso: [output corrispondente]

Pattern che funzionano

1. Specifica il contesto del file

// MALE
"Scrivi una funzione per filtrare gli utenti"

// BENE
"Sto lavorando su un'API Express.js con MongoDB.
Ho una collezione 'users' con campi: id, email, role, createdAt, isActive.
Scrivi una funzione filterUsers(query) che accetta:
- role: 'admin'|'user'|'editor' (opzionale)
- isActive: boolean (opzionale)
- createdAfter: Date (opzionale)
Deve restituire una Promise con l'array di utenti filtrati."

La differenza tra i due prompt non è la lunghezza — è che il secondo elimina ogni ambiguità su schema dati, tipi accettati e valore di ritorno. Il modello non deve indovinare nulla, quindi non ha margine per assumere qualcosa di sbagliato.

2. Chiedi prima il piano, poi il codice

// Per task complessi: prima la struttura
"Prima di scrivere codice, descrivi l'approccio che userai per [task].
Elenca i passi principali e le potenziali problematiche."

// Poi, dopo la tua approvazione:
"Ora implementa il piano che hai descritto."

Questo pattern vale il tempo extra su task non banali: revisionare un piano di 5 righe prima che diventi codice è molto più veloce che scoprire, a codice già scritto, che l'approccio era sbagliato fin dall'inizio.

3. Includi i test nel prompt

"Scrivi la funzione E i test unitari.
I test devono coprire: caso base, edge case con input vuoto,
edge case con input non valido, e almeno un caso di errore."

Chiedere i test insieme al codice ha un doppio beneficio: ottieni una rete di sicurezza immediata, e il solo fatto di dover scrivere i test spesso spinge il modello a essere più preciso anche nell'implementazione, perché deve "pensare" ai casi limite in anticipo.

4. Richiedi gestione errori esplicita

"La funzione deve gestire esplicitamente:
- Input null o undefined → throw TypeError con messaggio chiaro
- Timeout della richiesta → retry con backoff esponenziale (max 3 tentativi)
- Risposta API non valida → log dell'errore e return null"

Senza questa istruzione, molto codice generato da AI gestisce solo il "percorso felice" — funziona nella demo, si rompe silenziosamente al primo input inatteso in produzione.

Errori da evitare

• Prompt senza contesto: "Scrivi una funzione che invia email" — quale libreria? quale provider? quale struttura?
• Non specificare la versione: Python 2 vs 3, React 17 vs 18, Node 14 vs 20 — cambiano le API
• Chiedere "codice funzionante" senza definire funzionante: il modello non sa il tuo ambiente
• Non chiedere commenti: senza spiegazioni, il codice AI diventa difficile da mantenere
• Accettare il primo output senza leggerlo: il codice AI può essere sintatticamente perfetto e logicamente sbagliato — la revisione umana resta necessaria, specie sulla logica di business

Per il debug

"Questo codice produce l'errore: [messaggio esatto]
Contesto di esecuzione: [ambiente, versioni]
Input che causa l'errore: [dato specifico]

Il codice:
[incolla il codice]

Spiega perché si verifica l'errore e proponi la fix."

Tutto questo vale per il coding "riga per riga", dove leggi e controlli ogni output. Esiste anche un approccio più radicale, in cui deleghi interi task all'agente e giudichi solo il risultato finale: lo spiego nella pagina dedicata al vibe coding, insieme a quando conviene usarlo e quando invece è meglio restare su un controllo più stretto.

Domande frequenti

Il codice generato dall'AI è sicuro da usare in produzione così com'è?

No, non senza revisione. Il codice AI può contenere vulnerabilità (validazione input mancante, gestione credenziali non sicura) che sembrano corrette a un occhio poco attento. Trattalo come il codice scritto da un collaboratore junior: probabilmente buono, ma da rivedere prima del merge.

Conviene far scrivere all'AI un intero modulo o solo funzioni singole?

Dipende dalla complessità. Per logica ben definita e circoscritta, un modulo intero va bene. Per logica che tocca più parti del sistema (autenticazione, pagamenti, dati sensibili), meglio procedere per funzioni singole, revisionando ogni pezzo prima di comporli — riduce lo spazio in cui un errore può nascondersi.

Come gestisco il codice AI quando il progetto usa convenzioni interne specifiche?

Includile esplicitamente nel prompt (naming convention, struttura cartelle, pattern architetturali già in uso) oppure, se lavori con strumenti che leggono il codice esistente (come Claude Code), lascia che il modello analizzi prima file simili nel progetto — il codice generato sarà molto più coerente con lo stile esistente.