Non scrivo queste righe da sviluppatore in attività.

Ho lavorato a lungo nel mondo del codice, poi sono passato dall'altra parte della barricata, sul versante del Product Management. Continuo a lavorare con gli sviluppatori, vedo i loro vincoli, i loro strumenti, le loro decisioni, e anche la loro stanchezza. E anche se lo sviluppo non è più il mio mestiere principale, non riesco a non chiedermi come i mestieri del software cambieranno con l'IA.

Questo testo non è quindi una verità definitiva. È lo sguardo di un osservatore curioso, un po' preoccupato, che ha frequentato il codice abbastanza a lungo da cogliere certi segnali deboli, e che adesso guarda la produzione software dal lato del prodotto. In fondo, un Product Manager che smette di essere curioso del modo in cui i prodotti vengono fabbricati probabilmente smette anche di fare bene il proprio mestiere.

Da qualche tempo gioco con gli assistenti di sviluppo. Ho generato script, ho fatto avanzare piccoli progetti, poi ho lavorato più seriamente su un'applicazione. E quello che vedo è insieme impressionante e inquietante: l'IA riesce a produrre moltissimo, molto velocemente. In pochi giorni si ottiene qualcosa che somiglia a un'applicazione vera.

Ma in tutto quel tempo ho anche speso un'energia enorme a correggerla.

E non su dettagli. Sui fondamentali. File che diventano troppo grandi. Test che mancano. Logica di dominio finita dentro gli endpoint. Scelte di architettura troppo complicate rispetto al bisogno. Soluzioni che funzionano adesso, ma che domani possono diventare fragili. La cosa più strana è che, quando le chiedo esplicitamente di fare diversamente, ci riesce. Sa scrivere i test. Sa separare il dominio dall'infrastruttura tecnica. Sa proporre una soluzione più semplice. Sa riconoscere che esiste un'opzione migliore.

Lo sa fare. Ma non lo fa sempre da sola.

Ed è qui che la questione diventa interessante.

L'IA non inventa i brutti vizi del software

Conviene partire da una constatazione onesta: l'IA non ha inventato il debito tecnico. Non ha inventato la sovra-ingegnerizzazione. Non ha inventato le architetture contraddittorie, i test dimenticati, le decisioni implicite, i prodotti mal inquadrati o le riscritture che si rimandano troppo a lungo.

Tutto questo esisteva già.

C'erano già sviluppatori capaci di costruire una cattedrale per montare una mensola. C'erano già team capaci di andare a sbattere al rallentatore. C'erano già aziende capaci di confondere la velocità di delivery con il valore reale. Il problema del software non è mai stato soltanto scrivere codice. È sempre stato produrre qualcosa che regge, che si capisce, che si mantiene, che evolve, che serve a un uso reale.

L'IA non crea quindi un problema del tutto nuovo. Ne cambia la scala.

Accelera quello che già andava troppo in fretta. Rende meno visibile quello che già era mal compreso. Permette di impilare più rapidamente decisioni che nessuno ha davvero preso. Dà una forma di maturità apparente a sistemi che non hanno ancora attraversato le normali tappe della maturazione.

Il pericolo non è che l'IA scriva codice. Il pericolo è che permetta di produrre sistemi mantenuti come prototipi, da persone che non sempre hanno l'esperienza necessaria per sapere dove quei sistemi si romperanno.

L'illusione della maturità

Il vibe coding dà una sensazione inebriante: si chiede, il codice compare, l'applicazione avanza. Dove servivano giorni, a volte settimane, bastano poche ore. L'effetto psicologico è fortissimo. Si vedono schermate. Si clicca. Risponde. C'è un database. Un'API gira. Compaiono funzionalità.

Il prodotto sembra maturare.

Ma quello che matura davvero, a volte, è soprattutto la superficie.

Un'applicazione può funzionare senza essere davvero capita. Può superare qualche scenario felice senza essere robusta. Può reggere una demo senza essere pronta per la produzione. Può contenere centinaia di scelte tecniche che nessuno sa spiegare, perché sono state generate, accettate, rattoppate e poi dimenticate.

Prima dell'IA una parte di questa fragilità esisteva già. Ma aveva spesso un limite naturale: la lentezza. Produrre codice costava tempo. Quella lentezza a volte imponeva conversazioni, scelte discusse, revisioni, momenti in cui bisognava capire quello che si stava facendo prima di andare oltre.

Con l'IA quel limite salta.

Si può andare molto più velocemente della propria comprensione. È utile per esplorare. È pericoloso quando si comincia a confondere l'esplorazione con la produzione.

Quando l'errore arriva troppo tardi, non insegna più

Buona parte dell'esperienza tecnica si costruisce nell'errore.

Non un errore qualsiasi, è chiaro. Si può soffrire a lungo senza imparare niente. Il dolore da solo non insegna nulla. Ma nello sviluppo l'apprendimento profondo nasce spesso da un ciclo molto concreto: si prova, si sbaglia, si cerca, si capisce, si corregge, e poi di quella correzione resta qualcosa.

A volte ci si blocca per mezz'ora. A volte per una giornata. A volte non si trova la soluzione lo stesso giorno, ci si torna l'indomani, ed è proprio quel giro largo a creare esperienza. Si impara a riconoscere i segnali deboli nel codice. Si impara che una soluzione troppo facile nasconde quasi sempre un costo. Si impara che un bug non è solo un ostacolo, ma un pezzo del sistema che resiste e chiede di essere capito.

L'IA può spezzare questo ciclo.

Quando compare un problema, le si può dire: arrangiati, trovami una soluzione. Qualcosa lo troverà. Magari una buona soluzione. Magari una soluzione orribile ma funzionante. In entrambi i casi, se non ci si prende il tempo di capire, si avanza senza imparare.

Il rischio non è solo che l'errore arrivi in ritardo. È che arrivi a una scala in cui non è più analizzabile. Il sistema è cresciuto. Gli strati si sono accumulati. Le decisioni sono implicite. I test, quando ci sono, magari confermano una lettura sbagliata del bisogno. E quando tutto crolla, non si sa più bene perché.

Allora si rattoppa.

Non si capisce meglio. Si mette solo un'altra pezza su un'architettura che non si è mai davvero abitata.

Il cuore del problema: la scomparsa del primo gradino

È probabilmente il punto che mi preoccupa di più.

La questione non è solo sapere se l'IA sostituirà gli sviluppatori junior. È una domanda importante, ma ne nasconde un'altra, più profonda: che cosa succede se l'IA sostituisce i compiti che fabbricavano i junior?

In molti team l'apprendimento avveniva per gradi. C'era un lead, c'erano sviluppatori esperti, profili intermedi e poi i junior. A un junior non si affidava subito l'architettura completa di un prodotto critico. Gli si davano piccoli compiti. Un bug circoscritto. Un endpoint semplice. Uno script. Una correzione. Un test. Un refactor modesto.

Quei compiti non erano solo lavoro da smaltire. Erano i primi gradini della scala.

Permettevano di farsi le ossa senza mettere a rischio tutto il sistema. Permettevano di imparare a leggere codice esistente, a capire un ticket, a chiedere aiuto, a ricevere una revisione, a scoprire che una modifica locale può produrre effetti altrove. Permettevano di entrare gradualmente nel mestiere.

Ed è proprio questo il tipo di lavoro che l'IA automatizza meglio.

Boilerplate, piccoli script, correzioni semplici, test standard, integrazioni ovvie: tutto questo si genera in pochissimo tempo. Dal punto di vista della produttività immediata è un'ottima notizia. Dal punto di vista della formazione è molto più ambiguo.

Se i primi gradini spariscono, come si diventa senior?

Si può rispondere che i junior impareranno in un altro modo, con l'IA come tutore socratico. È possibile. Un buon uso dell'IA aiuta a spiegare, a confrontare, a far verbalizzare, a generare esercizi, a simulare una revisione del codice. Ma questa possibilità richiede disciplina, curiosità e un quadro di riferimento. Richiede anche che l'azienda accetti di pagare tempo di apprendimento.

Ed è qui che la questione economica diventa brutale.

Se un senior potenziato dall'IA produce dieci volte di più, quante aziende accetteranno ancora che un junior vada dieci volte più piano perché deve imparare? Quante accetteranno che qualcuno passi una giornata su un problema che l'IA aggira in pochi minuti? Quante proteggeranno la lentezza necessaria alla formazione, mentre il mercato spinge a consegnare sempre più rapidamente?

Il rischio è di spezzare il ciclo di riproduzione del mestiere.

Le aziende software non hanno bisogno solo di codice. Hanno bisogno di persone capaci di diagnosticare, semplificare, mantenere, mettere in sicurezza, decidere tra opzioni e inventare. E persone così non nascono dal semplice pilotaggio di un assistente. Si costruiscono con anni di pratica sul campo, di errori, di revisioni, di decisioni difficili e di ritorni dal reale.

Se l'IA potenzia i senior che ci sono già ma indebolisce la crescita dei junior, non minaccia soltanto qualche posizione d'ingresso. Minaccia la capacità futura delle aziende software di produrre software di qualità.

Chi inventerà le prossime buone pratiche?

Si parla spesso delle buone pratiche come se fossero un patrimonio stabile. Basterebbe documentarle, metterle nei file di direttive per l'IA e poi chiedere agli assistenti di applicarle.

Ma le buone pratiche non sono ferme.

Nascono quando il terreno cambia. I design pattern classici rispondevano a un certo mondo software. Poi il cloud, i sistemi distribuiti, l'asincrono, i microservizi, le architetture a eventi hanno fatto emergere altri problemi. È stato necessario inventare nuovi modi di ragionare: idempotenza, retry, circuit breaker, saga, osservabilità, resilienza distribuita.

Quelle pratiche non sono comparse perché qualcuno le ha semplicemente chieste a uno strumento. Sono nate da sistemi reali, da guasti, da incidenti, da migrazioni difficili, da vincoli operativi, da compromessi dolorosi.

L'IA potrà probabilmente aiutare a formulare i prossimi pattern. Potrà confrontare soluzioni, individuare ricorrenze, documentare pratiche emergenti. Ma potrà inventarli da solo, prima che sia il terreno a renderli necessari e comprensibili?

Non ne sono sicuro.

Per inventare una buona pratica non basta conoscere quelle vecchie. Bisogna sentire perché non bastano più. Bisogna essere passati attraverso la resistenza del reale. Bisogna saper distinguere quando un pattern è una risposta elegante e quando è soltanto complessità inutile.

La semplicità, di per sé, è una competenza da senior.

Un'IA può proporre una soluzione troppo complessa e poi riconoscere subito che una soluzione più semplice è migliore, se glielo si fa notare. Ma serve comunque qualcuno che se ne accorga. Serve qualcuno che dica: questo problema non merita quest'architettura. Serve qualcuno che preferisca una soluzione meno brillante, ma più giusta.

Produrre di più, per farne che cosa?

La velocità di generazione non è la velocità di consegna.

Un team può ritrovarsi con decine di pull request create dall'IA durante la notte. Ma chi le rilegge? Chi verifica gli impatti? Chi capisce le scelte fatte? Chi prova gli scenari limite? Chi decide che cosa deve davvero andare in produzione? Chi si assicura che l'utente riesca ad assorbire questa complessità?

Produrre più codice non significa necessariamente produrre più valore.

C'è una tentazione competitiva evidente. Se un concorrente rilascia una feature in tre giorni, come si fa ad accettare che un team ci metta tre mesi? Se un mockup generato può diventare rapidamente codice di produzione, chi avrà il coraggio di dire: fermiamoci, non è ancora abbastanza pulito?

Ma il software non è solo una gara alla quantità. Un prodotto diventa presto illeggibile, per chi lo usa come per chi lo costruisce, se si aggiungono funzionalità più rapidamente di quanto si capisca a che cosa servono davvero. La complessità non si misura solo nel codice. Si misura anche nell'adozione, nel supporto, nella documentazione, nella coerenza dell'esperienza, nella capacità dell'organizzazione di spiegare quello che fabbrica.

L'IA sposta quindi i colli di bottiglia.

Il codice diventa più veloce. Ma la revisione, la sicurezza, l'inquadramento delle esigenze funzionali, l'integrazione, la comprensione e l'assorbimento da parte delle persone restano limitati. Forse diventano addirittura più critici.

La ricostruibilità come criterio di qualità

Nel mio uso recente, quello che mi ha rassicurato non è solo aver prodotto un'applicazione. È aver imposto dei punti di ancoraggio.

Ho insistito sui contratti tra API. Ho spinto l'IA a produrre i set di test, e poi la piramide dei test, prima di sviluppare. Ho cercato di mantenere una separazione netta tra il dominio e l'infrastruttura tecnica. Non sono arrivato a un approccio DDD completo, perché il progetto non lo giustificava, ma ho rifiutato che il dominio finisse semplicemente sparso negli endpoint.

Perché?

Perché un sistema davvero capito è un sistema che si saprebbe ricostruire.

Se domani devo portare questa applicazione su un'altra tecnologia, so dove sono i contratti, dove sono le regole di dominio, dove sono i test che descrivono il comportamento atteso. Non è tutto perfetto, ma il sistema non è soltanto un ammasso di codice generato. Ha appigli. Riferimenti. Linee di separazione.

Forse è proprio questo il criterio centrale dello sviluppo assistito dall'IA: non chiedersi solo «funziona?», ma «saprei ricostruirlo?».

Se la risposta è no, allora manca qualcosa.

Reintrodurre la difficoltà di proposito

Non basta imparare a sviluppare con l'IA. Ogni tanto bisogna anche imparare senza.

Non per nostalgia. Non per difendere una visione eroica dello sviluppatore che deve soffrire per meritarsi il mestiere. Ma perché una competenza che non incontra mai la difficoltà diventa fragile.

Altrove questa idea la accettiamo senza problemi. In matematica la calcolatrice è utile, ma imparare senza mai svolgere un'operazione da soli crea dipendenza. Nello sport si aggiungono di proposito vincoli, pesi, resistenza, perché è quella resistenza a sviluppare i muscoli.

Anche lo sviluppo avrà bisogno della stessa logica.

Dojo senza IA. Esercizi con l'IA limitata. Revisioni in cui bisogna spiegare il codice senza chiedere all'assistente di farlo al posto nostro. Momenti in cui ci si prende di proposito il tempo di leggere, di capire, di semplificare.

L'obiettivo non è rallentare ovunque. L'obiettivo è rallentare nel punto giusto.

Forse i team di domani dovranno accettare un ritmo ibrido: produrre molto velocemente per una parte del tempo, ma proteggere tempo lungo per capire quello che è stato prodotto. Una giornata di miglioramento continuo. Momenti da soli davanti al codice. Revisioni di architettura. ADR. Refactoring lenti. Post mortem sulle generazioni venute male.

Prima dell'IA questo tempo lungo mancava già troppo spesso. Molti sviluppatori restavano con la testa china sul lavoro, a produrre senza prendere abbastanza distanza per crescere. L'IA può aggravare il problema, se serve solo a riempire con altra produzione tutto lo spazio che ha liberato. Ma può anche diventare un'occasione, se ci obbliga a distinguere meglio il tempo del fare e il tempo del capire.

Qualche regola semplice per mantenere il controllo

Se i team vogliono usare l'IA senza perdere profondità, dovranno probabilmente inventarsi una disciplina esplicita. Non una burocrazia. Un'igiene della comprensione.

Alcune regole mi sembrano già utili.

Prima di tutto, non fare mai il merge di codice che nessuno sa spiegare. È una regola semplice, quasi brutale, ma essenziale. Un team che accetta codice non capito accetta un debito di comprensione.

Poi, prevedere un piccolo budget di comprensione per ogni feature: il contratto, i test, la decisione di architettura, i limiti noti. Non una documentazione interminabile. Quanto basta perché il ragionamento resti trasmissibile da persona a persona.

Bisogna anche legare i test alle esigenze funzionali. Un test generato può essere pulitissimo e confermare una lettura sbagliata del bisogno. Il ciclo dovrebbe essere: esigenze funzionali, test, codice, ritorno alle esigenze funzionali. Più i test esprimono davvero l'uso atteso, più il codice ha probabilità di restare vicino al valore.

Bisogna tenere aggiornata una mappa dei pattern che il team autorizza. Come si fa un'API? Come si gestiscono gli errori? Come si scrive un job asincrono? Come si testa una chiamata esterna? Senza questo, ogni feature generata rischia di inventarsi il proprio modo di fare, e il team si ritroverà a mantenere più architetture senza motivo.

Bisogna infine analizzare i fallimenti dell'IA. Quando produce una soluzione troppo complessa, quando dimentica i test, quando mette il dominio nel posto sbagliato, non ci si dovrebbe limitare a correggere. Andrebbe capito quale segnale è mancato, andrebbero aggiustate le direttive, andrebbero arricchite le pratiche.

L'IA può scrivere il codice. Ma il team deve restare padrone del ragionamento.

Capire dieci volte meglio

Non credo che lo sviluppo software affonderà a causa dell'IA.

Credo invece che alcuni team annegheranno in codice che non capiscono abbastanza. Avranno prodotto in fretta. Avranno consegnato cose visibili. Avranno magari perfino impressionato il mercato per un po'. Poi scopriranno che la velocità non sostituisce l'architettura, che i test valgono solo se esprimono il bisogno giusto, che la sicurezza si gioca nei casi limite, che il legacy richiede una comprensione storica, e che i senior non si fabbricano eliminando i compiti che formavano i junior.

La vera posta in gioco non è quindi rifiutare l'IA. Sarebbe assurdo. È troppo utile, troppo potente, ormai troppo presente.

La vera posta in gioco è non lasciarle i meccanismi che producono competenza.

Se l'IA ci permette di produrre dieci volte più velocemente, allora dovrebbe anche obbligarci a riservare del tempo per capire dieci volte meglio quello che produciamo. Altrimenti non avremo soltanto accelerato lo sviluppo software. Avremo accelerato la dimenticanza di ciò che permette di svilupparlo bene.