Sviluppare con l'AI: come cambia il lavoro (e i rischi)

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. Lo è nella prototipazione: un prototipo funzionante che prima richiedeva una settimana oggi puoi tirarlo su in un giorno, e per testare un’idea in fretta il vantaggio è evidente.

Funziona molto bene anche sul lavoro ripetitivo. Ogni progetto ha una quantità enorme di codice “noioso”: configurazioni, routine standard, integrazioni, boilerplate. L’AI riduce tutto questo da ore a minuti e libera più tempo per la logica di business.

Aiuta poi a orientarsi nei progetti esistenti. Un nuovo sviluppatore di solito impiega settimane solo per capire dove ha messo i piedi; l’AI può ridurre sensibilmente questo tempo, rendendo l’onboarding, cioè l’ingresso operativo nel progetto, e i passaggi di consegne meno pesanti.

Infine accelera il refactoring. Rinominare, riorganizzare e sistemare codice vecchio diventa più veloce, anche se qui serve sempre un controllo umano perché gli errori sottili restano possibili.

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, cioè il costo futuro delle scorciatoie che prendi oggi, è quel conto che paghi domani per guadagnare velocità adesso. 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ù. Il motivo è semplice. Chi ha esperienza sa fare la domanda giusta, perché l’output dell’AI dipende molto da come la interroghi; sa giudicare il codice che riceve e scartarlo se non va bene; sa dove inserirlo nel sistema e come adattarlo al resto del progetto; 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, il primo punto è non ridurre il team ma spostarne il lavoro. L'AI non elimina il bisogno di sviluppatori: cambia il tipo di attività su cui li vuoi concentrare. Il tempo risparmiato sulle task ripetitive va investito in revisione del codice, test e ragionamento architetturale, non in una corsa cieca ad aggiungere feature.

Conta anche puntare sulla competenza più che sulla quantità. Uno sviluppatore senior che sa guidare e valutare l’AI vale spesso più di tre junior che si fidano ciecamente di ciò che esce. Quello che sembra un risparmio all’inizio si trasforma facilmente in un costo pesante dopo pochi mesi.

Va poi considerata la revisione come parte del processo. Se il flusso è “genera con AI, poi deploy”, stai accumulando debito tecnico a una velocità pericolosa. Quel codice va letto, capito e validato da qualcuno che sappia davvero cosa sta guardando. Allo stesso modo non bisogna farsi ingannare dalle demo: con l'AI è facilissimo tirare fuori un prototipo brillante in un pomeriggio, ma tra “funziona nella demo” e “regge in produzione con mille utenti contemporanei” resta un abisso.

Infine bisogna monitorare il debito tecnico. Chiedi al team quanto tempo passa a sistemare problemi vecchi rispetto a costruire cose nuove. Se quella percentuale cresce mese dopo mese, la velocità iniziale si sta trasformando in zavorra. E attenzione a non aggiungere persone pensando che questo risolva il problema, perché spesso lo aggrava.

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.