Dal 2025 al 2026

C’è un modo di raccontare l’intelligenza artificiale che la presenta come alternativa alle persone, la domanda sottintesa è sempre la stessa chi farà questo lavoro, l’umano o la macchina? È una domanda che sembra ragionevole, si presta bene ai titoli, alimenta dibattiti. Ma non corrisponde a quello che succede quando si lavora davvero con questi strumenti.

Ho passato l’ultimo anno a sviluppare progetti con Claude, l’assistente AI di Anthropic. Non sono un programmatore, non scrivo codice di mestiere anche se l’ho fatto a lungo un paio di vite professionali fa, in questi mesi ho continuato a non scrivere codice eppure ho rilasciato applicativi su GitHub con licenza MIT, strumenti che altri possono scaricare e usare. Com’è possibile? La risposta sta in una parola che nel dibattito pubblico compare poco, collaborazione.

La logica binaria e i suoi limiti

Il dover scegliere «o l’umano o l’AI» funziona per compiti semplici e definiti. Se devo trascrivere un audio posso farlo io o può farlo una macchina, la stessa cosa se devo tradurre un documento. In questi casi ha senso chiedersi chi sia più veloce, più economico, più accurato.

Ma molto del lavoro interessante non funziona così, non è un pacchetto chiuso da assegnare a qualcuno. È un processo che si sviluppa, richiede decisioni lungo il percorso, seguire un contesto che cambia, giudicare cosa funziona e cosa no. In questi casi la domanda «chi lo fa» è mal posta, perché assume che il lavoro esista già definito prima che qualcuno lo esegua.

Il progetto più complesso che ho sviluppato quest’anno è Ollama Easy GUI, un’interfaccia grafica per Ollama, il software che permette di eseguire modelli AI in locale. L’esigenza era mia: cercavo il giusto equilibrio tra semplicità e funzionalità, qualcosa nel mezzo tra l’essenzialità del terminale e la dispersività delle interfacce più complete già disponibili. Volevo funzioni specifiche come il supporto MCP, un prompt di sistema globale, la possibilità di definire istruzioni diverse per ogni modello, e soprattutto che tutti i dati restassero locali.

Claude poteva scrivere il codice, ma non aveva né l’esigenza né il contesto d’uso. Io avevo l’esigenza e il contesto, ma non le competenze per tradurli in software funzionante. Il mio ruolo è andato oltre quello di semplice committente, di volta in volta sono stato capo-progetto e direttore della revisione, definendo requisiti, architettura generale e supervisionando ogni fase dello sviluppo. Non si è trattato di «io ho chiesto, l’AI ha eseguito», ma di un lavoro a più livelli dove entrambi abbiamo contribuito in modi diversi e complementari.

C’è un dettaglio che rende bene l’idea. Il progetto era iniziato mesi prima, ma le versioni precedenti di Claude non riuscivano a gestire la complessità crescente dell’applicazione. Solo con l’arrivo di Opus 4.5 le cose sono cambiate, un modello che riesce a mantenere coerenza su progetti articolati. Questo dice che la collaborazione umano-AI non è statica, evolve con l’evoluzione degli strumenti e con la crescita dell’attore umano.

Sei progetti, un pattern

Nel corso dell’anno ho rilasciato sei repository, tutti nati dallo stesso pattern: un’esigenza concreta mia, competenze tecniche di Claude, risultati che non sarebbero esistiti senza entrambi.

Oltre a Ollama Easy GUI c’è un server MCP per collegare Claude a NotebookLM, lo strumento di Google per interrogare raccolte di documenti. Il problema che volevo risolvere era specifico, NotebookLM lavora esclusivamente sui documenti caricati, ma non ha le capacità elaborative di Claude, quest’ultimo tende a completare e arricchire con le proprie conoscenze generali. Unire senza controlli le due parti avrebbe sommato anche i difetti. La soluzione è stata sviluppare un sistema che struttura automaticamente le domande prima di inviarle a NotebookLM, con vincoli operativi espliciti che indirizzano le richieste e anche l’elaborazione delle risposte: usare solo le informazioni presenti nei documenti, citare le fonti per ogni affermazione, dichiarare esplicitamente quando un’informazione non è disponibile. Non è un ridurre le capacità di Claude, ma un indirizzarle automaticamente verso la fedeltà alle fonti.

C’è poi un server MCP che collega Claude con GIMP, il software di fotoritocco. È un proof of concept più che uno strumento maturo, ma dimostra la possibilità di collegare Claude con altri stumenti.

C’è una raccolta di simulatori interattivi per la didattica, strumenti visuali che permettono di esplorare concetti complessi. Qui la collaborazione ha funzionato su un piano diverso, partiva dalla mia richiesta di cosa il simulatore doveva mostrare, quale concetto doveva rendere comprensibile, Claude traduceva queste specifiche in codice funzionante. Il risultato arriva a dopo una intensa sessione di interazione fra noi due.

C’è un server MCP per gestire Ollama direttamente da Claude Desktop: verificare quali modelli sono installati, lo stato del sistema, scegliere quale modello usare per quale compito.

E infine c’è un sistema di documentazione online, basato su MkDocs e GitHub Pages, che alimenta le pagine del mio sito. Questo progetto è nato da un problema concreto: i manuali su strumenti AI diventano vecchi nel giro di settimane. Un PDF distribuito oggi contiene già informazioni superate domani. La soluzione è stata spostare tutto sul web, con un workflow semplice: modifico un file di testo, faccio commit su GitHub, il sito si aggiorna automaticamente. L’intero percorso, dall’analisi del problema al sito funzionante, si è concluso in mezza giornata.

Il valore emergente

C’è un aspetto della collaborazione che rischia di passare inosservato se ci si ferma all’elenco dei progetti. Non si tratta semplicemente di sommare il meglio delle due parti, quello che si ottiene infatti è più della somma.

Nel processo emergono possibilità che nessuno dei due avrebbe visto da solo. Propongo qualcosa, Claude suggerisce un’alternativa tecnica, quella alternativa mi fa scaturire l’idea di una feature a cui non avevo pensato, l’implementazione apre altre direzioni. Il risultato finale non era nella testa di nessuno all’inizio.

Questo cambia la natura del discorso. Non stiamo parlando di «l’AI mi aiuta a fare cose che non so fare». Stiamo parlando di un processo generativo dove il risultato è oltre la somma dei contributi individuali. È la differenza tra delegare un compito e costruire qualcosa insieme.

Oltre i progetti: l’ecosistema personale

I repository pubblici sono la parte visibile del lavoro. Ma c’è una parte meno visibile che per me è altrettanto importante: gli strumenti che ho costruito per uso strettamente personale.

Nel corso dell’anno ho sviluppato diverse «skill», configurazioni specializzate che Claude usa quando lavoro su determinati tipi di compiti. Una è dedicata alla scrittura: incorpora le convenzioni tipografiche italiane, i controlli di consistenza terminologica, le regole di stile che applico ai miei contenuti. La sto usando adesso, mentre scrivo questo articolo.

Un’altra è dedicata alla revisione del codice. Quando si chiude un progetto lungo e complesso è facile che restino variabili definite e poi mai usate, funzioni duplicate, pezzi di logica diventati inutili dopo successive modifiche. Questa skill esegue una revisione sistematica, identifica questi problemi, suggerisce come risolverli. La uso alla fine di ogni progetto e la trovo indispensabile.

Queste skill non le condivido, non avrebbe senso perché sono calibrate sul mio modo di lavorare, sui miei standard, sui problemi che incontro nella mia attività. Per chiunque altro sarebbero inutili o fuorvianti. Ma proprio per questo funzionano, sono strumenti su misura, sviluppati in collaborazione per esigenze specifiche.

Qui sta un aspetto della collaborazione che va oltre il singolo progetto. Non si tratta solo di «fare cose insieme», si tratta di costruire progressivamente un ambiente di lavoro che amplifica le proprie capacità. È un investimento che si accumula nel tempo.

Cosa significa per chi lavora

Un professionista che valuta se e come usare l’AI nei propri flussi di lavoro si trova spesso davanti alla stessa logica binaria di cui parlavo all’inizio. L’AI può fare il mio lavoro? Se sì, sono a rischio. Se no, posso ignorarla.

La domanda da farsi invece è cosa potrei fare con un collaboratore AI che oggi non faccio. Non perché potrebbe sostituire qualcosa che faccio già, ma perché insieme diventa possibile qualcosa che prima non lo era.

Io, la parte umana, non scompaio, devo comunque sapere cosa voglio costruire, devo testare, devo iterare, devo prendere decisioni. Ma la parte che non sapevo o volevo fare ora posso farla in collaborazione.

Ognuno ha competenze in alcune aree e lacune in altre. L’AI non riempie le lacune magicamente, ma può diventare il complemento che permette di realizzare cose che richiederebbero competenze che non si hanno.

Verso il 2026

Credo che l’anno appena iniziato sarà quello in cui diventerà chiaro che con l’AI si collabora. Non perché lo dicano gli esperti o le aziende che vendono questi strumenti, ma perché chi ci lavora davvero lo scoprirà per esperienza.

La narrazione «o l’umano o l’AI» continuerà, perché è semplice e funziona bene nei titoli. Ma chi avrà investito tempo nel capire come collaborare avrà un vantaggio che non si recupera in fretta. Non è questione di imparare a usare un software: è questione di sviluppare un modo di lavorare diverso, costruire un proprio ecosistema di strumenti, capire cosa si può fare insieme che da soli non si poteva.

I progetti che ho rilasciato lo scorso anno sono la prova concreta che questo è possibile, le skill che uso quotidianamente sono la prova che diventa sempre più efficace con il tempo.

Se c’è una cosa che mi sento di suggerire a chi si affaccia su questi strumenti, è questa: non chiedetevi se l’AI può sostituirvi. Chiedetevi cosa potreste costruire insieme che oggi non esiste.

PS qui ho parlato dei lavori fatti con Claude, ma ho fatto cose anche con altre AI. Ho parlato di Claude perché per me è quella che considero un vero strumento di lavoro aziendale.