Per molto tempo non ero nemmeno sicuro che questo sito avesse bisogno di un blog.
Passo già la maggior parte del mio tempo di lavoro a risolvere problemi. Alcuni sono normali task frontend o backend. Altri diventano molto più specifici: encoding delle immagini, comportamento dei browser, esperimenti SEO, problemi di infrastruttura, sviluppo assistito dall'AI, elaborazione dei media o qualche strano problema in produzione che parte da una domanda semplice e si trasforma in diversi giorni di indagine.
Dopo tutto questo, scrivere altre migliaia di parole può sembrare inutile.
Chi le leggerà?
Che cosa ci guadagno?
Perché non risolvere semplicemente il problema e andare avanti?
Alla fine ho trovato una risposta che per me era sufficiente: una parte di questo lavoro costa troppo, in termini di tempo e ragionamento, per essere buttata via.
Un problema difficile può contenere un intero articolo prima ancora che me ne renda conto
I miei articoli di solito non iniziano con il pensiero: “Questa settimana devo pubblicare un post.”
Iniziano con un problema.
A volte nasce dal mio lavoro. A volte da uno dei miei progetti. Altre volte qualcosa che non capisco mi incuriosisce e continuo ad approfondire finché non lo comprendo molto meglio.
L'elaborazione delle immagini mi ha portato spesso in questo tipo di rabbit hole.
All'inizio un compito può sembrare quasi stupidamente semplice:
Prendi queste immagini e rendile più piccole.
Puoi chiedere uno script a un modello AI e riceverlo quasi subito.
Questo non significa avere una buona pipeline di elaborazione delle immagini.
La prima versione può ignorare le differenze tra JPEG, PNG, WebP e contenuti animati. Può usare un unico valore di qualità per tutto, fare upscaling senza motivo, gestire male la trasparenza, conservare metadata che volevi eliminare o distruggere quelli che volevi mantenere. Può ottimizzare soltanto la dimensione del file senza misurare il danno visivo. Può funzionare perfettamente su dieci file di prova e diventare un errore molto costoso a una scala molto più grande.
Uno script che termina correttamente non è la stessa cosa di un sistema di cui mi fido.
Molti miei articoli nascono proprio da questa differenza.
Il mio workflow con l'AI è molto più lento di “chiedi la risposta a ChatGPT”
Uso molto un account ChatGPT a pagamento quando lavoro su problemi di questo tipo.
Una sola conversazione può durare giorni o settimane. Faccio domande, testo i suggerimenti, riporto i risultati, metto in discussione le ipotesi, ispeziono il codice, trovo un altro edge case, cambio l'implementazione, la rieseguo, confronto il risultato e ricomincio.
Per indagini particolarmente profonde ho accumulato più di 100 ore di lavoro intorno allo stesso problema generale.
Questo non significa che passi 100 ore ad aspettare che un modello AI scopra magicamente la risposta.
Il processo è iterativo.
Di solito assomiglia più a questo:
- Descrivo il problema.
- Il modello propone una soluzione iniziale.
- La eseguo su dati reali.
- Qualcosa è debole, inefficiente o semplicemente sbagliato.
- Riporto le prove nella conversazione.
- Cambiamo approccio.
- Testo di nuovo.
- Compare un altro edge case.
- Ripetiamo.
Questo ciclo può ripetersi molte volte.
Il risultato utile spesso non è il primo script, ma l'insieme di fallimenti, misurazioni, correzioni e decisioni accumulate intorno a esso.
L'AI ha reso economico generare un punto di partenza. Non ha reso economica la verifica
Questo è uno dei motivi per cui trovo troppo semplicistica la discussione abituale sui contenuti tecnici scritti con l'AI.
Sì, un modello AI può produrre molto velocemente un tutorial plausibile.
Può anche produrre codice che sembra assolutamente ragionevole ed è sbagliato proprio nelle situazioni che contano.
Nei problemi tecnici molto specifici, raramente voglio la prima risposta plausibile. Voglio sapere che cosa succede quando la eseguo davvero.
Se sto costruendo una pipeline di immagini, voglio controllare dimensioni di output e qualità visiva. Voglio sapere che cosa accade con formati sorgente diversi. Voglio testare dimensioni insolite, alpha, animazioni e input corrotti. Voglio capire quali assunzioni sta facendo l'implementazione.
Se lo script dovrà poi toccare una collezione enorme, questo lavoro diventa ancora più importante.
Dieci milioni di immagini è volutamente un esempio estremo, non un'affermazione sulla dimensione di un mio dataset specifico. Ma illustra bene il problema: un piccolo errore sistematico moltiplicato dieci milioni di volte non è più piccolo.
Il costo della generazione del codice è crollato.
Il costo per determinare se quel codice meriti di essere eseguito su larga scala, invece, no.
La chat è materiale di ricerca, non l'articolo finale
Dopo una lunga indagine di questo tipo, la cronologia della chat può contenere una quantità assurda di informazioni.
Può includere:
- approcci falliti;
- codice sostituito in seguito;
- risultati di benchmark utili;
- log;
- fraintendimenti;
- correzioni;
- spiegazioni di comportamenti poco chiari;
- confronti tra alternative;
- edge case a cui inizialmente non avevo pensato;
- e le regole finali di cui alla fine mi sono fidato.
Lasciare tutto questo chiuso in una conversazione privata mi sembra uno spreco.
Quindi estraggo le parti utili e le trasformo in un articolo.
L'articolo non è una trascrizione della conversazione. Gran parte della conversazione non dovrebbe mai diventare articolo.
Un articolo tecnico utile richiede un altro passaggio: eliminare i vicoli ciechi che non insegnano nulla, mantenere quelli che spiegano qualcosa di importante, verificare le affermazioni, ricostruire la cronologia, distinguere osservazione e spiegazione e trasformare il risultato in qualcosa che un altro sviluppatore possa realmente usare.
Questa fase editoriale conta.
L'AI può partecipare, ma le prove arrivano comunque dal lavoro svolto.
L'elaborazione delle immagini mi ha insegnato quanto può diventare profondo un problema “semplice”
L'ottimizzazione delle immagini è probabilmente l'esempio più chiaro del mio lavoro.
Ci ho passato abbastanza tempo da vedere ciò che inizialmente sembrava una collezione di impostazioni dell'encoder trasformarsi gradualmente in un problema di sistema molto più grande.
Le domande cambiano rapidamente.
Con quale formato sorgente sto lavorando?
È animato?
Le dimensioni devono cambiare?
Come scelgo la qualità?
Quale metrica deve stabilire se la perdita di qualità è accettabile?
Un solo threshold di qualità funziona su immagini completamente diverse?
Come evito l'upscaling?
Quali metadata devono sopravvivere?
Che cosa succede alla trasparenza?
Come va validato l'output?
Il file più piccolo giustifica davvero il costo aggiuntivo di encoding?
Che cosa succede quando cambia la popolazione degli input?
Per questo sono scettico nei confronti degli script di cinque righe per la “massima ottimizzazione delle immagini”.
Possono certamente elaborare un'immagine.
È diverso dal costruire una pipeline di cui comprendi i compromessi.
Per i miei attuali workload ricchi di immagini, AVIF è di solito il primo formato che considero. È una regola basata sul tipo di progetti su cui lavoro, non un'affermazione che ogni sito del mondo dovrebbe cancellare domani tutti i formati più vecchi. Requisiti di compatibilità, materiale sorgente, latenza, costo dell'encoder e architettura di delivery possono cambiare la risposta.
La parte interessante non è dichiarare vincitore un formato.
È capire abbastanza bene il workload da prendere la decisione consapevolmente.
Vorrei approfondire allo stesso modo anche l'elaborazione video. Non ci sono ancora arrivato. È anche questo che rende interessanti questi temi: ogni volta che penso di aver raggiunto il fondo di un problema, compare un altro strato.
Poi un sito giapponese ha trovato il blog
Non mi aspettavo un ritorno particolare dalla pubblicazione di questi articoli.
Questo blog non mi dà un ritorno economico significativo. Lo faccio perché mi piace il processo e perché preferisco conservare il lavoro utile piuttosto che lasciarlo sparire in vecchie chat e nella cronologia del terminale.
Poi è successo qualcosa che davvero non mi aspettavo.
Il 17 settembre 2026, il sito giapponese Levtech Freelance ha pubblicato una raccolta con un titolo traducibile più o meno come “Blog consigliati agli ingegneri che vogliono migliorare le proprie competenze”.
L'articolo di Levtech Freelance includeva JSVar insieme a diversi altri blog di engineering.
Levtech fa parte di un grande ecosistema giapponese dedicato alle carriere IT, mentre Levtech Freelance si concentra sul supporto e sul matching degli ingegneri IT freelance con opportunità professionali. Per me, la parte interessante non era semplicemente ottenere un backlink. Era vedere quali parti del mio lavoro un team editoriale esterno ritenesse abbastanza interessanti da descrivere.
La sezione dedicata a JSVar evidenziava in particolare tre articoli.
Uno parlava del motivo per cui Codex e TypeScript mi erano sembrati una buona combinazione nello sviluppo in produzione, soprattutto perché i type e il feedback del compilatore TypeScript possono far emergere problemi nel codice generato.
Un altro raccontava la traduzione del blog in 20 lingue con ChatGPT e l'arrivo, da diversi Paesi, di visitatori provenienti dalla ricerca direttamente sulle pagine localizzate.
Il terzo era il mio esperimento di pubblicazione di 10.000 pagine SEO generate dall'AI, che alla fine si è trasformato più in una storia di fallimento che di crescita facile.
Quella selezione mi ha divertito perché si tratta di tre articoli molto diversi, ma con lo stesso schema.
Si basano tutti su qualcosa che ho fatto davvero.
Non so esattamente come Levtech mi abbia trovato
Qui c'è una storia molto invitante da raccontare.
Non parlo giapponese.
Il mio sito ha una versione giapponese.
Una pubblicazione giapponese di engineering ha trovato il sito.
Quindi la traduzione del blog in giapponese ha fatto sì che Levtech lo scoprisse.
Non posso dimostrarlo.
Forse le pagine giapponesi hanno aiutato.
Forse la ricerca li ha portati a un articolo in inglese.
Forse qualcuno ha condiviso un link.
Forse hanno trovato il sito attraverso un percorso completamente diverso.
Non dispongo di quei dati di attribuzione, quindi non intendo costruire da questa storia un case study SEO perfetto che i dati non sostengono.
Ciò che posso confermare è molto più semplice: ho pubblicato il blog in più lingue e in seguito una pubblicazione giapponese lo ha trovato abbastanza interessante da inserirlo in una selezione editoriale.
È già un buon risultato.
E mi fa particolarmente piacere perché anche la localizzazione era un esperimento che all'inizio sembrava richiedere molto lavoro per un ritorno incerto.
La citazione era importante perché rappresentava una validazione indipendente
Con “validazione” non intendo che Levtech abbia dimostrato che tutto ciò che scrivo è corretto.
Non hanno sottoposto ad audit la mia codebase né riprodotto ogni esperimento.
Ciò che contava era più modesto.
Qualcuno dall'altra parte del mondo, che scrive per un pubblico a cui io non potrei rivolgermi nella loro lingua, ha trovato abbastanza valore nel mio lavoro da riassumerlo per i propri lettori.
Non avevo fatto alcun pitch.
Non avevo scritto quegli articoli originali per Levtech.
Non mi aspettavo di comparire in una raccolta giapponese.
Per questo il risultato ha significato qualcosa per me.
Suggerisce che un articolo tecnico molto di nicchia non abbia necessariamente bisogno di un pubblico enorme per meritare di essere pubblicato.
Deve essere utile al lettore giusto.
Uno sviluppatore dovrebbe aprire un blog nel 2026?
Per me sì — a una condizione importante.
Devi avere davvero qualcosa che vuoi mettere per iscritto.
Non consiglierei di avviare un blog tecnico solo perché qualcuno sostiene che ogni sviluppatore abbia bisogno di un “personal brand”.
Non lo inizierei neppure aspettandomi un reddito passivo.
E non lo creerei soltanto per riempirlo di spiegazioni generiche su tecnologie che hanno già documentazione migliore.
Ma se il tuo lavoro produce continuamente cose che avresti voluto trovare quando hai iniziato, è diverso.
Scrivile.
Scrivi dello strano incidente in produzione.
Scrivi dell'ottimizzazione che ha richiesto tre giorni in più del previsto.
Scrivi del benchmark che ha contraddetto la tua ipotesi.
Scrivi dell'approccio che sembrava elegante e poi ha fallito.
Scrivi dell'implementazione finale, ma spiega anche perché quella ovvia non bastava.
Queste sono le parti difficili da costruire partendo solo da conoscenza generica.
L'AI mi dà più materiale su cui scrivere, non meno
L'AI non mi ha fatto pensare che i blog tecnici siano diventati obsoleti.
Per me è successo quasi il contrario.
Posso esplorare più idee perché ottenere un'implementazione iniziale o una spiegazione è più veloce di un tempo.
Ma iterazioni più rapide generano anche più prove: più varianti, più log, più benchmark, più tentativi falliti e più cose da verificare.
Quel materiale grezzo acquista valore solo dopo che qualcuno ha fatto il lavoro necessario per stabilire che cosa sia vero e che cosa sia importante.
Una conversazione con un'AI composta da 500 messaggi non è automaticamente conoscenza.
Uno script che alla fine supera test reali, insieme alla spiegazione delle 20 versioni che non ce l'hanno fatta, può diventarlo.
È questa differenza che voglio conservare nel blog.
Pubblicare è il modo in cui impedisco al lavoro utile di sparire
La maggior parte del lavoro tecnico è sorprendentemente temporanea.
Un bug difficile viene corretto.
Il terminale viene chiuso.
Il deployment riesce.
La conversazione scende nella cronologia.
Sei mesi dopo, potrei non ricordare nemmeno io perché l'implementazione finale abbia quella forma.
Scrivere cambia tutto questo.
Mi costringe a ricostruire il ragionamento finché le prove esistono ancora.
Crea qualcosa che può essere cercato.
Mi dà un riferimento per il mio lavoro futuro.
E a volte, a quanto pare, arriva a qualcuno che non avrei mai immaginato — compresa una pubblicazione di engineering in una lingua che non parlo.
Continuo a non avere una ragione particolarmente sofisticata per mantenere questo blog.
Mi piace imparare.
Mi piace costruire cose.
Mi piace andare troppo in profondità in problemi che all'inizio sembravano semplici.
E dopo aver passato decine, a volte più di cento ore, per arrivare a una risposta utile, non voglio più che quella risposta muoia dentro una finestra di chat.
Per me è una ragione sufficiente per pubblicarla.
Se anche il tuo lavoro produce lo stesso tipo di conoscenza guadagnata con fatica, penso che potrebbe essere una ragione sufficiente anche per te.