I was “just” a CMS developer.
Then came AI

Sono un tecnico e ho fatto CMS.

Ho passato buona parte degli ultimi vent’anni a lavorarci. CMS voleva spesso dire WordPress, e WordPress voleva dire siti. È un’associazione comprensibile, ma racconta solo una parte del lavoro.

Un titolo, una fotografia e un pulsante «Pubblica» possono essere tutto ciò che si vede. Dietro ci possono essere redazioni, traduzioni, permessi, integrazioni e anni di contenuti che devono sopravvivere al prossimo aggiornamento. È lavorando su questi problemi che ho imparato di più.

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

Prendiamo Directus, perché ci lavoro e posso guardarlo da vicino. Dire «un database con API e un pannello» è corretto quanto descrivere un animale come qualcosa con una pelle e degli organi. Per capire che cosa stiamo comprando, riusando o pensando di ricostruire con l’AI, bisogna separarne le responsabilità.

Parto dall’esterno. La pelle è il Data Studio: form, viste e dashboard rendono il sistema utilizzabile. Nascondere un campo nel form, però, non lo protegge sul server. Lo scheletro è il modello dati: tabelle e relazioni SQL, insieme ai metadati con cui Directus descrive campi, interfacce e configurazioni. Il significato di «cliente», «progetto» o «approvato» lo dobbiamo stabilire noi. Poi apriamo il coniglio.

La distinzione decisiva è tra quello che Directus sa fare e le decisioni che dobbiamo prendere noi. Offre collezioni, relazioni, permessi, versioni e automazioni. Stabilire chi può approvare una spesa, quando una bozza è pubblicabile o come riconoscere lo stesso cliente in due sistemi richiede un modello del nostro lavoro. Il prodotto ci dà strumenti con cui esprimerlo; la correttezza di quel modello resta una responsabilità nostra.

Seguiamo una modifica concreta: un editor cambia il prezzo di un prodotto. Il Data Studio raccoglie il nuovo valore; l’API riceve la richiesta; i servizi la eseguono nel contesto dell’utente e dei permessi configurati. Il database applica i propri vincoli. La cronologia, se configurata, conserva la modifica. Un Flow può avviare l’aggiornamento di un catalogo esterno. Sono responsabilità diverse: se quell’ultimo servizio non risponde, il prezzo già salvato e il prezzo ancora visibile altrove possono divergere. Servono una regola di recupero e un modo per accorgersene.

I confini contano anche quando estendiamo la piattaforma. La documentazione dei servizi richiede attenzione al contesto di autorizzazione, chiamato accountability: ometterlo può dare al servizio permessi amministrativi.³ E un campo marcato come nascosto nel Data Studio non sostituisce una policy sui dati.⁴ Il valore della piattaforma dipende anche da quanto bene ne rispettiamo i confini.

Fuori dall’animale restano l’esecuzione e la manutenzione del sistema: database e storage, segreti, backup verificati, monitoraggio, aggiornamenti e compatibilità con i client. Possiamo delegarne una parte a un servizio gestito. Dobbiamo comunque sapere chi la copre. Anche migrare lo schema o ripristinare una revisione risolve una parte del problema, non un intero piano di recupero.

Anche le scelte di licenza riportano l’attenzione sul costo di questo insieme. 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

Una memoria condivisa diventa operativa quando possiamo risalire da un dato alla sua fonte, da una decisione ai suoi motivi e da un’azione alle regole che la autorizzano.

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.

Il CMS potrebbe essere il pezzo da togliere

L’obiezione più seria alla mia tesi è che l’AI potrebbe rendere più importanti dati e regole, e meno necessario il CMS che li riunisce. Le responsabilità della tavola anatomica possono essere ricomposte in un altro modo. Le competenze che ho descritto appartengono all’ingegneria del software. Averle imparate sui CMS non dimostra che un CMS sia ancora la scelta migliore.

Se costruire strumenti specifici diventa più economico, cambia il vantaggio di adattarsi a una piattaforma generalista. Si può preferire un’applicazione piccola, costruita attorno al proprio lavoro, a un CMS pieno di estensioni. SDK, CLI e MCP sostengono anche questa alternativa: rendono ciascun prodotto accessibile e componibile, senza assegnargli necessariamente un ruolo centrale.

Anche il modello comune ha un costo. Un progetto per chi pianifica il lavoro e una commessa per chi fattura possono avere confini diversi. Il domain-driven design affronta proprio questa pluralità di modelli, delimitandoli e rendendo esplicite le relazioni tra loro.¹³ Forzarli in un’unica struttura può creare traduzioni fragili, copie obsolete e un punto attraverso cui deve passare ogni cambiamento.

Un’alternativa sensata conserva i sistemi autorevoli nei rispettivi ambiti e li collega attraverso contratti espliciti. L’agente coordina le operazioni; i servizi continuano ad applicare le proprie regole. Il CMS può restare dove serve agli editor, oppure uscire del tutto da quel flusso. È una possibilità che devo considerare anche per evitare di riconoscere nel futuro soprattutto lo strumento che conosco meglio.

Per me il CMS merita quel posto quando relazioni, permessi e flussi editoriali condivisi sono una parte sostanziale del lavoro. Se per usarlo devo duplicare regole già affidabili altrove e mantenere sincronizzazioni continue, il vantaggio può sparire. La verifica concreta è immaginare di toglierlo: quali responsabilità dovrei ricostruire, quali integrazioni eliminerei, e quanto sarebbe più difficile capire o recuperare un errore? La scelta migliore è quella che riduce il lavoro complessivo mantenendo le garanzie necessarie.

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

Nel mondo dei CMS c’è anche molto lavoro fatto per inerzia: installare un tema, sommare plugin e consegnare senza chiedersi come reggerà il sistema. Averci lavorato non è, di per sé, un segno di cura o di competenza. La facilità con cui si comincia può incoraggiare sia la curiosità sia la pigrizia.

Guardando a ciò che costruiamo oggi con l’AI, mi accorgo soprattutto di una cosa che è sempre stata ovvia: il buon software è buon software. Lo riconosci da quanto aiuta chi lo usa e da come regge il tempo e il cambiamento. Nome, sigla e tecnologia del momento dicono poco, da soli.

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?

I CMS sono stati il contesto in cui ho imparato a farmi queste domande. Mi porto dietro ciò che ho imparato, anche quando mi aiuta a scegliere un’architettura diversa.

CMS is dead. Long live the CMS.