Vibe coding: le app hanno un ciclo di vita

Il 20 agosto 2026 ho archiviato notebooklm-mcp-structured, il server MCP che collega Claude a Gemini Notebook. Il programma funziona ancora, ma due cambiamenti avvenuti fuori dal codice ne hanno chiuso il ciclo di vita, cioè il rename di NotebookLM deciso da Google a luglio e la nuova specifica MCP del 28 luglio. Racconto cosa è successo e perché un’applicazione costruita con il vibe coding dipende da una catena di software che chi la costruisce non governa, e per questo va mantenuta come qualsiasi altro programma.

Per la prima volta da quando lavoro con le AI ho deciso di archiviare un’app che ho sviluppato con il vibe coding. Il 20 agosto 2026 ho chiuso lo sviluppo di notebooklm-mcp-structured e ho archiviato il repository su GitHub. È il server MCP che collega Claude a Gemini Notebook, l’ho pubblicato a dicembre 2025, e l’ultima versione l’ho aggiornata il giorno prima di chiudere. Funziona, resta installabile, ma non riceverà altri aggiornamenti.

La decisione dipende da due cambiamenti avvenuti nel giro di poche settimane, entrambi fuori dal programma. Nessuno dei due riguarda il codice che avevo scritto.

Racconto come sono andate le cose perché della manutenzione del software costruito con il vibe coding si parla poco. Si trova molto materiale su come si costruisce un’applicazione, quasi niente su cosa succede dopo. Chi arriva al codice per questa strada tende a considerare il programma finito nel momento in cui funziona, ma il programma dipende da altri sistemi che nel tempo cambiano.

Cosa fa il server

Gemini Notebook, che fino a luglio si chiamava NotebookLM, è lo strumento di Google che permette di costruire delle raccolte specializzate di fonti e su quelle risponde alle richieste. Il server MCP che ho costruito permette il collegamento con Claude, in questo modo l’utente da Claude interroga i notebook come farebbe con qualsiasi altra fonte, senza uscire dalla conversazione in corso.

Questo server MCP fa anche altre cose oltre a collegare le due parti. Prima di inoltrare la domanda a Gemini Notebook, Claude la riscrive in forma strutturata, con alcune regole aggiuntive. Inoltre quando torna la risposta da Gemini Notebook mette dei paletti per evitare che le risposte vengano completate con conoscenze generali del modello. Il funzionamento nel dettaglio l’ho descritto quando l’ho pubblicato, in un nuovo MCP per connettere Claude e NotebookLM.

Due cambiamenti, nessuno dentro il codice

Il prodotto cambia nome e indirizzo

Il 16 luglio 2026 Google ha rinominato NotebookLM in Gemini Notebook. Il prodotto è rimasto lo stesso, con qualche funzione in più, ma sono cambiati gli indirizzi dei notebook e parte dell’interfaccia delle risposte. Google ha attivato un redirect per portare le richieste dai vecchi URL alla nuova versione.
Il redirect funziona, però il server MCP si aspetta risposte provenienti dai vecchi indirizzi e questo ha iniziato a creare problemi.

Questo è il tipo di rottura più frequente per un’applicazione che si appoggia a un servizio di terzi, ed è anche quella su cui chi ha costruito il programma non ha alcun potere, se non cercare di tenere aggiornata la propria app.

Il protocollo cambia le fondamenta

Il 28 luglio 2026, dodici giorni dopo il rename di Google, è uscita la nuova versione della specifica MCP, il protocollo che permette a Claude di parlare con strumenti esterni. È conosciuta come «versione 2», ma il nome ufficiale è revisione 2026-07-28.

Il cambiamento principale è che il protocollo diventa stateless. Fino a ieri client e server tenevano aperta una conversazione con una memoria condivisa, adesso ogni richiesta viaggia da sola e porta con sé tutto quello che serve a essere capita. In più tre funzioni del vecchio protocollo, Roots, Sampling e Logging, sono dichiarate deprecate, con dodici mesi di tempo per abbandonarle.

Il mio server è costruito sul modello precedente, e la sessione persistente è la parte su cui si regge tutta la sua logica. Portarlo sul nuovo protocollo non significa aggiornare una libreria, significa rifarlo. Questo è il secondo tipo di rottura, quella che arriva dallo strato più profondo, dove la riparazione non è un’opzione.

Cosa vuol dire «archived» su GitHub

Chi apre il repository trova in cima una barra grigia con la scritta «archived». Vale la pena spiegare cosa vuol dire in realtà, perché a prima vista sembra un necrologio.

Un repository archiviato è in sola lettura. Nessuno può più aprire segnalazioni, proporre modifiche o pubblicare nuove versioni, e l’autore dichiara in modo pubblico che quel lavoro è chiuso. Il codice resta scaricabile e installabile come prima.

Archiviare è una dichiarazione di intenzioni, non un certificato di morte. Serve a chi passa di lì per capire, senza dover leggere le date dei commit, che il progetto non riceverà correzioni. Nel mio caso l’ho fatto perché il seguito sarà un progetto diverso, e lasciare aperto quello vecchio avrebbe dato l’idea sbagliata.

Nessun programma sta da solo

Questo server l’ho sviluppato con Claude usando il vibe coding, ma il mio codice per funzionare dipende da altri software, e nessuno di questi dipende da me.

La misura si vede bene nei numeri. Nel file di configurazione del progetto le librerie dichiarate sono sei. Quando il programma viene installato, i pacchetti che finiscono sul disco sono oltre un centinaio perché ognuna delle sei ne porta con sé altre. Ciascuno di quei pacchetti ha un autore, un calendario di aggiornamenti e un proprio ciclo di vita, e nessuno di quegli autori sa che il mio programma esiste.

Chi sviluppa software da anni queste cose le dà per scontate, al punto che raramente le dice. Le tiene in conto quando progetta e considera normale che una parte del lavoro consista nel tenere il passo con codice scritto da altri.

Chi arriva al codice attraverso il vibe coding parte da una posizione diversa. Non ha quell’esperienza, e in più, di norma, i file non li apre. Chiede una cosa, la ottiene, la prova, e se funziona passa oltre. Anche aprendoli di quei file capirebbe poco, perché non ne conosce il funzionamento. Il risultato è che la catena di dipendenze resta invisibile e il programma sembra un oggetto autosufficiente. Il giorno in cui uno degli anelli si muove la sorpresa è doppia, perché il programma non funziona più e non è chiaro nemmeno perché.

Il ciclo di vita non lo decide chi costruisce

I due cambiamenti che hanno chiuso questa storia sono di natura diversa, vale la pena separarli, perché chi ha costruito qualcosa con il vibe coding li incontrerà prima o poi.

Il primo è il prodotto altrui che cambia. È il più frequente, si presenta senza preavviso, e la riparazione è quasi sempre alla portata. Il secondo è lo strato su cui il programma poggia che cambia forma. È il più raro e il più definitivo, perché non si ripara, si riscrive.

Nessuno dei due dipende da come è scritto il codice. Un programma costruito bene avrebbe dato problemi allo stesso modo il 16 luglio, e sarebbe stato altrettanto incompatibile con il nuovo protocollo. Questa è la parte che manca al racconto corrente sul vibe coding, dove la qualità del risultato viene misurata sul giorno della consegna.

In pratica, due cose aiutano. Tenere d’occhio gli annunci dei servizi da cui il programma dipende, perché il preavviso, quando c’è, arriva da lì. E accettare che a un certo punto la risposta giusta è smettere, invece di continuare a riparare qualcosa che sta su fondamenta abbandonate. Le indicazioni di metodo che uso quando costruisco le ho raccolte in vibe coding: cosa serve davvero per farlo funzionare.

Cosa arriva dopo

Il seguito è un progetto nuovo, costruito sulla specifica di luglio e distribuito come plugin. Il motivo per cui ho deciso di rifarlo non è il nuovo protocollo, che è solo l’occasione, ma è la parte per cui il progetto era nato, cioè dare una struttura alle domande, operazione che nella versione attuale è affidata a un blocco di istruzioni e può essere fatta molto meglio.

Chi vuole usare il collegamento con Gemini Notebook adesso può farlo senza problemi, partendo dal repository su GitHub. Chi preferisce aspettare troverà il seguito qui, quando sarà pronto.