Come usare l'IA per programmare: workflow che riducono il rischio

Regole per farsi aiutare dall'IA in sicurezza

Il modo migliore di usare l'IA per programmare è rallentarla proprio nei momenti in cui tirare a indovinare è pericoloso. L'IA sa spiegare codice sconosciuto, trasformare errori in ipotesi, abbozzare test, rivedere diff e proporre refactoring. Sa anche inventare API, ignorare dipendenze nascoste, adattarsi troppo allo snippet incollato o produrre una patch che sembra pulita mentre cambia un comportamento che volevi conservare.

Usa questa regola: l'IA può proporre, ma decide il tuo repository. La fonte di verità è il codice, la riproduzione che fallisce, la suite di test, i log a runtime, i requisiti di prodotto e la revisione umana. Un buon partner di programmazione basato sull'IA deve aiutarti a ragionare a partire da questi elementi, non sostituirli.

Regola	Perché conta	Cosa chiedere al modello
Riproduci prima	Evita patch a caso	"Ripeti il comportamento che fallisce e le prove prima di proporre codice."
Tieni piccolo l'ambito	Riduce il rischio di regressioni	"Proponi la modifica sicura più piccola ed elenca i file toccati."
Conserva il comportamento	Protegge utenti e contratti	"Indica le invarianti che questa modifica non deve rompere."
Pretendi i test	Rende la risposta verificabile	"Scrivi test che falliscono prima della correzione e passano dopo."
Rivedi prima del merge	Intercetta errori dati con sicurezza	"Rivedi questo diff per correttezza, sicurezza e casi limite mancanti."

Questo vale con tutti i modelli. OpenAI, Anthropic e altri fornitori pubblicano documentazione che descrive capacità, finestre di contesto e modalità d'uso degli strumenti diverse tra loro. Quelle capacità sono utili, ma non sostituiscono un workflow disciplinato. Per il lavoro di ingegneria, giudica i modelli con lo stesso metro che useresti per un collega: chiedono il contesto che manca, riducono l'incertezza, rispettano i vincoli e lasciano una traccia che puoi verificare?

Workflow di debug

Un workflow di debug affidabile con l'IA ha cinque fasi: riprodurre, isolare, ipotizzare, correggere e verificare. Non partire da "sistema questo". Parti dalle prove. Dai al modello il comando che fallisce, l'errore esatto, il comportamento atteso, quello osservato, il codice pertinente, i dettagli dell'ambiente e ogni modifica recente che potrebbe aver causato il problema.

Fase 1: cattura la riproduzione. Per il codice backend includi richiesta, risposta, codice di stato, log e test che fallisce. Per il frontend includi la rotta, l'azione dell'utente, l'errore nella console del browser, la risposta di rete, lo stato del componente e la descrizione di uno screenshot se serve. Per i problemi di build includi il comando, il gestore di pacchetti, la versione di Node e l'errore completo attorno al primo punto di rottura.

Fase 2: chiedi ipotesi prima del codice. Un modello attento dovrebbe ordinare le cause probabili e dire quali prove sostengono ognuna. Se non riesce a distinguere tra le cause, chiedi il passo diagnostico più piccolo. Può essere un log, un test mirato, un controllo dei tipi o la lettura di un altro file.

Fase 3: chiedi la patch più piccola. Di' al modello di non rinominare variabili, non riscrivere il codice attorno, non introdurre dipendenze e non cambiare il comportamento pubblico se non sa giustificarne il motivo. Chiedigli di restituire causa radice, schema della patch, file toccati, test e rischio.

Fase 4: esegui i test in locale. L'output dell'IA non è un passo di verifica. Il passo di verifica è il comando o il percorso utente che dimostra il comportamento. Se non esiste un test automatico, chiedi al modello di creare prima un test di regressione e poi di implementare la correzione.

Prompt per il debug:

Comportati come un partner di debug attento. Non scrivere ancora codice. Prima ripeti la riproduzione, il comportamento atteso, quello osservato e le tre cause radice più probabili. Ordina ogni causa in base alle prove. Poi proponi il passo diagnostico più piccolo. Bug: [descrivi]. Comando o azione utente: [incolla]. Errore e log: [incolla]. Codice pertinente: [incolla]. Vincoli: [stack, file da non toccare, comportamento da conservare].

Prompt per la correzione:

Partendo dalla causa radice confermata, proponi la correzione sicura più piccola. Restituisci: causa radice, file e funzioni da modificare, schema della patch, test che falliscono prima e passano dopo, casi limite e rischio di rollback. Non fare refactoring di codice non correlato. Contesto: [incolla].

Workflow di code review

Spesso l'IA rende meglio come revisore che come primo autore. Quando le chiedi di rivedere un diff, sa cercare casi limite dimenticati, problemi di sicurezza, assunzioni superate, buchi nei test e cambi di comportamento. Il punto è rendere specifica la revisione. Se chiedi "ti sembra a posto?" otterrai un'approvazione gentile. Se chiedi il rischio di correttezza, è più probabile che ottenga obiezioni utili.

Dai al modello il diff, il comportamento previsto, i test collegati e gli eventuali vincoli. Chiedigli di ignorare le questioni di stile minori, a meno che non incidano sulla manutenibilita. Vuoi che la revisione dia priorità ai bug, non ai cavilli di facciata.

Area della revisione	Domande a cui l'IA deve rispondere
Correttezza	Il diff soddisfa davvero il requisito?
Rischio di regressione	Quale comportamento esistente potrebbe cambiare per sbaglio?
Sicurezza	Input, autenticazione, segreti, permessi e rischi di injection sono gestiti?
Gestione degli errori	Cosa succede con valori nulli, timeout, retry, risposte errate o stato parziale?
Test	Quali comportamenti dichiarati non sono coperti?
Manutenibilita	Segue gli schemi locali e mantiene comprensibile la modifica?

Prompt per la code review:

Rivedi questo diff come un manutentore severo ma pratico. Concentrati su correttezza, rischio di regressione, sicurezza, casi limite e test mancanti. Ignora lo stile minore, a meno che non crei un rischio reale di manutenzione. Restituisci una tabella con problema, priorità, prova tratta dal diff, correzione proposta è test necessario. Comportamento previsto: [incolla]. Diff: [incolla]. Test esistenti: [incolla].

Per le modifiche ad alto rischio, usa in Whizi il workflow di confronto tra le correzioni dei modelli. Passa lo stesso prompt di revisione a due o tre modelli. Se un modello segnala un possibile problema, non accettarlo alla cieca: verifica se il problema esiste davvero nel codice. L'obiettivo non è raccogliere più opinioni. L'obiettivo e allargare la superficie di revisione prima del merge.

Workflow di refactoring e test

Fare refactoring con l'IA è rischioso perché molti refactoring si giudicano da ciò che non cambia. Il modello può rendere il codice più bello cambiando in modo sottile comportamento, gestione degli errori, tempi o contratti pubblici. Un workflow di refactoring più sicuro parte dal definire le invarianti prima di toccare l'implementazione.

Passo 1: descrivi l'obiettivo del refactoring. Esempi: ridurre la duplicazione, spezzare un componente grande, isolare l'accesso ai dati, semplificare le diramazioni, migrare un wrapper di API o migliorare la testabilita. Poi indica cosa deve restare uguale: firme delle funzioni pubbliche, comportamento delle rotte, nomi degli eventi, forma delle risposte, analytics, permessi, accessibilità e aspettative di prestazione.

Passo 2: chiedi un piano a fasi. Un buon piano di refactoring proposto dall'IA deve essere reversibile. Ogni fase dovrebbe toccare un'area piccola, includere test e produrre uno stato intermedio funzionante. Evita le riscritture in un colpo solo, a meno che il codice non sia minuscolo e ben coperto.

Passo 3: scrivi test di caratterizzazione. Prima di cambiare il codice, chiedi all'IA di individuare il comportamento attuale e di abbozzare test che blocchino i casi importanti. Questi test sono particolarmente utili sul codice legacy, dove l'intenzione non è chiara. Devono includere input normali, input di confine, percorsi di errore e un caso di regressione legato al motivo del refactoring.

Passo 4: implementa una fase alla volta. Dopo ogni fase, esegui i test e chiedi una revisione mirata. Se il modello propone un'astrazione ampia, fagli dimostrare che quell'astrazione elimina duplicazione o rischio reali. Altrimenti tieni il codice noioso e locale.

Prompt per pianificare il refactoring:

Crea un piano di refactoring a fasi. Obiettivo: [obiettivo]. Codice attuale: [incolla]. Vincoli: conservare il comportamento pubblico, ridurre al minimo le modifiche, seguire gli schemi esistenti, evitare nuove dipendenze, mantenere testabile ogni fase. Restituisci: invarianti, mappa delle dipendenze, fasi, file toccati, test per fase, rischio di rollback e lista di controllo per la revisione.

Prompt per i test unitari:

Scrivi i test prima di modificare l'implementazione. Usa lo stile dei test esistenti mostrato qui: [incolla]. Comportamento da conservare: [incolla]. Codice da testare: [incolla]. Restituisci nomi dei test, setup, input, risultato atteso e perché ogni test conta. Includi percorso felice, caso di confine, caso di errore e caso di regressione.

Modelli di prompt

I buoni prompt per programmare non sono lunghi perché sono ricercati. Sono lunghi quanto basta a eliminare l'ambiguita. Il modello ha bisogno di ruolo, compito, contesto, vincoli, formato dell'output e criteri di verifica. Salva i prompt che funzionano, così l'IA diventa un workflow di ingegneria ripetibile invece di una chat estemporanea.

Prompt per spiegare il codice:

Spiega questo codice a uno sviluppatore che entra nel progetto. Copri scopo, input, output, flusso dei dati, dipendenze, modi in cui può fallire e test che aumenterebbero la fiducia. Separa i fatti visibili nel codice dalle assunzioni. Codice: [incolla].

Prompt per la sicurezza del codice:

Rivedi questo codice cercando rischi di sicurezza. Concentrati su autenticazione, permessi, injection, segreti, validazione, redirect non sicuri, gestione dei file, rischio delle dipendenze ed esposizione di dati sensibili. Restituisci solo i problemi con prova, impatto, correzione proposta e test o controllo manuale. Codice o diff: [incolla].

Prompt per confrontare le correzioni dei modelli:

Sto confrontando modelli di IA su un compito di programmazione. Usa solo il contesto fornito. Restituisci causa radice, correzione sicura più piccola, test, rischi, assunzioni e domande. Valuta la tua fiducia da 1 a 5 ed elenca quali prove cambierebbero la tua risposta. Compito: [incolla]. Contesto: [incolla].

Lista di controllo prima di accettare codice generato dall'IA:

• Il modello ha ripetuto correttamente il compito.
• La patch è più piccola del problema, non più grande.
• Comportamento pubblico e contratti sono dichiarati.
• I test coprono direttamente il bug o l'obiettivo del refactoring.
• Casi limite e percorsi di errore sono elencati.
• Gli input sensibili per la sicurezza sono stati rivisti.
• Il diff segue gli schemi già presenti nel progetto.
• Hai eseguito il test, il lint, la build o la riproduzione manuale pertinente.
• Una persona ha rivisto il diff finale.

Whizi è utile quando vuoi confrontare le correzioni senza cambiare il compito. Incolla lo stesso prompt di debug o di revisione in più modelli, poi valuta gli output in base a prove, ambito, test e rischio. Parti dalle alternative a ChatGPT per programmare se vuoi una guida alla scelta del modello, confronta i piani nella pagina prezzi oppure crea un account per usare il workflow sul tuo codice.