Una delle cose che mi piace di più del lavorare con Claude è l’archeologia digitale. Ho passato vent’anni ad accumulare vecchi progetti su dischi di backup, SourceForge, server dimenticati — codice che ho scritto e non ho mai più guardato. Adesso posso puntare Claude su un tarball e dire “converti questo in git” o “spiegami cosa pensava il me ventunenne qui” e avere una conversazione vera e propria col mio passato.
Lo scavo di oggi: sono andato su SourceForge e ho scaricato il repository CVS di un progetto del 2003 — Sux Services, il mio tentativo di scrivere IRC services da zero, in C, per la rete IRC Azzurra. Ho detto “Claude, converti questo repo CVS in git” e pochi minuti dopo avevo un repository Git pulito con 954 commit, tre autori, e una storia continua da settembre 2002 a novembre 2005.
Questo è il prequel di Sux Services: IRC Services Multithreaded e SQL-Backed da Zero, 2002. Prima di iniziare a scrivere IRC services da zero, ho passato la parte migliore di un anno a fare qualcosa di probabilmente ancora più folle: forkare un server IRC per aggiungere IPv6 e SSL (oggi noto come TLS). Avevo ventun anni.
Il progetto viveva in un repository CVS su SourceForge — è ancora lì, un fossile digitale. Claude l’ha convertito in Git — 171 commit, tre autori, storia continua da febbraio 2002 a gennaio 2006. L’ho scritto io — un fork di Bahamut, il demone IRC che faceva girare DALnet, una delle più grandi reti IRC della sua era. Ve lo racconto.
Nel 2009, un piccolo team a Roma iniziava a costruire Panmind, una piattaforma collaborativa per condividere e organizzare la conoscenza. L’azienda era Mind2Mind S.r.L., fondata da Emanuele Caronia.
Panmind di per sé non è sopravvissuto. Ma lo stack che abbiamo costruito ha fatto qualcosa di interessante: ha anticipato pattern architetturali che non sarebbero diventati mainstream per cinque o dieci anni. Stavamo costruendo single-page application prima che esistesse il termine, streaming analytics prima di Segment, e condividendo sessioni tra linguaggi diversi prima dei JWT.
Ho presentato alcuni dei nostri spin-off open source al Ruby Social Club di Milano nel 2010, ma quel post toccava solo la superficie — era una carrellata veloce di plugin Rails. Questa è la storia più approfondita: tre tecnologie, tre problemi risolti troppo presto, e come le stesse idee si sono ripresentate in ogni major framework che è venuto dopo.
tl;dr — IBM WebSphere ha un’API di configurazione pulita (ConfigService) sepolta sotto un wrapper a stringhe rotto (AdminConfig). Ho costruito un layer Jython ad oggetti che si aggancia a ConfigService direttamente via JMX — semplificando la configurazione e garantendo la correttezza dei tipi tramite introspezione dei metadati — più un daemon persistente che elimina l’overhead di boot della JVM, e 55 script idempotenti che si integrano col rilevamento di cambiamenti di Ansible. github.com/vjt/ansible-wsadmin
Nel 2021 ho passato sei mesi ad automatizzare l’infrastruttura WebSphere dell’IFAD con Ansible. Lo stack era IBM WebSphere Application Server (WAS), WebSphere Portal Server (WPS) e Business Automation Workflow (BAW) — un deployment clusterizzato con Deployment Manager, nodi multipli, LDAP federato, messaging SIB, tutto quanto.
L’approccio standard per automatizzare WAS è scrivere script Jython usando AdminConfig, AdminTask e AdminApp — i quattro oggetti globali di scripting che IBM fornisce dentro wsadmin. Ho provato. È durato un giorno prima di iniziare a guardare cosa c’è sotto.
Quello che ho trovato ha cambiato il mio approccio all’intero progetto. Ha anche prodotto una libreria piena di idee che non ho mai avuto modo di descrivere come si deve — fino ad ora, con un piccolo aiuto da Claude.
Oggi è il mio compleanno, e ho deciso di aprire una capsula del tempo.
Diciotto anni fa, abbiamo iniziato a costruire Myousica — una piattaforma per creare musica collaborativamente nel browser. Registra dal microfono, carica tracce, remixa la musica degli altri, costruisci canzoni insieme a sconosciuti dall’altra parte del mondo. Abbiamo lanciato a settembre 2008 dopo nove mesi di sviluppo.
Era una startup. Ha funzionato per circa cinque mesi prima di essere messa in pausa, e il codice sorgente è stato poi rilasciato su GitHub con il nome Mewsic. Ho scritto dei dettagli tecnici in una serie di tre post: la piattaforma Rails, l’editor multitraccia Flash e la pipeline audio. Quei post coprono l’ingegneria. Questo è sul quadro più ampio.
Ho un server FreeBSD che si chiama m42 e gira da anni. Email, web, firewall, i soliti. Due anni e mezzo di backup mensili restic negli snapshot — circa 25 milioni di righe syslog su quattro formati: BSD syslog, fail2ban, pf packet filter, e nginx. Una miniera d’oro di telemetria di sicurezza, completamente non indicizzata e non ricercabile.
Ho costruito uno stack di observability su un Raspberry Pi 5 a casa — VictoriaLogs per lo storage, Telegraf per il processing, Grafana per la visualizzazione — e ho deciso di fare il backfill di ognuna di quei 25 milioni di entry attraverso la stessa identica pipeline di enrichment che processa i dati live. Geolocalizzazione GeoIP, identificazione ASN, reverse DNS per ogni indirizzo IP.
Il backfill in sé era semplice. Quello che non era semplice: i tre bug che ha scovato nelle viscere di Telegraf. Il genere di bug che emerge solo sotto carico sostenuto. Il genere che nessuno incontra perché nessuno fa questa roba.
L’approccio ingenuo è scrivere script Python che replicano la pipeline — parsare i log, arricchire con GeoIP, POST al log store. L’ho fatto. Due volte. Ogni volta gli script divergevano dalla pipeline live: nomi di campi diversi, enrichment mancanti, inconsistenze nel parsing tra Starlark e le regex Python.
TL;DR: Se usi OpenWrt con mwan3 (failover multi-WAN) e una VPN WireGuard in split-tunnel (cioè NON routi tutto il traffico attraverso la VPN), aggiungi nohostroute=1 all’interfaccia WireGuard. Senza, netifd crea un route statico per l’endpoint WireGuard all’avvio dell’interfaccia, pinnato a qualsiasi uplink sia attivo in quel momento. Per il primo corollario della Legge di Murphy, tutto ciò che può andare storto andrà storto nel momento peggiore possibile — quindi il link primario sarà giù esattamente quando WireGuard parte, e il route dell’endpoint resta incollato permanentemente al backup. La tua VPN resterà incollata al backup lento mentre il link primario se ne sta lì a non fare un cazzo. Non te ne accorgerai finché non dovrai trasferire qualcosa di grosso.
(Se routi tutto il traffico attraverso WireGuard, l’host route ti serve per evitare un routing loop — ma su un setup multi-WAN, il problema del route stantio resta identico. Ti servirà un workaround diverso, tipo uno script hotplug che aggiorni il route dell’endpoint quando mwan3 switcha uplink.)
Oggi ho scoperto che il mio tunnel WireGuard verso un server remoto strisciava a 2 Mbps da inizio febbraio. Il fix ha richiesto due comandi UCI. La root cause era il flag nohostroute mancante — più un bonus: il mio stesso firewall sabotava i miei stessi health check, facendo sembrare la fibra abbastanza inaffidabile da impedire al sistema di auto-correggersi.
Ecco la storia forense completa, perché sono ancora incazzato e meritate di imparare dalle mie sofferenze.
Prima però, un po’ di contesto su come è avvenuta questa indagine. Stavo lavorando con un assistente AI (Claude Code) che ha accesso SSH alla mia infrastruttura. Questo è possibile perché ho una base solida: autenticazione SSH a chiave ovunque, DNS interno corretto (m42, golem risolvono agli indirizzi VPN giusti), mesh WireGuard tra tutti i nodi, e l’assistente si connette tramite un ssh-agent che gira come servizio utente systemd. Una variabile d’ambiente e l’AI raggiunge ogni macchina della mia rete — e, cosa fondamentale, può incrociare i dati trovati su una macchina con quelli di un’altra. Quest’indagine mi avrebbe richiesto ore di salti tra terminali. L’AI l’ha fatta in minuti, testando ipotesi metodicamente su tre macchine simultaneamente. L’investimento in SSH, DNS e VPN fatti bene ha ripagato enormemente.
È come avere un ingegnere incredibilmente veloce, competente e preciso seduto accanto a te — uno che ti lascia davvero fluire creativamente senza freni. Dici “e se facessimo…” e trenta secondi dopo hai un prototipo funzionante davanti agli occhi. Dici “no, più così” e ha già finito prima che tu abbia spiegato il perché.
È questa la sensazione che ho avuto lavorando con Claude Code negli ultimi due giorni. Ho rifatto completamente questo blog — tradotto tutti e 69 gli articoli in italiano, ridisegnato il layout da zero, aggiunto un easter egg nerd con la sequenza di boot del kernel, ripulito anni di tag accumulati, e iterato su decine di decisioni di design. Tutto tracciato in git, tutto verificabile, tutto live.
Ogni singolo commit è pubblico. Se vuoi vedere il processo grezzo — il brainstorming, le iterazioni, i bugfix, il botta e risposta — è tutto nel repo: github.com/vjt/sindro.me (e il fork del tema: github.com/vjt/hugo-sindrome-theme). Non mi vergogno a mostrare come viene fatta la salsiccia. Anzi, spero che qualcuno lo trovi utile come esempio concreto di cosa sia davvero lo sviluppo assistito dall’AI — con tutti i difetti annessi.
Ecco il mio grafico di contribuzione su GitHub, per dimostrare che non sto esagerando:
Apri l’app per controllare lo stato dell’allarme e ti accoglie una pubblicità
di Verisure stessa. Io pago fior di quattrini per il servizio e loro mi
piazzano le ads dentro l’app. È il 2026 e un’azienda di sicurezza mi fa
vedere banner pubblicitari quando provo a verificare se casa mia è protetta.
Ma le ads sono il meno. I veri problemi sono:
Routine cieche. Sì, l’app ha le “routine” — attiva a
mezzanotte, disattiva alle 7. Ma non sanno dove sei. Mezzanotte
e sei ancora in giardino? L’allarme si attiva e i sensori scattano.
Finestra aperta? Il pannello annuncia che non riesce ad attivare,
ma se non lo senti l’allarme resta spento. Vai in vacanza e
dimentichi di disabilitare la routine di disattivazione mattutina?
Allarme spento con la casa vuota. E le modifiche alle routine
impiegano 20 minuti a propagarsi — “o il giorno dopo”. Nel 2026.
Zero presenza. L’app non sa dove sei. Non sa chi è in casa.
Non sa se la donna delle pulizie è andata via. Nessuna automazione
basata sulla posizione.
Una telecamera alla volta. Vuoi vedere tutte le camere? Tocca,
aspetta, torna indietro, tocca la prossima, aspetta. Nessuna vista
d’insieme. Nessun “cattura tutto”.
Lentezza biblica. Richiedi un’immagine, aspetti, aspetti, forse
arriva. A volte ricarichi l’app e riprovi. Nel 2026.
Nessuno storage permanente. Le immagini catturate spariscono. Non
c’è uno storico consultabile.
Nessun timestamp sulle immagini. Catturi una foto e non sai
quando è stata scattata né da quale camera. Devi ricordartelo tu.
Per un sistema di sicurezza è imbarazzante.
Notifiche generiche. Una notifica uguale per tutti. Niente
notifiche actionable, niente notifiche critiche che bypassano il
“Non Disturbare”.
Quello che volevo: il mio allarme, integrato nella mia domotica, con
automazioni intelligenti, notifiche per tutti i residenti, e una
dashboard che mostra tutto in un colpo d’occhio. Senza pubblicità.
