Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Non scrivo queste righe come sviluppatore in attività.
Ho lavorato a lungo nel mondo del codice, poi sono passato dall'altra parte della barricata, verso il Product Management. Lavoro ancora con gli sviluppatori, vedo i loro vincoli, i loro strumenti, i loro arbitraggi, la loro stanchezza. E anche se lo sviluppo non è più il mio mestiere principale, non riesco a smettere di interrogarmi su come i mestieri del software evolveranno con l'IA.
Questo testo non è una verità definitiva. È il punto di vista di un osservatore curioso, un po' preoccupato, che ha conosciuto abbastanza il codice da percepire certi segnali deboli, e che ora guarda la produzione software dal lato del prodotto. Dopotutto, un Product Manager che smette di essere curioso di come i prodotti vengono fabbricati smette probabilmente di fare bene il proprio mestiere.
Da qualche tempo gioco con gli assistenti di sviluppo. Ho generato script, fatto avanzare piccoli progetti, poi lavorato più seriamente su un'applicazione. E il bilancio è allo stesso tempo impressionante e inquietante: l'IA può produrre moltissimo, molto velocemente. In pochi giorni si può ottenere qualcosa che assomiglia a una vera applicazione.
Ma in tutto questo tempo, ho anche speso un'energia considerevole a correggerla.
Non solo sui dettagli. Su fondamentali. File che crescono troppo. Test assenti. Business messo nelle API. Scelte architetturali troppo complesse per il bisogno. Soluzioni che funzionano adesso, ma che potrebbero diventare fragili domani. La cosa più strana è che quando glielo chiedo esplicitamente, sa fare altrimenti. Sa scrivere test. Sa separare il dominio dalla tuyauterie. Sa proporre una soluzione più semplice. Sa riconoscere che esiste un'opzione migliore.
Lo sa. Ma non lo fa sempre spontaneamente.
Ed è qui che il tema diventa interessante.
L'IA non inventa i difetti del software
Bisogna cominciare con onestà: 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 i refactoring che si rimandano troppo a lungo.
Tutto questo esisteva già.
Certi sviluppatori sapevano già costruire una cattedrale per appendere un quadro. Certi team sapevano già andare lentamente nel muro. Certe aziende sapevano già confondere velocità di delivery e valore reale. Il problema del software non è mai stato solo scrivere codice. È sempre stato produrre qualcosa che regge, che si capisce, che si mantiene, che evolve, che serve un uso reale.
L'IA non crea quindi un problema interamente nuovo. Ne cambia la scala.
Accelera ciò che andava già troppo veloce. Rende meno visibile ciò che era già 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 di maturazione.
Il pericolo non è che l'IA scriva codice. Il pericolo è che permetta di produrre sistemi mantenuti come prototipi, da persone che non hanno sempre acquisito l'esperienza necessaria per sapere dove questi sistemi si romperanno.
L'illusione di maturità
Il vibe coding dà una sensazione esaltante: si chiede, il codice appare, l'applicazione avanza. Dove servivano più giorni, a volte settimane, bastano poche ore. L'effetto psicologico è molto forte. Si vedono schermi. Si clicca. Risponde. Esiste un database. Un'API gira. Compaiono funzionalità.
Il prodotto sembra maturare.
Ma ciò che matura davvero, a volte, è soprattutto la superficie.
Un'applicazione può funzionare senza essere davvero compresa. Può superare alcuni scenari felici senza essere robusta. Può rispondere a una demo senza essere pronta per la produzione. Può contenere centinaia di scelte tecniche che nessuno sa spiegare, perché sono state generate, accettate, patchate, poi dimenticate.
Prima dell'IA, una parte di questa fragilità esisteva già. Ma aveva spesso un limite naturale: la lentezza. Produrre codice costava tempo. Questa lentezza imponeva a volte conversazioni, arbitraggi, revisioni, momenti in cui bisognava capire cosa si stava facendo prima di andare avanti.
Con l'IA, questo limite salta.
Si può andare molto più veloci della propria comprensione. È utile per esplorare. È pericoloso quando si comincia a confondere esplorazione e produzione.
Quando l'errore arriva troppo tardi, non forma più
Gran parte dell'esperienza tecnica si costruisce nell'errore.
Non qualsiasi errore, ovviamente. Si può soffrire a lungo senza imparare nulla. Il dolore da solo non forma. Ma nello sviluppo, l'apprendimento profondo viene spesso da un ciclo molto concreto: si prova, si sbaglia, si cerca, si capisce, si corregge, poi si conserva qualcosa di quella correzione.
A volte si blocca per mezz'ora. A volte una giornata. A volte non si trova il giorno stesso, ci si ritorna il giorno dopo, ed è proprio questo detour che crea esperienza. Si impara a riconoscere i segnali deboli nel codice. Si impara che una soluzione troppo facile nasconde spesso 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 appare un problema, si può dire: arrangiatela tu, trovami una soluzione. Troverà qualcosa. Forse una buona soluzione. Forse una soluzione orribile ma funzionale. In entrambi i casi, se non si prende il tempo di capire, si avanza senza imparare.
Il rischio non è solo che l'errore venga ritardato. È che arrivi a una scala in cui non è più analizzabile. Il sistema è cresciuto. Gli strati si sono sovrapposti. Le decisioni sono implicite. I test, quando esistono, validano forse una comprensione sbagliata del bisogno. E quando tutto crolla, non si sa più davvero perché.
Allora si patcha.
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à sviluppatori junior. Questa domanda è importante, ma ne nasconde un'altra, più profonda: cosa succede se l'IA sostituisce le attività che fabbricavano i junior?
In molti team, l'apprendimento avveniva per gradazione. C'era un lead, sviluppatori esperti, profili intermedi, poi junior. Non si affidava immediatamente a un junior l'architettura completa di un prodotto critico. Gli si davano piccoli compiti. Un bug limitato. Un endpoint semplice. Uno script. Una correzione. Un test. Un refactor modesto.
Questi compiti non erano solo lavoro da fare. 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, capire un ticket, chiedere aiuto, ricevere una review, scoprire che un cambiamento locale può avere effetti altrove. Permettevano di entrare progressivamente nel mestiere.
Ora sono esattamente questi compiti che l'IA automatizza meglio.
Il boilerplate, i piccoli script, le correzioni semplici, i test standard, le integrazioni ovvie: tutto questo può essere generato molto velocemente. Dal punto di vista della produttività immediata, è un'ottima notizia. Dal punto di vista della formazione, è molto più ambiguo.
Se i primi gradini scompaiono, come si diventa senior?
Si può rispondere che i junior impareranno diversamente, con l'IA come tutore socratico. È possibile. Un buon uso dell'IA può aiutare a spiegare, confrontare, far verbalizzare, generare esercizi, simulare una code review. Ma questa possibilità richiede disciplina, curiosità e un contesto. Richiede anche che l'azienda accetti di pagare tempo di apprendimento.
Ed è qui che la questione economica diventa brutale.
Se un senior aumentato dall'IA produce dieci volte di più, quante aziende accetteranno ancora che un junior vada dieci volte più lentamente perché deve imparare? Quante accetteranno che qualcuno passi una giornata su un problema che l'IA può aggirare in pochi minuti? Quante preserveranno la lentezza necessaria alla formazione, mentre il mercato spinge a consegnare sempre più velocemente?
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, arbitrare e inventare. Ora queste persone non nascono dal semplice pilotaggio di un assistente. Si costruiscono con anni di pratica, errori, revisioni, decisioni difficili e feedback del reale.
Se l'IA aumenta i senior esistenti ma indebolisce la formazione dei junior, non minaccia solo alcuni posti 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 formassero uno stock stabile. Basterebbe documentarle, metterle in file di direttive per l'IA, poi chiedere agli assistenti di applicarle.
Ma le buone pratiche non sono fisse.
Nascono quando il campo cambia. I design pattern classici hanno risposto a un certo mondo software. Poi il cloud, i sistemi distribuiti, l'asincrono, i microservizi, le architetture event-driven hanno fatto emergere altri problemi. È stato necessario inventare nuovi modi di pensare: idempotenza, retry, circuit breaker, saga, osservabilità, resilienza distribuita.
Queste pratiche non sono apparse perché qualcuno le ha semplicemente chieste a uno strumento. Sono nate da sistemi reali, da guasti, incidenti, migrazioni difficili, vincoli operativi, compromessi dolorosi.
L'IA potrà probabilmente aiutare a formulare i prossimi pattern. Potrà confrontare soluzioni, individuare ricorrenze, documentare pratiche emergenti. Ma potrà inventarli da sola, prima che il campo le abbia rese necessarie e comprensibili?
Non ne sono sicuro.
Per inventare una buona pratica, non basta conoscere le precedenti. Bisogna sentire perché non bastano più. Bisogna essere stati esposti alla resistenza del reale. Bisogna sapere quando un pattern è una risposta elegante e quando è solo complessità inutile.
La semplicità stessa è una competenza senior.
Un'IA può proporre una soluzione troppo complessa, poi riconoscere immediatamente che una soluzione più semplice è migliore se glielo si fa notare. Ma bisogna ancora che qualcuno lo veda. Bisogna ancora qualcuno che dica: questo problema non merita questa architettura. Bisogna ancora qualcuno che preferisca una soluzione meno brillante, ma più giusta.
Produrre di più, per fare cosa?
La velocità di generazione non è la velocità di consegna.
Un team può ritrovarsi con decine di pull request create nella notte dall'IA. Ma chi le rilegge? Chi verifica gli impatti? Chi comprende le scelte? Chi testa gli scenari tortuosi? Chi arbitra cosa deve davvero andare in produzione? Chi si assicura che l'utente possa assorbire questa complessità?
Produrre più codice non è necessariamente produrre più valore.
C'è una tentazione competitiva evidente. Se un concorrente lancia una feature in tre giorni, come accettare che un team impieghi 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 i suoi utenti come per i suoi team, se si aggiungono funzionalità più velocemente di quanto non si comprenda il loro utilizzo. 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 ciò che fabbrica.
L'IA sposta quindi i colli di bottiglia.
Il codice diventa più veloce. Ma la revisione, la sicurezza, il cadrage funzionale, l'integrazione, la comprensione e l'assorbimento umano restano limitati. Forse diventano persino più critici.
La ricostruibilità come criterio di qualità
Nel mio uso recente, ciò che mi ha rassicurato non è solo aver prodotto un'applicazione. È aver imposto punti di ancoraggio.
Ho insistito sui contratti tra API. Ho spinto l'IA a produrre i set di test, poi la piramide di test, prima di sviluppare. Ho cercato di mantenere una separazione netta tra il dominio di business e lo strato operativo tecnico. Non sono arrivato a un approccio DDD completo, perché il progetto non lo giustificava, ma ho rifiutato che il business fosse semplicemente disperso negli endpoint.
Perché?
Perché un sistema davvero compreso è un sistema che si saprebbe ricostruire.
Se domani devo estrarre questa applicazione verso un'altra tecnologia, so dove sono i contratti, dove sono le regole di business, dove sono i test che descrivono il comportamento atteso. Non è tutto perfetto, ma il sistema non è solo un ammasso di codice generato. Contiene appigli. Punti di riferimento. Linee di separazione.
È forse un criterio centrale per lo sviluppo assistito dall'IA: non chiedere solo «funziona?», ma «saprei ricostruirlo?»
Se la risposta è no, allora manca qualcosa.
Reintrodurre volontariamente la difficoltà
Non bisogna solo imparare a sviluppare con l'IA. Bisogna anche, a volte, imparare senza di essa.
Non per nostalgia. Non per difendere una visione eroica dello sviluppatore che soffre per meritare il proprio mestiere. Ma perché una competenza che non incontra mai la difficoltà diventa fragile.
Accettiamo volentieri questa idea altrove. In matematica, la calcolatrice è utile, ma imparare senza mai fare un'operazione da soli produce dipendenza. Nello sport, si aggiungono volontariamente vincoli, pesi, resistenza, perché è questa resistenza che sviluppa i muscoli.
Lo sviluppo avrà bisogno della stessa logica.
Dojo senza IA. Esercizi con IA limitata. Revisioni in cui bisogna spiegare il codice senza chiedere all'assistente di farlo al proprio posto. Momenti in cui si prende volontariamente il tempo di leggere, capire, semplificare.
L'obiettivo non è rallentare ovunque. L'obiettivo è rallentare nel posto giusto.
Forse i team di domani dovranno assumere un ritmo ibrido: produrre molto velocemente per parte del tempo, ma riservare del tempo lungo per capire ciò che è stato prodotto. Una giornata di miglioramento continuo. Momenti soli di fronte al codice. Revisioni di architettura. ADR. Refactoring lenti. Post-mortem di generazioni fallite.
Prima dell'IA, questo tempo lungo mancava già troppo spesso. Molti sviluppatori restavano col naso nel manubrio, a produrre senza prendere abbastanza distanza per crescere professionalmente. L'IA può aggravare questo problema se serve solo a riempire tutto lo spazio guadagnato con ancora più produzione. Ma può anche diventare un'opportunità se ci obbliga a distinguere meglio il tempo del fare e il tempo del capire.
Alcune regole semplici per mantenere il controllo
Se i team vogliono usare l'IA senza perdere la loro profondità, sarà probabilmente necessario inventare una disciplina esplicita. Non una burocrazia. Un'igiene della comprensione.
Alcune regole mi sembrano già utili.
Innanzitutto, non fare mai il merge di codice che nessuno sa spiegare. È semplice, quasi brutale, ma essenziale. Se un team accetta codice incompreso, accetta un debito di comprensione.
Poi, prevedere un piccolo budget di comprensione per feature: il contratto, i test, la decisione di architettura, i limiti noti. Non una documentazione interminabile. Giusto abbastanza perché il ragionamento resti umanamente trasmissibile.
Bisogna anche collegare i test al funzionale. Un test generato può essere molto pulito e validare una comprensione sbagliata del bisogno. Il ciclo dovrebbe essere: funzionale, test, codice, ritorno al funzionale. Più i test esprimono realmente l'uso atteso, più il codice ha probabilità di restare vicino al valore.
Bisogna mantenere una mappatura dei pattern autorizzati dal team. 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 inventare il proprio modo di fare, e il team manterrà più architetture senza ragione.
Bisogna infine analizzare i fallimenti dell'IA. Quando produce una soluzione troppo complessa, quando dimentica i test, quando mette il business nel posto sbagliato, non si dovrebbe solo correggere. Si dovrebbe capire il segnale mancato, aggiustare le direttive, arricchire le pratiche.
L'IA può scrivere codice. Ma il team deve restare proprietario del ragionamento.
Capire dieci volte meglio
Non credo che lo sviluppo software andrà a fondo a causa dell'IA.
Credo invece che certi team si anneghino nel codice che non capiscono abbastanza. Avranno prodotto velocemente. Avranno consegnato cose visibili. Avranno forse persino impressionato il loro mercato per un certo tempo. Poi scopriranno che la velocità non sostituisce l'architettura, che i test valgono solo se esprimono il bisogno giusto, che la sicurezza vive nei casi tortuosi, che il legacy richiede una comprensione storica, e che i senior non si fabbricano sopprimendo i compiti che formavano i junior.
La vera sfida non è quindi rifiutare l'IA. Sarebbe assurdo. È troppo utile, troppo potente, troppo presente già.
La vera sfida è non abbandonarle i meccanismi che producono competenza.
Se l'IA ci permette di produrre dieci volte più velocemente, allora dovrebbe anche obbligarci a riservare tempo per capire dieci volte meglio ciò che produciamo. Altrimenti, non avremo solo accelerato lo sviluppo software. Avremo accelerato l'oblio di ciò che permette di sviluppare bene.
Per saperne di più
Code centric La qualità appartiene a chi consegna Zero bug: smettiamo di gestire scorte di difetti