Ho chiesto a cinque AI le stesse notizie ogni giorno. Poi ho smesso.

Il problema

Ogni giorno chiedo a cinque AI (Claude, ChatGPT, Gemini, Perplexity, Mistral) un report sull’intelligenza artificiale con lo stesso prompt. Ognuna risponde con qualcosa di leggermente diverso: stile diverso, enfasi diversa, profondità diversa. La notizia che tutte e cinque menzionano è un segnale forte. Quella che compare solo in una vale meno attenzione. Tenere traccia di tutto questo a mente, giorno dopo giorno, non scala.

Il problema reale non è il volume di informazioni, ma la frammentazione. Avevo report sparsi tra conversazioni diverse, nessun modo di vedere cosa si ripeteva tra le fonti, nessun archivio strutturato, nessun filtro per topic o rilevanza nel tempo. Una notizia veniva letta una volta e dimenticata.

Produco anche contenuti LinkedIn su temi AI. Il collo di bottiglia non era scrivere i post, ma scegliere su cosa scrivere. Passare manualmente in rassegna tre report per trovare cosa meritava attenzione era un costo fisso e ricorrente che non si eliminava con la buona volontà.

L’approccio: le scelte che contano

Le scelte non ovvie:

Clustering greedy con soglia coseno fissa (0.85). Avrei potuto usare algoritmi più sofisticati come HDBSCAN. Non l’ho fatto. A volumi di poche decine di item al giorno, un passaggio greedy con soglia di distanza coseno configurabile è debuggabile, sufficiente, e non introduce complessità che richiede tuning continuo. Se un item è semanticamente abbastanza vicino a un cluster esistente, vi entra; altrimenti ne crea uno nuovo. La soglia è un parametro di configurazione. In mesi di uso, non ho mai sentito il bisogno di qualcosa di più elaborato.

Retry asimmetrico sugli errori API. Quando Anthropic restituisce un 429 o un 529, significa che il servizio è sotto pressione. Ritentare subito peggiora la situazione. I job di synthesis usano un backoff progressivo con finestre di 1 minuto, 5 minuti, 15, 30, 1 ora, 2 ore, 4 ore, per una finestra totale di circa 8 ore. Il service layer non riprova mai sugli errori di capacità: il retry appartiene al queue worker, con attese abbastanza lunghe da permettere al servizio di recuperare.

Tassonomia controllata con proposte separate. Ho seeded il sistema con 22 tag specifici. Claude può suggerire nuovi tag durante la synthesis, ma questi atterrano in una tabella separata di proposte, non nella tassonomia principale. Questo previene la deriva semantica che si ottiene quando i sistemi AI possono creare etichette liberamente: nel giro di settimane si finisce con quasi-duplicati e copertura incoerente.

Hash canonico per la deduplicazione. Se ingerisco lo stesso report due volte (errore manuale o re-import accidentale), non succede nulla. L’hash è calcolato sul payload canonicalizzato: chiavi ordinate ricorsivamente, encoding consistente.

Build a fasi con criterio di completamento esplicito. Foundation → Embedding → Synthesis → Generator → Review UI → Report Management. Ogni fase ha un “done when” concreto scritto nella spec. Questo conta nel development spec-driven: obbliga a decidere lo scope prima di scrivere codice, non dopo.

Il meta-progetto: costruire con Claude Code

Questo progetto ha una seconda storia, che è forse quella più interessante.

Ho scritto pochissimo di questo codice direttamente. La maggior parte è stata scritta da Claude Code, lavorando da un file SPEC.md che definisce architettura, modello dati, regole di business e decisioni tecniche in forma strutturata. Un file CLAUDE.md separato funziona da contratto operativo con l’agente: convenzioni, naming, cosa evitare, come lavorare.

Il mio ruolo era quello di architetto e reviewer. Ho progettato il modello dati, preso le decisioni tecniche non ovvie, scritto la spec, e revisionato ogni pull request generata dall’agente. Quando la spec era ambigua, l’ho aggiornata prima del codice. Quando Claude proponeva un approccio che non condividevo, lo rifiutavo con motivazione, e riprovava.

Cosa ha funzionato. L’approccio spec-driven mantiene il contesto coerente tra sessioni multiple. Claude Code non perde mai il “perché” di una decisione perché è scritto. Posso aprire una nuova sessione a settimane di distanza e l’agente capisce i vincoli senza che io debba rispiegarli. La struttura a fasi ha funzionato bene: avere un criterio di accettazione concreto per ogni fase mi ha permesso di verificare il completamento prima di procedere.

Cosa non ha funzionato. All’inizio ero troppo vago nella spec: descrivevo cosa volevo senza essere sufficientemente preciso sui casi limite. L’agente ha riempito i gap con scelte ragionevoli che non erano sempre quelle che avrei fatto io. Ho speso più tempo a correggere di quanto avrei fatto se fossi stato più preciso dall’inizio. La lezione è diretta: il costo di una spec imprecisa si paga in tempo di review.

Claude Code tende anche a introdurre astrazioni non necessarie: un’interfaccia dove esiste una sola implementazione, un metodo helper per due righe che girano una volta sola. Ho bloccato la maggior parte in review. Qualcuna è passata.

Stato e cosa viene dopo

Il workflow quotidiano funziona end-to-end: eseguire i prompt sulle AI, depositare i JSON nell’inbox, lanciare l’ingest, processare la coda, aprire l’UI per revisionare i cluster e approvare le bozze.

Un componente opzionale non è stato costruito: un MCP server per interrogare la pipeline direttamente da Claude Code. Ho valutato che non fosse necessario per il valore attuale: l’interfaccia a riga di comando e la review UI coprono tutto quello che serve.

Non c’è ingestion automatica. Eseguo la pipeline manualmente, di solito la mattina. È una scelta deliberata: non voglio un sistema che accumula dati non letti in background.

Perché conta

Il collo di bottiglia nello sviluppo assistito da AI non è la capacità del modello di scrivere codice, ma la capacità dell’umano di mantenere la coerenza architetturale attraverso sessioni multiple. Una spec che l’agente deve rispettare, un gate di review prima che il codice entri, una struttura a fasi che previene la complessità prematura: questi sono strumenti di project management applicati alla collaborazione con l’AI.

Il risultato è che una persona, lavorando part-time, ha costruito una pipeline funzionalmente completa in poche settimane. Non perché l’AI sia magica, ma perché i vincoli erano ben definiti. L’agente è rapido e consistente su task ben specificati; deriva su quelli vaghi. Gestire questo tradeoff è una competenza di ingegneria, non un trucco di prompt engineering.