Un agente AI come editor dei miei articoli Dev.to

Tengo tutti i miei articoli Dev.to (pubblicati e bozze) sotto controllo di versione in un repository Git privato, devto-articles, e li scrivo e pubblico con l'aiuto di Claude Code, collegato a Dev.to tramite un server MCP, devto-mcp (un mio fork di Arindam200/devto-mcp). Lo racconto perché l'agente lavora anche da editor, prima ancora che da postino verso Dev.to, e quello alza la qualità del testo finale più di quanto farebbe da solo un buon editor di testo. L'agente come editor Concretamente, cosa fa in più rispetto a «scrivi il markdown e mandalo»: prima di tutto legge un paio di articoli già presenti nel repo per intonarsi a tono e struttura, invece di scrivere con la voce media di un modello linguistico. Poi applica una checklist esplicita contro i pattern tipici della prosa generata: via l'em-dash usato come connettore universale, via il contrasto fittizio «non è X, è Y» usato come effetto retorico invece che per correggere un vero equivoco del lettore, via le aperture e chiusure da manuale (tipo «Nel mondo di oggi...» o «In conclusione...»), via il lessico da traduzione automatica. Questo stesso articolo ne è un esempio concreto. La prima stesura conteneva oltre dieci em-dash e un paragrafo di chiusura costruito proprio sul contrasto fittizio segnalato sopra. Li ho fatti notare, l'agente ha riletto il testo e li ha corretti uno per uno, mostrandomi il diff prima di rimandarlo a Dev.to. Ecco una correzione, da una versione intermedia di questo articolo: Prima: «Non è mai autopilota, e la differenza non è cosmetica: cambia chi decide cosa finisce pubblicato, anche quando non sono io a battere per primo le parole sulla tastiera.» Dopo: «In pratica chi decide cosa viene pubblicato sono io, anche quando le prime parole le scrive l'agente.» La checklist che ha usato per farlo (sette divieti fissi e due cose da evitare, con le fonti da cui vengono) è ora parte permanente della skill che uso per scrivere, e si ripete a ogni articolo nuovo o rivisto, non solo su questo. Un altro aspetto: di solito l'articolo nuovo non parte da me che scrivo prosa da zero, ma da una sessione di lavoro già conclusa nella stessa conversazione, di cui l'agente ha già tutto il contesto (un bug risolto, una PR aperta). Le informazioni non le avevo mai messe per iscritto in forma di articolo: gli chiedo di scriverlo dopo, a lavoro finito, e il testo lo stende l'agente a partire da quello che abbiamo fatto insieme, non da una narrazione inventata. C'è poi una parte meno visibile ma altrettanto concreta: prima di sovrascrivere un file già sincronizzato con Dev.to, l'agente confronta lo stato locale con quello remoto e si ferma a chiedere se trova un disallineamento, invece di procedere alla cieca. Su un archivio che continuo a modificare anche a mano dal portale, questo controllo fa la differenza tra un assistente che aiuta a scrivere e uno che, ogni tanto, cancella silenziosamente qualcosa che avevi scritto altrove. Conviene essere precisi su cosa intendo con «editor». Dev.to distingue tre livelli di dichiarazione dell'uso dell'AI: scritto a mano, «AI-assisted» e «Fully Autonomous», quest'ultimo per i contenuti generati soprattutto da agenti o LLM. Questo articolo è dichiarato «AI-assisted». Anche quando lo stende materialmente l'agente a partire da una sessione di lavoro, il testo racconta cose che ho fatto davvero (bug risolti, decisioni prese insieme, comandi eseguiti) e non materiale inventato per l'occasione. Nessuna riga esce senza che io l'abbia riletta e senza una mia conferma esplicita prima della pubblicazione. In pratica chi decide cosa viene pubblicato sono io, anche quando le prime parole le scrive l'agente. Perché tenere gli articoli in un repository Le motivazioni sono più d'una, e questa (avere un editor che lavora sugli stessi file con git, cronologia e diff) è la principale. Le altre: Backup versionato indipendente da Dev.to: se il portale perde dati, cancella per errore una bozza o cambia formato, ho comunque una copia con tutta la storia delle modifiche, non legata alla disponibilità o alle scelte di un servizio terzo. Portabilità verso altre piattaforme: avere il testo grezzo in Markdown in un repository mio, senza dipendenze dal formato interno di Dev.to, rende più semplice riusare gli stessi articoli come base per pubblicarli altrove, in futuro, senza doverli prima esportare o estrarre dal portale. Il meccanismo di sincronizzazione, in breve Questa parte è tecnica, ma serve a capire perché posso lasciare scrivere l'agente sui miei file senza temere di perdere lavoro: ogni file tiene traccia, nel front-matter, dell'hash SHA-256 del corpo dell'articolo così com'era su Dev.to all'ultimo sync riuscito (devto_synced_hash). Prima di scrivere in un senso o nell'altro, l'agente ricalcola l'hash remoto attuale e lo confronta con quello salvato. Se combaciano, l'operazione è sicura. Se no, è un conflitto, e qui non c'è un git merge che decide da solo: le due versioni mi vengono mostrate entrambe e la scelta su quale prevale resta mia. La riscrittura vera e propria, quando serve unire i due testi in un discorso coerente, la fa l'agente, ma solo dopo che gliel'ho chiesto e prima di rimandarla a Dev.to. Per un push, i passaggi in sequenza sono questi: sequenceDiagram actor Io participant Agente participant Repo as File nel repo participant Devto as Dev.to Io->>Agente: correggi questo paragrafo Agente->>Repo: modifica il file Agente->>Repo: legge devto_synced_hash Agente->>Devto: legge il body remoto Devto-->>Agente: body_markdown attuale Agente->>Agente: calcola lo sha256 del body remoto alt gli hash coincidono Agente->>Devto: update_article Agente->>Repo: aggiorna devto_synced_hash e committa else gli hash sono diversi Agente->>Io: mostra le due versioni Io->>Agente: sceglie quale prevale end Un progetto per pubblicare su Dev.to da un repository Git, dev-to-git, descrive solo la direzione dal repo verso il portale, e le proprietà dell'articolo si controllano da lì. Io modifico gli articoli anche a mano dal portale, quindi mi serve un controllo nelle due direzioni, non solo da qui verso Dev.to. In pratica, per un articolo nuovo l'agente non scrive prima un file provvisorio in articles/. Scrive il body altrove e chiama create_article per farlo esistere su Dev.to come bozza. Solo con la risposta in mano (id, url, hash del body riletto da remoto) scrive una volta sola il file definitivo in articles/-.md e lo committa nel mio repository. La pubblicazione su Dev.to e il commit nel repo sono due passaggi distinti, entrambi necessari. Un'alternativa altrettanto legittima è partire dal portale: creo io la bozza a mano nell'editor di Dev.to, e l'agente la importa nel repo con la stessa operazione di pull che usa per rilevare modifiche fatte da lì. Ogni modifica successiva ripete il controllo dell'hash prima di ripushare con update_article. La pubblicazione (published: true) è uno dei passaggi che l'agente conferma sempre esplicitamente prima di eseguire, perché è visibile pubblicamente e non banale da annullare in modo pulito. Cosa cambia davvero Scrivere in Markdown invece che nella textarea del portale è comodo, ma da solo si otterrebbe anche incollando poi il testo a mano. Il vantaggio vero è avere un editor che conosce la mia voce da un corpus reale di articoli precedenti, applica una checklist esplicita contro i tic della prosa generata prima di consegnare, e si ferma a chiedere invece di sovrascrivere alla cieca quando qualcosa non torna. La parte tecnica del sync rende tutto questo possibile senza rischiare di perdere lavoro. È infrastruttura di supporto, e il lavoro che conta è quello di scrittura descritto sopra.