Il 12 marzo 2026 ho portato al WordPress Meetup di Pisa un tema che attraversa il mio lavoro e il laboratorio di casa: cosa possiamo imparare gestendo direttamente WordPress, servizi e modelli AI. Il titolo dell’incontro era “WordPress, AI & Co. a Km Zero. Viaggio alla scoperta del magico mondo dell’Homelab”.
Per un founder tecnico, preparare un intervento significa scegliere quali parti del proprio lavoro rendere comprensibili e utili agli altri. La parte interessante continua dopo il palco: le domande raccolte aiutano a capire quali spiegazioni mancano e quali meritano un articolo autonomo.
Perché ho scelto il laboratorio di casa
In Romiltec mi occupo di prodotti software e infrastrutture. Il laboratorio è il posto in cui posso studiare una scelta prima che diventi un impegno verso un cliente: installare un hypervisor, provare un modello locale, ricostruire un servizio, osservare cosa si rompe quando manca una dipendenza.
Questo collegamento rendeva l’homelab pertinente per una community WordPress. Il CMS è l’applicazione visibile; sotto ci sono database, storage, rete, certificati e backup. Anche quando scegliamo un servizio gestito, conoscere questi livelli ci aiuta a formulare domande migliori al fornitore e a diagnosticare un problema.
La scelta del tema aveva anche un vantaggio pratico: potevo partire da materiali e problemi che conoscevo. Non avevo bisogno di presentare una panoramica di tutte le novità AI. Dovevo selezionare poche decisioni e spiegarne le conseguenze.
La demo rende concrete le domande
Nel talk ho mostrato anche l’uso di un agente di coding collegato a un modello locale. Il punto da osservare era l’intera catena: la richiesta, il modello, l’esecuzione degli strumenti e il risultato da verificare. Vedere soltanto una risposta in chat non dice quanto sia affidabile il lavoro sul sistema.
Chi vuole rivedere l’intervento può partire dalla registrazione del meetup. È il riferimento più utile per distinguere ciò che è stato mostrato dalle considerazioni sviluppate in seguito. I nomi dei modelli e gli strumenti di quella demo vanno letti nel contesto dell’evento, non come una classifica aggiornata del mercato.
Per preparare una demo simile partirei sempre da una domanda circoscritta: cosa voglio che il pubblico possa giudicare? Se la risposta è “il modello sa modificare un progetto”, servono anche un risultato atteso e un controllo. Altrimenti il pubblico vede movimento sul terminale, ma non può distinguere un successo da un tentativo plausibile.
Dal parlato a un articolo: cosa cambia
Una trascrizione conserva le parole, ma porta con sé ripetizioni, riferimenti alle slide e passaggi comprensibili soltanto in sala. Pubblicarla senza revisione sposta sul lettore il lavoro che avrebbe dovuto fare l’autore.
Il procedimento che considero utile ha quattro passaggi:
- Individuare una domanda effettiva affrontata nel talk.
- Recuperare l’esempio e controllare i dettagli nella documentazione.
- Scrivere un testo che si capisca anche senza aver visto il video.
- Collegare quell’approfondimento al materiale originale e agli altri articoli pertinenti.
Da qui il percorso sul blog: il perché di un homelab, le scelte per eseguire WordPress in VM, LXC o Docker e i criteri per rendere accessibili i servizi. Ognuno deve rispondere a un problema diverso; il video resta il contesto comune.
Quale posizionamento può costruire un talk tecnico
Vorrei che chi ascolta capisse su quali problemi posso essere utile. Un intervento su backup e modelli locali comunica un campo di lavoro preciso, soprattutto se mostra limiti e scelte scartate. Una presentazione che promette di risolvere tutto con l’AI comunica molto meno sulla competenza di chi parla.
Il blog personale mi permette di approfondire quel campo con una voce distinta da quella commerciale di Romiltec. Posso spiegare perché una soluzione non conviene, cosa controllerei prima di adottarla e quali parti non ho ancora dimostrato. Sono informazioni utili anche a chi non diventerà un cliente.
Come misurerei se il tempo è stato ben speso
Terrei separati tre risultati: partecipazione all’evento, consultazione dei materiali e conversazioni nate in seguito. Le visualizzazioni non sono richieste commerciali; una richiesta arrivata dopo un talk non dimostra da sola che sia stata causata dal talk.
Un registro semplice può annotare ore di preparazione, materiali pubblicati, domande ricorrenti e origine dichiarata dei contatti. Non uso qui stime di ROI o posizioni su Google: senza dati confrontabili trasformerebbero un’esperienza di divulgazione in una promessa di marketing.
La ragione per ripetere il lavoro è più concreta: un problema spiegato bene può aiutare in sala e continuare a essere utile quando qualcuno lo cerca mesi dopo. È questo il legame che voglio costruire tra il lavoro quotidiano, la community e il blog.