Tutti quanti voglion fare i dev!

Da qualche tempo si sta diffondendo l'idea che con l'intelligenza artificiale chiunque può costruire un'applicazione senza sapere programmare. La promessa è molto seducente: a colpi di prompt generiamo codice e trasformiamo un'idea in un prodotto.

Non è un caso che questa visione abbia preso così rapidamente piede e abbia fatto nascere servizi come Lovable.dev, Blot.new, v0, ecc. Ogni nuova evoluzione della tecnologia che avvicina la distanza tra idea e software tende a far apparire il lavoro degli sviluppatori come un rito arcano da smontare con una formula più semplice.

C'è qualcosa di familiare in tutto questo. Qualcosa che mi suggerisce il verso di quella canzone che ha accompagnato alcuni di noi da bambini, con il suo entusiasmo un po' infantile: tutti quanti voglion fare jazz!

https://www.youtube.com/watch?v=wk1qIwSbr7A

Oggi sembra che tutti quanti vogliano fare i dev. Il punto è se tutti quanti possono fare i dev.

Al di là della battuta, il tentativo di rendere la programmazione accessibile a tutti è una storia vecchia, che non nasce certo con l'avvento dell'AI.

Un mondo senza sviluppatori

L'idea che l'evoluzione della tecnologia possa rendere accessibile la programmazione è uno dei corsi e ricorsi della storia dell'informatica. Ogni volta che appare una nuova astrazione, qualcuno proclama che il lavoro di chi scrive software sta per diventare obsoleto. A volte la promessa è accattivante, altre volte è solo un modo elegante per vendere un nuovo strumento. Però il nucleo resta sempre lo stesso: se il computer si avvicina sempre più alla comprensione del linguaggio umano, allora forse non servono più quelle competenze tecniche che sembrano indispensabili.

Ho visto questo schema ripetersi più volte. Una demo si fa in mezz'ora, un prototipo sembra funzionare, e all'improvviso l'idea di un'applicazione appare alla portata di chiunque. La cosa è affascinante, ma il problema è che quello che si vede all'inizio è spesso solo la parte più esteriore del lavoro: l'interfaccia, la schermata, il flusso di interazione. Quello che resta nascosto è il lavoro più difficile, quello che decide se l'applicazione regge davvero quando entra realmente in produzione.

Le promesse del passato

Se guardiamo indietro, la storia dell'informatica è piena di ondate che hanno annunciato la fine dei programmatori. Queste ondate non hanno eliminato la professione, ma l'hanno trasformata. E quella trasformazione dovrebbe servire proprio come lezione per capire ciò che sta succedendo oggi con l'AI.

COBOL e il linguaggio quasi naturale

Negli anni '50 e '60, quando programmare significava lavorare con hardware, assembly e logica matematica, nacque il COBOL. Il suo obiettivo era chiaro: rendere la programmazione più vicina al linguaggio comune, così che chi gestiva un'azienda potesse esprimere delle regole in modo più naturale. L'idea era che un manager potesse descrivere la logica di un processo in inglese e il computer avrebbe fatto il resto.

Quella promessa non si realizzò nel modo immaginato. Non comparve un mondo in cui tutti scrivevano software come si scrive una lettera. Quello che accadde, invece, fu un'altra cosa: nacque un vasto ecosistema di specialisti che sapevano usare quel linguaggio in modo rigoroso, efficiente e sostenibile. In altre parole, la barriera che ostacolava l'accesso alla programmazione del computer non sparì, ma si spostò.

SQL e i linguaggi di quarta generazione

Negli anni '70 e '80, con la diffusione dei database, arrivarono i linguaggi di quarta generazione e SQL. L'idea era semplice: invece di spiegare al computer ogni passo della procedura, bastava dichiarare cosa si voleva ottenere. In teoria, un utente non tecnico poteva chiedere qualcosa al database e ottenere un risultato. In pratica, però, scrivere query corrette, gestire schemi complessi e capire come i dati si collegano tra loro richiede una forma di ragionamento molto più profonda di quanto non sembri a prima vista.

Il risultato fu che il linguaggio diventò più accessibile, ma la necessità di competenza non scomparve. Anzi, si fece più specializzata. Nacquero nuovi ruoli, nuovi professionisti, nuovi problemi da gestire. Il computer continuava a fare la sua parte, ma la capacità di pensare in modo ordinato e preciso restava essenziale.

HyperCard e il sogno della programmazione democratica

Negli anni '80, HyperCard sembrò davvero una rivoluzione. Con una metafora semplice, quella delle schede, e un linguaggio leggibile, prometteva di mettere la creazione di software nelle mani di chiunque. Insegnanti, artisti, studenti, persone comuni: tutti potevano costruire applicazioni interattive, giochi o strumenti didattici senza avere una formazione informatica approfondita.

Il sogno era suggestivo, e in parte funzionò. HyperCard fu un enorme strumento di creatività e ispirò l'evoluzione del web e delle prime forme di collaborazione digitale. Ma quando si trattava di costruire qualcosa di davvero robusto, scalabile o professionale, il sistema si scontrava con limiti tecnici e organizzativi. La democrazia della programmazione restava una promessa più bella della realtà industriale.

CASE e il sogno di un software più guidato

Tra gli anni '80 e gli anni '90, un'altra promessa provava a rendere lo sviluppo più accessibile: quella degli strumenti CASE (Computer-Aided Software Engineering). L'idea era semplice: se un sistema potesse aiutare a disegnare il flusso di un'applicazione, generare parti di codice e guidare la progettazione, allora anche chi non era un esperto avrebbe potuto costruire software in modo più strutturato.

In pratica, però, i CASE non hanno cancellato il bisogno di competenza. Hanno semplificato alcuni passaggi, soprattutto nella fase di analisi e progettazione, ma non hanno sostituito il lavoro di chi sa vedere il problema nel suo complesso.

Visual Basic e l'era del drag and drop

Negli anni '90, Visual Basic rese la creazione di applicazioni desktop quasi una questione di drag and drop. Era la versione moderna del sogno: bastava disegnare una finestra, mettere un pulsante e dire al computer cosa fare quando quel pulsante veniva premuto. Per molti, sembrò il momento in cui la barriera tra utente e sviluppatore si sarebbe definitivamente dissolta.

In parte fu così. In parte, però, si aprì un'altra storia. Molte applicazioni nate in quel modo erano veloci da costruire, ma fragili se non supportate da una solida architettura. Quando un sistema cresce, non basta più sapere come far comparire una finestra. Serve saper definire una architettura, manipolare lo stato, gestire gli errori, fare manutenzione, garantire qualità del codice. La semplicità iniziale non cancellò il problema delle competenze tecniche, lo rinviò a una fase successiva della vita del prodotto.

Il no-code e il mito del citizen developer

Negli anni 2010, con la diffusione del Web e delle API, il no-code e il low-code hanno portato avanti una nuova promessa. Piattaforme come Bubble, Webflow o Zapier hanno suggerito che anche chi non sa programmare potesse costruire strumenti personali, automazioni o vere e proprie applicazioni. Era l'idea del citizen developer: una persona di business che, senza passare per l'IT, crea la propria soluzione.

Anche qui la realtà fu più sfumata. Queste piattaforme sono straordinarie per prototipare, automatizzare piccoli processi e creare esperienze semplici. Ma appena un progetto richiede integrazioni complesse, sicurezza, scalabilità o logica non banale, il limite appare subito. Le persone riescono a muoversi nel sistema, ma non sempre ad averne un ampio controllo.

L'AI non è la fine della programmazione

Oggi l'AI sta rendendo più semplice costruire una prima versione di un'applicazione, ma non sta eliminando il lavoro dello sviluppatore. Quello che cambia è il modo in cui si lavora, come accennavo in un altro articolo: meno tempo speso a scrivere codice, più tempo dedicato a capire il problema, definire i requisiti, guidare gli strumenti e verificare il risultato. Le competenze che contano oggi non sono solo quelle di scrivere codice, ma anche quelle di scegliere la soluzione più adatta al contesto, anticipare gli errori e capire se un sistema regge davvero.

Chi usa l'AI può produrre software più velocemente, ma non sempre sa dire se quel risultato è corretto, sicuro o sostenibile. E proprio qui si vede la differenza. Un principiante può far funzionare qualcosa di semplice. Uno sviluppatore con esperienza sa anche spiegare perché quel sistema regge, dove può rompersi e come evitarlo.

La storia dell'informatica ci ha già insegnato che ogni nuova tecnologia fa un passo avanti verso l'accessibilità dello sviluppo software, ma non elimina la necessità di competenze specifiche. Cambia il tipo di competenza richiesta, ma non la sua importanza.