L’AI coding funziona meglio quando smette di essere una chat generica e diventa parte di un workflow controllato. Il valore non sta solo nel prompt giusto, ma nel modo in cui si prepara il contesto, si limita lo scope e si verifica il risultato.
Un assistente può scrivere molto codice in poco tempo. Questo è utile solo se il codice è coerente con il progetto, testabile, revisionabile e proporzionato al problema. Altrimenti produce velocità apparente: tante righe, tante modifiche, poca certezza.
Il prompt da solo non basta
Un buon prompt aiuta, ma non sostituisce il processo. Puoi scrivere istruzioni molto precise e ottenere comunque una soluzione sbagliata se mancano file, vincoli, casi limite o contesto storico.
Per questo preferisco pensare all’AI coding come a una sequenza:
- leggere il codice esistente;
- definire il problema;
- limitare i file coinvolti;
- chiedere un piano breve;
- applicare una modifica piccola;
- eseguire test;
- fare review del diff.
È meno spettacolare del “costruiscimi tutto”, ma molto più affidabile.
Contesto prima del codice
Il primo errore è chiedere codice prima di aver dato contesto. L’AI è brava a completare pattern, ma quando non conosce il progetto indovina.
Il contesto utile non è un romanzo. Bastano spesso poche informazioni:
- file coinvolti;
- comportamento atteso;
- errore o requisito;
- vincoli tecnici;
- librerie già usate;
- cosa non deve cambiare;
- comando di test da eseguire.
Questo vale sia per strumenti integrati nell’editor sia per agenti che leggono il repository. Ho già trattato i limiti generali in AI-assisted coding: tool, prompt e limiti, ma nella pratica il salto di qualità arriva quando il contesto diventa verificabile.
Diff piccoli battono riscritture grandi
L’AI tende a proporre soluzioni complete. A volte sono utili, spesso sono troppo ampie. Una riscrittura grande sembra ordinata, ma può cancellare dettagli impliciti: edge case, workaround, compatibilità, naming, contratti con altre parti del sistema.
Meglio chiedere modifiche piccole:
- “tocca solo questa funzione”;
- “mantieni la firma pubblica”;
- “non cambiare il formato della risposta”;
- “non aggiungere dipendenze”;
- “aggiungi un test di regressione”.
Un diff piccolo è più facile da capire, da revertire e da discutere. In un progetto reale, questa caratteristica pesa più dell’eleganza apparente.
Test come confine operativo
Senza test, l’AI coding diventa una promessa. Con i test, diventa almeno un processo osservabile.
I test non devono essere decorativi. Devono verificare comportamento, casi limite e regressioni reali. Un test scritto dall’AI può essere utile, ma va letto: il rischio più comune è generare test che confermano il mock invece del comportamento.
Per questo una richiesta sana è:
Prima scrivi un test che descrive il comportamento atteso.
Poi applica il fix minimo.
Infine esegui il comando di test e riporta l’output.Il tema è collegato a quello dei test automatici generati con AI: l’AI può accelerare la copertura, ma non deve inventare sicurezza dove non c’è.
Review: l’AI non approva sé stessa
Un altro errore è usare l’AI per scrivere il codice e poi accettare la sua spiegazione come review. La review deve guardare il diff con un ruolo diverso: cercare regressioni, dati esposti, input non validati, dipendenze inutili, API obsolete, gestione errori fragile.
La code review con AI può essere molto utile come secondo controllo, soprattutto se le chiedi esplicitamente di essere critica. Ma l’approvazione finale resta umana: contesto di business, priorità e rischio non sono sempre nel repository.
Permessi e confini
Quando un assistente può modificare file, eseguire comandi o chiamare strumenti esterni, servono confini chiari.
Per task piccoli, può bastare un workflow locale. Per progetti con dati sensibili, credenziali o clienti, è meglio separare i permessi:
- lettura libera del codice;
- scrittura limitata allo scope;
- niente nuove dipendenze senza approvazione;
- niente accesso a segreti;
- niente deploy automatico senza review;
- log e output controllati.
Qui entra anche la governance AI in azienda: non come burocrazia, ma come modo per evitare che strumenti utili diventino canali opachi.
Editor, agenti e scelta dello strumento
Non tutti gli strumenti servono allo stesso momento. Un assistente dentro l’editor è ottimo per refactor locali, spiegazioni e completamenti. Un agente più autonomo è utile per task multi-file, diagnosi o lavori ripetitivi con test.
Il confronto tra Copilot, Cursor e Claude Code non dovrebbe partire dalla classifica dello strumento, ma dal tipo di controllo che vuoi mantenere.
Per molte attività, il miglior setup è ibrido: AI vicina al codice per le modifiche piccole, agente più ampio per esplorazione e verifica, review umana prima del merge.
Una checklist pratica
Prima di accettare una modifica generata con AI, controllo sempre:
- ha letto i file giusti?
- ha rispettato lo scope?
- ha introdotto dipendenze?
- ha cambiato API pubbliche?
- ci sono test reali?
- i test sono stati eseguiti davvero?
- il diff è leggibile?
- ci sono dati sensibili in log o errori?
- la soluzione è più complessa del problema?
Questa checklist riduce molto il rischio di codice plausibile ma sbagliato.
Conclusione
L’AI coding non è magia e non è da evitare. È uno strumento potente, ma rende meglio quando lavora dentro un processo: contesto, scope, diff piccoli, test, review e permessi chiari.
La velocità utile non è scrivere più codice. È arrivare prima a una modifica corretta, comprensibile e mantenibile.