Automatizzare un blog con IA è facile da immaginare e molto più difficile da realizzare bene. Volevo pubblicare un articolo al giorno in quattro lingue senza toccarlo; due settimane dopo, 91 pagine erano danneggiate. Ecco che cosa si è rotto, come lo abbiamo riparato Claude e io, e che cosa funziona oggi.

L’essenziale in poche righe

  • Uno script e l’IA Gemini pubblicavano un articolo al giorno, in quattro lingue, senza che nessuno li rileggesse. Dopo due settimane, 91 pagine erano danneggiate.
  • Un’altra IA, Claude, ha trovato la causa (l’architettura molto più del modello), poi ha verificato e riparato quelle 91 pagine in diretta sul sito, con backup e ripristino automatici a ogni passaggio.
  • È stato costruito un nuovo generatore: una struttura imposta, un’impaginazione affidata a un programma, controlli che bloccano e bozze al posto delle pubblicazioni.
  • Resta a mio carico ciò che una macchina non può decidere: la linea editoriale, i fatti da verificare e il rinnovo di alcune credenziali di accesso.

La scommessa iniziale

Un piccolo ufficio di agenzia con un portatile, una sveglia e quattro nuvolette di dialogo vuote
La scommessa: un articolo al giorno, in quattro lingue, senza toccarlo.

Dirigo dal 2013 un’agenzia web con sede a Pondicherry, in India. Realizziamo siti, negozi online e app mobili, gestiamo i social dei nostri clienti e lavoriamo in una cinquantina. Il blog del nostro stesso sito dovrebbe quindi essere la vetrina più curata della casa. Spesso accade il contrario: il calzolaio ha sempre le scarpe rotte.

All’inizio di ottobre ho voluto sistemare la cosa in un colpo solo. L’idea stava in una frase: un articolo al giorno, scritto in inglese, poi adattato in francese, spagnolo e italiano, e pubblicato senza che io debba toccarlo. Leggo queste quattro lingue. So quali porte può aprire un sito multilingue fatto bene, e so anche quante ore costa alimentarlo a mano.

Il meccanismo sembrava semplice, quasi troppo bello. Uno script scritto in Python. L’intelligenza artificiale di Google, Gemini, per scrivere. Un’attività pianificata su Windows che parte ogni mattina alle 10:14. E il mio sito WordPress, con il tema Avada, le traduzioni gestite da WPML e il suo plugin SEO, per ospitare il tutto.

Era troppo bello, infatti. Per qualche giorno tutto è sembrato funzionare. Gli articoli arrivavano, le traduzioni si allineavano accanto all’originale e il blog si riempiva a una velocità che nessun team umano avrebbe mai retto. Dopo due settimane c’erano ventidue argomenti online, cioè novantuno pagine contando tutte le traduzioni.

Sulla carta, era un successo. In realtà, nessuno aveva letto quelle pagine riga per riga. Non io, preso da tutto il resto. Non lo script, che sa solo seguire le sue istruzioni. Non la macchina che le aveva scritte, che non ha alcun motivo di dubitare di ciò che produce.

Questo testo racconta il seguito. Come mi sono accorto che qualcosa non andava, perché la situazione è diventata critica, come un’altra intelligenza artificiale, Claude, ha verificato e poi riparato ognuna di quelle pagine direttamente sul mio sito online, e come abbiamo ricostruito il generatore perché non succeda più. Ho cercato di scriverlo in modo che si capisca anche senza conoscere una riga di codice. Ti racconto anche le false partenze, perché sono quelle che mi hanno insegnato di più.

Che cosa succede davvero ogni mattina alle 10:14

Una cucina di ristorante dove un cuoco passa i piatti a un cameriere e nessuno assaggia niente
Una cucina dove nessuno assaggia: l’errore arriva fino al tavolo.

Per capire che cosa è andato storto bisogna guardare in cucina. Immagina un ristorante in cui un cuoco molto bravo prepara i piatti, un cameriere li taglia, li raddrizza e li dispone nei piatti, e nessuno assaggia niente prima che il piatto arrivi al cliente. Finché tutto va bene, il sistema è di un’efficacia formidabile. Appena un anello sbaglia, l’errore viaggia fino al tavolo senza che nessuno l’abbia visto.

Ecco, a grandi linee, che cosa faceva il mio script ogni giorno:

  1. Scorreva i titoli di alcuni siti di notizie su SEO e intelligenza artificiale, poi chiedeva a Gemini di scegliere un argomento nuovo.
  2. Gli chiedeva un articolo di duemila-duemilacinquecento parole, in inglese, scritto in un semplice linguaggio di marcatura.
  3. Faceva realizzare tre immagini, una per l’intestazione e due per il corpo del testo.
  4. Richiedeva un titolo e una descrizione per i motori di ricerca.
  5. Passava il testo in una funzione di pulizia, incaricata di trasformarlo in una pagina web pulita.
  6. Chiedeva poi tre traduzioni, in francese, spagnolo e italiano, con l’istruzione di non cambiare nulla della formattazione.
  7. Depositava il tutto sul sito, trasmetteva i collegamenti tra le lingue grazie a un piccolo ponte installato apposta sul mio WordPress e aspettava il giorno dopo.

Si nota subito che cosa manca: un passaggio per guardare il risultato. Nessuna rilettura, nessun controllo, nessun avviso se qualcosa non somigliava a un articolo finito.

I primi segnali

Leggo le quattro lingue, cosa che è insieme un vantaggio e una maledizione: vedo tutto. Ecco che cosa ho notato per primo, e che cosa l’audit avrebbe poi confermato:

  • Gli esempi di codice erano spariti o arrivavano a brandelli, anche in articoli tecnici di cui erano il cuore.
  • Segni parassiti punteggiavano il testo: asterischi, cancelletti, emoji, frecce disegnate con i trattini.
  • Alcune traduzioni si fermavano a metà di un’idea, a volte a metà di una frase.
  • In italiano, la piccola preposizione “ai”, che significa “a i”, si scriveva “AI”, come l’intelligenza artificiale, decine di volte.
  • Unità di misura e sigle perdevano le maiuscole, e i prezzi non coincidevano più da una lingua all’altra.
  • Tutti gli articoli puntavano alla stessa parola chiave principale, “Digital Strategy”, esattamente ciò che non si deve fare in SEO.

Presi uno per uno, questi difetti si correggono in cinque minuti. Moltiplicati per ventidue argomenti e quattro lingue, formavano un cantiere che non potevo più ignorare. La situazione era diventata critica: il blog di un’agenzia web, che dovrebbe dimostrare la nostra serietà, mostrava i propri difetti a ogni visitatore, in quattro lingue.

Ho provato prima a risolvere con lo stesso Gemini, mostrandogli il problema e chiedendogli di correggere il suo script. Ci ho passato molto tempo, e ne sono uscito con la sensazione che ogni correzione ne creasse un’altra. È lì che ho capito che forse stavo guardando nella direzione sbagliata.

Gemini era colpevole solo a metà

Un nastro trasportatore che porta pagine di testo dentro una macchina cancellatrice troppo zelante
L’addetto alle pulizie troppo zelante cancellava tutto ciò che sembrava codice.

Quando un piatto arriva freddo, si dà la colpa al cuoco. A volte è il cameriere che l’ha dimenticato sul pass. Leggendo lo script da cima a fondo, Claude ha ripercorso la catena anello per anello, e il verdetto mi ha sorpreso: la maggior parte dei danni non veniva da ciò che Gemini aveva scritto, ma da ciò che gli succedeva dopo.

Il pulitore troppo zelante

La funzione incaricata di trasformare il testo in pagina web aveva una missione ragionevole: evitare che pezzi di codice o schemi mal formati inquinassero gli articoli. Per farlo, eliminava tutto ciò che somigliava a codice. In concreto, cancellava ogni riga che contenesse certe parole, come “import” o “class”, e tutto ciò che si trovava tra tre apici inversi. In un articolo per principianti il codice vero è l’eccezione. In un articolo tecnico è la ragion d’essere del testo, e spariva senza alcun messaggio di errore.

Il limite invisibile

A Gemini si chiedevano da duemila a duemilacinquecento parole, ma lo script gli concedeva un margine di risposta limitato a 8192 “token”, l’unità di misura del testo per una IA. È poco. Soprattutto, lo script non verificava mai se la risposta fosse stata portata fino in fondo. Un testo troncato di netto veniva pubblicato come un testo finito.

La traduzione in un colpo solo

Le traduzioni venivano richieste in blocco, con l’istruzione di conservare la formattazione “esattamente”. Nessuna regola propria di ogni lingua, nessun glossario dei nomi di marca da non toccare, nessuna convenzione sulle maiuscole. Il risultato era fluido in superficie e pieno di piccoli errori in profondità, come il celebre “AI” italiano.

Titoli e descrizioni approssimativi

Il titolo e la descrizione per i motori di ricerca venivano estratti cercando la parola “title:” nella risposta. Se mancava, lo script ripiegava su un testo generico, uguale per tutti. Il codice, inoltre, tagliava il titolo SEO a cinquanta caratteri, qualunque fosse la frase.

E che cosa Gemini aveva davvero sulla coscienza

La sua parte non è nulla. Quando gli si chiede un articolo di attualità, a volte inventa una cifra o una caratteristica per sembrare preciso. Ama le emoji, gli elenchi con le spunte e le tabelle decorative. Ma sono inclinazioni, non guasti, e un buon sistema è progettato per inquadrarle.

La lezione

Un modello linguistico è un ottimo redattore e un pessimo controllore di sé stesso. Ciò che avevo costruito somigliava a una fabbrica senza reparto qualità. Il problema non era trovare una IA migliore. Bisognava cambiare l’architettura attorno a lei.

Ho cambiato interlocutore

Il giorno in cui ho aperto una conversazione con Claude, avevo una richiesta in due tempi, e l’ho formulata con la franchezza di chi non ne può più: Gemini mi creava solo problemi, avevo faticato troppo e volevo sapere due cose. Prima, che cosa non andava nel mio script. Poi, e soprattutto, come riparare tutti gli articoli pubblicati dal 1° ottobre, traduzioni comprese, con l’elenco degli identificativi a supporto.

Non avevo alcuna garanzia che avrebbe funzionato. Ho capito subito che la strada sarebbe stata lunga, e non solo per il lavoro in sé.

Primo ostacolo: il sito chiudeva la porta

Claude lavora in un ambiente informatico isolato, da qualche parte nel cloud. Quando ha provato a interrogare il mio sito, questo ha risposto con un rifiuto. Niente di grave: è il comportamento normale di un sito protetto. Ma l’autorizzazione all’accesso si imposta nelle impostazioni del mio account Claude, dove bisogna aggiungere il nome di dominio del mio sito a un elenco di siti autorizzati. Ho risposto che non vedevo l’opzione, perché ero nel piano gratuito. Subito dopo sono passato al piano Pro, e l’opzione è comparsa.

Secondo ostacolo: le credenziali

Per modificare gli articoli servono diritti di scrittura. Invece di incollare le password in una conversazione, le ho raccolte in un file di configurazione sul mio computer, che Claude ha poi usato per lavorare, con un accesso specifico che posso revocare in qualsiasi momento. Questa abitudine è una delle regole che consiglio alla fine di questo testo.

Terzo ostacolo: il sito rispondeva solo al mio computer

Anche con il dominio autorizzato, il mio sito continuava a diffidare dell’ambiente di Claude. La soluzione è arrivata da un’angolazione inattesa: il mio portatile, che il sito conosce e accetta. Ho aperto l’applicazione desktop di Claude, che può collegarsi al mio computer. Poi Claude ha preparato per il mio PC un piccolo programma, una specie di sportello, che avvio io e che esegue uno per uno i lavori che Claude deposita in una cartella e gli restituisce i risultati. Claude scrive le istruzioni e le verifica, il mio computer parla con il sito e il risultato risale.

Restava l’unica domanda che contava davvero: fin dove lasciarlo arrivare? Ho deciso senza sfumature. Volevo che intervenisse direttamente sul sito online, che pubblicasse lui stesso le sue correzioni e che mi dimostrasse, invece di promettermelo, di essere all’altezza. Ho aggiunto che, se gli serviva più potenza, doveva dirmelo. Non ne ha avuto bisogno.

Ho posto anche una condizione, che ripeto volentieri a chiunque affidi un lavoro a una IA: “tocca a te verificare ciò che fai”. Ha guidato ciascuna delle tappe successive.

L’audit: novantuno pagine sotto la lente

Una lente d'ingrandimento gigante sopra una griglia di miniature di pagine con segni verdi e punti arancioni
L’audit: novantuno pagine esaminate una per una.

Prima decisione, e me l’ha imposta il buon senso più che la voglia: riparare solo dopo aver misurato. Non avevo un elenco affidabile dei difetti, solo impressioni. Ho quindi chiesto a Claude di lanciare il suo audit, con dati freschi letti direttamente dal sito, senza fidarsi di quelli che avevo io.

Un audit è semplicemente una rilettura metodica, ma fatta da una macchina che non si stanca. Per ogni pagina, il programma confrontava il titolo, la struttura dei sottotitoli, i paragrafi, gli elenchi, le tabelle, i blocchi di codice, le immagini, i link, le informazioni destinate ai motori di ricerca, la lingua usata e la presenza del pulsante di contatto. Ottantotto pagine si ripartivano in ventidue gruppi di quattro lingue. Altre tre traduzioni vagavano per conto loro, senza un genitore ufficiale: doppioni di uno stesso articolo, che abbiamo classificato come “orfane”.

Quando non risponde nessuno

Ho avuto un momento di dubbio. A un certo punto ho scritto che lo script che avevo lanciato mi dava l’impressione di girare a vuoto. Pochi minuti dopo mi sono corretto: girava eccome, ma molto lentamente. La ragione è semplice e un po’ umiliante per l’impazienza umana: interrogare novantuno pagine, in più lingue, più volte ciascuna, richiede tempo, soprattutto quando il sito si preoccupa di non lasciarsi sommergere.

Ho dato allora l’unica consegna che vale in una situazione del genere. Non mi serviva che fosse veloce. Mi serviva che il risultato finale fosse perfetto, e non importava quanto tempo ci volesse. Quella frase ha cambiato il modo di lavorare: Claude ha smesso di ottimizzare la velocità per ottimizzare l’affidabilità.

Che cosa ha rivelato l’audit

Che cosa abbiamo trovato Un esempio concreto Che cosa ne abbiamo fatto
Codice mancante o rotto Esempi di configurazione spariti da articoli tecnici Ricostruiti nelle quattro lingue, con commenti in inglese
Formattazione parassita Asterischi, cancelletti, emoji, schemi fatti di trattini e frecce Ripuliti; confronti disegnati con i caratteri trasformati in vere tabelle
Traduzioni troncate Conclusioni assenti, frasi interrotte Completate e rilette
Errori di maiuscole e di lingua “ai” trasformato in “AI” in italiano (35 volte); kW e kHz in minuscolo Corretti ovunque
SEO La stessa parola chiave per tutti, titoli troppo lunghi (90 su 91) Titoli, descrizioni e parole chiave rifatti pagina per pagina
Doppioni e link Tre traduzioni orfane, un link esterno morto Orfane ripulite, link sostituito

Il quadro, preso singolarmente, non era drammatico, ma nel complesso era enorme. E definiva il cantiere: non ritoccare tre frasi, ma rifare ogni pagina secondo regole identiche, verificare il risultato pagina per pagina e non dare mai per scontato che “deve andare bene”.

Il cantiere: lavorare in diretta senza rompere il sito

Un funambolo con una cassetta degli attrezzi sopra una rete di sicurezza
Lavorare in diretta sul sito, con una rete sotto.

In ogni riparazione arriva un momento in cui bisogna scegliere tra prudenza ed efficacia. Ho scritto a Claude che dovevo andare a dormire e che volevo che lavorasse in autonomia. Poi, qualche messaggio dopo: “go”. Verificare, correggere e ripubblicare tutti gli articoli creati dal 1° ottobre, direttamente sul sito online.

La frase può sembrare temeraria. Affidare a una IA la scrittura su un sito che riceve visitatori, senza rileggere di persona ogni modifica, è il tipo di decisione che fa venire i brividi. Ciò che l’ha resa ragionevole non è stata la mia fiducia. È stata la rete di sicurezza che Claude ha predisposto prima di scrivere una sola riga.

La rete di sicurezza

Per ogni articolo, la procedura era sempre la stessa, in quest’ordine:

  1. Salvare lo stato attuale della pagina, in un file conservato sul mio computer.
  2. Scrivere la versione corretta sul sito.
  3. Rileggere ciò che il sito ha davvero registrato e confrontarlo con ciò che avrebbe dovuto registrare.
  4. Aprire la pagina pubblica come farebbe un visitatore: deve rispondere, non mostrare codice tecnico per errore, contenere le frasi attese e mostrare il pulsante di contatto.
  5. Tornare indietro automaticamente, senza aspettare il mio parere, se uno di questi controlli falliva.

Con questo dispositivo, lo scenario peggiore non era più una pagina rotta online, ma una pagina rifiutata e poi ripristinata com’era, con un messaggio di errore che ne spiegava il motivo.

Come venivano riparate le pagine

Claude non ritoccava gli articoli a caso. Ricostruiva ogni pagina a partire dal suo contenuto, secondo le stesse regole per tutte le lingue: formattazione ripulita, codice ripristinato, maiuscole corrette, titoli e descrizioni riscritti, pulsante di contatto conservato, link verificati. Poi un secondo giro di controlli, indipendente dalla riparazione, rileggeva il risultato. L’idea è la stessa di un team umano: chi corregge non è chi convalida.

Le ondate

Il lavoro è avanzato per ondate successive, sempre più fini. La prima ha trattato ottantasette pagine: ottanta hanno superato tutti i controlli al primo colpo, sette sono state rifiutate e poi corrette. La seconda ha ripubblicato le novantuno pagine con testi rifiniti, e tutte hanno superato i controlli. Una terza ha ripreso undici pagine per dettagli rimasti. Ma la parte più difficile doveva ancora arrivare.

Nel frattempo, le tre bozze che non volevo assolutamente veder toccate sono rimaste rigorosamente intatte, come concordato: il perimetro del cantiere era stabilito, ed è stato rispettato.

Il mistero delle parentesi graffe

Un detective che ispeziona un filtro a imbuto che inghiotte simboli di parentesi graffe
Il mistero delle parentesi graffe: un filtro che inghiottiva il contenuto.

È la parte del racconto che preferisco, perché somiglia a un’indagine poliziesca e perché mostra perché non ci si può accontentare di “sembra a posto”.

Passate le prime ondate, Claude ha continuato a guardare le pagine pubbliche come un visitatore, in particolare quelle che contenevano codice. Qualcosa non andava, in modo sottile. Alcuni esempi superavano tutti i controlli interni ma si mostravano storti sul sito: pezzi erano spariti, altri si erano trasformati.

Un dettaglio tecnico, spiegato semplicemente

In una pagina web certi caratteri sono riservati: il segno “minore di” serve ad aprire un tag. Per mostrarlo come semplice simbolo lo si scrive in una forma codificata, una “entità”, per esempio <. Il browser la legge e visualizza il segno. È un meccanismo molto comune, e lo usavamo in tutti i blocchi di codice.

Prima ipotesi: l’errore veniva da noi. Claude ha quindi scritto l’entità in una forma rinforzata, perché sopravvivesse a una decodifica in più. Un’intera ondata è stata ripubblicata su questa base. I controlli di allora sono stati superati, il che dimostra una cosa: a volte un controllo misura solo ciò per cui è stato progettato.

Perché il sintomo persisteva, e aveva una particolarità inquietante. Compariva solo negli articoli il cui codice conteneva parentesi graffe, quei segni { e } che si trovano in quasi tutti i file di configurazione. Gli articoli senza graffe si comportavano benissimo.

Esperimenti che non lasciano traccia

Per capire, Claude ha fatto ciò che farebbe un buon investigatore: riprodurre il fenomeno in condizioni controllate. Su un solo articolo ha messo una versione di prova, osservato la pagina pubblica, poi ripristinato la versione originale. Ha ricominciato con delle varianti. Ogni test era reversibile e ogni risultato è stato annotato.

Le conclusioni stanno in tre righe:

  • Quando un articolo contiene una parentesi graffa, un filtro del sito cancella tutto ciò che sta tra una graffa aperta e la sua chiusura: testo, configurazione ed esempi compresi.
  • Negli stessi articoli, questo filtro decodifica una volta le entità, così che <title> diventava un vero tag, invisibile a schermo.
  • Gli articoli senza graffe sfuggivano a tutto questo.

Non sono riuscito a identificare il colpevole. Il mio sito fa girare numerosi plugin e frammenti di codice, e quello che applica questa regola non si è denunciato. Claude ha passato in rassegna ciò che era leggibile, senza modificare nulla, senza trovare una pista chiara. Bisognerà tornarci, e lo annoto tra i miei cantieri.

La soluzione: aggirare invece di combattere

Invece di aspettare di scovare il filtro, Claude ha cercato una scrittura che il filtro non riconoscesse. Ha provato diverse codifiche delle graffe. Alcune fallivano, altre funzionavano ma davano un risultato inutilizzabile. Una sola ha superato tutti i test: un’entità con nome del linguaggio delle pagine web, { per la graffa aperta e } per quella chiusa. Il filtro non le vede come graffe, e il browser le mostra esattamente come tali.

Restava da applicarla. La sesta ondata ha riscritto le settanta pagine interessate, tre traduzioni orfane comprese, con questa convenzione, e ogni blocco di codice è stato confrontato con la sua fonte, segno per segno, sulla pagina pubblica, con marcia indietro automatica alla minima differenza. Risultato: settanta successi su settanta, nessuna marcia indietro.

C’è stato un ultimo dettaglio curioso. Un plugin di link interni inserisce automaticamente collegamenti nei miei articoli, anche, per eccesso di zelo, dentro i blocchi di codice. Per ora è innocuo, ma non è pulito, ed è ormai nella lista di ciò che farò escludere.

Verificare per davvero

Passata l’ultima ondata, la tentazione di proclamare la vittoria era forte. Claude ha fatto l’opposto: ha lanciato un audit finale sulle novantuno pagine, con una logica aggiornata per tenere conto della scoperta sulle graffe. Il programma ha esaminato ogni pagina da tre angolazioni: ciò che il sito ha registrato, ciò che il sito restituisce ai programmi che lo interrogano e ciò che vede realmente un visitatore.

Il verdetto è arrivato: novantuno pagine su novantuno conformi. Ogni pagina risponde, ha un solo titolo principale, mostra il titolo giusto, la descrizione giusta, il pulsante di contatto, nessun codice tecnico visibile per errore, sottotitoli e paragrafi identici alla fonte. Milleduesessantadue blocchi di codice, ripartiti su settantaquattro articoli, escono identici sulle pagine pubbliche. Sono stati testati ottantadue link diversi; uno solo era davvero morto ed è stato sostituito.

Il falso allarme che dice molto

Il primo audit completo si era tuttavia concluso con un apparente fallimento: uno dei controlli segnalava ottantaquattro articoli. Confrontava il contenuto grezzo registrato sul sito con quello che era stato inviato e trovava differenze.

Invece di dichiarare l’allarme senza importanza, Claude ha cercato di capire. La causa era benigna: il sito stesso riscrive gli indirizzi dei link interni in una forma più corta, il che modifica il testo grezzo senza cambiare la pagina. Tenuto conto di questa riscrittura, le novantuno pagine risultavano davvero identiche alla loro fonte.

Ciò che conta non è il risultato finale, ma il metodo: un allarme che non si capisce non si elimina, si spiega. È questo che separa un “finito” verificato da un “finito” dichiarato.

Il cantiere in cifre

Per gli appassionati di numeri, ecco il bilancio di questa riparazione:

  • 91 pagine riparate: 22 argomenti in quattro lingue, più 3 traduzioni orfane.
  • 1062 blocchi di codice verificati uno per uno, ripartiti su 74 articoli.
  • 82 link testati, di cui uno solo era morto.
  • 70 pagine riscritte per aggirare il problema delle graffe, senza una sola marcia indietro.
  • Più di 30 regole di controllo nel nuovo generatore, e 10 test automatici che non toccano il sito.
  • 6 minuti circa per produrre, collegare e verificare quattro bozze durante il test reale.

Ricostruire invece di rattoppare

Un laboratorio a tre postazioni con un robot redattore, un assemblatore e un ispettore
Ricostruire: una postazione per scrivere, una per assemblare, una per controllare.

Riparare novantuno pagine non risolveva nulla se il giorno dopo, alle 10:14, il generatore ne produceva una nuova infornata di difetti. Bisognava trattare la causa. E la causa, lo avevamo visto, non era un bug da correggere ma un modo di progettare: un sistema in cui un modello scrive testo libero, che uno script ripulisce a colpi di espressioni regolari, senza che nessuno guardi il risultato.

Claude ha proposto di non rattoppare lo script, ma di scriverne uno nuovo, costruito su tre principi semplici.

Tre principi

Chiedere una struttura, non un testo già impaginato. Invece di richiedere un articolo in linguaggio di marcatura, che lo script dovrebbe poi ripulire, si chiede alla IA di restituire l’articolo suddiviso in blocchi identificati: un paragrafo, un sottotitolo, un elenco, una tabella, un blocco di codice. Ogni blocco viene verificato uno per uno. Non c’è più nulla da “ripulire”, quindi nulla da cancellare per errore.

Separare la scrittura dall’impaginazione. La IA non scrive mai una riga di pagina web. Un programma classico, che fa sempre la stessa cosa nello stesso modo, trasforma i blocchi in pagine nel formato del mio tema. Per una buona ragione: una macchina che scrive è creativa, quindi variabile. Una macchina che impagina deve essere noiosa, quindi affidabile.

Non pubblicare mai senza controllo. Tra la scrittura e il sito si interpone un’ispezione di qualità indipendente, che può bloccare l’operazione.

Il percorso di un articolo oggi

  1. Scelta dell’argomento. Il programma consulta gli articoli già pubblicati, le bozze e le relative parole chiave, per non farsi mai concorrenza da solo. Per impostazione predefinita sceglie un argomento duraturo piuttosto che di attualità, perché i fatti di attualità sono quelli che una IA inventa più volentieri.
  2. Scrittura in inglese, sotto forma di blocchi, con una parola chiave principale precisa.
  3. Controllo qualità. Una trentina di regole, ciascuna delle quali corrisponde a un difetto realmente incontrato nelle pagine riparate: testo troncato a fine articolo, emoji, residui di formattazione, unità senza maiuscole, “AI” in un testo non inglese, lingua dubbia, parola chiave assente dal primo paragrafo, codice non valido, link a un articolo inesistente. In caso di errore, si chiede una correzione mirata, al massimo due volte.
  4. Adattamento in francese, spagnolo e italiano. Non una traduzione parola per parola: un adattamento, con una guida di stile per lingua, un elenco di nomi di marca che non si traducono e l’obbligo di conservare esattamente la stessa struttura. I blocchi di codice non vengono mai ritradotti: sono semplicemente copiati dall’originale.
  5. Secondo controllo, lingua per lingua, con in più un confronto con la versione inglese.
  6. Impaginazione, fatta dal programma, e realizzazione delle immagini.
  7. Deposito come bozze sul sito, collegamento delle quattro lingue, rilettura di ogni bozza per accertarsi che il sito abbia registrato ciò che doveva.
  8. Rapporto, in un file, con tutto ciò che è successo e ogni avviso.

Se un passaggio si blocca, non viene creato nulla. Meglio nessun articolo che un articolo rovinato.

Quattro lingue, quattro modi di sbagliare

Dire “traduciamo in tre lingue” dà l’impressione di un lavoro meccanico. È falso, ed è una delle ragioni per cui il vecchio script sbagliava in modo così discreto: ogni lingua ha le sue trappole, e si sommano.

In francese l’intelligenza artificiale si scrive “IA” e non “AI”, i due punti, i punti interrogativi e le virgolette francesi si staccano dalla parola con uno spazio, e un titolo ha la maiuscola solo sulla prima parola e sui nomi propri. Anche spagnolo e italiano usano la sigla “IA”. In italiano, “ai” è inoltre una parola di tutti i giorni, una preposizione: è proprio quella che il vecchio script trasformava in “AI”, trentacinque volte. In spagnolo, il pulsante di contatto ha dovuto passare al tu per allinearsi al tono del resto del sito.

Ovunque si applicano altre regole: i nomi di marche e prodotti non si traducono mai, le unità di misura hanno una maiuscola che conta (un kW non è un kw) e la parola chiave principale deve suonare naturale in ogni lingua invece di essere tradotta alla lettera. Nessuna di queste regole esisteva nel vecchio script. Il nuovo dà a ogni lingua la sua guida di stile, il suo glossario di marche e i suoi controlli. Questo lavoro è invisibile quando riesce, ed è proprio questo lo scopo.

Le salvaguardie

Il nuovo programma si ferma da solo dopo novanta minuti. Si rifiuta di partire due volte nello stesso momento. Crea un solo articolo al giorno. Tiene un registro. Si appoggia a dieci test automatici che verificano il suo comportamento senza toccare il sito, compreso un sito finto che simula i guasti. Infine, le password non sono più scritte nel codice ma conservate in un file a parte.

La trappola nascosta delle 10:14

Un orologio da parete senza numeri accanto a un enorme pulsante di pausa
La pausa che non finiva mai: nessuno per premere un tasto.

Il nuovo generatore esisteva, superava i suoi test, aveva persino riuscito una prova a secco con il vero Gemini. Restava da collegarlo alla mia attività pianificata, ed è lì che ho chiesto a Claude di assicurarsi che il file principale del mio script, quello che Windows avvia ogni giorno, fosse perfetto per generare i prossimi articoli. Il lavoro meritava più di un semplice copia e incolla, e Claude ha scoperto due cose.

Una pausa che non finiva mai

La prima: la mia attività, chiamata “Rédaction post lcwa”, avviava un piccolo file di partenza la cui ultima riga conteneva un comando “pause”. Aspetta che si prema un tasto, cosa comoda quando si avvia lo script a mano e si vuole leggere il risultato. Ma in un’attività automatica non c’è più nessuno che prema qualcosa.

Risultato: lo script aveva finito il suo lavoro in pochi minuti, ma l’attività restava indicata come “in esecuzione”. E Windows, per impostazione predefinita, rifiuta di avviare una nuova esecuzione finché la precedente non è terminata. L’avvio del giorno dopo sarebbe quindi stato ignorato senza rumore. Nessun errore, nessun avviso, semplicemente un articolo che non sarebbe mai arrivato.

Claude ha eliminato il comando, aggiunto un file di partenza separato per le mie prove manuali e terminato l’esecuzione rimasta bloccata dalla mattina. L’attività è tornata allo stato “pronta”, con la prossima esecuzione prevista il giorno dopo alle 10:14.

Una bozza ancora all’antica

La seconda scoperta mi ha fatto sorridere amaramente. L’esecuzione della mattina era avvenuta con il vecchio script, e aveva quindi creato quattro bozze nelle quattro lingue, con tutti i vecchi difetti. Non erano pubblicate, il che le rendeva innocue, ma mi hanno ricordato che il calendario di un processo automatico non si ferma solo perché stai riparando qualcosa.

Il test reale

Per verificare, non c’è sostituto di una prova vera. Prima di arrivarci, un primo controllo di connessione era fallito, per giunta in modo istruttivo: Claude aveva chiesto a Gemini una risposta minuscola per testare il collegamento, e il modello aveva esaurito il suo budget di risposta pensando senza scrivere nulla. Il nuovo programma ha rilevato quell’uscita interrotta invece di lasciarla passare. È esattamente ciò che il vecchio script non avrebbe mai fatto.

Il test reale si è poi svolto sul sito, come bozza. Il programma ha scelto un argomento, “The Essential Website Maintenance Checklist for Small Businesses”, ha scritto l’articolo, l’ha adattato nelle altre tre lingue senza errori bloccanti, ha realizzato le immagini e ha depositato le quattro bozze, collegate tra loro. L’insieme è durato circa sei minuti.

Poi un audit indipendente ha riletto le quattro bozze sul sito: titoli, descrizioni, immagine in evidenza, due immagini nel testo con i relativi testi alternativi, quattro link interni verso articoli pubblicati nella lingua giusta, pulsante di contatto, struttura identica a quanto inviato. Nessun problema. Un nuovo avvio immediato del programma è stato invece rifiutato subito: un articolo era già stato creato quel giorno, e la protezione anti-doppioni ha fatto il suo lavoro.

Che cosa l’IA non fa al posto mio

Una persona e un robot che si stringono la mano accanto a una bilancia e a un cartello indicatore
Alcune decisioni restano umane: la macchina propone, io decido.

Il rapporto che Claude mi ha consegnato alla fine della riparazione contiene una sezione intera intitolata “Decisioni che spettano a te”. Dice molto sulla ripartizione dei ruoli. Una macchina può verificare che un link funzioni, che un pezzo di codice sia intatto, che un titolo sia identico alla sua fonte. Non può decidere che cosa la mia agenzia vuole raccontare, né quali rischi accetta di correre. Ecco che cosa è rimasto sul mio tavolo.

Le decisioni editoriali

I doppioni. Tre traduzioni “orfane” (in francese, spagnolo e italiano) sono doppioni di scarsa qualità di un articolo sulle meta description già presente sul sito. Claude le ha ripulite e ripubblicate, ma mi ha avvertito che la cosa più pulita sarebbe reindirizzarle all’articolo principale o toglierle. Tenere, reindirizzare o ritirare: è una decisione SEO, quindi una decisione da capo.

L’attualità. Tra gli articoli di Gemini, alcuni commentavano l’attualità di grandi marchi: un costruttore di auto, piattaforme di streaming, giganti del digitale. Contengono cifre e affermazioni che nessuno ha verificato alla fonte, e Claude mi ha raccomandato una rilettura umana dei fatti. Questi argomenti sono inoltre molto lontani dal mio mestiere, il che riporta a una domanda più semplice: ho davvero bisogno di parlarne?

La concorrenza tra i miei stessi articoli. Diversi articoli puntano a parole chiave molto vicine (le meta description, i titoli generati dalla IA, i contenuti scritti dalla IA). Quando due pagine dello stesso sito rispondono alla stessa ricerca, Google deve scegliere, e non sempre sceglie quella che avresti preferito. Fondere, differenziare o spingere uno dei due: tocca a me arbitrare.

I titoli e le immagini. Aggiunto il nome dell’agenzia, 90 titoli su 91 superano i sessanta caratteri, e Google rischia di tagliarli nei risultati. In un’immagine fabbricata dalla IA una parola è scritta male; in un altro articolo manca un’immagine. Sono difetti minori, ma toccano l’immagine dell’agenzia: sono io a scegliere come trattarli.

Pubblicare o non pubblicare

Il nuovo generatore deposita i suoi articoli come bozze, come il vecchio. Un’opzione permetterebbe di pubblicarli da solo quando tutti i controlli sono verdi; non l’ho attivata, e gli argomenti di attualità resterebbero comunque in bozza. Una sola prova completa con articoli veri non basta per affidare la vetrina dell’agenzia a un automatismo. Deciderò dopo aver osservato diversi giorni di produzione.

Ciò che resta imperfetto

Preferisco essere onesto su ciò che non è risolto. Il filtro del sito che cancellava tutto ciò che stava tra parentesi graffe è aggirato, ma non spiegato: sappiamo com’è fatto e come evitarlo, non quale elemento del sito lo applichi. È come asciugare una perdita senza aver trovato il tubo. Un modulo di link interni inserisce inoltre collegamenti nei blocchi di codice, dove non c’entrano nulla; è innocuo, ma resta da sistemare. Infine, per igiene, alcuni accessi al sito vanno rinnovati. È un lavoro di sicurezza, spetta a me, e Claude in effetti si è astenuto dal toccarlo: qui non dirò di più.

Niente di tutto questo è un fallimento della IA. Il giorno in cui un assistente ti annuncia che tutto è perfetto, è il momento di diffidare. Questo mi ha consegnato l’elenco di ciò che non lo è.

Manuale d’uso: dieci regole per automatizzare un blog con IA senza cadere in trappole

Se hai un blog, anche piccolo, e pensi di affidare una parte del lavoro a una IA, ecco che cosa mi ha insegnato questa avventura. Non sono principi teorici: ognuna di queste regole corrisponde a un incidente reale di questo racconto.

  1. Non pubblicare mai senza che qualcuno abbia guardato. Il mio generatore pubblicava ogni mattina senza alcun controllo umano. C’è voluto un audit completo per misurare l’entità dei danni. Una bozza costa un minuto di rilettura; un articolo rotto online costa la fiducia dei lettori.
  2. Separa la scrittura, l’impaginazione e il controllo. La IA scrive, un programma prevedibile costruisce la pagina, un terzo livello verifica. Quando un solo strumento fa tutto, controlla sé stesso, e questo non è un controllo.
  3. Chiedi una struttura, non un testo già formattato. Invece di richiedere un articolo da convertire dopo, si chiedono blocchi identificati (titoli, paragrafi, elenchi, tabelle, codice) che il programma assembla da solo.
  4. Trasforma ogni difetto in una regola. La piccola parola italiana “ai” diventata la sigla “AI” in trentacinque punti non è stata solo corretta: ha generato un controllo automatico. Il generatore ne applica oggi più di trenta.
  5. Prova per davvero, ma in modo reversibile. Prima di ogni modifica al sito online, un backup; dopo, una rilettura e un ripristino automatico se qualcosa non va.
  6. Verifica come un visitatore, non come uno sviluppatore. Guardare che cosa contiene il database non basta: bisogna aprire la pagina pubblica. È confrontando ciò che il sito mostrava davvero con ciò che gli avevamo inviato che è emerso il mistero delle graffe.
  7. Parti dalle bozze. Ti lasciano il diritto di sbagliare e l’ultimo minuto per rimediare a un errore.
  8. Sorveglia i testi troncati. Una IA può fermarsi a metà frase senza avvisare. Il generatore verifica ora che ogni risposta sia terminata normalmente, e rifiuta un articolo che non finisce come si deve.
  9. Preferisci gli argomenti duraturi e verifica i fatti. Una guida pratica invecchia bene. Un articolo di attualità richiede cifre esatte, che una IA a volte inventa con una sicurezza perfetta.
  10. Tieni le password fuori dal codice e pretendi tracce di ciò che fanno le tue attività automatiche. Gli accessi sono ora in un file a parte. E ogni esecuzione lascia un registro e un codice di uscita leggibili, perché è stata una semplice pausa dimenticata in fondo a un file di avvio a bloccare l’attività della mattina.

Nessuna di queste regole è riservata agli sviluppatori. Tutte si riducono alla stessa idea: fare in modo che l’errore sia visibile prima che raggiunga il lettore.

Una memoria per ciò che viene

Ultima richiesta di questa serie, e non la minore: ho chiesto a Claude di conservare una memoria di tutto ciò che abbiamo fatto, per attingervi ogni volta che creeremo nuovi articoli. Un articolo in più non riparte quindi da zero: eredita ciò che i precedenti hanno insegnato a questo sito.

In concreto, questa memoria trattiene cinque cose:

  • le regole editoriali imparate a caro prezzo (le maiuscole italiane, il tu spagnolo, le marche che non si traducono);
  • l’organizzazione del generatore e dei suoi file;
  • il funzionamento dell’attività delle 10:14 e le sue trappole;
  • la storia degli incidenti, con la loro causa;
  • l’elenco di ciò che resta da decidere.

Non contiene invece né password né chiavi: quei segreti non c’entrano nulla con una memoria. L’abitudine vale per qualsiasi progetto. Dopo un cantiere, chiedi al tuo assistente di annotare ciò che vale la pena ricordare: quindici giorni di tentativi diventano così un saper fare, invece di restare un semplice aneddoto.

Che cosa è cambiato dal 1° ottobre

Una scrivania al mattino con un portatile, un caffè, una pila di bozze e un piccolo robot che saluta
Domani alle 10:14: una nuova bozza mi aspetterà.

Il 1° ottobre avevo un blog che pubblicava ogni giorno grazie a uno script che credevo sotto controllo. Il 15 ho novantuno pagine verificate e riparate una a una, controllate sul sito online come farebbe un visitatore; un generatore interamente ricostruito; un’attività pianificata che non resta più bloccata; e una prima prova reale che ha prodotto quattro bozze collegate in quattro lingue, controllate prima ancora che le aprissi.

Il punto da ricordare: Gemini scrive ancora gli articoli della mattina. Ciò che è cambiato non è il nome del modello: è tutto ciò che c’è intorno. Una struttura imposta, un assemblaggio prevedibile, controlli che bloccano, bozze, un registro, backup. Non ho imparato che una IA è meglio di un’altra. Ho imparato che una IA si guida come qualsiasi collaboratore: gli spieghi che cosa ti aspetti, verifichi ciò che ti restituisce e metti in piedi il sistema che permette di rimediare all’errore.

Ho imparato anche a chiedere. Ciò che mi è servito davvero è stato esigere un’analisi dettagliata prima di agire, una verifica reale dopo e un rapporto che dica che cosa resta da fare. Il risultato è migliore, ma soprattutto ora so perché lo è.

È il genere di rigore che cerco di portare nei progetti dei miei clienti: siti web, automazioni, contenuti. Se hai un blog che pubblica da solo e che nessuno ha mai riletto per intero, o se vuoi automatizzare senza perdere il controllo, parliamone. Guarderemo insieme che cosa è solido, che cosa lo è meno e che cosa conviene fare per primo.

Domani alle 10:14 verrà generato un nuovo articolo. Mi aspetterà come bozza, e per me va benissimo così.

Appendice: piccolo glossario per non perdersi

Alcune parole ritornano di continuo in questo racconto. Eccole, senza gergo.

  • Script: un piccolo programma, scritto qui in Python, che esegue una serie di istruzioni senza intervento umano.
  • Attività pianificata: una sveglia per computer. Windows avvia il programma all’ora stabilita, che qualcuno sia davanti allo schermo o no.
  • Gemini, Claude: due assistenti di intelligenza artificiale, il primo creato da Google, il secondo da Anthropic.
  • Token: l’unità di misura del testo per una IA, più o meno un pezzo di parola. La lunghezza di una risposta è limitata in token.
  • WordPress, Avada, WPML: WordPress è il software che fa funzionare il mio sito; Avada è il suo tema, cioè il suo aspetto; WPML è il modulo che gestisce le versioni in più lingue e collega ogni pagina alle sue traduzioni.
  • Plugin: un modulo che si aggiunge a WordPress per dargli una funzione in più (SEO, traduzione, link interni…).
  • Bozza: un articolo salvato sul sito ma invisibile al pubblico, in attesa di rilettura.
  • Linguaggio di marcatura (HTML, Markdown): l’HTML è il linguaggio delle pagine web. Il Markdown è una scrittura semplificata, con asterischi e cancelletti, che poi si converte in HTML; quando la conversione fallisce, questi segni restano visibili nel testo.
  • Entità: un modo di scrivere un carattere riservato in una pagina web. Il segno “minore di” si scrive <.
  • Espressione regolare: una formula di ricerca e sostituzione, molto potente e molto fragile, che il vecchio script usava per “ripulire” il testo.
  • SEO: l’insieme delle pratiche che aiutano una pagina a comparire nei risultati di Google.
  • Parola chiave principale: l’espressione con cui una pagina cerca di posizionarsi nei risultati. Quando due pagine puntano alla stessa, si fanno concorrenza: è la cannibalizzazione.
  • Audit: una rilettura metodica e quantificata, qui condotta da un programma.
  • Codice di uscita: il piccolo numero che un programma restituisce quando termina, zero se tutto è andato bene, altro in caso contrario. È ciò che permette a un’attività automatica di segnalare un guasto.
  • Ripristino: il ritorno automatico alla versione precedente di una pagina quando una verifica fallisce.

Ti manca qualche parola? Dimmelo e la aggiungerò a questo glossario.

Pronto a scalare la tua infrastruttura digitale?

Non lasciare che i colli di bottiglia tecnici rallentino la tua crescita. Discuti del tuo progetto su Quando il mio generatore ha rotto 91 pagine: la storia di una riparazione direttamente con i nostri esperti senior di Low Cost Web Agency.

💬 Contattaci su WhatsApp (+919786495150)