Da Bill Atkinson a Cursor.AI: il ritorno della democrazia del codice.
Negli ultimi 50 anni ci sono stati due momenti in cui era possibile per chiunque "programmare un computer" per risolvere problemi personali. Ora sta arrivando il terzo.
Mi piacerebbe affrontare un tema sicuramente contemporaneo. Vorrei, cioè, provare a spiegare perché sono convinto che (un certo tipo di) AI possa favorire il ritorno della democratizzazione dello sviluppo software. Non è la prima volta che questo accade. Per capirlo facciamo un salto indietro di 46 anni.
Siamo nel 1980 e il ventottenne Bill Atkinson mostra il suo badge numero 51 alla guardia all’ingresso che, salutandolo, gli consente l’accesso alla Texaco Tower. Ci troviamo a Cupertino, in California. L’edificio non assomiglia per nulla ad una torre, ma è l’unico palazzo Apple con più di un piano. E in più si trova di fianco ad un distributore di benzina Texaco.
Gli angoli arrotondati sono ovunque!
Mentre Bill carica il dischetto da 5 pollici e un quarto nel prototipo del computer Lisa, la lunga barba di Jef Raskin incornicia un volto scettico. Al suo fianco il fragile e geniale Burrell Smith é così eccitato che non riesce ad infilare nel verso giusto il connettore RJ-45 della tastiera. Il badge di Raskin riporta il numero 282 ma gli piace imporsi come una figura autorevole. In fondo è l’unico in grado di tenere testa alla sola persona in quella stanza che indossa una camicia: Steve Jobs.
Bill si aggiusta gli occhiali e avvia il programma. Sullo schermo del Lisa appaiono, in sequenza, una serie di ovali sovrapposti. La velocità di disegno è strabiliante tanto che Smith si mette a saltellare sul posto. Raskin non distoglie lo sguardo dallo schermo e, con la sua voce da baritono, chiede: “come diavolo hai fatto?”.
Il calcolo della circonferenza di cerchi ed ellissi richiede l'estrazione di radici quadrate, ma il processore del Lisa, un Motorola 68000, non include un’unità in virgola mobile. La tecnica di Bill sfrutta il fatto che la somma di una sequenza di numeri dispari sia sempre il quadrato perfetto successivo (ad esempio, 1 + 3 = 4, 1 + 3 + 5 = 9, 1 + 3 + 5 + 7 = 16, ecc.). In questo modo, poteva capire quando aumentare il valore della coordinata dipendente iterando in un ciclo fino al superamento di una soglia. Atkinson gli risponde con un sorriso: “beh, magia!”
Jobs è l’unico che non sembra molto impressionato. Dalla sua scrivania e senza guardare nessuno in faccia, chiede: “Ok, quindi ora possiamo fare rettangoli con i bordi arrotondati?”. Atkinson è deluso, anzi furioso. Spiega che è impossibile. Tutti si preparano per la classica sfuriata di Jobs, ma lui prende la giacca e esce dall’ufficio: “Forza seguitemi.” Raggiungono la sua Mercedes (parcheggiata, come al solito, nello stallo riservato ai portatori di handicap) e in qualche modo riescono a salire tutti per un giro dell’isolato. Jobs, capelli al vento, deve alzare la voce per farsi sentire: “Guardatevi intorno. Tutto quello che vediamo è fatto di rettangoli arrotondati!”. All’ennesimo cartello stradale con i bordi arrotondati, Atkinson si arrende.
Il giorno seguente, con gli occhi pesti da una notte di lavoro, Bill mostra sullo schermo dello stesso computer, una serie di rettangoli con angoli smussati. Stavolta Jobs si alza in piedi e applaude platealmente. Il Macintosh era in grado di disegnare elementi e di farlo velocemente. Jobs appoggia una mano sulla spalla di Atkinson: “Decidi tu come chiamare queste funzioni.” Atkinson crolla, esausto, sulla sedie a rotelle e pensa che sono funzioni che disegnano in modo dannatamente veloce. Con un sorriso sospira “Quickdraw”.
Quindi? Cosa è successo?
L’idea comune di computer, fino a quei giorni, è quella di una schermata di testo verde su uno sfondo nero. Molti elaboratori sono già in grado di disegnare, ma viene considerata un’attività accessoria, magari per rappresentare un report o un grafico. Si, esistono giochi, lo stesso Apple II ne è pieno, ma il codice che serve per disegnare la grafica è estremamente specifico e adatto allo scopo.
Certo ci furono altri tentativi di proporre un’esperienza grafica. Oltre al famoso Xerox Alto da cui Apple rubò prese ispirazione per la propria UI, esistevano molte proposte che consentivano di utilizzare pulsanti, menù, finestre sovrapposte. Ma nessuna di queste obbligava il programmatore ad utilizzarle. Le routine di Bill Atkinson rappresentarono il primo strato necessario, il primo framework diremmo oggi, per consentire ad un utente di fruire un’applicazione software.




“Lisa” prima, e “Macintosh” dopo, offriranno, per la prima volta, l’intera esperienza di utilizzo in formato grafico. Per riuscirci sono necessarie funzioni di base che siano flessibili e, sopratutto, veloci. E come se non bastasse, devono poter girare negli esigui 128k di spazio di quei computer. Quickdraw è il mattone che abilita tutto questo.
Perché lo sto raccontando?
Perché per la prima volta viene definita una libreria, cioè uno strato, da studiare obbligatoriamente, per poter mostrare un risultato sullo schermo. Da quel momento in avanti ogni sistema operativo inizia a dotarsi di primitive grafiche, cioè pezzi di codice che hanno la responsabilità di disegnare, per esempio, pulsanti con i bordi arrotondati (ma anche menù a discesa, barre di scorrimento, dialog modali, ecc).
Il mondo dimenticato dei programmi personali
Oggi ci resta quasi difficile immaginarlo, ma prima di quei giorni è esistito un lungo periodo in cui “usare un computer” significava (anche) scrivere dei programmi, per lo più in uno dei vari dialetti del BASIC, per rispondere a necessità molto personali. Tipo …
Sono un appassionato di cinema e ho un’ampia videoteca Betamax di film collezionati nel tempo. Quando li presto rischio di perderne traccia, allora mi creo un programma personale per gestire le videocassette e ricordarmi a chi le ho prestate.
Sono un professore di scuola media e passo un sacco di tempo a compilare le pagelle, allora realizzo un piccolo registro scolastico, classe per classe, per consentirmi di inserire i voti e calcolare in automatico le medie.
Per soddisfare queste necessità oggi cercheremmo soluzioni pre-esistenti, sperando di trovare qualcosa di gratis. L’idea di poter scrivere un programma da soli non ci attraverserebbe la mente.
Prima di Macintosh, invece, le strade erano due:
ok, me lo scrivo da me;
ok, cerco qualcuno che possa scriverlo per me
E questo era possibile perché la rappresentazione a video delle informazioni era basilare e l’interazione con l’utente avveniva esclusivamente tramite tastiera. Non c’erano, cioè, strati tra il “codice” e la sua rappresentazione a schermo.
Da quel giorno alla Texaco Tower la distanza tra la scrittura di un programma e l’interazione con l’utente ha iniziato ad allungarsi. Il mondo ha guadagnato un nuovo approccio per creare una relazione con l’utente, visuale ed elegante, multilivello e più ricco di informazioni, ma, nel farlo, ha perso uno dei modi più “personali” di utilizzare un personal (appunto) computer.
Sembra una questione superficiale
Sopratutto agli occhi di noi utenti del 2025. Ma smettere di programmare, anzi associare la parola “programmazione” ad un compito per specialisti, ha concentrato un potere nelle mani di poche persone.
Il termine “potere” qui va inteso nella sua accezione più ampia: l’estensione della possibilità. In un’epoca di centralizzazione delle informazioni, della conoscenza e, quindi, in un mondo in cui la censura intenzionale è sempre ad un click di distanza, saper sfruttare dei dispositivi per risolvere necessità individuali o quelli di una piccola comunità significa avere il potere di sperimentare approcci scardinanti e percorrere strade alternative.
Al giorno d’oggi, il professore del nostro esempio non avrebbe alcun problema nel calcolare le medie dei voti, ma, magari, potrebbe voler offrire esperienze diverse ai propri studenti …
Sono un professore di scuola media e mi piacerebbe organizzare una gara di video-reel per consentire ai ragazzi di acquisire competenze di comunicazione, evitando però di esporre i contenuti a piattaforme social
Quel professore avrebbe potuto chiedere alla scuola un finanziamento per coinvolgere uno sviluppatore professionista per realizzare questa piccola applicazione web. Sentendosi rispondere che non ci sono soldi.
Quindi? Che si fa?
Per capire quali opzioni ci sta offrendo oggi l’AI è necessario tornare di nuovo indietro nel tempo. Ritorniamo indietro, questa volta, di 38 anni. Siamo nel 1987, quando le interfacce grafiche per computer sono un’esperienza condivisa. Macintosh è una realtà. Anche se è stato lanciato nel 1984, sta guadagnandosi un suo mercato solo ora. Microsoft inizia a distribuire Windows 2.0, la prima versione che riscuote successo. L’interazione con un computer richiede sempre più universalmente l’utilizzo di un mouse. Per scrivere programmi “personali” servono più conoscenze, più competenze.
Il protagonista di questo pezzo della storia è di nuovo lui, Bill Atkinson. Probabilmente si rende conto di aver avuto una qualche responsabilità nella creazione dei numerosi strati che hanno allontanato gli sviluppatori casalinghi dalla programmazione. Ed è intenzionato a cambiare le cose.
Atkinson realizza quello che noi oggi chiameremmo un “ambiente di sviluppo” e lo chiama HyperCard. L’idea è semplice: ci sono una serie di schede (raccolte in un fascicolo, uno “stack”) che si possono popolare con testo, grafica, pulsanti e suoni. Ogni elemento può essere cliccabile e l’azione che viene innescata è descritta in un quasi-inglese. HyperTalk, il linguaggio di programmazione evitava di ricordarsi sintassi complesse.
Per fare un esempio, se voglio creare una variabile chiamata “nome”, aggiungo un campo di testo in una scheda (magari una di quelle che non vengono raggiunte dalla navigazione principale) e lo chiamo “nom”. Poi sulle “azioni” associate ad un pulsante scrivo questo:
put ‘michele torbidoni’ into nome
Se ora voglio appendere il cognome appena inserito in una lista di nomi creati, aggiungo un componente lista chiamato “cognomi” (sempre in quella scheda nascosta) e scrivo:
put the second word of nome into cognomi
E se voglio mostrarlo a schermo, metto un nuovo campo “nome mostrato” sulla scheda principale e scrivo:
put name into field ‘nome mostrato’
Scrivere in un quasi-inglese colloquiale, utilizzare contenitori comprensibili per immagazzinare e gestire i dati, offre di nuovo ai non-programmatori, quello spazio di libertà sufficiente a sfruttare la potenza di un computer per le proprie necessità personali.





E così una nuova ondata di utenti ritorna a programmare. Docenti, ricercatori universitari, appassionati e hobbisti creano una quantità letteralmente sterminata di stack. In un mondo pre-internet si scambiano floppy disk con “stack” per ogni scopo.
Atkinson aveva scritto HyperCard per lo più da solo e lo concesse all’allora presidente di Apple, John Sculley (Steve Jobs era stato allontanato all’inizio di quell’anno) con l’unica clausola di includerlo gratuitamente all’interno di ogni Macintosh. Fu un vero successo.
Perché, allora, HyperCard non è ovunque oggi?
Perché non ha saputo interpretate l’avvento del World Wide Web, nonostante il concetto di ipermedialità e ipertesto facesse parte del tessuto del progetto.
HyperCard perse terreno, Apple inizio a non regalarlo più trasformandolo in un prodotto a pagamento, finché, a fine 1999, l’applicazione scomparve dai radar di qualsiasi utente.
La scrittura di un programma utilizzabile attraverso un computer tornò ad essere un operazione complessa, accessibile solo a coloro interessati a studiare molto e acquisire una competenza specifica. Il mondo degli appassionati, del rest-of-us sopravvisse per un po’ in alcune nicchie (qualcuno ricorderà i programmi in “Access” e, ancora oggi, c’è chi scrive fogli di calcolo complessi in “Excel”), ma niente di questo può essere paragonato ad un’esperienza applicativa completa e soddisfacente.
Fino a oggi.
La terza volta. Tornare a scrivere programmi personali.
Se QuickDraw ha reso “obbligatoria” una base grafica condivisa, HyperCard ha restituito agli utenti un modo colloquiale per programmare. Se oggi il panorama di interazioni tra reti e framework è troppo complesso per programmi personali, la terza ondata arriva dagli ambienti di sviluppo potenziati da AI. Qui il ponte non è tra “codice e schermo”, ma tra “intento e codice”: descrivi ciò che vuoi in linguaggio naturale e l’ambiente ti aiuta a trasformarlo in un progetto funzionante.
Cursor.AI, in breve.
Uno dei protagonisti di questa terza fase è Cursor.AI. Nasce nel 2022 con l’idea semplice e radicale di spostare il baricentro di un ambiente di sviluppo dal codice al contesto. È un editor progettato attorno a modelli linguistici (GPT‑4, Claude, e modelli proprietari) che “leggono” il tuo codice, capiscono file, dipendenze e test, e agiscono come un copilota operativo: completano funzioni, generano componenti, scrivono test, spiegano errori, e — cosa cruciale — iterano le modifiche dialogando con te in italiano o inglese. Non è un’automazione cieca: il flusso è conversazionale. Tu definisci l’intento (“Voglio una piccola web‑app che gestisca i reel senza social, con login locale e moderazione”), Cursor propone architettura e interazione tra vari strati. Tu confermi o correggi, lui implementa e documenta. L’approccio è pragmatico: ridurre l’attrito tra desiderio e codice, facendo dell’IDE un facilitatore, non un sostituto.
Cursor.AI risponde ad una domanda estesa e condivisa. Per questo è un successo: nel 2025 Anysphere ha raggiunto la valutazione di circa 29 miliardi. È la cifra che ha consacrato Cursor come uno dei progetti AI più finanziati nello sviluppo software.
Perché è (di nuovo) democratizzazione
Utilizzando questo tool ho da poco completato un prototipo funzionante per testare un gioco da tavola a cui sto lavorando. Cursor.AI mi ha consentito di farlo in modo efficace con un netto abbattimento dei costi e con una spiccata autonomia decisionale. Anche solo un anno fa non avrei avuto questa possibilità e sarei stato costretto a coinvolgere dei professionisti. Certo, il codice che sto utilizzando non è perfetto, non credo sia production-ready, ma nemmeno quello che avrei realizzato con HyperCard o in BASIC lo sarebbe stato.
Sistemi come Cursor.AI abbassano le soglie: meno sintassi da ricordare, più obiettivi da descrivere. Come HyperTalk, ma in grado di operare in contesti moderni. Si accetta che l’errore faccia parte del flusso: l’AI propone, tu validi. La competenza umana resta nel giudizio e nel contesto d’uso.
Proprio qualche giorno fa Cursor.AI ha annunciato la possibilità di lavorare sul “design” visuale dell’applicazione, sfumando ulteriormente le barriere tra intenzione e “messa a terra” del codice funzionante.
Un docente, un maker, un amministratore di comunità possono prototipare soluzioni su misura, senza attendere budget o prodotti “mainstream”. E quello che viene realizzato rimane sul proprio computer.
Quella gara di video‑reel scolastici, senza piattaforme social?
Ecco, oggi quel professore può realizzarla in autonomia. È importate avere le idee chiare (come avrebbe dovuto averle chiunque avesse scritto un programma in BASIC nel 1980 o uno stack HyperCard nel 1987). È necessario descrivere requisiti e vincoli (privacy, login, upload, moderazione, votazioni locali). Ma poi si lascia che Cursor generi struttura, moduli e test.
Non è magia, non funzionerà tutto e subito. È richiesta attenzione e test. Il ruolo umano è la chiave abilitante per raggiungere lo scopo. Ma come il BASIC prima e HyperCard poi hanno trasformato l’intenzione in codice, questi strumenti trasformano obiettivi in codice conversando. E rimettono nelle mani degli utenti il potere di immaginare soluzioni a questioni personali.
Ci sono molti temi ancora da risolvere. In particolare questi tool di sviluppo AI hanno una forte dipendenza da modelli proprietari che comportano questioni di sicurezza e licenze. La strada è ancora lunga, ma, ehi!, l’AI mi ha messo, di nuovo, in mano la possibilità di trasformare un’idea in un programma.
E, beh, è una bella sensazione.







