Come Claude Code mi ha aiutato a costruire workflow di automazione che funzionano davvero

L'AI non ti ruberà il lavoro. Ma qualcuno che sa usare l'AI per risolvere problemi veri, quello sì. E il confine tra usare uno strumento e diventarne dipendenti è più sottile di quanto pensiamo.

Quando ho iniziato a esplorare Claude Code per costruire automazioni complesse, mi sono reso conto di una cosa: non si tratta più di "saper programmare". Si tratta di saper porre le domande giuste, e di avere il coraggio di testare idee che sulla carta sembrano assurde. In questo articolo ti mostro il processo esatto che ho usato per progettare workflow di automazione che aumentano l'efficienza di chiamate commerciali fino al 50-80%, e come puoi applicare lo stesso metodo al tuo settore.

Come definire un problema che vale la pena risolvere con l'AI

Ogni progetto di automazione parte da una domanda semplice: quale problema sto cercando di risolvere, e quanto costa non risolverlo? Nel caso delle chiamate commerciali outbound, il problema è lampante. Un venditore fa 100 chiamate all'ora, ma solo il 40% risponde. Tempo di composizione del numero, squilli a vuoto, numeri sconosciuti ignorati: il risultato è che su 8 ore di lavoro, le conversazioni reali sono una frazione ridicola del tempo investito.

Ho chiesto a Claude Code: "Come posso aumentare il tasso di risposta alle chiamate commerciali?". Ma non mi sono fermato lì. Gli ho detto di spawnarmi 10 sotto-agenti paralleli, ognuno con il compito di generare 10 meccanismi diversi per migliorare la metrica. Algoritmi, psicologia comportamentale, infrastruttura, timing, identità chiamante. Nessun auto-censura sulla fattibilità: quella la faccio io dopo.

Il risultato? 200-300 idee. La maggior parte spazzatura totale. "Regressione meteo-pickup rate" (sul serio?). Ma in mezzo a tutto quel rumore, 5-6 idee concrete. Modelli di propensione temporale: chiamare le persone nell'orario in cui storicamente rispondono di più. Predictive pacing: comporre più numeri simultaneamente per azzerare i tempi morti. Offset algoritmici: se chiamo due persone insieme e una non risponde, l'altra è già in linea.

Il loop di sviluppo che funziona: dalla simulazione al deploy reale

Ecco il processo che uso per trasformare un'idea in un sistema funzionante. Primo: definisco il problema in modo misurabile. Nel mio caso, tasso di risposta su chiamate in 10 secondi. Secondo: chiedo a Claude di elencare tutte le soluzioni possibili, anche quelle assurde. Terzo: applico il cervello umano (sì, serve ancora) e faccio una shortlist delle idee fattibili.

Quarto step, fondamentale: costruisco una simulazione. Claude Code mi ha aiutato a progettare un harness di test che prende dati storici di chiamate (decine di migliaia) e simula scenari di predictive pacing con offset variabili. Quinto: itero sui parametri usando ottimizzazione bayesiana fino a trovare la configurazione che massimizza il pickup rate senza far rispondere troppe persone contemporaneamente (sì, può succedere, ed è imbarazzante).

Infine, il vero banco di prova: deploy su casi reali. Ho testato questi algoritmi su aziende che fanno centinaia di chiamate al giorno, in settori come HVAC, idraulica, coperture. Il dato: un'azienda texana è passata da 3 a 5 milioni di dollari al mese di fatturato. Un aumento del 66% mensile. In Italia, progetti di questa scala sono rari, ma il principio è lo stesso: identifica un collo di bottiglia operativo, costruisci un sistema che lo risolve, testa su dati reali.

Perché i framework agentici sono sopravvalutati (e cosa uso davvero)

Ho testato una cinquantina di approcci diversi: Hermes, OpenClaw, librerie di contesto con vector DB, memory embeddings. La mia conclusione? Ogni framework aggiuntivo è inversamente correlato al valore che crei. Non sto scherzando.

Ogni volta che salti su un nuovo framework, ti distrai dal problema vero. E peggio: crei regressioni nel codice. Una regressione è quando qualcosa che funzionava perfettamente con il prompt vanilla smette di funzionare perché il framework media diversamente l'input. Claude Code ha una sua logica interna, un suo modo di interpretare il contesto. Se ci metti sopra un layer di astrazione, quella logica si inceppa.

La vera intelligenza sta nel modello, non nel wrapper fancy che ci metti sopra. È come mettere un coprivolante peloso sulla tua auto e convincerti che per questo va più veloce. L'auto va perché ha un motore, ruote, telaio. Il coprivolante è solo estetica. Lo stesso vale per i framework agentici: ti danno l'illusione di controllo, ma nella maggior parte dei casi stai solo aggiungendo complessità.

Uso Claude Code vanilla, con un file agent.md minimale e system prompt essenziali. Niente Hermes, niente librerie esotiche. E funziona. Il 90% della qualità con il 100% della consistenza batte il 100% teorico che si rompe ogni tre giorni.

Come scegliere problemi che pagano (e perché la maggior parte delle persone sbaglia)

Puoi costruire qualsiasi cosa con l'AI. Ma non tutto vale la pena costruire. Esiste un diagramma di Venn: da una parte, tutto ciò che potresti costruire. Dall'altra, ciò per cui la gente è disposta a pagare. Il tuo obiettivo è stare nell'intersezione.

Il 90% dei progetti AI finisce nel lato sbagliato: to-do app, estensioni browser carine, tool di produttività personale. Problemi tiepidi. "Nice to have", non "need to have". In un mondo dove chiunque può convertire token in software, se il problema non è abbastanza grande, il cliente si costruisce la soluzione da solo.

Io ho scelto un problema rovente: aziende che perdono milioni all'anno per inefficienza nelle chiamate commerciali. Settori ad alto volume di chiamate: HVAC, idraulica, vendita di servizi locali. Budget grandi, dolore reale, nessuna soluzione moderna. Ho puntato su aziende mid-market con 50-100+ operatori. A 250 euro al mese per sede, un contratto da 100 posti vale 25.000 euro di MRR. Bastano pochi clienti così per costruire un'attività solida.

Altra lezione: scegli un settore con barriere normative. Nel mio caso, numeri telefonici e registrazioni A2P (Application-to-Person). Sono processi burocratici che l'AI non può bypassare. Questo crea un moat naturale in un mondo dove tutto il resto è replicabile. Lo stesso vale per la sanità (HIPAA), finanziario (compliance), legal tech (certificazioni). Trova un settore dove l'AI da sola non basta, e dove la tua implementazione umana ha valore.

Pricing: dimentica i modelli statistici, usa il buon senso

Ho iniziato a 100 euro al mese. La gente diceva sì troppo facilmente. Sono salito a 150. Ancora sì. Poi 200, poi 250. A un certo punto diventerà più difficile, e quello sarà il prezzo giusto. Non c'è bisogno di regressioni multivariate o modelli di willingness-to-pay trainati con AI. Parti da un numero che ti sembra sensato, vendi, e aumenta finché non inizi a sentire resistenza.

La differenza tra SaaS low-touch e high-touch è cruciale. Low-touch: self-service, 5-20 euro al mese, onboarding automatico. Il problema? In un mondo dove Claude Code può ricostruire il tuo prodotto in poche ore, ogni business owner si chiederà: perché non lo faccio io? High-touch: implementazione personalizzata, contratti da 100+ sedi, problemi complessi che richiedono consulenza umana. Questo è dove c'è margine, retention, e protezione dalla commoditizzazione.

Nel mio caso, non vendo singole licenze. Vendo pacchetti per team. Un cliente mid-market mi dà 300k di ARR in un colpo solo. Ne bastano tre per superare il milione. È un gioco di volumi diverso rispetto al freemium consumer, e richiede capacità di vendita B2B, ma è molto più difendibile.

Model-agnostic: come prepararsi al futuro dell'AI

Claude Code è eccellente, ma non puoi sposare un solo modello. La disponibilità di compute sta diventando un problema per tutte le major AI, e la qualità dei modelli oscilla nel tempo. Serve flessibilità.

Ho reso la mia codebase completamente model-agnostic. Claude ha il suo claude.md e skills.yaml? Perfetto. Ma ho anche codex.md, gemini.md, deepseek.md. Ogni modello ha le sue specifiche: alcuni leggono il YAML front matter delle skill, altri caricano tutto il file. Claude Code ha logiche di preload diverse da Codex. Piccole differenze, ma critiche.

Il vantaggio? Posso fare hot swap tra modelli in pochi minuti. Se Claude ha un'outage, passo a Codex. Se un task è troppo costoso su Claude, uso DeepSeek per refactoring continuo e bug fix. Questa architettura mi ha salvato più volte, e diventerà sempre più importante man mano che l'ecosistema AI si frammenta.

Chiedi a Claude di duplicare le tue spec per ogni modello che prevedi di usare. Testa regolarmente che il passaggio funzioni. È un'assicurazione che costa poco e vale tantissimo.

La domanda che vale la pena farsi

Costruire con l'AI è diventato quasi banale. Chiunque può convertire token in prodotto. Il vero valore non è più "posso costruire questo?", ma "dovrei costruire questo?". E soprattutto: quanto vale per qualcuno che il problema esista o sparisca?

Se stai iniziando a esplorare Claude Code o altri strumenti di sviluppo assistito da AI, il mio consiglio è di partire da problemi reali, misurabili, costosi. Non da idee carine. Costruisci simulazioni prima di scrivere codice di produzione. Testa su dati veri, con utenti veri, in contesti veri. E non innamorarti del framework del momento: tieni la tua architettura semplice, il tuo stack flessibile, e la tua attenzione sul problema, non sullo strumento.

Perché alla fine, l'AI è solo un moltiplicatore. Se moltiplichi zero, ottieni zero. Ma se moltiplichi una soluzione che vale milioni per qualcuno, allora sì, le cose diventano interessanti. E forse, solo forse, riusciremo a stare un passo avanti rispetto al momento in cui sarà l'AI a decidere cosa costruire, e noi a eseguire.