Sviluppare con l'AI: più veloce, non più facile

Sviluppare con AI è il tema del momento, e negli ultimi due anni gira un'idea che affascina un sacco di gente: l'AI sta democratizzando la programmazione. In teoria, serve meno personale, si fa tutto più in fretta, si spende meno. Chi guida aziende e prodotti sta impostando assunzioni e strategie di crescita su questa promessa. Ma il punto è che questa storia non è completa. E quando basi le tue decisioni su una visione parziale, rischi di pagare caro.

Io uso Claude Code ogni giorno, Codex ogni tanto soprattutto per revisionare. Questi strumenti ti fanno andare più veloce nello sviluppo. Non lo rendono più facile. Sembra una sfumatura da poco, ma cambia tutto: da come strutturi il team a come pianifichi la roadmap, fino a dove metti i soldi.

Dove l’AI fa davvero la differenza

Partiamo dal concreto: dove l’AI è particolarmente efficace..

Prototipazione. Un prototipo funzionante che prima ti portava via una settimana, adesso lo tiri su in un giorno. L’AI è perfetta per buttare giù una prima versione da cui partire. Se vuoi testare un’idea in fretta, è un vantaggio enorme.

Lavoro ripetitivo. Ogni progetto ha una montagna di codice “noioso”: configurazioni, routine standard, integrazioni varie. L’AI riduce tutto questo da ore a minuti. In pratica, i tuoi sviluppatori passano più tempo sul vero valore — la logica di business — e meno su roba meccanica.

Orientarsi in progetti esistenti. Un nuovo dev che entra in un progetto di solito ci mette settimane solo a capire dove ha messo i piedi. L’AI può ridurre sensibilmente questi tempi. L’onboarding diventa molto più rapido e il turnover pesa meno.

Refactoring. Riorganizzare, rinominare, sistemare codice vecchio: l’AI accelera anche qui, anche se un occhio umano deve sempre controllare, perché qualche errore sottile lo piazza.

Tutto questo è concreto. Se il tuo team sa usare questi strumenti, la produttività sale — e lo vedi. Il vero problema nasce quando “più veloce” viene confuso con “più facile”.

I costi nascosti che nessuno ti dice

Il debito tecnico cresce a una velocità nuova

Il debito tecnico è quel conto che paghi domani per le scorciatoie che prendi oggi. Tutti i progetti ce l’hanno, chi più chi meno. Ma con l’AI, la velocità con cui cresce non si era mai vista.

Il motivo è semplice: scrivere codice con l’AI costa quasi zero in termini di tempo e fatica. E allora prendi quello che arriva: “Funziona? Dai, andiamo avanti.” Il codice che ti dà l’AI spesso fa quello che chiedi, sì, ma magari in modo poco efficiente, fragile, o con problemi di sicurezza che non si vedono subito.

Nel concreto, il debito tecnico lo senti quando tra sei mesi il team ti dice: “Per aggiungere questa feature ci vogliono tre mesi invece di tre settimane, perché prima dobbiamo rifare le fondamenta.” O quando un bug in produzione tiene tutti fermi per giorni, perché nessuno capisce più come funziona quel pezzo di codice.

Il debito tecnico che prima si accumulava lentamente, con l’AI può accumularsi molto più in fretta. Più codice imperfetto, più problemi.

Spesso il team non conosce davvero il codice che finisce in produzione

Qui c'è un problema che chi guida un team dovrebbe tenere bene a mente: quando uno sviluppatore usa l’AI per generare codice, quel pezzo finisce nel progetto, ma nessuno ci ha davvero ragionato sopra. Nessuno ha fatto scelte consapevoli, nessuno si è costruito un modello mentale di come funziona quel codice, riga per riga.

Poi, puntualmente, qualcosa si rompe. Nel software succede sempre. E invece di risolvere in fretta, ci si mette di più. Lo sviluppatore si trova a fare il detective su un pezzo di codice che, ufficialmente, è suo… ma che in realtà non ha mai davvero progettato.

In pratica, le stime diventano un terno al lotto. Il bug che “dovrebbe portar via un’ora” si trasforma in un giorno intero. E ripeti questa storia, tutte le settimane, tutto l’anno.

Le decisioni strategiche restano umane

L'AI scrive codice, sì. Ma non decide quale codice serve.

Che architettura regge il salto da 100 a 10.000 utenti? Quali compromessi sono accettabili per lanciare prima senza tagliarsi le gambe per il futuro? Come si struttura un sistema perché il team non si blocchi da solo quando lavora in parallelo?

Queste cose richiedono esperienza vera, conoscenza del contesto, una visione chiara sul prodotto. L’AI, queste cose, non le ha. Può darti una risposta generica, se gliela chiedi, ma le decisioni di architettura che separano un prodotto che scala da uno che va riscritto da zero tra 18 mesi sono dettagliate, dipendono dal contesto e richiedono giudizio umano.

Quando costruisci un prodotto software, le scelte più rischiose e costose non sono sul codice, ma sulla struttura. E qui l’AI non ti dà una mano. Almeno ancora non oggi.

Chi ci guadagna davvero con l'AI nello sviluppo software

Arriviamo al punto: chi gestisce team e fa assunzioni deve capirlo bene.

Gli strumenti di AI aiutano di più chi ha meno bisogno di aiuto: gli sviluppatori senior. Quelli che costano di più.

Perché? Perché chi ha esperienza:

• Sa fare la domanda giusta — l’output dell’AI dipende tutto da come la interroghi
• Sa giudicare il codice che riceve — e scartarlo se non va bene
• Sa dove va inserito quel codice — e come adattarlo al resto del sistema
• Sa riconoscere problemi prima che diventino bug in produzione

I junior spesso non hanno ancora sviluppato questi filtri. Prendono il codice generato, lo infilano nel progetto senza capirlo davvero, e costruiscono sopra fondamenta che non conoscono. Quando qualcosa si rompe, non hanno gli strumenti per venirne a capo. È il motivo per cui i design pattern valgono più di qualsiasi linguaggio: servono a riconoscere se la struttura proposta dall'AI ha senso oppure no.

L’AI moltiplica le capacità di chi già sa cosa fare. Non sostituisce la competenza.

Questa cosa si riflette direttamente sulle scelte di hiring: un team di cinque senior con AI produce di più (e meglio) di dieci junior con gli stessi strumenti. E ti costa meno in manutenzione, alla lunga.

Cosa cambia davvero per chi decide

Se guidi un team, gestisci un budget o una roadmap, ecco cosa cambia sul serio.

Non ridurre il team, spostalo. L'AI non elimina il bisogno di sviluppatori: cambia il tipo di lavoro che fanno. Il tempo che risparmi sulle task ripetitive va usato per revisionare codice, testare, ragionare sull’architettura — non per buttare dentro ancora più feature a una velocità insostenibile.

Punta sulla competenza, non sulla quantità. Meglio uno sviluppatore senior che sa guidare e valutare l’AI, che tre junior che si fidano ciecamente di quello che viene fuori. Quello che sembra un risparmio all’inizio si trasforma in un costo pesante dopo pochi mesi.

Considera la revisione. Se il tuo processo è “genera con AI → deploy”, stai accumulando debito tecnico a una velocità folle. Il codice generato va letto, capito e validato da qualcuno che sa cosa sta facendo. Questo tempo lo devi mettere in conto.

Non farti ingannare dalle demo. Con l'AI è facilissimo tirare fuori un prototipo spettacolare in un pomeriggio. Ma un prototipo non è un prodotto. Tra “funziona nella demo” e “regge in produzione con mille utenti contemporanei” c’è un abisso, e l’AI non lo colma.

Monitora il debito tecnico. Chiedi al team: "quanto tempo passiamo a sistemare problemi vecchi rispetto a costruire cose nuove?" Se quella percentuale cresce mese dopo mese, significa che la velocità iniziale dell'AI si sta trasformando in zavorra. E attenzione a non aggiungere persone pensando che risolva il problema: spesso lo peggiora.

L'AI amplifica la competenza, non la sostituisce

L'AI non ha reso lo sviluppo software più facile. Ha velocizzato il lavoro meccanico, ma la parte che richiede giudizio, esperienza e visione è rimasta. Anzi, ora pesa ancora di più.

Chi costruisce software non dovrebbe chiedersi “quanta gente posso tagliare grazie all'AI”, ma piuttosto "come posso usare l'AI per far lavorare meglio le persone giuste".

Le aziende che ci arrivano prima stanno giocando d’anticipo: lanciano prodotti migliori, più robusti, e ci arrivano prima degli altri. Chi invece pensa che “più veloce” voglia dire “più facile” finisce per costruire roba che fra un anno dovrà rifare da capo.

E questa differenza, alla lunga, vale centinaia di migliaia di euro.