CMS is dead.
Long live the CMS.

Sono un tecnico e ho fatto CMS. Ecco, l’ho detto.

Ho passato buona parte degli ultimi vent’anni a lavorarci, e per un certo periodo sembrava quasi una cosa da giustificare. CMS voleva dire WordPress, WordPress voleva dire siti, e fare siti occupava un gradino piuttosto basso nella gerarchia immaginaria dell’ingegneria del software. Le applicazioni serie, evidentemente, abitavano altrove.

Lo chiamo CMS bullying: quello snobismo professionale che deduce la complessità di un sistema dalla sua schermata più semplice. Si vedevano un titolo, una fotografia e il pulsante «Pubblica». Restavano fuori dall’inquadratura le redazioni, le traduzioni, i permessi, le integrazioni e gli anni di contenuti che dovevano sopravvivere al prossimo aggiornamento.

Oggi l’AI permette a molte più persone di costruirsi un’applicazione, un gestionale, persino il proprio CMS. Lo trovo entusiasmante. E riconosco, in quei progetti, molti dei problemi sui quali abbiamo lavorato per anni.

Più diventa facile generare software, più diventa utile sapere che cosa quel software deve saper fare nel tempo. È di questa esperienza che vorrei parlare.

Il software comincia da chi deve usarlo

Chi apre un CMS di solito ha un lavoro da finire: pubblicare un articolo, aggiornare un catalogo, organizzare un evento. Il nostro modello dati deve incontrare quel lavoro. Un campo obbligatorio, per esempio, può essere perfettamente sensato nel database e impossibile da compilare quando una persona sta appena abbozzando un contenuto. Prima o poi qualcuno ci scriverà «da definire», e il vincolo avrà prodotto dati peggiori.

È una lezione di prodotto che diventa subito architettura: distinguere una bozza da un contenuto pubblicabile, chiedere le informazioni al momento giusto, rendere comprensibile un errore e possibile il recupero.

Nel software aziendale chi compra e chi usa spesso sono persone diverse. Un dipendente può dover convivere per anni con un’interfaccia scomoda. Nel mondo consumer, dove è più facile abbandonare un prodotto, quella stessa scomodità può costare un cliente. Molti CMS stanno in mezzo: sono strumenti di lavoro, ma finiscono nelle mani di persone con competenze, abitudini e pazienza molto diverse. È stata una buona scuola per imparare a tenere insieme struttura e usabilità.

Guardando le applicazioni di oggi, quella familiarità si riconosce. Un CRM, un gestionale immobiliare, un pannello amministrativo: filtro un insieme di informazioni, scelgo come visualizzarlo, faccio qualcosa. Query, vista, azione. La tabella, il calendario e il kanban possono essere tre modi di lavorare sugli stessi dati.

Questa grammatica ha radici anche nei database e nei gestionali. I CMS l’hanno esercitata a lungo, portandola davanti a chi doveva usarla tutti i giorni senza conoscere le chiavi esterne. Ora l’AI ci permette di generare una vista per un singolo compito, magari destinata a durare dieci minuti. Sotto, il significato dei dati e le regole per modificarli devono restare riconoscibili.

Anatomia di un CMS

Directus è un buon esempio perché ci lavoro e perché rende visibile questa struttura: un database relazionale, API per accedervi, un’interfaccia per gestirlo. Intorno ci sono utenti, ruoli e policy, permessi su record e campi, strumenti per trasferire lo schema tra ambienti, collegamenti a storage esterni come S3.

Se domani decidessi di ricostruirlo con l’AI, partirei dalle responsabilità che si è preso:

Un prodotto maturo contiene anni di decisioni su questi problemi. Per apprezzarne il valore bisogna entrare nei dettagli: che cosa succede a una traduzione incompleta, a un file ancora referenziato, a un campo che un utente può leggere ma non modificare. È qui che si vede quanto un software sia stato modellato sul proprio dominio.

Anche le scelte di licenza riportano l’attenzione su quel valore. Directus oggi adotta una licenza source-available, la MSCL: il sorgente è consultabile, l’uso dipende dalle condizioni applicabili. Per chi valuta un’alternativa, il conto comprende quanto costerà mantenere nel tempo le responsabilità che decide di assumersi.

Usabilità, anche fuori dal browser

La stessa cura deve arrivare a chi lavora attraverso codice, script e automazioni. La developer experience, o DevEx, è un’altra forma di usabilità: documentazione chiara, tipi espliciti, comandi prevedibili, errori comprensibili. Sono qualità che permettono di essere precisi e di ripetere un’operazione sapendo che cosa aspettarsi.

In Directus questa attenzione prende forme concrete. L’SDK JavaScript e TypeScript offre un client componibile per API, autenticazione e realtime, con supporto ai tipi del proprio schema. La CLI per la sincronizzazione degli ambienti permette di esportare schema e configurazioni, esaminare le differenze e applicarle a istanze compatibili, anche in una pipeline. Il server MCP, attraverso il Model Context Protocol, espone dati e operazioni agli assistenti AI, rispettando i permessi dell’identità con cui si collegano.

Questo dà alla persona una libertà concreta: usare il pannello, scrivere un’integrazione, lanciare un comando o lavorare con il proprio agente nel proprio ambiente. Si può scegliere come interagire e ritrovare lo stesso modello dati, con le autorizzazioni richieste dalle diverse operazioni. L’AI entra così in un sistema che possiede già struttura e regole.

Per me «bello e comodo» comprende anche questo: un software orchestrabile da una persona, anche attraverso il suo agente. Posso comporre un flusso, delegarne alcuni passaggi, controllarne l’esito e intervenire. L’automazione diventa un modo di esercitare più controllo sul lavoro. Una DevEx curata rende questa possibilità accessibile già oggi.

«È solo una galleria di immagini»

Prendiamo una richiesta normale: l’immagine principale di un articolo deve diventare una galleria ordinata. Nel form aggiungiamo qualche miniatura e la possibilità di trascinarle. Sembra un pomeriggio tranquillo.

Il modello, però, passa da un riferimento singolo a una relazione con più immagini e un ordine. Gli articoli esistenti devono conservare la fotografia che avevano. Le API e i template devono capire la nuova struttura. I permessi devono consentire agli editor di gestire anche la relazione, senza aprire accessi indesiderati ai file. E gli editor, nel frattempo, continuano a lavorare.

Possiamo procedere per gradi: aggiungere la relazione, trasformare i riferimenti esistenti nella prima immagine di ciascuna galleria, aggiornare le letture e infine ritirare il vecchio campo. Durante la transizione dobbiamo decidere anche come trattare le nuove scritture: se qualcuno cambia la vecchia immagine dopo la migrazione iniziale, quella modifica deve arrivare nella galleria. Un rilascio compatibile si progetta anche per ciò che accade mentre lo stiamo eseguendo.

Schema, dati, file e codice devono poter funzionare insieme in ogni fase del cambiamento. Possono evolvere in momenti diversi, purché ci sia un percorso che li tenga compatibili.

Per questo promuovere lo schema da sviluppo a produzione e trasferire i contenuti sono operazioni distinte. Per questo tornare al codice di ieri può lasciare il sistema rotto, se nel frattempo abbiamo trasformato i dati. E per questo un backup del database, da solo, può essere insufficiente: se cita immagini ormai eliminate dallo storage, abbiamo recuperato i riferimenti a qualcosa che non esiste più.

Da una galleria siamo arrivati al disaster recovery. Ci serve sapere quali file conservare, con quali versioni del codice possiamo riaprire i dati e come riavviare le integrazioni senza ripetere azioni già eseguite. Un’email inviata o un’operazione su un servizio esterno non tornano indietro insieme al database.

È qui che entra il laboratorio costruito attorno al CMS: infrastruttura, pipeline di CI/CD, osservabilità, prove di ripristino. Serve a rilasciare in un ordine preciso, distinguere un permesso errato da un servizio fermo e verificare quanto lavoro potremmo perdere in un incidente. Ci sono poi le persone: chi approva il cambiamento, chi interviene, chi sa perché esiste quella strana regola.

In welance, il nostro cloud e i processi che ci abbiamo costruito attorno fanno parte di questa esperienza collettiva. Chi ha seguito CMS complessi spesso si porta dietro un intero modo di lavorare, molto più difficile da vedere di una schermata.

L’AI può aiutarci a scrivere anche le migrazioni, i test e le procedure di recupero. L’esperienza serve a riconoscere quali chiedere e a capire se le prove dimostrano davvero ciò che ci interessa. Il prototipo ci mostra che una cosa può funzionare; il lavoro successivo stabilisce a quali condizioni continuerà a farlo.

La C sta per contenuto

Fin qui ho parlato di articoli e fotografie. Ma un contenuto può essere anche un requisito, un immobile, una disponibilità, una decisione o la relazione tra un progetto e una persona. È questa apertura che mi ha sempre interessato nei CMS.

Un sistema abbastanza flessibile può diventare la base di un gestionale immobiliare, di un CRM o di parti di un ERP. Offre già un posto per descrivere entità, collegarle, assegnare accessi e costruire interfacce. Su quella base si aggiunge la conoscenza del dominio: una prenotazione deve impedire sovrapposizioni anche quando arrivano due richieste contemporaneamente; una decisione contabile porta vincoli che un articolo non ha.

Per me il CMS è interessante proprio come contenitore di queste possibilità. Molto di ciò che chiamiamo «gestionale» consiste nel dare struttura a informazioni e permettere alle persone giuste di agire su di esse. Con l’AI, tra quelle persone e quelle informazioni si aggiunge un nuovo interlocutore, capace di leggere, proporre e operare. La qualità della struttura diventa ancora più importante.

Quando la memoria diventa operativa

In welance questa idea ha preso forma nel nostro sistema interno, Butler/Otto. Lavoriamo con un ecosistema di circa sessanta-settanta persone, con un ricambio frequente nelle collaborazioni. Raccogliere contenuti e requisiti in un contenitore comune, basato su CMS, ci aiuta a mantenere continuità anche quando cambiano le persone. Oggi lavoriamo su quel patrimonio anche attraverso MCP, ciascuno con i propri strumenti e il proprio agente.

Un requisito deve sopravvivere alla persona che lo ha raccolto. Chi arriva dopo dovrebbe poter ritrovare la richiesta, capire da quale decisione nasce, risalire ai materiali originali e continuare il lavoro. Questa memoria comprende anche i dati concreti con cui l’azienda opera ogni giorno.

Nel nostro caso, penso ai movimenti bancari in Qonto, al tempo registrato in Clockify, al codice e alle attività in GitLab. Più recentemente si sono aggiunti OpenRouter, con l’accesso ai modelli e i relativi consumi, e gli LLM con cui lavoriamo. Mettere queste informazioni in relazione permette di collegare ciò che abbiamo deciso a ciò che abbiamo fatto, impiegato e incassato.

Per rispondere a una domanda come «quanto lavoro abbiamo dedicato a questo progetto e che cosa è stato pagato?», bisogna riconoscere lo stesso progetto nei diversi sistemi, collegare le ore alle attività e i movimenti ai documenti corretti. Un nome simile in due applicazioni non basta. Servono identità condivise, relazioni esplicite e regole per aggiornare i dati.

È così che mi avvicino all’idea di Single Source of Truth: una base centrale di dati, definizioni e connessioni sulla quale possiamo ragionare insieme. Qonto resta il riferimento per i movimenti del conto, Clockify per le registrazioni del tempo, GitLab per codice e attività. Il sistema comune deve sapere da dove arriva ogni informazione, quanto è aggiornata e quale fonte prevale se due versioni discordano. Ogni connessione trova posto in un modello condiviso.

La conoscenza diventa razionale nella misura in cui possiamo ricostruirla e verificarla. Un movimento registrato, una stima e una conclusione del modello devono restare distinguibili. Le regole di calcolo e i collegamenti devono essere ispezionabili. È questa base che consente a persone diverse, con agenti diversi, di lavorare sugli stessi fatti e di discutere le interpretazioni.

Qui vedo un collegamento con la LLM Wiki proposta da Andrej Karpathy: un modello legge le fonti e mantiene una conoscenza persistente, fatta di sintesi e collegamenti che si aggiornano nel tempo. In un CMS possiamo associare quella conoscenza a progetti, responsabilità e stati: quale requisito è approvato, chi può cambiarlo, quale attività ne dipende.

Le fonti possono essere un documento, una registrazione o una fotografia. Gli strumenti che le interpretano devono conservarne la provenienza, così da permettere a una persona di controllare la sintesi e correggerla. Il modello può cambiare; dati, decisioni e relazioni devono poter restare. È in questo senso che il sistema diventa parte dell’intelligenza dell’azienda.

Il passaggio all’azione richiede autorizzazioni precise. Leggere un requisito non dà automaticamente il diritto di modificare il progetto o inviare qualcosa a un cliente. Ogni connettore deve verificare l’azione richiesta e usare credenziali appropriate sul servizio esterno. MCP offre un modo comune di collegare gli strumenti; la corrispondenza tra i permessi dei diversi sistemi va progettata. Anche una sintesi ricavata da documenti riservati deve rispettare quei confini.

È questa l’evoluzione che immagino quando penso a un AI Management System, o AI MS: un gestionale nel quale persone e agenti lavorano sulla stessa memoria operativa. Ciascuno può interagirci a proprio modo, mentre regole, responsabilità e storia delle modifiche restano verificabili. È un nome di lavoro per una direzione che mi sembra promettente.

Gli strumenti che vorrei usare domani

Questa prospettiva influenza anche gli strumenti verso cui guardo. Mi interessa l’approccio di Railway, dove servizi e ambienti sono parti visibili del progetto. Lovable parte dalla costruzione dell’applicazione e offre anche un backend gestito, con database, autenticazione e storage. Sono modi diversi di rendere accessibile un sistema che, sotto, continua ad avere dipendenze.

La mia preferenza va verso piattaforme capaci di rendere comprensibili quelle dipendenze e di aiutarci a governarle. Immagino la costruzione conversazionale come una delle capacità di una piattaforma più ampia, che accompagna il software anche dopo il primo rilascio.

Vorrei poter chiedere «trasforma questa immagine in una galleria» e vedere quali dati cambieranno, come verranno trattati quelli esistenti, quali servizi saranno coinvolti e dove servirà un’approvazione. Vorrei sapere anche come recuperare se qualcosa va storto. Disegnare i componenti su un canvas è un buon punto di partenza; il valore sta nel gestire il cambiamento che li attraversa.

Il prossimo CMS potrebbe nascere da qui, oppure dall’evoluzione di strumenti che già usiamo. Mi interessa che una persona possa scegliere la propria interfaccia e il proprio agente, continuando a lavorare su una base condivisa. La differenza la farà la capacità di accompagnare un cambiamento dall’intenzione di chi lo chiede fino alle sue conseguenze sul sistema.

Viva il CMS

Il 2 novembre mi sembra un giorno adatto per seppellire l’idea che lavorare sui CMS significhi fare ingegneria di serie B. Quei sistemi mi hanno insegnato quanto sia impegnativo tenere insieme persone, informazioni e software mentre tutti e tre cambiano.

A chi oggi si costruisce il proprio gestionale con l’AI lascerei quattro domande, le stesse che continuerei a farmi:

• Quali regole devono restare vere mentre il sistema cambia?
• Chi può agire, su quali dati e con quali conseguenze?
• Che cosa abbiamo davvero provato a recuperare dopo un errore?
• Che cosa saprà chi arriverà dopo di noi?

Sono un tecnico e ho fatto CMS. Qualunque nome daremo al prossimo software, mi porto dietro quello che mi hanno insegnato.

CMS is dead. Long live the CMS.