Prompt per sviluppatori: dal bug alla revisione del codice

Incolli uno stack trace, scrivi «correggi», e l'assistente ti restituisce una funzione riscritta che mette a tacere l'errore. Il test passa, a volte perché il try/except aggiunto inghiotte l'eccezione. Il sintomo è sparito, non il bug.

Uno sviluppatore non ha bisogno che gli si spieghi che cos'è un prompt. Ha soprattutto bisogno di riflessi per impedire all'IA di lanciarsi sulla prima soluzione plausibile. I modelli qui sotto impongono questo rallentamento, e funzionano in una chat come in un assistente di codice.

Fare debug: separare la diagnosi dalla correzione

L'istruzione più redditizia sta in una riga: niente codice prima della diagnosi. Evita di convalidare una correzione fondata su una causa supposta.

Bug in [LINGUAGGIO/FRAMEWORK, VERSIONE SE CONTA].

Comportamento atteso: [COSA DOVREBBE SUCCEDERE]
Comportamento osservato: [COSA SUCCEDE]
Riproduzione: [PASSAGGI O TEST]
Errore completo:
[STACK TRACE]

Codice interessato:
[ESTRATTI]

Cosa ho già provato o escluso: [ELENCO]

Non proporre ancora una correzione.
1. Elenca 3 ipotesi ordinate per probabilità.
2. Per ciascuna, indica l'osservazione del codice o della traccia che la sostiene.
3. Indica la verifica più rapida per confermarla o escluderla (log preciso, query, test minimo).

Eseguirò queste verifiche e ti darò i risultati. Se ti manca un file per ragionare, chiedilo invece di supporne il contenuto.

Prendi uno sviluppatore Rails davanti a una fattura creata due volte: qui le ipotesi avranno buone probabilità di riguardare un doppio invio del modulo, un webhook rieseguito o un job rilanciato, e ognuna si verifica in pochi minuti nei log. Questa divisione in due tempi riprende il principio del ragionamento passo dopo passo, con in più un essere umano che fornisce i fatti tra i due passaggi.

Rileggere un diff, non un file intero

Una revisione chiesta senza orientamento restituisce soprattutto osservazioni di stile. Dai il diff, di' che cosa deve fare la modifica e precisa che cosa ti interessa.

git diff main...HEAD > diff.txt

Stai rivedendo questa pull request.

Obiettivo della modifica: [TICKET O DESCRIZIONE]
Contesto: [STACK, CONVENZIONI, VINCOLI DI PERFORMANCE]
Diff:
[INCOLLA IL DIFF]

Cerca in quest'ordine:
1. I bug: casi limite, errori non gestiti, concorrenza, valori nulli.
2. La sicurezza: injection, controllo degli accessi, dati sensibili nei log.
3. Gli scostamenti dall'obiettivo: ciò che manca e ciò che esce dal perimetro.

Per ogni problema, indica il file e la riga del diff, lo scenario concreto che lo innesca e la gravità (bloccante, da correggere, minore). Ignora formattazione e nomi, se ne occupa un linter. Se il diff ti sembra corretto su un asse, dillo semplicemente invece di inventare un problema.

L'ultima frase conta. Senza di essa, un modello a cui si chiedono problemi tende a trovarne a ogni costo, anche in codice sano.

Mettere in sicurezza il codice legacy prima di toccarlo

Devi modificare una funzione di 300 righe senza test, scritta da qualcuno che se n'è andato. Chiedere «rifattorizza» equivale a perdere i comportamenti non documentati. La sequenza giusta comincia con test di caratterizzazione, che fissano ciò che il codice fa oggi, bug compresi.

Ecco una funzione senza test, in produzione:
[CODICE]

Framework di test: [PYTEST, JEST, PHPUNIT...]

Prima di qualsiasi refactoring:
1. Descrivi il comportamento reale di questo codice, caso per caso, inclusi i comportamenti che ti sembrano bug.
2. Scrivi test di caratterizzazione che documentino questo comportamento attuale, senza correggerlo. Segna con un commento i casi che somigliano a bug.
3. Elenca le dipendenze da simulare (database, orologio, API) e le zone che non puoi coprire senza modificare il codice.

Non modificare la funzione. Il refactoring verrà in un secondo momento, a piccoli passi, con i test verdi tra l'uno e l'altro.

Lancia questi test sul codice attuale prima di andare avanti. Se falliscono sul codice attuale, è il modello che ha sbagliato sul comportamento, e quegli scarti sono proprio ciò che volevi scoprire. Spezza poi il refactoring in una catena di prompt: un'estrazione per messaggio, un commit per passaggio.

Scrivere test che attaccano il codice

Quando le si chiedono dei test dopo aver mostrato un'implementazione, l'IA scrive spesso test che descrivono quell'implementazione. Passano e non provano granché. Orientala verso la specifica e le rotture.

Specifica della funzione: [REGOLE DI BUSINESS]
Firma: [FIRMA]
Esempio reale di input e di output: [ESEMPIO]

Scrivi i test a partire dalla specifica, senza cercare di riflettere un'implementazione.
Copri i limiti, gli input non validi, i duplicati, i fusi orari e gli arrotondamenti se pertinenti.
Per ogni test, indica in una riga quale bug realistico intercetterebbe.
Scarta i test che potrebbero fallire solo se il linguaggio stesso fosse rotto.

Per un'applicazione di prenotazione di ristoranti, questo prompt ha buone probabilità di far emergere la fascia oraria a cavallo del cambio dell'ora legale, il genere di caso che spesso si dimentica.

Migrazione SQL: far cercare ciò che può andare storto

Una migrazione funziona in locale e blocca la tabella in produzione. L'IA è un buon revisore pessimista, a condizione di conoscere il volume e il motore.

Motore e versione: [POSTGRESQL, MYSQL...]
Dimensione delle tabelle interessate: [RIGHE]
Traffico: [LETTURE/SCRITTURE, FINESTRA DI MANUTENZIONE]
Migrazione:
[SQL]
Codice applicativo che legge queste colonne: [ESTRATTI]

Analizza:
1. I lock acquisiti da ogni istruzione e il loro effetto probabile su questo volume.
2. La compatibilità durante il deploy, quando vecchio e nuovo codice girano insieme.
3. Il piano di rollback, e ciò che non può essere annullato.
4. Una versione in più passaggi se necessario.

Se un comportamento dipende dalla versione del motore, dillo e indica che cosa devo verificare nella documentazione.

Tre precauzioni prima di fidarti del codice generato

Verifica che ciò che viene citato esista. Un modello può inventare un metodo, un'opzione o un pacchetto. Il rischio è reale sul fronte della sicurezza: il nome di un pacchetto inventato può essere registrato da un terzo malintenzionato. Prima di installare, guarda il registro, l'autore e l'attività del progetto:

npm view [pacchetto]
pip index versions [pacchetto]

Non incollare ciò che non puoi condividere. Chiavi API, stringhe di connessione, dati dei clienti e codice coperto da accordo di riservatezza non c'entrano niente in uno strumento non approvato dalla tua azienda. Guarda le condizioni del tuo piano, perché variano da un prodotto all'altro, e fai passare uno scanner di segreti su ciò che invii.

Mantieni la responsabilità della revisione. Il codice generato si rilegge come quello di un collega, con in più la questione delle licenze se si tratta di un prodotto commerciale. Se lavori con un agente che esegue da solo dei comandi, le sue istruzioni meritano tanta cura quanto il tuo codice: è tutto nella nostra guida alle istruzioni per agenti.

Apri il tuo ultimo ticket di bug risolto, ridallo al tuo assistente con il primo prompt e confronta le sue ipotesi con la vera causa. Capirai presto quanto vale il tuo strumento sulla tua base di codice.