Sviluppare con l'AI

Intorno all'AI il dibattito si è polarizzato in due scuole di pensiero. Conviene conoscerle entrambe, perché ognuna contiene una verità e un errore.

• «L'AI farà tutto»: secondo questa visione, presto nessuno leggerà più il codice riga per riga. Descriverai il risultato, l'AI scriverà, correggerà e collegherà i pezzi, e a te resteranno direzione, priorità e gusto. La verità che contiene: la delega aumenterà davvero, e molto. L'errore: senza capacità di giudizio non ti accorgi nemmeno di quando l'AI sta sbagliando, e sbaglia con la stessa sicurezza con cui azzecca.
• «Il codice si scrive a mano»: secondo la visione opposta, delegare troppo atrofizza il ragionamento. Se non sai fare debug, non capisci le strutture dati e non leggi il codice con occhio critico, assembli sistemi fragili che reggono solo fino al primo problema serio. La verità che contiene: le basi restano indispensabili, oggi più di prima. L'errore: rifiutare per principio la leva più potente mai arrivata nelle mani di uno sviluppatore.

La sintesi: orchestrare senza abdicare

La strada solida le attraversa entrambe. L'AI accelera scrittura, ricerca, refactoring e debug, e ti toglie dalle mani quasi tutto il lavoro ripetitivo. Ma orchestrare non significa abdicare: la responsabilità di ciò che entra nel progetto resta tua.

Lo sviluppatore moderno assomiglia a un regista. Non monta ogni fotogramma con le proprie mani, ma capisce ritmo, luce, tono e direzione — e soprattutto riconosce una scena debole quando la vede. Senza quell'occhio, nessuna troupe al mondo gli consegnerà un buon film.

Con il codice funziona allo stesso modo, e questa guida segue proprio quel percorso: prima capisci come ragiona la macchina, poi impari a trasformare richieste vaghe in specifiche chiare, infine costruisci un metodo in cui AI, Git, test e revisione lavorano insieme.

Nota dell'assistente AI: per usare bene uno strumento devi sapere dove può tradirti. Questo capitolo è il punto di vista della macchina, raccontato dalla macchina.

Un modello di AI non vive il software come lo vivi tu. Non sente il peso di un server lento, non conosce la pressione di una release, non ha un gusto estetico suo. Lavora su pattern, probabilità e relazioni tra informazioni: produce la continuazione più plausibile di ciò che gli hai dato, non necessariamente quella giusta per il tuo progetto.

Questa natura lo rende fortissimo nei compiti ben delimitati, ma genera anche errori ricorrenti — e prevedibili. Sono proprio questi che devi imparare a intercettare:

• Compiacenza: se gli proponi una scelta debole, il modello tende ad assecondarti invece di fermarti — è addestrato a essere collaborativo, non a farti da revisore severo. Chiedigli esplicitamente un parere critico («cosa non funziona in questo approccio?»), non solo conferme.
• Mancanza di intenzione: il modello può scrivere una funzione tecnicamente perfetta senza sapere se quella funzione serva davvero al prodotto. Decidere cosa è utile, semplice e sensato non si delega: resta compito tuo.
• Fragilità davanti al contesto sporco: con file confusi, istruzioni vaghe o troppe informazioni irrilevanti, il modello riempie i vuoti inventando: API che non esistono, convenzioni mai adottate, strutture che il progetto non ha. Non lo fa per «bugia» — completa un pattern con il materiale che ha.

Niente di tutto questo rende l'AI inutile o inaffidabile: la rende uno strumento da guidare. Più il perimetro della richiesta è chiaro, più il risultato diventa solido — ed è esattamente ciò che costruiremo nei prossimi capitoli.

Molti pensano che usare bene l'AI significhi scrivere prompt brillanti. In realtà il salto di qualità avviene un passo prima: devi sapere tu cosa vuoi costruire. Se chiedi codice quando l'idea è ancora confusa, ricevi una risposta confusa — magari scritta bene, ma fragile.

Prima di generare qualunque cosa, trasforma l'intuizione in una piccola specifica. Bastano quattro righe, una per domanda:

• Scopo: quale problema risolve questa modifica, per l'utente o per il progetto?
• Confini: quali file e comportamenti l'AI può toccare, e quali deve lasciare intatti?
• Criteri di successo: come verificherai, concretamente, che la modifica funziona?
• Stile del progetto: quali convenzioni già esistenti deve rispettare?

In pratica, una specifica completa può essere piccola così:

Scopo: impedire l'invio del form di contatto con email non valida.
Confini: solo js/form.js; markup e CSS non si toccano.
Successo: input errato → messaggio sotto il campo; input valido → invio normale.
Stile: niente librerie esterne, funzioni pure, nomi coerenti con il resto del file.

Scriverla sembra un rallentamento, ed è invece l'abitudine che fa risparmiare più tempo di tutte. Una specifica chiara evita le patch chilometriche, azzera i fraintendimenti e — soprattutto — ti dà criteri concreti per giudicare il risultato, invece di valutarlo «a sensazione».

Chiarito il metodo, puoi scegliere lo strumento. Oggi l'AI entra nello sviluppo in tre forme, in ordine crescente di autonomia: suggerimenti inline mentre scrivi, chat integrata nell'editor per spiegare e modificare porzioni di codice, e agenti capaci di leggere più file, proporre un piano e applicare modifiche coordinate sotto la tua supervisione.

Estensioni per VS Code

Se usi VS Code, resisti alla tentazione di installare tutto. Parti con una sola integrazione, imparala a fondo e inseriscila nel tuo modo di lavorare; potrai sempre cambiarla dopo, con cognizione di causa.

• GitHub Copilot: il più diffuso. Suggerimenti inline, chat, spiegazione del codice e flussi sempre più orientati agli agenti.
• Gemini Code Assist: una buona scelta se lavori vicino all'ecosistema Google Cloud o vuoi un assistente conversazionale ben integrato negli IDE supportati.
• Cody / Continue: le opzioni più flessibili, per chi vuole scegliere tra modelli diversi, controllare con precisione il contesto e personalizzare il flusso di lavoro.

Editor nativi AI e agenti

Editor come Cursor o Windsurf portano l'AI al centro dell'esperienza: leggono più file insieme, propongono piani di lavoro, applicano modifiche coordinate e ti aiutano a ragionare su porzioni ampie del progetto. Più potere in cambio di più responsabilità: con questi strumenti la precisione nel definire il perimetro non è un'opzione, è il prerequisito.

Consiglio pratico: se stai iniziando, preferisci gli strumenti che ti obbligano a leggere e approvare ogni modifica prima di applicarla. Quel passaggio «lento» è esattamente il momento in cui impari — ed è la rete di sicurezza che ti manca finché non sai ancora riconoscere una patch sbagliata a colpo d'occhio.

Il contesto è ciò che separa una risposta da manuale da una risposta per il tuo progetto. Senza contesto, anche il modello migliore produce codice che potrebbe appartenere a qualunque codebase del mondo. Ma vale anche l'eccesso opposto: se rovesci nella chat mezzi progetti e istruzioni alla rinfusa, il modello perde il filo e inizia a mescolare le cose.

La regola è: non dare tutto, dai ciò che serve. Quando chiedi una modifica, includi sempre:

• il file o la sezione interessata;
• il comportamento attuale e quello desiderato;
• le convenzioni già presenti nel progetto (nomi, struttura, pattern ricorrenti);
• i vincoli tecnici: framework in uso, librerie vietate, browser da supportare, stile CSS esistente;
• come verificherai la modifica una volta applicata.

Se lavori con assistenti agentici, fai un passo in più: scrivi le regole di progetto in un file dedicato che lo strumento legge a ogni sessione. Stile dei commit, convenzioni dei componenti, limiti sulle dipendenze, comandi di test, preferenza per modifiche piccole. Sono poche righe, ma cambiano la natura dello strumento: l'AI smette di comportarsi come un generatore generico e inizia a muoversi dentro il tuo ambiente, con le tue regole.

"Prima di modificare il codice, leggi i file coinvolti, riassumi il comportamento attuale e proponi un piano breve. Mantieni lo stile esistente, non aggiungere dipendenze e modifica solo i file necessari."

Un prompt efficace non è una formula magica: è una richiesta chiara, completa e verificabile. Se scrivi «fammi una pagina di login», stai lasciando all'AI decine di decisioni non dette — struttura, stile, validazione, gestione errori. Le riempirà da sola: a volte indovinando, spesso no.

Il prompt migliore è quello che non lascia spazio alle interpretazioni inutili. In cinque blocchi dice tutto: chi deve essere l'assistente, in quale progetto lavora, cosa deve produrre, quali limiti deve rispettare e come controllerai il risultato.

[Ruolo] Agisci come sviluppatore front-end esperto.
[Contesto] Il progetto usa Vite, JavaScript vanilla e CSS puro.
[Obiettivo] Crea una funzione JS per validare email e password.
[Vincoli] Non usare librerie esterne. La password deve avere almeno 8 caratteri e una cifra.
[Output atteso] Restituisci { isValid: boolean, error: string } e mostra 3 esempi di input/output.

Una richiesta così non rende l'AI infallibile, ma la costringe dentro binari chiari: il codice generato sarà più vicino allo stile del progetto, più facile da controllare e molto meno incline alle soluzioni inventate. Nota il blocco finale, il più sottovalutato: chiedere esempi di input/output ti consegna già i primi casi di test.

La regola da portarsi a casa: un buon prompt non è lungo, è controllabile. Se non sai dire come verificherai la risposta, la richiesta è troppo grande o troppo vaga — spezzala prima di inviarla.

La frustrazione con l'AI nasce quasi sempre dallo stesso copione: chiedi troppo, ricevi troppo, qualcosa si rompe, chiedi una correzione ancora più grande e il progetto peggiora. Dopo tre giri di questo tipo non sai più cosa è cambiato, né dove è nato l'errore — e la colpa non è del modello, è della dimensione delle richieste.

L'antidoto è una routine semplice: non usare l'AI per fare tutto in un colpo solo. Usala per avanzare a blocchi piccoli, leggibili e verificabili. Quattro regole bastano.

Le regole del metodo

Regola 1: Fai piccoli passi isolati

Mai un'intera funzionalità in una sola risposta. Chiedi un pezzo alla volta: una funzione, un componente, una correzione, un refactoring circoscritto. Il metro è questo: se puoi leggere e provare il risultato in pochi minuti, la dimensione è giusta; se ti serve mezz'ora solo per capire cosa è cambiato, era troppo.

Regola 2: Git è il tuo paracadute

Prima di far generare modifiche importanti, fai un commit pulito o apri un branch temporaneo. Se la direzione si rivela sbagliata, torni indietro con un comando invece di ricostruire a memoria. È un paradosso solo apparente: Git ti rende più audace negli esperimenti proprio perché ti protegge da quelli riusciti male.

Regola 3: Leggi e comprendi PRIMA di salvare

Non accettare un suggerimento perché «sembra plausibile» — la plausibilità è esattamente ciò in cui i modelli eccellono, anche quando sbagliano. Rileggi il codice, controlla i nomi, guarda cosa importa, verifica che segua lo stile del progetto. E se una riga non ti è chiara, fermati e chiedi una spiegazione mirata:

"Spiegami questa riga in modo semplice e dimmi quali casi limite potrebbe non gestire."

Regola 4: Prima diagnosi, poi AI

Quando qualcosa si rompe, resisti all'impulso di incollare l'errore in chat con un «perché non va?». Prima fai tu il primo passo di diagnosi: console, log, riga coinvolta, ultima modifica fatta. Poi porta all'AI quel punto preciso, con il contesto già ristretto. Meno rumore le dai, più la risposta sarà utile — e nel frattempo avrai tenuto allenato il muscolo del debug, che resta tuo.

Quando inizi un progetto con l'AI, la tentazione è chiedere subito il risultato finale: «Fammi una landing page per una palestra». Sembra efficiente, ma è la ricetta del disastro: costringi l'agente a indovinare da solo centinaia di decisioni — struttura, contenuti, stile, architettura dei file — e ricevi in cambio un blocco monolitico che non puoi revisionare, pieno di scelte che nessuno ha mai preso davvero.

Il salto di qualità sta nel rovesciare l'approccio: tratta l'assistente come un team di sviluppo in miniatura e guidalo lungo una pipeline di 8 step, uno alla volta. Ogni step ha un obiettivo unico, produce un risultato piccolo e si chiude con una verifica tua. L'agente affronta così un solo problema per volta — la condizione in cui i modelli lavorano meglio — e tu mantieni il controllo su ogni decisione che entra nel progetto.

La pipeline, step per step

Nell'esempio che segue il progetto è una landing page per una palestra, ma la sequenza è identica per qualunque progetto: prima si decide, poi si costruisce, infine si rifinisce. La regola che tiene insieme tutto: non si passa allo step successivo finché il risultato di quello corrente non è stato verificato da te.

STEP 1 — Il brief: si progetta, non si programma

Il primo prompt non chiede codice: chiede un progetto. Struttura della pagina, esperienza utente, organizzazione delle sezioni. Il divieto esplicito («non scrivere codice») è la parte più importante della richiesta: senza, il modello salta dritto all'implementazione.

"Progettiamo un template per una palestra. Voglio una landing page professionale composta da Home, About, Services, Pricing, Trainer, Contact. Non scrivere codice. Definisci struttura, UX e organizzazione dei contenuti."

Prima di proseguire: leggi la proposta come farebbe un cliente. Le sezioni servono tutte? Manca qualcosa? Taglia e correggi adesso — ogni ambiguità che sopravvive al brief la ritroverai moltiplicata nel codice.

STEP 2 — L'architettura: l'alberatura dei file

Validata la struttura dei contenuti, chiedi di tradurla in uno schema di cartelle. Il criterio da imporre è la responsabilità unica: ogni file fa una cosa, e il suo nome dice quale.

"Crea l'albero delle cartelle per un progetto Vite usando HTML, CSS e JavaScript vanilla. Ogni file deve avere una responsabilità precisa."

Il risultato è una struttura modulare, ordinata e facile da navigare:

src/
├── assets/
│   ├── images/
│   └── icons/
├── css/
│   ├── base.css
│   ├── layout.css
│   ├── components.css
│   └── utilities.css
├── js/
│   ├── main.js
│   ├── menu.js
│   ├── slider.js
│   └── form.js
└── index.html

Prima di proseguire: chiediti se sapresti spiegare a cosa serve ogni file. Se uno non lo sapresti giustificare, chiedi all'AI di motivarlo o di eliminarlo: l'architettura si corregge adesso, non al decimo file scritto.

STEP 3 — Le regole ferree del progetto

Prima della prima riga di codice, metti per iscritto le regole non negoziabili. Non è burocrazia: senza vincoli espliciti il modello scivola verso le sue abitudini generiche, e la qualità del codice la decide il caso invece che tu.

"Prima di iniziare a scrivere il codice, segui queste regole:
- È vietato usare !important nel CSS
- Niente CSS duplicato
- Niente JavaScript inline
- Usa nomi descrittivi
- Commenta solo quando serve
- Evita workaround
- Se trovi un problema strutturale proponi una soluzione invece di aggiungere codice."

L'ultima regola è la più preziosa: autorizza l'AI a fermarsi e segnalare un problema di fondo, invece di seppellirlo sotto una toppa.

STEP 4 — Una sezione alla volta

Qui inizia la costruzione, ed è qui che serve più disciplina. Niente richieste massive come «fammi tutto il sito»: una sola sezione per richiesta, HTML e CSS insieme, in blocchi che puoi leggere per intero.

• "Crea la struttura HTML e lo stile CSS per la sola sezione Hero."
• "Adesso passa alla Navbar (header)."
• "Ora procedi con la sezione Services."

Prima di proseguire: apri la pagina nel browser e guarda la sezione appena costruita, anche in versione mobile. Ogni sezione approvata diventa terreno stabile su cui appoggiare la successiva.

STEP 5 — Il JavaScript, per ultimo

L'interattività arriva solo quando struttura e layout sono completi e stabili. Il motivo è pratico: il JavaScript si aggancia al markup, e ogni cambiamento di markup successivo rischia di rompere la logica già scritta. Anche qui, un componente alla volta:

• il menu mobile;
• lo slider dei contenuti;
• gli effetti all'invio dei moduli o allo scroll.

Prima di proseguire: prova ogni componente appena aggiunto, incluso qualche uso «sbagliato» — doppio click, campi vuoti, resize della finestra.

STEP 6 — Refactoring e pulizia

Quando tutto funziona, cambia cappello all'AI: da sviluppatore a revisore. Chiedi un'analisi dell'intero progetto come la farebbe un senior esterno appena arrivato, con un vincolo esplicito: il comportamento non deve cambiare.

"Analizza l'intero progetto come se fossi un senior developer. Cerca codice duplicato, CSS ridondante, JavaScript inutile, possibili bug e proponi un refactoring senza modificare il comportamento."

Prima di proseguire: fai un commit prima di applicare il refactoring (è il paracadute della Regola 2), poi verifica che tutto funzioni esattamente come prima.

STEP 7 — Ottimizzazione

Solo ora, sul progetto pulito, ha senso investire in rifiniture: ottimizzare prima significa lucidare codice che forse verrà buttato.

• Riduci CSS e JavaScript ridondanti.
• Ottimizza il caricamento di immagini e risorse esterne.
• Verifica SEO, accessibilità dei tag e resa responsive su schermi diversi.

STEP 8 — La review finale: pensare a fra sei mesi

L'ultimo passaggio non cerca bug: cerca debolezze. Chiedi una code review spietata orientata alla manutenibilità, con domande che costringono il modello a esporsi invece di farti i complimenti:

"Esegui una code review completa del codice e del progetto. Dimmi:
- Cosa non ti piace della struttura attuale
- Cosa cambieresti se potessi rifarlo
- Quali parti potrebbero creare problemi o colli di bottiglia tra sei mesi
- In quale sezione il codice potrebbe essere ulteriormente semplificato"

Non tutto ciò che emerge va corretto subito: alcune risposte diventeranno interventi immediati, altre semplici note per il futuro. L'importante è che le debolezze siano note a te, non solo al codice.

Il momento decisivo non è quando l'AI scrive il codice: è quando tu decidi se quel codice merita di entrare nel progetto. La revisione è il punto in cui riprendi davvero il volante — saltarla significa trasformare ogni suggerimento in un atto di fede.

Per ogni modifica che ricevi, passa in rassegna cinque aspetti:

• Coerenza: segue lo stile, i nomi e le strutture già presenti nel progetto?
• Perimetro: ha cambiato solo ciò che serviva, o ha toccato aree che nessuno le aveva chiesto?
• Comportamento: gestisce stati vuoti, errori, casi limite e input inattesi?
• Manutenibilità: tra un mese capirai ancora perché quella soluzione esiste?
• Verifica: hai eseguito test, build o prove manuali proporzionati al rischio della modifica?

E se qualcosa non torna, non chiedere un generico «sistema tutto» — è il modo più rapido per peggiorare le cose. Chiedi una diagnosi stretta: quale file è coinvolto, qual è la causa probabile, quali alternative esistono e quale ha meno impatto sul progetto. Poi scegli tu.

È la domanda che chiunque si fa, prima o poi, davanti allo schermo: se una macchina scrive codice al posto mio, ha ancora senso studiare scope, cicli, asincronia, database e architettura?

La risposta è sì — ma è cambiato il motivo. Non studi più per diventare qualcuno che digita codice velocemente: quella gara con un modello l'hai già persa. Studi per capire i problemi, scegliere le soluzioni, giudicare ciò che viene generato e costruire sistemi che restano in piedi. In altre parole: studi per essere la persona che può dire «questo va bene» — o «questo no» — con cognizione di causa.

Tre ragioni concrete:

• Leva tecnologica: chi sa programmare e usa l'AI progetta, integra e distribuisce a una velocità impensabile prima. Meno energia nella scrittura meccanica significa più energia nel valore del prodotto.
• Pensiero computazionale: programmare insegna a scomporre problemi complessi in passaggi chiari e verificabili. Che è, alla lettera, la stessa capacità che serve per guidare bene un assistente AI.
• Qualità dell'intento: l'AI traduce il tuo intento in codice. Se l'intento è debole, il codice sarà fragile per quanto sia scritto bene. Chi capisce sistemi, dati, rete e vincoli sa chiedere meglio — e ottiene risultati migliori dallo stesso identico strumento.

Parafrasando una riflessione molto citata di Andrej Karpathy: l'inglese sta diventando un linguaggio di programmazione. Ma per usarlo bene nel software devi comunque pensare come un ingegnere — conoscere i sistemi, pesare i compromessi e distinguere una soluzione elegante da una scorciatoia fragile.

Nessuno può prevedere i prossimi anni con precisione, ma la direzione è già leggibile: lo sviluppo software si sta spostando dalla digitazione del codice alla progettazione di sistemi, flussi e decisioni. Tre tendenze in particolare:

• Agenti sempre più presenti: non userai una chat per farti scrivere singole funzioni; coordinerai strumenti diversi che si occupano di analisi, implementazione, test, sicurezza e documentazione. Il tuo lavoro assomiglierà sempre più a dirigere, sempre meno a digitare.
• Più peso a gusto e utilità: quando il codice diventa abbondante ed economico, smette di essere il collo di bottiglia. La differenza la farà ciò che scegli di costruire, quanto è utile e quanto è piacevole da usare.
• Team piccoli con grande leva: una o poche persone potranno realizzare prodotti che oggi richiedono team interi, combinando AI, automazioni, template e infrastrutture cloud.

Il futuro non appartiene a chi rifiuta l'AI per orgoglio, né a chi accetta tutto passivamente. Appartiene a chi usa strumenti potenti con lucidità, gusto e metodo — cioè esattamente le tre cose che questa guida ha provato a costruire.

A questo punto la teoria deve diventare abitudine. Questa è la sequenza da ripetere a ogni modifica assistita dall'AI — sette gesti che dopo una settimana diventano automatici:

• Salva uno stato pulito con Git prima di chiedere modifiche importanti;
• Indica sempre tecnologie, vincoli e file coinvolti;
• Definisci il risultato atteso prima di generare la soluzione;
• Chiedi modifiche piccole, verificabili e coerenti con il task;
• Rileggi il codice generato prima di integrarlo;
• Prova la modifica localmente, con test manuali o automatici;
• Formatta, pulisci e fai commit solo quando il risultato è chiaro.

Il principio dietro la lista è uno solo: l'AI deve toglierti peso, non lucidità. Lasciale le fatiche ripetitive, la prima bozza, l'analisi di dettaglio. Tieni per te architettura, giudizio, direzione e responsabilità finale.

Usare bene l'AI richiede basi solide: più conosci gli strumenti intorno al codice, meglio saprai valutare ciò che l'assistente ti propone. Il percorso naturale dopo questa guida passa da qui:

• VS Code essenziale: per lavorare in un editor pulito, ordinato e davvero tuo — la base su cui ogni estensione AI si appoggia.
• Git pratico senza panico: per padroneggiare il paracadute di cui questa guida ha parlato in continuazione, e sperimentare con l'AI senza paura di rompere nulla.
• Tutti i tutorial: per continuare a costruire basi pratiche, una guida alla volta.

I quattro blocchi di un prompt professionale, in una tabella da tenere sott'occhio finché non diventano automatici:

Il modo migliore per fissare il metodo è usarlo subito, su un caso piccolo e reale: