AI SDLC: una raccolta di buone pratiche per sviluppare con l'IA

C’è molto hype intorno allo sviluppo assistito dall’IA. Claude, Copilot, Cursor… la lista cresce ogni settimana. E sì, questi strumenti sono potenti. L’IA è eccellente per un PoC, ma andare in produzione è un’altra storia.

Che cos’è l’AI SDLC?

L’AI SDLC è l’integrazione di strumenti e sistemi di IA in ogni fase del ciclo di sviluppo del software tradizionale — planning, analysis, design, coding, testing, deployment e maintenance — per potenziare lo sviluppatore umano e migliorare velocità, qualità e processo decisionale. Come riassume IBM in questo articolo, l’idea non è sostituire il dev, ma aggiungere un livello intelligente lungo tutto il processo. E avvertono su un punto chiave: il codice generato dall’IA «may look correct, but can contain subtle problems» — può sembrare corretto e nascondere problemi sottili. Per questo l’approccio human-in-the-loop è quasi obbligatorio in qualsiasi progetto serio.

Questo post non vuole coprire tutte e sette le fasi. È una raccolta di buone pratiche durante l’AI SDLC, concentrata sulla parte in cui il dev è più nel loop: design, costruzione e revisione. Non è la verità assoluta; troverai molte altre pratiche e standard man mano che approfondisci. È quello che funziona per me.

L’IA è ottima per un PoC — ma un PoC non è pronto per la produzione

Gli AI dev tool sono fantastici per partire da zero e avere qualcosa che funziona in fretta. Gli dici cosa vuoi, lo lasci girare e in pochi minuti hai un PoC. Il problema è che quel codice non segue necessariamente le buone pratiche di design, architettura o coding. Nella maggior parte dei casi, ciò che ne esce non è un prodotto pronto per la produzione.

Ed ecco la parte scomoda: devi capire il codice. Il vibe coding va bene per un mockup, ma non per qualcosa di prod-grade. E questo resta vero anche con l’ultimo modello e i migliori strumenti.

Gli scenari: dove l’IA brilla e dove si complica

Creare da zero un PoC completamente funzionante — molto bene. È il terreno in cui brilla di più.
Aggiungere feature semplici a un codebase — bene. In genere non richiede molto altro aiuto.
Aggiungere feature complesse a un codebase complesso — così così. Qui serve già molta più guidance da parte del dev.
Modificare feature esistenti in un codebase semplice — bene. In genere meno guidance.
Modificare una feature esistente in un codebase grande — bene. Continua a non richiedere troppa guida.
Implementare una feature complessa in un codebase grande — qui si fa difficile. Non importa quanto contesto, skill o hook tu abbia, né quanto sia buono il tuo prompt: qui ti serve un buon piano. È molto facile che l’agente generi codice non ideale — probabilmente codice che funziona, ma non scalabile, soggetto a errori, poco leggibile, ecc.
Codebase grandi in generale, e migrazioni di codice — la faccenda diventa davvero delicata.

La conclusione: più il codebase è grande e complesso, e più la feature è complessa, più cala l’utilità dell’IA lasciata da sola — e più cresce l’importanza del dev nel loop.

Quando vai in produzione: il mio flusso di AI SDLC

Quando vuoi portare qualcosa in produzione, il vibe coding non è la risposta — almeno non se pensi che l’agente faccia tutto. Queste sono le buone pratiche che applico, basate sulla mia esperienza personale:

1. Progetta prima di scrivere prompt

Prima di scrivere un solo prompt, sei tu a decidere l’architettura, il design e il linguaggio. Puoi fare brainstorming con l’IA, ma dovresti aver progettato in anticipo ogni aspetto dell’applicazione e dell’infrastruttura.

2. Chiedigli un piano dettagliato

Usa quel design e chiedi all’IA di generare un piano dettagliato, con le tue istruzioni e le decisioni già prese come input.

3. Rivedi il piano!

Con attenzione. Chiedi le modifiche necessarie. Di solito gli chiedo di creare un file .md che sia io sia l’IA possiamo modificare e rivedere — non lo lascio solo nel prompt.

4. Dividi e avanza

Quando il piano è a posto, spezza i compiti più grandi in compiti piccoli e parti.

5. Non lasciargli mai fare tutto senza chiedere

Rivedi ogni modifica. Completa un commit. In questa fase mi piace rivedere ancora una volta le modifiche del commit. Il codice generato dall’IA sembra buono, ed è facile farsi sfuggire problemi con una sola passata. Quando sei soddisfatto del commit, passi al passo successivo.

6. Revisione finale, in triplice copia

Quando è tutto pronto, chiedi all’IA di rivedere un’ultima volta per trovare potenziali problemi. E fai tu stesso un rapido controllo manuale del nuovo codice. Questa è la terza revisione.

Altre pratiche che vale la pena tenere presenti

I test come guardrail

Chiedi all’IA di scrivere i test, ma con occhio critico. A volte genera test che passano banalmente, o che testano l’implementazione invece del comportamento reale. I test sono la tua rete di sicurezza quando lasci che l’agente modifichi il codice, ma vanno rivisti con la stessa diffidenza di tutto il resto. Un test che non fallisce mai non ti protegge da nulla.

Sicurezza: mai fidarsi alla cieca

L’IA infila con facilità secret hardcoded, dipendenze non sicure, validazioni mancanti o vulnerabilità di injection. Funziona, ma lascia la porta aperta. Rivedi sempre il codice generato dal punto di vista della sicurezza: quali dati tocca, cosa valida, cosa espone.

Strumenti deterministici nel loop

Non tutto deve passare dal tuo giudizio o da quello del modello. Linter, type checker, formatter e CI intercettano automaticamente un sacco di cose che né tu né l’agente dovreste controllare a mano. Lascia che gli strumenti deterministici facciano il loro lavoro e riserva la tua attenzione a ciò che richiede davvero giudizio.

Attenzione allo scope creep

L’agente tende a «migliorare» cose che non gli hai chiesto, o a toccare file fuori dall’ambito del compito. All’improvviso una modifica semplice arriva con tre refactor a sorpresa. Tienilo concentrato su ciò che hai chiesto; le modifiche fuori scope sono uno dei modi più facili per introdurre bug che nessuno si aspettava.

Sappi quando scriverlo tu

A volte spiegare all’IA come fare qualcosa costa più che farlo a mano. Riconoscere quel momento è una skill di per sé. L’IA è uno strumento, non un obbligo: se ci metti meno a scrivere il codice da solo, scrivilo.

Scegli il modello e l’effort giusti per ogni compito

Non tutto merita il modello più potente all’effort massimo. Per i compiti semplici — rinominare, refactor meccanici, boilerplate — un modello più leggero basta e avanza. Riserva i modelli grandi e il reasoning alto a ciò che ne ha davvero bisogno: architettura, feature complesse, debugging difficile. Risparmiare costi e token non è solo una questione di soldi: adattare modello ed effort alla complessità reale del compito dà risultati migliori e meno rumore.

Alcune regole importanti

Assicurati di avere configurati i tuoi skill, hook, command, rule e il code styling nel contesto dell’agente, pronti prima di iniziare.
Sfrutta le rule per fissare i comportamenti non negoziabili dell’agente: «non dare mai niente per scontato», «verifica o chiedi sempre se qualcosa non è del tutto chiaro», «non toccare file fuori dall’ambito del compito», «non inventare API né librerie». Una buona rule ti evita di ripetere la stessa cosa in ogni prompt.
Fai adversarial review del tuo progetto.
In generale, le soluzioni semplici sono le migliori. Diffida delle soluzioni complesse generate dall’IA — spesso c’è una strada più diretta che il modello non ha scelto.
Se non sei sicuro del modo migliore di implementare qualcosa, torna alla fonte: documentazione ufficiale, specifiche, il codice originale. Non accontentarti della prima risposta dell’agente.
Non mandare in produzione niente che non capisci.