Negli anni 90 un sito internet era formato da pagine html, statiche e con al massimo immagini e link (hyperlink); poi venne flash. Nacquero siti in .js, e poi arrivò l'epoca di PHP+Mysql. Arrivarono i CMS open source e tutti si scoprirono web-qualcosa ... Ok, anche io mi sono fatto questo sito con Joomla, il mio CMS Open Source preferito, ma professionalmente non sono sono la somma di tutte le figure necessarie per gestire un "vero" sito web. Ma ho studiato i db, Apache web Server, il linguaggio PHP abbastanza a fondo da capire se e cosa "accade" qui sopra.
Adesso siamo nell'era del faccio tutto ma non ne so proprio niente! L'era di "L''ho fatto con ChatGPT"
L'avvento dei Large Language Models (LLM) come strumenti di generazione di codice ha aperto nuove possibilità nello sviluppo web, ma ha anche sollevato questioni fondamentali riguardo all'affidabilità, alla sicurezza e alla sostenibilità a lungo termine dei progetti digitali. Quando si tratta di costruire siti web complessi (es. con database, gestione articoli, marketplace, aree riservate, banner, gallerie ed estensioni) la scelta dell'approccio tecnologico diventa una decisione di architettura del sito ed è di primaria importanza.
Ma quante sono le figure professionali (non "mio cuggino fa i siti web") realmente necessarie? Inutile che faccia uno sterile elenco, tanto l'utente medio (quello che continua a dire "chiamiamo il tecnico informatico") conosce solo il webmaster. Sono 1, 3, 5...25 ...basta cercare su qualsiasi motore di ricerca e leggere, leggere, leggere e decidere in base alle proprie esigenze: https://duckduckgo.com/?q=quante+sono+le+figure+realmetne+necessarie+per+creare+e+gestire+un+sito+web%3F&t=euandroid&ia=web
Ora analizziamo in modo critico (esatto) i vantaggi dei Content Management System (CMS) open source come WordPress, Joomla e Drupal rispetto all'utilizzo di codice generato da strumenti LLM, con particolare attenzione agli aspetti di sicurezza, audit del codice e gestione del ciclo di vita del software. State forse pensando che non amo gli LLM? Avete indovinato... ma leggete comunque, male non fa.
La complessità dei progetti web moderni
Un sito web professionale oggi non è più una semplice vetrina statica. Le applicazioni web moderne sono sistemi complessi che devono gestire:
- database relazionali con migliaia o milioni di record
- strutture dati complesse con relazioni tra entità multiple, e query ottimizzate per le performance.
La gestione dinamica dei contenuti richiede sistemi robusti, con versioning, workflow editoriali e pubblicazione programmata.... insomma il "Perozzi" da solo non basta.
Le funzionalità e-commerce (beni o servizi che siano) rappresentano un ulteriore livello di complessità:
- cataloghi prodotti,
- carrelli,
- checkout,
- integrazione con gateway di pagamento,
- gestione fiscale (se vuoi è il mio lavoro, scrivimi pure...
This email address is being protected from spambots. You need JavaScript enabled to view it. - logistica e tracking delle spedizioni.
Tutto questo magari deve essere integrato con sistemi di gestione delle scorte, CRM (Bitrix24, Odoo, HubSpot, Dolibarr) e magari strumenti di marketing automation (a me piacciono mailchimp e Mautic).
Le aree riservate richiedono sistemi di autenticazione e autorizzazione sofisticati, con gestione dei ruoli, permessi granulari, single sign-on (SSO), autenticazione a due fattori e conformità con normative (GDPR in primis). La sicurezza non è un'opzione ma un requisito fondamentale!
Le estensioni e integrazioni con servizi terzi — da Google Analytics ai social media, dai sistemi di email marketing ai servizi di cloud storage — devono funzionare in modo affidabile e sicuro, gestendo API key, webhook e sincronizzazione dati.... ci sei ancora? troppi termini strani?
Il caso dei CMS Open Source
Ecosistema maturo e Community globale
WordPress, con oltre il 40% di market share del web globale (cercate su internet le fonti..c'è chi parla del 60%), Joomla e Drupal rappresentano piattaforme consolidate con ecosistemi estremamente maturi. WordPress vanta oltre 50.000 plugin gratuiti e migliaia di temi, con milioni di sviluppatori in tutto il mondo che contribuiscono attivamente al codice, alla documentazione e al supporto.
Questa massa critica di utenti e sviluppatori crea un effetto rete potentissimo: qualsiasi problema, vulnerabilità o caso d'uso particolare è probabilmente già stato affrontato e risolto da qualcuno. La community fornisce risorse inestimabili: forum di supporto, tutorial, corsi, conferenze (WordCamp, DrupalCon, Joomla Day), e una documentazione estremamente dettagliata. Ricordo che le bigtech supportano e finanziano il mondo FLOSS con forza lavoro e soldi e dai progetti open source attingono a piene mani per i loro servizi.
Il valore economico di questo ecosistema è enorme: invece di reinventare la ruota, gli sviluppatori possono concentrarsi sulle funzionalità specifiche del progetto, riutilizzando componenti già testati e ottimizzati. Un plugin per l'integrazione con Stripe o PayPal, ad esempio, è già stato installato milioni di volte e ha gestito miliardi di transazioni — un livello di affidabilità impossibile da raggiungere con codice generato ex novo.
Sicurezza e gestione delle vulnerabilità
La sicurezza è forse l'argomento più convincente a favore dei CMS consolidati. WordPress, Joomla e Drupal hanno team dedicati alla sicurezza che monitorano costantemente le vulnerabilità, coordinano disclosure responsabili e rilasciano patch spesso tempestive. Mentre il software "proprietario" probabilmente lo fa quando economicamente è sostenibile. Il processo è standardizzato e trasparente: quando viene scoperta una vulnerabilità, viene assegnato un CVE (Common Vulnerabilities and Exposures) ID, pubblicato un security advisory, e rilasciata una patch. Gli amministratori dei siti ricevono notifiche automatiche e possono applicare gli aggiornamenti con un click. In molti casi, gli aggiornamenti di sicurezza critici vengono installati automaticamente.
Confrontiamo questo con il codice generato da un LLM: chi monitora le vulnerabilità? Chi rilascia le patch? La risposta è: nessuno, se non il proprietario del sito, che probabilmente non ha né il tempo né le competenze per fare security audit regolari. Una vulnerabilità zero-day nel codice custom può rimanere non scoperta per anni, esponendo dati sensibili a rischi inaccettabili.
I CMS open source implementano best practice di sicurezza consolidate prevenire SQL injection, protezione CSRF (i famosi Token per semplificare), gestione sicura delle sessioni, hashing delle password con algoritmi di criptazione moderni, open source e auditabili, headers di sicurezza HTTP, Content Security Policy, e molto altro. Queste protezioni sono integrate nel core e automaticamente disponibili a tutti gli sviluppatori.... senti un po' ChatGPT quando ti ha generato 4 pagine in croce se lo ha fatto?
Audit del codice e sua trasparenza
Il codice open source ha un vantaggio intrinseco: la trasparenza. Il principio di Linus Torvalds: "given enough eyeballs, all bugs are shallow" si applica perfettamente ai CMS. Il codice di WordPress core è sottoposto a review continua da parte di centinaia di sviluppatori esperti. Ogni commit passa attraverso processi di code review rigorosi.
Questa peer review diffusa ha implicazioni profonde per la qualità del codice. Bug, vulnerabilità, inefficienze vengono individuati e corretti rapidamente (o almeno si spera). Il codice tende a convergere verso best practice consolidate. La documentazione migliora costantemente grazie ai contributi della community.
Per confronto, il codice generato da un LLM è essenzialmente una black box. L'LLM produce codice basandosi su pattern statistici (a caso...diciamolo) appresi da enormi dataset, ma non c'è garanzia che quel codice segua best practice di sicurezza, sia efficiente, o sia privo di vulnerabilità sottili (o immense cagate). L'output può sembrare corretto a una lettura superficiale, ma può nascondere problemi profondi.
Inoltre, senza un team dedicato che audita regolarmente il codice generato, le vulnerabilità possono accumularsi nel tempo. Ogni modifica, ogni nuova feature generata dall'LLM è un potenziale vettore di attacco che nessuno sta verificando sistematicamente... ho sentito qualcuno voler costrure un CRM/ERP con Claude-Code e Python e non ho ancora finito di ridere....e poi piangere.
Manutenibilità e ciclo di vita del software
Un sito web non è mai "finito". I requisiti evolvono, emergono nuove esigenze, cambiano le normative, si presentano nuove opportunità di business. La manutenibilità a lungo termine è quindi cruciale.
I CMS open source eccellono in questo aspetto. L'architettura modulare permette di aggiungere, rimuovere o aggiornare funzionalità senza dover riscrivere l'intero sistema. I plugin e i temi seguono standard ben definiti, con API documentate e backward compatibility ben gestita.
Se lo sviluppatore originale non è più disponibile, qualsiasi altro sviluppatore esperto di WordPress, Joomla o Drupal può intervenire sul progetto senza dover decifrare codice custom (o peggio dover fare reverse engineering su codice proprietario). La curva di apprendimento è minima perché la struttura del progetto segue convenzioni standard.
Con codice generato da LLM, invece, ogni progetto è unico. Non ci sono convenzioni standard, non c'è documentazione standardizzata (quando c'è, ma sta imparando), non c'è una community a cui fare riferimento. Se l'LLM genera codice in un certo modo oggi e in modo diverso domani, si creano inconsistenze che rendono la manutenzione sempre più difficile.
Peggio ancora, il codice generato da LLM può contenere pattern obsoleti o deprecated, perché i modelli sono addestrati su dataset che includono codice vecchio. Un LLM potrebbe suggerire l'uso di funzioni PHP deprecate, librerie JavaScript obsolete, o pattern di sicurezza superati, creando debito tecnico fin dall'inizio.
Scalabilità e performance
I CMS moderni sono ottimizzati per gestire siti di ogni dimensione, da piccoli blog a portali enterprise con milioni di pageviews al giorno. WordPress.com, ad esempio, ospita centinaia di milioni di siti, come Joomla e come Drupal in ambito PA). Queste piattaforme hanno affrontato e risolto problemi di scalabilità che la maggior parte dei siti non incontrerà mai.
Un LLM può generare codice funzionante per un prototipo, ma difficilmente produrrà codice ottimizzato per performance e scalabilità. Le ottimizzazioni richiedono comprensione profonda dell'architettura, profiling, benchmarking, e spesso compromessi complessi tra diversi obiettivi. Sono competenze che richiedono esperienza.... ed esseri umani.
I rischi nascosti del codice generato da LLM
Assenza di responsabilità
Quando si usa WordPress e un plugin si rivela difettoso o introduce una vulnerabilità, c'è un ecosistema di responsabilità: gli sviluppatori del plugin hanno reputazione da difendere, ci sono canali ufficiali per segnalare problemi, esistono processi standardizzati per rilasciare fix. (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=OJ:L_202402853)
Con codice generato da LLM, non c'è nessuna catena di responsabilità. L'LLM non ha reputazione da proteggere, non rilascia patch, non monitora CVE. La responsabilità ricade interamente sul proprietario del sito, che spesso non ha le competenze per gestirla adeguatamente. Sicuramente non ne risponderanno Altman, Amodei o Musk...state sereni.
Vulnerabilità involontarie
Gli LLM non "comprendono" il codice che generano nel senso umano del termine. Riproducono pattern statisticamente probabili basati sul loro training. Questo significa che potrebbero generare codice che:
- È vulnerabile a SQL injection perché non usa prepared statements correttamente.
- È esposto a Cross-Site Scripting (XSS) perché non sanitizza gli output.
- Ha problemi di Cross-Site Request Forgery (CSRF) perché non implementa token di protezione.
- Gestisce male le sessioni, esponendo il sito a session hijacking.
- Usa algoritmi di hashing deboli (se lo fa) per le password.
- Non valida correttamente gli upload di file, permettendo l'esecuzione di codice arbitrario.
Tu sei in grado di verificarlo? Sei in grado di chiamare qualcuno che lo faccia?
La comunità FLOSS lo fa per te quando mantiene i CMS ... pensa un po'
Queste vulnerabilità possono non essere evidenti immediatamente. Il sito può funzionare perfettamente in condizioni normali, ma essere completamente esposto ad attacchi mirati. Un security researcher o un attaccante malintenzionato potrebbe scoprirle e sfruttarle prima che il proprietario del sito si accorga del problema... cosa che può avvenire anche nei CMS fatti da cuggino o da me, perchè il software non è mai perfetto.
Dipendenze non verificate
Gli LLM spesso suggeriscono l'uso di librerie esterne per implementare funzionalità complesse. Questo è ragionevole, ma quante di queste librerie sono state verificate? Sono mantenute attivamente? Hanno vulnerabilità note?
Un CMS come WordPress ha processi rigorosi per l'approvazione dei plugin nel repository ufficiale. Drupal Security Team verifica attivamente i moduli contribuiti. C'è un processo di vetting, anche se non perfetto.
Con codice generato da LLM, si finisce spesso con un mix eterogeneo di dipendenze, alcune delle quali potrebbero essere abbandonate, non mantenute, o addirittura malevole. Il supply chain attack (compromissione attraverso dipendenze di terzi) è un vettore di attacco sempre più comune, e il codice generato da LLM è particolarmente vulnerabile a questo rischio.
Costi nascosti e Total Cost of Ownership
A prima vista, generare codice con un LLM può sembrare economico: niente licenze da pagare, development apparentemente rapido, nessun costo per plugin premium. Ma questa è una visione miope che ignora i costi a lungo termine.
I costi nascosti del codice custom generato da LLM includono:
- debugging e troubleshooting continui per problemi non previsti,
- security audit regolari (o peggio, rimediazione dopo un breach),
- refactoring per mantenere il codice aggiornato con nuove versioni di linguaggi e framework
- riscrittura di componenti quando emergono nuovi requisiti,
- difficoltà nel trovare sviluppatori disposti a lavorare su codebase custom senza documentazione,
- rischio di vendor lock-in se il codice è troppo specifico e difficile da migrare.
Il Total Cost of Ownership (TCO) di un sito WordPress professionale, anche considerando hosting, plugin premium, e sviluppo custom quando necessario, è spesso inferiore al TCO di un sito custom, quando si considerano tutti i costi lungo un orizzonte di 3-5 anni.
Quando gli LLM possono essere utili
Questo non significa che gli LLM siano inutili nello sviluppo web. Al contrario, possono essere strumenti potentissimi, se usati nel contesto giusto e con la consapevolezza dei loro limiti.
Sviluppo rapido di prototipi
Per validare rapidamente un'idea, creare un MVP (Minimum Viable Product) da mostrare agli stakeholder, o testare l'usabilità di un concept, gli LLM possono accelerare enormemente il processo. Il codice generato non deve essere production-ready — deve solo funzionare abbastanza bene da validare l'idea.
Personalizzazione di temi e plugin
Anche usando un CMS, spesso si ha bisogno di personalizzazioni specifiche. Un LLM può aiutare a modificare un tema WordPress, creare un plugin custom per un'esigenza particolare, o scrivere snippet di codice per integrazioni specifiche. In questo caso, si parte da una base solida (il CMS) e si aggiunge codice custom solo dove strettamente necessario.
Automazione e scripting
Gli LLM sono eccellenti per generare script di automazione, tool di migrazione dati, script di deploy, o utility per task ripetitivi. Questi use case hanno un rischio inferiore perché tipicamente non sono esposti pubblicamente e non gestiscono dati sensibili.
Assistenza allo sviluppo
Un LLM può essere un assistente prezioso per sviluppatori esperti: suggerire soluzioni, spiegare pattern complessi, aiutare con debugging, generare test, scrivere documentazione. In questo scenario, il developer umano mantiene il controllo e valuta criticamente ogni suggerimento.
Best practice per un approccio ibrido
La soluzione ottimale spesso combina il meglio di entrambi i mondi:
- Usare un CMS consolidato come base, scegliendo WordPress, Joomla o Drupal (o altri.. ci mancherebbe, io amo anche quelli flat senza db) in base alle specifiche esigenze del progetto.
- Utilizzare plugin e temi del repository ufficiale quando possibile, privilegiando quelli ben mantenuti, con molte installazioni attive e buone recensioni.
- Ricorrere a codice custom solo per funzionalità veramente specifiche che non possono essere risolte con plugin esistenti.
Se si usa un LLM per generare codice custom, è fondamentale fare code review approfondite, testare estensivamente il codice generato, fare security audit regolari, documentare accuratamente ogni componente, e mantenere il codice aggiornato con patch di sicurezza. Considerare l'uso di strumenti di analisi statica del codice per identificare problemi di qualità e sicurezza.
Pianificare per il lungo termine: valutare non solo i costi iniziali ma il TCO su 3-5 anni. Considerare chi manterrà il sito, come verrà gestita la sicurezza, e come evolverà il progetto nel tempo.
Conclusioni (mie)
Per siti web complessi con database, gestione contenuti, marketplace, aree riservate e funzionalità avanzate, l'utilizzo di CMS open source come WordPress, Joomla o Drupal rappresenta una scelta architettonica superiore rispetto alla generazione di codice tramite LLM.
Le ragioni sono molteplici e convincenti a mio parere (modestissimo):
- ecosistema maturo con migliaia di estensioni testate, gestione professionale della sicurezza con team dedicati e processi standardizzati, audit continuo del codice da parte di community globali, manutenibilità a lungo termine grazie a standard consolidati, scalabilità provata su milioni di installazioni, e supporto di una community vasta e attiva.
- Il codice generato da LLM, per quanto impressionante possa essere in termini di rapidità di sviluppo iniziale, presenta rischi significativi:
- assenza di audit indipendente,
- vulnerabilità potenzialmente non scoperte,
- mancanza di processi di gestione delle vulnerabilità,
- difficoltà di manutenzione a lungo termine,
- costi nascosti che emergono nel tempo.
Questo non significa che gli LLM non abbiano un ruolo nello sviluppo web moderno. Sono strumenti potenti per prototipazione rapida, personalizzazione di componenti esistenti, automazione, e assistenza allo sviluppo. Ma devono essere usati con consapevolezza dei loro limiti e sempre sotto la supervisione di sviluppatori esperti... ed il peggio arriverà quando "tuo cuggino farà i siti con ChatGPT).
La scelta della tecnologia giusta non è solo una questione tecnica, ma una decisione di business che impatta sul rischio, sui costi a lungo termine, e sulla sostenibilità del progetto digitale. Per progetti professionali che devono durare negli anni e gestire dati sensibili, la prudenza e l'esperienza consolidata dei CMS open source rimangono la scelta più saggia.
La tecnologia evolve rapidamente, e forse un giorno gli LLM raggiungeranno livelli di affidabilità e sicurezza comparabili ai CMS moderni (oppure la bolla esploderà e Altman dovrà restituire tutti i soldi ai finanziatori). Ma quel giorno non è oggi.
Nel frattempo, WordPress, Joomla e Drupal continuano a alimentare una porzione significativa del web, provando ogni giorno la loro robustezza, sicurezza e capacità di adattarsi alle esigenze in continua evoluzione del panorama digitale.
