Claude Code Routines: Caso Studio Architettura Ibrida 2026

Sei giorni con le Routines in produzione: cosa ho capito davvero

Anthropic ha lanciato le Claude Code Routines il 14 aprile 2026. Automazioni cloud-native che girano sull'infrastruttura Anthropic, 15 esecuzioni giornaliere incluse nel piano Max, trigger via cron o webhook GitHub o API. Fine del vincolo "il mio Mac deve essere acceso".

Il giorno dopo il lancio ho migrato 5 task. Una settimana dopo, posso dire quello che è difficile trovare nei post di lancio: le Routines non sostituiscono un sistema di automazione locale. Lo completano. E se non risolvi un problema specifico prima di migrare, il bus di comunicazione fra cloud e locale, rompi metà della tua infrastruttura.

Questo è un caso studio reale. Ecco cosa ho migrato, cosa ho lasciato su Cowork, e perché la scelta più importante non è stata nessuna delle due.

Cosa sono davvero le Claude Code Routines

Una Routine è un prompt più un contesto più un trigger. Gira sull'infrastruttura Anthropic. Non dipende dal tuo laptop, dal Wi-Fi di casa, dal fatto che il Mac abbia dormito o no. La crei da claude.ai/code/routines oppure con /schedule dentro Claude Code CLI. Puoi collegarla a un repo GitHub, la Routine legge i file del repo come contesto e può committare modifiche direttamente. Puoi collegare Connectors MCP (Slack, Gmail, Sanity, Notion) che girano cloud-side senza bisogno di un client locale.

Tre tipi di trigger:

1. Cron schedulato, classico, gira all'ora X di Y
2. API, partenza su chiamata HTTP
3. GitHub webhook, partenza su push, PR, issue, release

Il piano Max include 15 esecuzioni al giorno. Le esecuzioni contano per Routine, non per trigger: se una Routine parte alle 06:00 e 18:00 ogni giorno, sono due esecuzioni su 15. Haiku, Sonnet e Opus sono tutti disponibili, il modello lo scegli tu, e la scelta pesa sul costo interno all'ecosistema (pagherai il tempo che occupa, non la Routine in sé).

Se vuoi il dettaglio operativo su come Claude Code funziona da terminale e come si costruisce un sistema agentico sopra, ho scritto la guida completa a Claude Code che copre installazione, Skills, MCP e workflow. Le Routines sono il livello sopra: stessa mentalità, infrastruttura diversa.

Il discorso è un altro: non tutto si migra

Il punto che quasi nessuno sta raccontando è questo: le Routines sono perfette per alcuni task, inutili (o peggio, dannose) per altri. La regola che ho estratto dopo sei giorni di test:

Le Routines sono cloud-native. Se il tuo task deve toccare qualcosa di locale, file sul Mac, il browser Chrome, la sessione LinkedIn autenticata nel tuo profilo, la UI di un'app desktop, la Routine non può farlo.

Facciamo un esempio concreto. Ho 38 task schedulati su Cowork. Alcuni pubblicano post su LinkedIn via Chrome MCP, con sessione autenticata nel mio profilo personale. Se provo a migrarli su una Routine cloud, perdo la sessione. La Routine gira da un'infrastruttura Anthropic, non vede il mio browser, non ha accesso al cookie che tiene attiva la mia sessione LinkedIn. Quei task restano obbligatoriamente su Cowork, dove il Chrome dell'utente è raggiungibile.

Stesso discorso per task che scrivono file locali sul Mac, leggono una directory di lavoro specifica, si appoggiano a script Python installati localmente con dipendenze native. Cloud-native significa che il contesto di esecuzione è effimero: ogni run parte con un ambiente pulito, senza file system persistente, senza processi in background.

Quindi la domanda prima di migrare un task è semplice: "Questo task ha bisogno di qualcosa che esiste solo sul mio Mac?". Se sì, resta Cowork. Se no, è candidato per Routine.

I 5 task che ho migrato e perché

Ho selezionato 5 task che rispondevano "no" alla domanda di sopra. Erano tutti task che usavano solo connettori cloud (Gmail, Sanity, Slack, web search) o leggevano repo GitHub. Zero dipendenze locali.

1. news-intelligence

Scan giornaliero delle news su AI, Claude, automazione. Prima girava alle 06:00 su Cowork, quando il Mac era sveglio. Nella metà dei casi partiva tardi perché il Mac dormiva, a volte saltava. Sonnet come modello, perché fa scan più classificazione più ranking, non ragionamento complesso. Su Routine cloud gira alle 06:00 puntuali, ogni giorno, indipendentemente dal mio laptop. Output: aggiorna una sezione ## news-intelligence dentro un file system-signals.md che vive nel repo GitHub giovanniliguori-ops.

2. blog-post-auditor

Audit automatizzato di ogni post pubblicato su Sanity nelle ultime 48 ore. Checklist di 8 punti: word count, seo.title/description, FAQ, link interni come markDefs, link esterni, mainImage, anonimizzazione. Sonnet perché serve valutazione su soglie fisse senza creatività. Questo task è stato critico da migrare: doveva girare PRIMA del blog-writer, perché se il blog-writer partiva con un audit del giorno prima, pubblicava articoli che l'audit avrebbe bloccato. Su Routine cloud alle 06:00, blog-writer su Cowork alle 06:30, e fra i due c'è un sync che porta il risultato dell'audit al blog-writer locale prima che parta.

3. system-health-check

Ping giornaliero alle 22:00 che verifica stato deploy Vercel, conteggio post Sanity, task schedulati aggiornati. Haiku perché è puro pattern matching su timestamp. Zero ragionamento. Quando un task critico non è stato aggiornato nelle ultime 48 ore, manda un alert su Slack. Prima girava su Cowork con il rischio di non girare mai proprio quando c'era un problema (Mac spento uguale non vedo il problema uguale non ricevo alert).

4. outreach-feedback-loop

Monitora Gmail per risposte alle email di outreach (guest post, collaborazioni, backlink). Classifica ogni risposta (positiva, neutra, negativa, bounce), genera draft di follow-up per quelle positive. Sonnet perché la generazione dei draft deve seguire uno stile preciso (colloquiale-autorevole, mai supplicante). Prima girava su Cowork con Gmail MCP; migrato su Routine, il Gmail Connector cloud funziona identico. Un episodio concreto che ha motivato la migrazione: una risposta persa per sette giorni a metà aprile, perché il Mac era stato spento per un viaggio. Mai più.

5. repo-sync-metrics

Sync di metriche (engagement rate, detection incidents, giorni attivi) da un repo privato verso un repo pubblico, triggered da push su main. Questo è il caso d'uso più elegante: trigger event-driven invece di cron settimanale. Haiku perché è sync meccanico di campi, zero generazione creativa. Appena arriva un push sul repo sorgente, la Routine parte, legge i nuovi numeri, apre una PR sul repo target. Non serve un cron che chiede "ci sono novità?" ogni ora, la Routine si sveglia solo quando c'è davvero qualcosa da fare.

Il vero problema: system-signals split

Qui arriva la parte che non ho trovato in nessun tutorial di migrazione. I miei task Cowork comunicano fra loro attraverso un file system-signals.md che vive nel workspace locale. Il pianificatore settimanale scrive direttive in una sezione, il blog-writer le legge, scrive risultati in un'altra sezione, il compliance checker li controlla. È un bus di comunicazione asincrono, leggibile a occhio nudo, versionabile con git.

Quando migri un task su Routine cloud, quel task non vede più il file locale. Il cloud può scrivere su un file dentro un repo GitHub, ma il repo non è automaticamente sincronizzato con il workspace locale. Risultato: bus spezzato.

Dopo la migrazione dei 5 task, ecco le dipendenze rotte:

• news-intelligence (cloud), sezione ## news-intelligence, consumato da weekly-blog-writer e linkedin-weekly-planner: rotto, blog-writer non vede le news.
• blog-post-auditor (cloud), sezione ## blog-audit, consumato da system-compliance-checker: rotto, compliance non vede l'audit.
• outreach-feedback-loop (cloud), sezione ## outreach-tracking, consumato da seo-outreach-resend: rotto, outreach non vede le risposte.
• system-health-check (cloud), sezione ## system-health, consumato da compliance-checker e orchestratore: rotto, health invisibile al resto.

Il compliance-checker girava la sera, non vedeva il blog-audit del mattino, passava come "tutto ok" mentre in realtà c'erano post pubblicati senza i requisiti minimi. Non è un problema teorico: l'ho visto succedere la prima notte dopo la migrazione.

Non è il codice. È l'assunzione che ci avevo messo dentro, "migro un task e basta". Falsa.

La soluzione: signals-sync bidirezionale

La soluzione è un task Cowork locale che si chiama signals-sync. Gira tre volte al giorno (05:45, 08:30, 21:30) e fa una cosa sola: sincronizza il file system-signals.md fra il workspace locale e il repo GitHub. Non fa merge intelligente, non risolve conflitti. Ogni sezione ha un unico owner, il task che la scrive. Il sync sovrascrive per sezione intera basandosi sul timestamp last_updated.

Logica in due fasi:

Fase PULL (GitHub verso locale): pull del repo ops. Per ogni sezione owned da una Routine cloud (news-intelligence, blog-audit, outreach-tracking, system-health), confronta il last_updated remoto con quello locale. Se il remoto è più recente, sovrascrivi la sezione locale.

Fase PUSH (locale verso GitHub): leggi il file locale. Per ogni sezione owned da un task Cowork (orchestrator-directives, seo-performance, competitor-alerts, linkedin-plan, content-patterns), confronta i timestamp. Se il locale è più recente, sovrascrivi la sezione remota. Commit più push.

Il timing dei tre run è calibrato: alle 05:45 sincronizza PRIMA che news-intelligence (cloud, 06:00) e blog-writer (locale, 06:30) partano, così il blog-writer parte con le news del giorno fresche. Alle 08:30 sincronizza DOPO il blog-audit cloud così l'orchestratore mattutino lo vede. Alle 21:30 sincronizza PRIMA del system-health (cloud, 22:00) e del compliance-checker (locale, 22:30).

Il modello scelto è Haiku. È un sync meccanico: leggi, confronta timestamp, sovrascrivi. Zero ragionamento. Usare Opus o Sonnet qui sarebbe spreco.

Questa stessa filosofia, un task semplice che fa una cosa sola, modello scelto in base al ragionamento effettivamente richiesto, è il cuore di tutto il sistema. Ne ho scritto di più nella guida ai task schedulati con Claude Code e nel caso studio dei 5 workflow B2B reali in produzione, che ora include anche la parte ibrida Routines.

Cosa ho imparato in sei giorni

Andiamo per ordine. Tre insight che mi porto dietro da questa settimana di test.

1) Il vincolo cloud-native è un filtro di qualità, non una limitazione. Quando sai che un task non può toccare il Mac, sei costretto a strutturarlo pulito: input dichiarati via connettori o repo, output dichiarati in uno stato versionabile. I task Cowork che ho scritto in fretta a gennaio erano sporchi, leggevano file da qualsiasi posto, scrivevano log ovunque, dipendevano da variabili d'ambiente undocumented. I 5 task migrati, invece, sono piccoli manuali di ingegneria: sanno esattamente da dove leggono e dove scrivono. Migliori anche quelli che restano su Cowork, perché inizi a pensare in quel modo.

2) Il modello giusto è più importante del prompt giusto. Dei 5 task migrati, due girano su Haiku (system-health, repo-sync). Tre su Sonnet (news-intelligence, blog-audit, outreach-feedback-loop). Zero su Opus. Ho testato i task più complessi (blog-audit) anche su Opus e la qualità dell'output era identica. La differenza era nel tempo di esecuzione e nel consumo. Opus serve per scrittura long-form di qualità o ragionamento multi-step profondo. Per tutto il resto, Sonnet. Per il pattern matching puro, Haiku. Chi mette Opus su tutto sta solo bruciando budget.

3) Il sync è la parte critica. Se avessi migrato i task senza il signals-sync, avrei rotto il sistema. L'architettura ibrida funziona solo se il bus di comunicazione regge. Questo è il tipo di problema che si vede dopo averlo rotto, non prima, motivo per cui nel mio piano di migrazione il sync è stato lo step 0, non uno step finale. Prima il sync, poi i task. Mai il contrario.

Quando ti serve un'architettura ibrida (e quando no)

Le Routines non sono per tutti. Se stai iniziando adesso con Claude Code e hai 2-3 task schedulati, migrare tutto su Routine cloud è la scelta giusta: meno complessità operativa, niente sync da gestire, meno punti di rottura. La complessità ibrida ha senso solo quando hai abbastanza task Cowork da giustificare il costo di tenerli sincronizzati col cloud.

La mia regola personale: sotto i 10 task schedulati, tutto su Routine se i task non toccano il Mac. Sopra i 10, ibrido. Sopra i 30 (il mio caso, 38 task attivi ad aprile 2026), l'ibrido è l'unica scelta sensata, perché molti di quei task toccano LinkedIn, Chrome, file locali e non si possono migrare.

Per chi ha già un sistema complesso e vuole vedere come si struttura un ecosistema completo di automazioni con Claude Code, 21 automazioni in produzione, task schedulati, Routines cloud, MCP custom, sync bidirezionali, ho costruito Claude Mastery come manuale operativo. Non è teoria: è esattamente la struttura che sto descrivendo qui, con i prompt e le architetture usati ogni giorno.

FAQ

Le Claude Code Routines sostituiscono i task schedulati di Claude Code Cowork?

No. Le Routines girano cloud-side: non possono toccare file sul Mac, il browser locale, sessioni autenticate in app desktop. I task Cowork sono necessari per tutto ciò che richiede presenza locale (LinkedIn via Chrome MCP, script Python con dipendenze native, file system dell'utente). L'architettura corretta è ibrida: cloud per task cloud-friendly, locale per task che richiedono l'ambiente dell'utente.

Quante Routines posso far girare con il piano Max?

Il piano Max include 15 esecuzioni al giorno, contate per run e non per Routine. Se una Routine parte due volte al giorno, sono due esecuzioni. Se parte su trigger webhook senza cron fisso, conta ogni run effettivo. Con 5 task migrati che girano 1-2 volte al giorno, resto ampiamente nel budget.

Come faccio a far comunicare task cloud e task locali?

Serve un task di sync che tenga allineato un file di stato condiviso. Nel mio caso uso un system-signals.md che vive sia nel workspace locale sia in un repo GitHub; un task Cowork dedicato (signals-sync) sincronizza le due copie tre volte al giorno. Ogni sezione del file ha un unico owner, il sync sovrascrive per sezione intera in base a last_updated. Senza questo, il bus di comunicazione si spezza appena migri il primo task.

Posso triggerare una Routine da un push GitHub?

Sì. Le Routines supportano trigger webhook GitHub su push, PR, issue, release. Questo è il caso d'uso più interessante: automazioni event-driven invece di cron. Nel mio setup il repo-sync-metrics parte su ogni push sul branch main, sincronizza metriche fra repo privato e pubblico, apre una PR. Zero intervento manuale.

Che modello dovrei usare per le Routines?

Dipende dal task. Haiku per pattern matching puro (sync meccanico, confronto timestamp, health check). Sonnet per classificazione, scan più ranking, generazione draft con stile. Opus solo se serve ragionamento multi-step complesso o scrittura long-form di qualità, e di solito nei task schedulati non serve. Per i 5 task che ho migrato, zero Opus: due Haiku, tre Sonnet.

Come verifico che una Routine funziona prima di disabilitare il task Cowork corrispondente?

Procedura in cinque passi: 1) crea la Routine, 2) run manuale immediato, 3) verifica che l'output sia nel repo GitHub o connector atteso, 4) triggera il sync, 5) verifica che il dato arrivi anche nel workspace locale. Solo se tutti i passi passano, disabiliti il task Cowork. Non disabilitare mai il task locale prima di aver verificato che la Routine E il sync funzionano end-to-end. Documentazione ufficiale su docs.claude.com/routines.

Cosa c'è dopo

Ho 10 slot liberi sui 15 del piano Max. I prossimi candidati alla migrazione sono task che analizzano dati via GitHub API, generano report settimanali leggibili da qualsiasi stakeholder, sincronizzano metriche fra servizi cloud. Tutto quello che non tocca il mio Mac, prima o poi, migra.

Quello che resta su Cowork sono i task che toccano il profilo LinkedIn (post, engagement, DM, cross-post), gli script che leggono file locali grandi, i workflow che integrano app desktop native. Non è una limitazione da risolvere, è una divisione del lavoro sensata: il cloud fa il cloud, il locale fa il locale. Un sync in mezzo tiene tutto sincronizzato.

Il vantaggio reale non è "più task". È meno rischio che il sistema si rompa quando il Mac è spento. Se lavori con automazioni in produzione, sai quanto pesa questa singola differenza.

Leggi anche

Se vuoi approfondire il sistema di automazione che sta alla base di questo caso studio: Claude Code Guida Completa 2026 per il setup da zero, come ho costruito il sistema di task schedulati che ora gira in parte su Routines, i workflow B2B con Claude Code per il contesto operativo, e Claude Mastery se vuoi costruire qualcosa di simile da zero.

Caso studio misurato su N=1, periodo: 14-21 aprile 2026. 5 task migrati da Cowork a Routine cloud, 1 task di sync bidirezionale attivo su Cowork, 33 task residui su Cowork per vincoli locali (LinkedIn Chrome MCP, file system utente).