English version here.
Antefatto
Recentemente sono andato a visitare la ricca mostra/museo dell’amico Gian Paolo Cremonesini, da una vita imprenditore nel settore IT, scrittore e artista a 360 gradi. Allestita all’interno della sede della sua azienda, è un affascinante percorso tra le macchine da ufficio che vanno dalla fine dell’Ottocento fino al recente passato. Da un punto di vista pedagogico, penso che dovrebbe essere una tappa obbligata per i giovani studenti che si affacciano al mondo dell’elettronica e dell’informatica. In poche decine di metri lineari, percorrerebbero milioni di anni uomo spesi per concepire, costruire, ingegnerizzare, produrre, programmare e manutenere queste macchine. Nell’era della diffusione capillare dell’AI — che, come era facile prevedere, sta facendo credere ai giocani che chiunque può essere un programmatore grazie al vibe coding … — sarebbe per loro estremamente istruttivo. Capire cosa voleva dire programmare queste macchine, battagliando per risparmiare ogni bit e, in generale, per gestire al meglio le scarsissime risorse hardware a disposizione (esercizio ingegneristico per eccellenza) li farebbe riflettere su cosa hanno a disposizione oggi e, penso, li farebbe vedere le cose con una maturità diversa. Cosa che è successa puntualmente anche a me in quanto, in virtù del fatto che abbia iniziato a programmare gli Z80 in assembly nei primi anni ’90, mi sentivo un “pioniere” dell’informatica … Durante la visita, infatti, Paolo mi ha raccontato di come era riuscito a sviluppare per la Olivetti P101 (nella immagine in evidenza di questo post) un programma di calcolo ingegneristico in una scheda di memoria e mezza, stracciando il programma realizzato dal suo cliente di allora che utilizzava una macchina della concorrenza: nonostante questa fosse molto più potente, gli servirono ben 4 schede di memoria con una capacità ben superiore a quelle della P101! Per capirci, la capacità della scheda (anche detta “cartolina”) della P101 è di 1920 bit. L’aneddoto di Paolo mi ha quindi riportato decisamente con i piedi per terra …
Il progetto Retriva
In questo periodo sto lavorando al progetto Retriva. Si tratta al momento di un PoC relativo ad un agente conversazionale da utilizzare in ambito business per lo sfruttamento, senza alcun uso di servizi esterni per motivi di confidenzialità, della conoscenza aziendale accumulata nel tempo sotto forma di documenti eterogenei (file Word, fogli elettronici, PDF, scansioni di documenti cartacei, foto, audio, video, ecc.). Si tratta di un classico esempio di impiego delle tecnologie RAG (retrieval-augmented generation) abbinate a LLM. Il progetto è un’ottima occasione anche per mettere in pratica le competenze che ho acquisito grazie ai corsi che ho frequentato e che sto attualmente frequentado (AI Solutions Architecture). Per la fase di design e di implementazione, sto adottando un approccio completamente AI-assisted, senza però “scadere” nel vibe coding. Piuttosto, ho optato per la filosofia spec-driven development (SDD) per i motivi illustrati qui. Credo che non serva dilungarsi oltre sul perché ritenga questa metodologia di gran lunga preferibile, a maggior ragione in un progetto di questa complessità che un domani — mai mettere limiti alla Provvidenza — potrebbe diventare qualcosa di più di un semplice esercizio svolto per passione e sete di conoscenza.
In estrema sintesi, fino ad ora ho proceduto in questo modo (nel repository GitHub linkato ci sono tutti i dettagli):
- Ho fatto una lunga sessione di brainstorming con Microsoft Copilot per giungere ad un design sufficientemente completo da coprire anche le ragionevoli evoluzioni future che il prodotto, se riuscirò a farlo funzionare in maniera per me soddisfacente, potrà avere.
- Ho dato in pasto il documento descrittivo del design a Copilot stesso perché producesse un documento di specifica aderente alle convenzioni di Google Antigravity, il coding agent che sto usando per l’implementazione.
- Ho lasciato che Antigravity facesse la sua magia.
Come può immaginare il lettore, per uno che ha iniziato in assembly, lavorare così vuol dire letteralmente fare un viaggio come quello di Alice nel paese delle meraviglie. Grazie alle attuali tecnologie — che non va mai dimenticato sono disponibili, almeno per il momento, a costi irrisori — con il minimo dispendio di energie si riesce a produrre una mole di lavoro stupefacente. L’incremento di produttività è paragonabile se non superiore a quello che si è avuto nell’industria e nell’agricoltura quando nella loro fase di meccanizzazione. Ritornando all’etimologia della parola informatica (ovvero trattamento auomatico dell’informazione), davanti ai nostri occhi sta rapidissimamente prendendo forma la sua sublimazione.
Fino alla visita presso l’azienda di Paolo, provavo una immensa gratificazione per l’efficienza con cui questi strumenti consentono di raggiungere gli obiettivi prefissati e una profonda gratitudine, memore di cosa significava programmare e debuggare il codice di uno Z80. Dopo aver (ri)visto con i miei occhi il lavoro che svolgevano i “veri” programmatori che mi hanno preceduto, credo di essere prossimo alla sublimazione della devozione in campo ingegneristico.
Background
Not long ago, I had the pleasure of visiting the remarkable exhibition—one might almost call it a museum—curated by my friend Gian Paolo Cremonesini, a lifelong entrepreneur in the IT sector, as well as a writer and an artist in the fullest sense of the term. Housed within the premises of his company, it offers a captivating journey through the history of office machinery, from the closing years of the nineteenth century to the comparatively recent past. From an educational point of view, I am convinced it ought to be a compulsory destination for young students taking their first steps into the worlds of electronics and computer science. In the span of just a few dozen metres, they would traverse millions of man-hours devoted to conceiving, designing, engineering, manufacturing, programming, and maintaining these machines. In an age marked by the pervasive spread of AI—which, as was only to be expected, is leading many young people to believe that anyone can become a programmer thanks to vibe coding—such an experience would be profoundly instructive. To understand what it once meant to program these machines, to struggle over the saving of every last bit and, more broadly, to make the best possible use of desperately scarce hardware resources—engineering in its purest and most demanding form—would force them to reflect on the extraordinary means now at their disposal. More importantly, I believe, it would teach them to regard those means with a different kind of maturity. The same happened to me. Having begun my own programming life in the early 1990s, writing assembly for the Z80, I had perhaps come to think of myself as something of a computing “pioneer.” Yet during the visit Paolo told me how he had once managed to develop an engineering calculation program for the Olivetti P101—the machine shown in the featured image of this post—using no more than one and a half memory cards. In doing so, he surpassed a program developed for one of his clients on a rival machine which, despite being vastly more powerful, required four memory cards, each of a significantly greater capacity than those used by the P101. For context, the P101 memory card—also known as a cartolina, or “postcard”—stores just 1,920 bits. Paolo’s anecdote had the salutary effect of bringing me firmly back down to earth.
The Retriva Project
Lately, I have been working on a project called Retriva. At present, it is a proof of concept for a conversational agent designed for business use, with the specific goal of making use of the body of knowledge a company has accumulated over time in the form of heterogeneous documents—Word files, spreadsheets, PDFs, scans of paper records, photographs, audio, video, and so forth—without resorting to any external services, for obvious reasons of confidentiality. Technically speaking, this is a classic application of RAG (retrieval-augmented generation) in combination with large language models. It is also proving to be an excellent opportunity to put into practice the skills I have acquired through the courses I have completed, and those I am currently attending, in AI Solutions Architecture. For both the design and implementation phases, I have adopted an approach that is entirely AI-assisted, though without allowing it to degenerate into vibe coding. Instead, I have chosen to follow the philosophy of spec-driven development (SDD), for the reasons I have outlined here. I do not think there is any need to dwell further on why I regard this methodology as vastly preferable—especially in a project of this complexity, one which may, someday (never set limits to Providence), evolve into something more serious than a mere exercise undertaken out of passion and intellectual curiosity.
To summarise very briefly, this is the path I have followed so far (the linked GitHub repository contains the full details):
- I engaged in a long brainstorming session with Microsoft Copilot in order to arrive at a design sufficiently complete to accommodate the reasonable future evolutions the product might undergo, should I succeed in making it work in a way that satisfies me.
- I then fed that design document back into Copilot, asking it to produce a formal specification in accordance with the conventions of Google Antigravity, the coding agent I am using for implementation.
- And finally, I let Antigravity work its magic.
As the reader can easily imagine, for someone who began with assembly language, working in this way feels quite literally like stepping into Alice’s Adventures in Wonderland. Thanks to today’s technologies—which, it should never be forgotten, remain available, at least for now, at almost negligible cost—one can produce an astonishing volume of work with a minimal expenditure of effort. The resulting increase in productivity is comparable to, if not greater than, the transformation brought about by mechanisation in industry and agriculture. To go back to the very etymology of the word informatics—the automatic processing of information—it becomes clear that we are now witnessing, before our eyes, the swift emergence of its ultimate sublimation.
Until my visit to Paolo’s company, I felt immense satisfaction at the efficiency with which these tools make it possible to achieve one’s aims, together with a deep sense of gratitude born from remembering what it once meant to program and debug Z80 code. But after seeing once more, with my own eyes, the work carried out by the true programmers who came before me, I find myself approaching something close to the sublimation of engineering devotion.
Credits
Feature image provided by Gian Paolo Cremonesini.
