Nota sulla stesura di questo articolo

Sì, questo articolo è stato scritto con l’aiuto dell’IA. Tuttavia, le idee, le opinioni e le esperienze espresse sono interamente mie. Il testo nasce da lunghe discussioni preliminari durante le quali ho sviluppato il mio pensiero, risposto a domande e precisato il mio punto di vista. L’IA è servita principalmente a organizzare e formulare questo materiale sotto forma di articolo. In seguito ho riletto, corretto e approvato l’intero testo prima della pubblicazione.

Non sono un bravo sviluppatore. Ed è proprio per questo che l’IA ha cambiato il mio modo di creare

Comincerò da qualcosa che potrebbe sembrare strano detto da una persona che sviluppa applicazioni da diversi anni: non mi considero uno sviluppatore particolarmente bravo.

Non è falsa modestia e non lo dico perché qualcuno venga a spiegarmi che soffro della sindrome dell’impostore e che in realtà sono eccezionale.

Ho davvero delle lacune tecniche. Non sono particolarmente bravo con gli algoritmi, non ho mai avuto una grande facilità con l’astrazione informatica o con la matematica, e non sono il tipo di persona che apre un editor e comincia a costruire mentalmente un’architettura complessa da zero.

Eppure sviluppo software.

Anche parecchio, in realtà.

Ed è proprio per questo che trovo interessante la mia esperienza con gli LLM.

Sviluppavo già prima di ChatGPT

Ho iniziato con un bootcamp nel 2020-2021 incentrato su HTML, CSS, JavaScript, PHP e Symfony.

Poi, come molti sviluppatori autodidatti o provenienti da percorsi di formazione brevi, ho continuato a imparare facendo.

Durante uno stage di sei mesi presso Plastic Omnium, ero l’unico sviluppatore. Ero stato assunto dal reparto IT del sito, che si occupava soprattutto di amministrazione di sistema e aveva bisogno di piccole soluzioni web interne.

Ne ho sviluppate diverse.

La prima era un’applicazione molto semplice che permetteva di confrontare dei codici a barre. Se i due codici coincidevano, lo schermo mostrava un enorme messaggio verde. In caso contrario, mostrava un enorme messaggio rosso. L’obiettivo era semplicemente evitare alcuni errori durante la spedizione dei pezzi.

Ho anche sviluppato un’applicazione Symfony per la gestione degli operai della fabbrica, con la creazione dei profili e l’assegnazione alle postazioni di lavoro.

Infine, ho realizzato un’interfaccia collegata a SQL Server che mostrava in tempo reale la produzione di diverse celle produttive su uno schermo diviso in quattro sezioni.

Tutto questo esisteva prima che gli LLM diventassero di uso comune.

Quindi no, l’IA non mi ha improvvisamente permesso di passare da zero conoscenze alla creazione di applicazioni.

Ma il modo in cui sviluppavo all’epoca era già piuttosto rivelatore.

Guardavo tutorial su Udemy e YouTube. Cercavo su Google. Quando rimanevo bloccato, andavo su Stack Overflow. Trovavo qualcuno che aveva incontrato un problema simile, cercavo di adattare la risposta al mio caso e andavo avanti.

Riuscivo a produrre qualcosa di funzionante senza necessariamente comprendere a fondo tutto ciò che utilizzavo.

Ripensandoci, Internet aveva già iniziato a esternalizzare una parte delle mie competenze.

Non avevo tutte le conoscenze in testa. Sapevo soprattutto dove cercarle e come assemblarle abbastanza bene da ottenere il risultato che volevo.

Poi sono arrivati gli LLM.

Gli LLM non hanno cambiato la mia natura, hanno eliminato l’attrito

La grande differenza con ChatGPT, Claude, Gemini, DeepSeek e gli altri non è semplicemente che scrivono codice più velocemente di me.

È che quasi tutto l’attrito che esisteva tra un’idea e la sua realizzazione è scomparso.

Prima, una funzionalità poteva richiedermi diverse ore semplicemente perché avrei incontrato un problema tecnico, cercato una soluzione, letto diverse risposte, provato qualcosa, constatato che non funzionava e ricominciato da capo.

Oggi, quando rimango bloccato, posso spiegare con precisione il problema a un modello.

Se non riesce a risolverlo, ne provo un altro.

Se il contesto diventa troppo complesso, posso esportare il codice, fornire più informazioni e far analizzare il problema da diversi modelli.

Nella stragrande maggioranza dei casi, riesco a sbloccarmi molto rapidamente.

Il risultato è piuttosto paradossale: sono diventato molto più produttivo senza essere diventato proporzionalmente più bravo nella programmazione.

E direi addirittura che esiste un effetto inverso.

Cerco di capire meno di prima.

In passato, rimanere bloccato a volte mi obbligava a capire cosa stesse succedendo. Ora, il blocco spesso scompare prima che quella comprensione diventi necessaria.

Questo è probabilmente uno degli aspetti meno confortevoli del mio modo di lavorare oggi. Produco di più, ma alleno meno alcune competenze.

In realtà, non ho mai voluto davvero essere un programmatore

Per molto tempo ho associato la creazione di software all’essere sviluppatore.

Oggi faccio una distinzione molto più netta.

Quello che mi interessa davvero è il prodotto.

Quando immagino una funzionalità per LingRise, il mio primo istinto non è quasi mai chiedermi quale struttura dati usare, quale design pattern scegliere o come organizzare i componenti.

Penso prima a cosa dovrebbe offrire la funzionalità.

A come l’utente la utilizzerà.

Al perché dovrebbe esistere.

A cosa sarebbe piacevole, pratico o frustrante.

Il "come" tecnico è diventato secondario.

So che questa posizione probabilmente farà sobbalzare alcuni sviluppatori, ma per la maggior parte dei progetti che voglio creare, mi importa relativamente poco sapere se un’applicazione è costruita con Symfony, Laravel, React o qualcos’altro.

Lo stesso vale per le applicazioni mobile tra Flutter, React Native, Kotlin o Swift.

Non sto dicendo che non esistano differenze. Ovviamente esistono.

Sto semplicemente dicendo che, nel mio contesto, per la grande maggioranza dei prodotti classici che potrei voler costruire, queste differenze contano molto meno della qualità del prodotto stesso.

Non lavoro su un sistema bancario critico, su un dispositivo medico o su un’infrastruttura in cui pochi millisecondi, una particolare proprietà matematica o determinate garanzie tecniche possono diventare fondamentali.

Costruisco prodotti destinati agli utenti.

La mia domanda principale è quindi diventata: che cosa dovremmo costruire?

Non: sono tecnicamente in grado di costruirlo?

E l’IA ha accelerato enormemente questa transizione.

LingRise probabilmente non sarebbe mai esistito prima

Questo è forse il modo migliore per misurare il vero impatto dell’IA su di me.

Senza gli LLM, probabilmente non avrei mai lanciato LingRise.

Non perché il progetto sarebbe stato impossibile.

Avrei potuto imparare. Avrei potuto passare centinaia, forse migliaia, di ore in più a cercare, sperimentare e sviluppare.

Ma è proprio questo il problema.

Probabilmente non l’avrei fatto.

Il costo sarebbe stato troppo elevato rispetto alla mia motivazione per la programmazione in sé.

L’IA ha cambiato le idee che considero realizzabili.

Prima, potevi avere un’idea e pensare immediatamente alle settimane o ai mesi di sviluppo necessari.

Oggi, per me è molto più facile pensare: proviamoci.

E credo che questa evoluzione avrà conseguenze molto più importanti del semplice aumento di produttività degli sviluppatori esistenti.

Se costruire diventa più facile, avere l’idea giusta diventa più importante

Si ripete spesso che un’idea non vale nulla senza esecuzione.

Capisco cosa vuole dire questa frase, ma penso che l’IA stia progressivamente cambiando l’equazione.

Quando l’esecuzione costa enormemente, tantissime buone idee non vedono mai la luce.

Se il suo costo diminuisce, più persone possono mettere alla prova le proprie idee.

Per me, questa è una buona notizia per l’umanità.

Probabilmente esistono moltissime persone con intuizioni eccellenti, una comprensione perfetta di un problema o idee di prodotto interessanti, ma che non avrebbero mai passato due anni a imparare lo sviluppo software per realizzarle.

L’IA dà loro una possibilità.

Ovviamente, a livello personale, è un po’ meno conveniente perché significa anche molta più concorrenza.

E non sono sicuro che LingRise sfuggirà a questa nuova realtà. Mi piace molto ciò che sto costruendo e penso che il prodotto abbia un grande potenziale, ma sono perfettamente consapevole che potrebbe anche finire un giorno nell’enorme pila di prodotti SaaS che qualcuno ha costruito e che quasi nessuno utilizza.

Perché se tutti possono costruire, il problema si sposta: bisogna costruire qualcosa che le persone vogliono davvero.

E a quel punto, prodotto, design, marketing, comprensione degli utenti, strategia e creatività acquistano ancora più valore.

Ed è lì che mi sento molto più nel mio elemento.

La mia sindrome dell’impostore non riguarda tutto

Dubito moltissimo di me stesso quando si parla di sviluppo. Per quanto riguarda le astrazioni informatiche o le competenze tecniche pure, mi considero francamente mediocre.

Al contrario, non ho affatto lo stesso rapporto con l’immaginazione.

È probabilmente la qualità in cui ho più fiducia.

Mi torna spesso in mente un esempio piuttosto stupido. All’esame di maturità francese avevo praticamente studiato pochissimo, ma una delle prove chiedeva di immaginare e scrivere il seguito di un testo. Avevo preso 18 su 20.

Può sembrare aneddotico, ma rappresenta abbastanza bene ciò che mi ha sempre attratto.

Immaginare.

Creare qualcosa che ancora non esiste.

Trovare una direzione.

E il mio sogno più grande, in fondo, non è mai stato diventare uno sviluppatore eccezionale.

Mi piacerebbe un giorno scrivere un’opera memorabile, qualcosa capace di segnarmi quanto un’opera come L’Attacco dei Giganti ha segnato me.

E lì, paradossalmente, non vorrei che l’IA la scrivesse al posto mio.

Potrei usarla per rileggere un passaggio o suggerirmi una formulazione migliore, ma l’opera, i personaggi, la storia e le idee vorrei che venissero da me.

È un confine importante nel mio rapporto con l’IA.

Non ho alcun attaccamento particolare al fatto di scrivere personalmente una funzione PHP o Java se una macchina può farlo meglio e più velocemente.

Al contrario, tengo moltissimo a rimanere l’autore di ciò che considero davvero creativo e personale.

Il codice che funziona non è necessariamente buon software

Ovviamente, delegare così tanto all’IA crea un problema.

Un LLM è estremamente bravo a produrre una soluzione che funziona adesso.

Questo non significa che produca spontaneamente una soluzione di cui sarai ancora soddisfatto tra due anni.

L’ho sperimentato con LingRise.

Per una funzionalità legata all’audio, l’IA aveva scelto una soluzione tecnicamente funzionante ma pessima dal punto di vista architetturale. Aveva privilegiato la strada più diretta invece di pensare alla riutilizzabilità e alla coerenza del sistema nel lungo periodo.

Il codice funzionava. Ma la decisione era davvero sbagliata.

Questa è probabilmente una delle lezioni più importanti che ho imparato lavorando con gli LLM.

Tendono a cercare un percorso rapido verso una risposta soddisfacente.

E quando si sviluppa un vero prodotto, non è sempre quello che si vuole.

Un buon software non è soltanto codice che supera i test oggi.

È anche un sistema che potremo capire, modificare e mantenere domani.

Dopo quell’errore, ho cambiato il mio modo di lavorare.

In particolare, utilizzo molto BMAD, Breakthrough Method for Agile AI-Driven Development, per strutturare meglio il lavoro degli agenti, fornire loro più contesto e introdurre diverse fasi di controllo.

Cerco anche di prestare molta più attenzione alle decisioni che possono avere conseguenze a lungo termine.

Ed è qui che penso che il ruolo dello sviluppatore stia davvero evolvendo.

Comprendere le conseguenze diventa più importante che scrivere velocemente

Se dovessi completare una frase sull’evoluzione del mestiere, direi questo:

Con l’IA, lo sviluppatore non è più principalmente qualcuno che sa programmare velocemente, ma qualcuno che comprende le implicazioni di ogni decisione e sa guidare gli LLM in modo da non creare debito tecnico e perdere tempo.

È molto diverso.

Produrre dieci volte più codice non ha alcun valore se significa produrre un’architettura disastrosa dieci volte più velocemente.

Quando gli agenti diventano capaci di implementare una quantità enorme di lavoro, il collo di bottiglia si sposta.

Bisogna essere capaci di dire ciò che si vuole.

Di fornire i vincoli giusti.

Di individuare una decisione dubbia.

Di sapere quando chiedere una seconda analisi.

Di capire che una soluzione elegante a livello locale può creare un problema globale.

Ed è proprio qui che i miei limiti diventano pericolosi.

Posso supervisionare molte cose.

Ma so anche che esistono situazioni in cui non sono abbastanza competente per giudicare correttamente ciò che l’IA mi propone.

Preferisco ammetterlo piuttosto che fingere che qualche prompt mi abbia improvvisamente trasformato in un ingegnere senior.

Non mi fiderei dell’IA per tutto

Non ho alcuna voglia di cadere nel discorso secondo cui oggi basta avviare qualche agente per sostituire qualsiasi team di ingegneri.

Mi fido dell’IA in proporzione al costo potenziale dei suoi errori.

Se sceglie una cattiva astrazione per una piccola funzionalità e perdo tre ore, non è drammatico.

Se introduce una vulnerabilità nei pagamenti, nell’autenticazione o nella gestione dei dati degli utenti, il problema è completamente diverso.

Se LingRise funzionerà abbastanza bene e inizierà ad avere un utilizzo reale, ho intenzione di far revisionare le parti fondamentali da qualcuno realmente competente, in particolare tutto ciò che riguarda pagamenti, sicurezza e account utente.

Per me, la regola è abbastanza semplice.

Più una decisione è facile da annullare e poco pericolosa, più posso delegarla.

Più le conseguenze potenziali diventano importanti, più ho bisogno di comprensione e validazione umane.

Questo principio spiega anche perché non generalizzo la mia esperienza a tutti i settori.

Costruire una piccola applicazione SaaS e costruire un sistema bancario o medico non richiedono ovviamente lo stesso livello di cautela.

Non penso nemmeno che una laurea risolva magicamente il problema

La conclusione opposta sarebbe però altrettanto semplicistica.

Dire che sono necessari esseri umani competenti non significa che mettere dieci ingegneri qualificati in una stanza garantisca automaticamente un software eccellente.

Vediamo regolarmente sistemi costruiti da grandi organizzazioni incontrare problemi importanti.

La competenza tecnica conta moltissimo, ma è soltanto una parte dell’equazione.

Servono anche serietà, volontà, risorse, tempo, una buona organizzazione, una manutenzione adeguata e persone abbastanza motivate e ben pagate da svolgere correttamente il proprio lavoro.

Il fatto che gli esperti possano commettere errori non dimostra quindi che l’esperienza non serva più a nulla.

Dimostra semplicemente che costruire software complesso è difficile.

Con o senza IA.

Non sono nemmeno sicuro che gli LLM siano "più intelligenti" di me

Ormai mi capita di lasciare che i modelli riflettano al posto mio su un numero enorme di problemi.

Non necessariamente perché li considero intelligenti nel senso umano del termine.

Potremmo passare ore a discutere di cosa significhi davvero intelligenza.

Quello che mi interessa di più è il risultato pratico.

Dispongono di una quantità di conoscenze con cui non posso competere e di una velocità di esecuzione molto superiore alla mia.

Per tantissimi problemi, quindi, semplicemente non mi conviene più passare un’ora a riflettere da solo su qualcosa che un modello può esplorare in pochi secondi.

Ma questo crea un altro rischio.

A forza di delegare il pensiero, si rischia di diventare meno capaci di pensare autonomamente.

Lo vedo su me stesso.

È un compromesso che oggi accetto perché il mio obiettivo principale è costruire.

Chi ha come obiettivo diventare un ingegnere eccellente dovrebbe probabilmente adottare un approccio molto diverso.

Se oggi avessi 20 anni, probabilmente non sceglierei lo sviluppo software

Questa è forse la mia conclusione più personale.

Se oggi avessi 20 anni e dovessi scegliere una carriera, non credo che diventerei sviluppatore.

Non perché penso che il mestiere scomparirà.

Non ne ho idea, e diffido molto delle previsioni troppo sicure su questo argomento.

Farei semplicemente un calcolo in base al mio profilo.

Non sono appassionato del codice in sé.

Non sono eccellente in matematica o nell’astrazione.

Non provo particolare piacere nel passare ore a capire il funzionamento interno di un sistema semplicemente perché il problema è interessante.

Ciò che mi attira sono i prodotti e le idee.

In un mercato in cui moltissime persone stanno imparando a sviluppare software, in cui la concorrenza è globale e in cui le aziende possono probabilmente produrre di più con meno sviluppatori grazie all’IA, non vedo perché dovrei scegliere volontariamente di competere su uno dei miei punti deboli.

Mi orienterei molto più naturalmente verso il prodotto o verso un altro ambito in cui la mia capacità di immaginare e progettare qualcosa sarebbe più centrale.

Detto questo, non darei assolutamente questo consiglio a tutti.

Se hai 18 o 20 anni, sei eccellente nell’astrazione e ami la matematica, i sistemi, la programmazione, la sicurezza o la comprensione profonda dei computer, buttati.

L’IA potrebbe persino renderti incredibilmente potente.

Se hai ottime idee e vuoi imparare abbastanza tecnica da poterle trasformare in realtà, buttati anche in quel caso. La barriera probabilmente non è mai stata così bassa.

Ma se sei semplicemente una persona qualunque a cui lo sviluppo software è stato venduto come una facile strada verso il successo, sarei molto più prudente.

Rischi di ritrovarti in concorrenza con milioni di persone che hanno avuto esattamente la tua stessa idea, alle quali ora bisogna aggiungere macchine capaci di produrre una quantità di codice che sarebbe stata inimmaginabile soltanto pochi anni fa.

Imparare qualche framework probabilmente non basta più a costituire un vantaggio duraturo.

Forse sono esattamente il tipo di creatore che l’IA moltiplicherà

Alla fine, trovo piuttosto difficile dire se sono ancora davvero uno sviluppatore.

Costruisco software.

Prendo decisioni di prodotto.

Definisco funzionalità.

Do istruzioni agli agenti.

Faccio test manualmente.

Chiedo agli agenti di correggere quando trovo dei difetti.

A volte scelgo tra diverse soluzioni.

Tengo sotto controllo le conseguenze di certe decisioni.

Ma non scrivo più codice personalmente.

E non ho particolare voglia che questo cambi.

Forse tra qualche anno il mio profilo sarà del tutto normale.

Persone che comprendono abbastanza la tecnologia da poter dialogare con le macchine, ma il cui vero valore si trova altrove.

Nella conoscenza di un settore.

Nella comprensione di un utente.

Nel gusto.

Nella capacità di vendere.

Nella creatività.

Nell’immaginazione.

Nella capacità di individuare un problema interessante prima degli altri.

Trovo questa prospettiva allo stesso tempo entusiasmante e preoccupante.

Entusiasmante perché più persone potranno creare.

Preoccupante perché quando tutti possono costruire, costruire non basta più.

E forse, in fondo, è proprio questo che l’IA ha davvero cambiato per me.

Non mi ha insegnato ad amare la programmazione.

Non mi ha trasformato in un ingegnere eccellente.

Mi ha semplicemente permesso di dipendere meno dalle cose in cui sono mediocre, così da poter dedicare più tempo a quelle in cui penso di essere bravo.

Avere idee.

Immaginare prodotti.

Creare.

E se l’IA continuerà a progredire, forse la domanda più interessante non sarà nemmeno più se gli sviluppatori scompariranno.

Forse sarà chiedersi perché, per così tanto tempo, fosse necessario saper programmare per trasformare un’idea in qualcosa di reale.