Ho delegato metà del mio lavoro alle AI

Ti porto dentro il sistema che ha cambiato il mio modo di lavorare

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

---

Una delle domande che mi fanno più spesso ultimamente è “Te che sei nerd di computer, come usi l’AI per lavorare?”.

E ci sta, perché di chiacchiere generiche sul tema ne girano un botto. Ci sono tanti che parlano di AI come se la usassero seriamente, pochi però che mostrano completamente tutto senza comprare un corso (furbacchioni).

Quindi questa newsletter è il tentativo di rispondere una volta per tutte. Sei aree del mio business, una per sezione. Tool nominati per nome e cognome (stile Conte in pandemia), workflow preciso con immagini e riferimenti.

Partiamo però dal framework di base generico che è comune a tutte le aree.

Il “mio” framework AI

Per tanti mesi io con l’AI ho fatto la stessa cosa che fanno tutti: aprivo una chat, scrivevo una richiesta, ottenevo una risposta. A volte buona, a volte mediocre, a volte da buttare. Il problema era che la qualità del risultato sembrava casuale, e quando ti capita di buttare via il 40% di quello che ottieni, smetti di fidarti dello strumento. È così che la maggior parte delle persone si convincono che “l’AI non è ancora pronta”, perché l’hanno usata in modo non strutturato e si sono rotti i coglioni di setacciare l’output.

Spinto dal migliorare questa cosa, ho trovato quello che fa il team di Every con il loro approccio al compound engineering. L’idea, riassumibile in due righe, è questa: invece di usare l’AI come un assistente al quale chiedi una mano per il singolo task, la usi come un sistema che si auto-rafforza, dove ogni esecuzione produce contesto utile per le successive, e dove gli agenti AI fanno review del lavoro di altri agenti AI prima che il risultato arrivi a te.

Tempo 0 secondi ho “rubato” il metodo, l’ho riadattato al mio lavoro, e da lì in poi tutto è cambiato. Quello che è uscito dalla mia versione del framework sono quattro fasi che ormai applico, con sfumature diverse, a praticamente ogni attività del mio business.

FASE I: il contesto. Prima ancora di chiedere all’AI di fare qualcosa, decido quali informazioni le devo passare e da dove devono arrivare. Knowledge base di un cliente, transcript di una call, documento markdown con i requisiti, esempi di output passati che mi sono piaciuti, vincoli operativi.

Dentro il contesto ci sono due tipi di informazioni diverse, ed è importante distinguerle. Una parte è dinamica e cambia da task a task: i dati specifici del cliente di turno, i requisiti del singolo lavoro, le ultime call. Un’altra parte è invece statica, e sono le regole di base di quell’area. Ogni area del mio business ha uno o più file markdown specifici che descrivono cose come gli anti-pattern da evitare assolutamente, le convenzioni che voglio rispettare sempre, i vincoli operativi che non cambiano mai. Per il contenuto sono la mia style guide e il file degli anti-pattern di scrittura. Per il codice di un progetto sono le convenzioni del repository, gli ADR storici, i pattern vietati. Per le offerte sono i template di servizio, le condizioni standard, i pricing di riferimento. Sembra una banalità, ma se l’AI non le ha in contesto le ignora puntualmente, e tu te ne accorgi al primo output.

Se il contesto è generico, il risultato è generico. Se il contesto è preciso, beh… puoi immaginare.

FASE II: la pianificazione del task. Prima di toccare l’esecuzione vera e propria, ragiono con l’AI su cosa significa quel task. Quali sono i requisiti, gli edge case, l’output atteso, i vincoli, gli step. Questa fase produce un piano scritto, di solito in markdown, a volte in HTML quando voglio renderlo navigabile (perché HTML te lo faccio dire da lui). Il piano diventa l’input strutturato della fase successiva. È la fase che ha più impatto sulla qualità finale, ed è quella che la maggior parte delle persone salta perché sembra “perdere tempo prima di iniziare”, in realtà è dove si fa il vero lavoro.

FASE III: l’esecuzione. A questo punto l’AI esegue sul piano. È la fase più visibile, ed è anche quella di cui parla la maggior parte della gente, ma è la meno strategica delle quattro. Se contesto e pianificazione sono fatti bene, l’esecuzione è (quasi) automatica. Se sono fatti male, l’esecuzione produce un risultato che sembra buono al primo sguardo e si rivela inutilizzabile alla seconda lettura.

FASE IV: la review, ed è doppia. C’è la review umana, dove sono io a leggere, correggere, integrare, ridire. E c’è la review fatta da un altro agente AI, separato da quello che ha eseguito, con istruzioni e focus diversi. È il pezzo che ho preso più di tutti da Every: avere un agente che fa review del lavoro di un altro agente prima che il risultato arrivi a me. Significa che quando lo vedo io, ha già passato un primo filtro che intercetta gli errori stupidi e mi fa concentrare sulle cose che davvero richiedono il mio giudizio.

Le sei aree che ti racconto adesso sono tutte costruite sopra questo scheletro. Cambia il tipo di contesto, cambia la pianificazione, cambia chi fa la review e con che criteri. Ma le quattro fasi sono sempre lì.

1. Il core business: la tecnologia

Per anni il mio lavoro da Fractional CTO era stato “non sviluppo più, faccio strategia, advisory, decisioni architetturali, gestisco team” (detto alla brutta). L’idea di rimettere mano direttamente al codice di una startup era fuori scope. Lo delegavo, scrivevo le specifiche, facevo review delle PR, correggevo le scelte e nei casi peggiori riscrivevo io stesso alcune parti perché era più veloce farlo che spiegarlo.

Oggi con l’AI le cose sono un po’ cambiate. Perché adesso son tornato molto più in prima linea riuscendo a portare valore come CTO e come sviluppatore (non lo faccio per tutti ovviamente, impazzirei). Ma il valore che riesco a portare ora è davvero 3x rispetto a prima.

Lo stack è questo semplice: Claude Code e Codex (cento dollari al mese ciascuno, sono i due abbonamenti più produttivi che ho mai pagato), più Cursor che tengo nella versione free perché lo uso solo per fare review del codice generato, non per generarlo. Il set di skill è quello di Every:Compound Engineering (non mi invento nulla)

Sul fronte contesto, per ogni progetto cliente ho un set di markdown che descrive l’architettura, le convenzioni di codice, i pattern accettabili e quelli vietati, le regole di branching, i tool di testing usati, gli ADR (architectural decision records) presi nel tempo. Quando lancio un task, il coding agent ha già tutta questa roba caricata in contesto, e non parte mai da zero come se fosse appena arrivato sul progetto. È la differenza tra dare un task a un dev senior che è in azienda da due anni e darlo a uno che è arrivato il giorno prima.

Quando un cliente ha più repository (tipicamente frontend, backend, magari una mobile app e magari altri servizii separati), il contesto non può vivere solo dentro i singoli repo, perché un sacco di task sono full-stack e toccano due o tre repository contemporaneamente. Quindi mantengo una cartella docs nella root folder del cliente, condivisa tra tutti i repo, con tutto il contesto trasversale: architettura ad alto livello, contratti API tra servizi, convenzioni di naming condivise, ADR che valgono per più di un repo, modelli dati cross-servizio. Poi ogni singolo repo mantiene la sua docs interna con quello che è specifico solo a lui. Quando il coding agent lavora in modalità full-stack parte dalla docs della root e scende nelle docs dei singoli repo che sta toccando, quando lavora su un repo solo va direttamente lì. È un accorgimento di struttura piccolo, ma fa la differenza tra un agent che capisce il sistema e uno che capisce solo il pezzo che ha sotto gli occhi.

Sul fronte pianificazione, prima di toccare codice faccio brainstorming tecnologico con l’AI. Output del brainstorming: o un markdown strutturato che diventa input per l’agent, oppure un HTML leggibile che apro in browser, scrollo, verifico, correggo. L’HTML è la parte che cambia tutto, perché vedere un piano formattato e navigabile è completamente diverso da rileggere il proprio Google Doc lungo tre pagine. Vedi subito se la struttura regge, dove sono i buchi, quali decisioni non hai ancora preso.

Un esempio di HTML doc

Solo dopo che il piano è validato, il coding agent esegue. E qui entra in gioco la review automatica: prima ancora che io guardi il risultato, il codice generato passa per un secondo agente configurato come reviewer, con un prompt focalizzato su errori comuni nel tipo di task corrente (migration, refactor, nuova feature, fix), su pattern vietati nel progetto, su rischi di regressione. Solo dopo questo passaggio il risultato mi arriva in mano per la review umana finale.

Sembra macchinoso a parole, ma il setup lo fai una volta e poi gira. E il risparmio in cose stupide intercettate prima del mio occhio è enorme.

Ti faccio un esempio concreto. Ho lavorato per un cliente ad una migrazione da MongoDB a PostgreSQL. Lavorone enorme: ripensare lo schema dati, riscrivere le query, gestire la transizione infrastrutturale, la migrazione dei dati in produzione e (ovviamente) testare tutto. Il tipo di progetto che sei mesi fa avrei delegato completamente a uno sviluppatore, seguendolo passo passo, facendo call di kickoff e discutendo se quell’indice serviva davvero o se fosse una prematura ottimizzazione.

Questa volta ho fatto diversamente, lavorando in autonomia end-to-end con l’AI. Risultato sbalorditivo, migrazione fatta in 2 mesi. Su questo farò un articolo separato, perché è andato tutto liscio (più o meno).

Il cambiamento concreto è che il ciclo tra “penso una cosa” e “vedo il risultato funzionare” è passato da giorni a minuti. C’è stato un momento in cui ho cambiato idea su come gestire una relazione nel database. In un flusso tradizionale avrei scritto un commento sulla PR, aspettato che il collega la leggesse, aspettato l’alternativa, fatto review dell’alternativa. Qui ho cambiato idea, aggiornato il piano, fatto rilanciare l’agent sulla parte impattata, testato la nuova struttura. Venti minuti.

La confidence che hai nel gestire questo tipo di attività cambia completamente. Decidi cose che prima non avresti deciso, perché il costo di provare era troppo alto.

2. Content creation: il Content OS

Tutto quello che pubblico, dalla newsletter che stai leggendo al video del venerdì su YouTube, ai post LinkedIn delle mattine, esce da un repository che ho chiamato Content OS.

Il Content OS è un progetto in markdown che ho costruito apposta per me, con cartelle organizzate per piattaforma e per status (idea, in progress, to review, published), e un set di skill custom che ho scritto per le fasi del workflow.

Anche qui le quattro fasi del framework valgono, basta sostituire “codice” con “contenuto”.

Il contesto, in questo caso, è una style guide in markdown lunga un paio di centinaia di righe che descrive il mio tono di voce, le espressioni che uso, i riferimenti culturali che faccio (che non prende mai, ‘sto fango…), le strutture di apertura e chiusura che funzionano. Più un secondo file di anti-pattern che elenca le cose da non fare mai (frasi da guru motivazionale, simmetrie forzate, tic da AI tipo “Non è X, è Y”). E infine gli ultimi cinque-dieci post pubblicati, che servono da riferimento per l’evoluzione recente dello stile. La style guide è anche lei un file che si auto-aggiorna ogni volta che pubblico un nuovo pezzo: una skill confronta il post appena pubblicato con la guida attuale e aggiunge i pattern nuovi che ha riconosciuto.

La pianificazione è il momento in cui un’idea grezza diventa un brief strutturato. Scrivo /idea capture e cattura il pensiero. Scrivo /write brainstorm e parte una sessione di domande e risposte che mi aiuta a tirare fuori storia, esempi concreti, frasi forti. Da lì arrivo al brief con angolo, hook, struttura a sezioni.

Quello che fa la vera differenza in questo processo è che tutto questo non lo faccio scrivendo, ma lo faccio a voce. Uso VoiceInk, un tool di dettatura AI per Mac che trasforma la voce in testo in tempo reale dentro qualsiasi text input mi serva. La differenza tra scrivere e parlare, quando si tratta di creare contenuti, è abissale e me ne sono accorto solo dopo averla provata seriamente.

Quando parli, ragioni a voce alta e non costruisci la frase perfetta, racconti. E quando l’AI ti fa domande di follow-up sui dubbi che hai espresso, sui passaggi che hai dato per scontati, sugli esempi che non hai fatto, ti costringe a razionalizzare cose che nella tua testa erano implicite. È letteralmente un’intervista, dove l’AI fa il giornalista e io faccio l’intervistato. In una singola sessione di mezz’ora a voce, di solito tiro fuori il materiale per due o tre contenuti diversi, perché un’idea ne apre un’altra e una domanda di follow-up porta su un filone nuovo.

Per me questa è la cosa più sottovalutata di tutto l’uso dell’AI lato content. L’AI qui non sta scrivendo al posto mio (sarebbe terribile e si vedrebbe subito alla prima parola). Mi sta intervistando e mi sta aiutando a mettere a terra la competenza e il valore che ho già, ma che da solo non saprei verbalizzare con la stessa pulizia. Quello che esce dall’esecuzione successiva è poi figlio di quella conversazione registrata, non di una mia richiesta a freddo.

L’esecuzione è /write draft e mi tira fuori una prima bozza nel mio tono. Non è quasi mai pubblicabile così com’è, ma è un punto di partenza che mi farebbe perdere una mezza giornata a partire dal foglio bianco.

La review è doppia. /review lancia un agente che controlla il draft contro la style guide e gli anti-pattern, mi segnala dove ho frasi che puzzano di AI, dove la struttura è troppo simile ai post precedenti, dove l’argomento sta diventando da life coach generico invece che da Fractional CTO. Poi entro io con la review umana finale cambiando cose e riscrivendo paragrafi.

E quando arriva il momento, sincronizzo su Notion per farmi aiutare con un’ulteriore review da parte di Veronica con un bel /sync push. /sync pull fa il viceversa quando loro hanno aggiornato lo stato di un pezzo.

Probabilmente questa newsletter è uno degli esempi più concreti che ti capiterà di leggere quest’anno: una newsletter scritta dentro un sistema che ho costruito io per scrivere newsletter, dove ti sto raccontando il sistema stesso. Inception spostati.

E lo stesso Content OS gestisce anche tutta la parte di acquisizione, che è una delle leve che ho aperto più di recente: i lead magnet li genero molto più velocemente, le thumbnail della newsletter e del canale YouTube le tiro fuori con Higgsfield e i caroselli LinkedIn li produco partendo dal contenuto principale.

[Se ti sta piacendo la newsletter e non sei iscritto, è il momento giusto per farlo]

3. Discovery e knowledge clienti: Fathom + Business OS

Ogni call con un cliente, sia di discovery che operativa, viene registrata. Il tool che uso è Fathom, un note taker AI che oltre a generare il transcript ti dà anche action items e riassunti automatici. Costa il giusto e funziona meglio degli altri che ho provato.

Il transcript però non lo uso così com’è. Per me è materia prima.

Per ogni cliente ho una cartella dentro un secondo progetto markdown che ho chiamato Business OS. Dentro quella cartella ci sono tutti i transcript delle call con quel cliente, le decisioni prese e perché, il contesto storico (chi sono, cosa fanno, dove stanno andando), i pattern che ho osservato (come comunicano, dove fanno fatica, su cosa girano in tondo), le persone chiave, le rogne aperte, i deliverable concordati, gli ADR di business. Tutto strutturato in modo che un agente possa pescarlo e usarlo come contesto.

Sopra quella knowledge base ci ragiono con l’AI. Prima di una call operativa con un cliente lancio una skill che fa una cosa specifica: pesca le ultime due o tre call con quel cliente, le mette in fila con quello che era rimasto in sospeso e mi tira fuori una mini-agenda con tre o quattro punti da affrontare ordinati per urgenza. In cinque minuti ho il contesto pieno di un cliente.

Prima di una discovery con un cliente nuovo, il flusso è diverso. Carico in contesto le informazioni che ho su di loro (sito, eventuali documenti che mi hanno mandato, contesto sull’industry), e faccio brainstorming sul tipo di outcome che potrebbero servire. Esco dalla discovery con domande già in testa, ipotesi da verificare, e una mappa mentale di dove probabilmente sta il valore. Questo cambia completamente la qualità della call. Non sto più ascoltando per la prima volta tutto, sto verificando ipotesi e cercando segnali che confermino o smontino quello che già mi ero immaginato.

A questo punto la review è meno automatica e più umana, perché siamo sul fronte relazionale e il mio giudizio diretto conta di più. Però anche qui ho un secondo agente che, dopo la call, prende il transcript fresco e lo confronta con la knowledge base esistente: segnala se ci sono contraddizioni con quello che mi avevano detto prima, decisioni che hanno cambiato, persone nuove menzionate, rischi che si stanno alzando. Roba che a occhio nudo dopo una giornata di call ti sfugge.

Ah e una piccolezza, ho un’automazione su n8n che analizza il transcript e estrapola una lista di to do che poi mi mette direttamente su Notion (se sono riferiti a me).

4. Sales: offerte HTML personalizzate

Sempre dentro Business OS c’è una sezione dedicata alle offerte, e questa è la parte dove il framework cambia un po’ di forma. Ti racconto come funziona, in ordine.

Quando arriva il momento di pitchare un cliente, parto con tutto il suo materiale già caricato in contesto (transcript di discovery, mappa degli obiettivi, vincoli espressi, persone coinvolte, segnali su budget e tempistiche) più i miei template di servizio (pacchetti, deliverable tipici, prezzi di riferimento, condizioni standard). A quel punto, prima ancora di generare l’offerta, decido con l’AI quale taglio darle. Stesso servizio, ma per un cliente in early stage lo strutturo diversamente rispetto a un cliente in fase di scale. Per un founder tecnico parlo di una cosa, per un founder business di un’altra.

Solo quando il taglio è chiaro, l’AI genera l’offerta in HTML, strutturata come un mini-sito a sezioni: contesto del cliente, obiettivi che andremo a coprire, servizi inclusi, deliverable misurabili, retainer mensile, durata. La pubblico su offers.christianvarisco.com con un accesso privato protetto da password. Il cliente riceve un link, entra, naviga l’offerta come fosse una landing dedicata a lui, e se vuole può scaricarla in PDF direttamente dalla pagina.

Prima che il cliente la veda, però, l’offerta passa per un secondo agente reviewer che fa un check di coerenza: ogni sezione è allineata con i dati del cliente, non ci sono deliverable promessi che poi non compaiono nel pricing, il pricing è allineato ai miei template. Solo dopo entro io, rileggo, aggiusto il tono dove serve, taglio le parti che diventano troppo generiche.

Perché lo faccio così? Perché un’offerta in HTML spacca 100 volte di più di un PDF sepolto in una cartella Drive che il cliente non aprirà mai più dopo la prima call. È sempre online, sempre aggiornata e il cliente può tornarci in qualsiasi momento senza dover frugare nelle mail. Ma soprattutto, quando un cliente la riceve, già da come è confezionata capisce che dall’altra parte non c’è un quaqquaraquà qualsiasi con un template scaricato da Canva. È un segnale (prego eh).

5. Amministrazione: autofatture e tool esteri

Questa è la parte meno glamour della newsletter, ma forse quella che mi fa risparmiare più tempo psicologico al mese.

Lavoro con un sacco di tool americani o comunque esteri. Ogni mese tra Claude Code, Codex, Fathom, Higgsfield, server, dominio, AWS e altri tool minori, mi ritrovo con una decina di fatture da paesi diversi che il commercialista deve poter usare per fare autofatture.

Una volta era una rottura pazzesca. Aprivo le mail una per una, scaricavo i PDF, li rinominavo a mano, li mettevo in una cartella Drive seguendo un naming consistente che ovviamente sbagliavo tre volte su dieci, manco fossi un archivista alle prime armi, mandavo il link al commercialista, gli rispondevo alle domande quando mi diceva che una fattura non si capiva di chi era. Tempo totale: una mezza giornata al mese di lavoro morto, da fare puntualmente in fondo al mese quando hai zero voglia di farlo.

Adesso c’è un’automazione (anche questa scritta come skill custom) che fa tutto il flusso. Pesca le mail con allegati che provengono dai provider che le emettono, riconosce il tipo di documento (fattura, ricevuta, note di credito), lo rinomina, lo mette nella cartella Drive del mese corrente. Il commercialista entra in cartella, prende tutto e ci fa quel che vuole.

La review è banale ma c’è: ogni mese guardo il riepilogo per quindici minuti, controllo che gli importi tornino con quello che mi aspetto di aver speso, e se qualcosa non quadra vado a guardare la singola fattura. Fine.

Non è sexy. Ma quelle due orette di lavoro morto al mese, moltiplicata per dodici, son 3 giorni di vita all’anno che ora passo in maniera più produttiva (guardo i tik e tok).

6. Strategy: l’AI come socio

L’ultima area è anche quella un pò più strana se vogliamo, perché è quella che si avvicina di più al tipo di lavoro che teoricamente è “il mio”.

Pensiero strategico sul business. Decisioni di posizionamento. Lettura del mercato. Capire dove sta andando il mondo dei Fractional, cosa stanno facendo gli altri (sì, vi osservo tutti) e dove c’è spazio per differenziarsi. Capire quando vale la pena aprire una nuova linea di servizio e quando invece sto perdendo terreno.

Per tanto tempo questa era la parte che mi tenevo strettissima, perché “è quella in cui aggiungo valore”. Poi mi sono accorto che fare tutto da solo nel proprio cervello ha un sacco di limiti tra cui: confirmation bias, blind spot, mancanza di confronto reale con un interlocutore che ti dica “guarda che non torna” senza temere di farti incazzare.

L’AI in questa fase è diventata quasi un socio.

Tutto parte da una cartella dentro Business OS dove tengo strutturati i numeri del business (ricavi, marginalità, mix dei clienti), gli obiettivi annuali, le decisioni strategiche prese (e quelle scartate, con il perché), le riflessioni che ho buttato giù nei mesi precedenti, i feedback dei clienti, i pattern che ho osservato nel mercato. È il backup esterno del mio cervello da Fractional, ed è il primo input che entra nelle sessioni strategiche.

Da lì in poi il framework cambia un po’ forma, perché in fase strategica non pianifico un task e poi lo eseguo separatamente, ma ci ragiono su. Discuto a voce alta con Claudio (lo chiamiamo tutti così dai), buttiamo giù mappe, scenari e contro-argomenti. A volte gli delego ricerche di mercato vere e proprie: “guarda come si sta posizionando il mondo del Fractional CTO in Italia, fammi una mappa dei competitor diretti e adiacenti, identifica le narrative emergenti, segnalami dove vedi pattern che non sto cogliendo”. Roba che sei mesi fa avrei dovuto fare a mano io, o pagare una caterva di soldi a qualcuno per farla.

Sulla review invece il framework si conferma, ma con una variante che vale solo qui. Sul fronte strategico non lascio fare a un altro agente, perché la qualità del giudizio dipende dal contesto profondo del business e da pezzi di intuito che fatico anche solo a verbalizzare. La review me la faccio io con un trucchetto: rileggo i ragionamenti a distanza di una settimana. Spesso quello che mi era sembrato brillante una settimana fa, riletto a freddo, è un’idea normale o addirittura sbagliata.

Il punto qui, per essere chiari, è che decido sempre io. Ma avere un interlocutore competente, che non ha agenda, che non si stanca, che ricorda tutto, che ti porta dati freschi quando serve, è una cosa profondamente diversa rispetto al ragionare da solo. Anche solo come sparring partner.

Ora, le riflessioni

Detto tutto il pratico, ci sono un paio di cose da dire, che fanno parte del pezzo tanto quanto i tool e i workflow.

Sono diventato dipendente dall’AI.

Non è un’esagerazione retorica. Se domani mattina mi togliessero tutto, dovrei riadattarmi a un modo di lavorare che ormai non ricordo più. E lo ammetto, farei fatica. Sarei meno produttivo, meno lucido, meno autonomo su una marea di cose che ho disimparato a fare da solo.

E qui sta il paradosso. Questa dipendenza è esattamente quello che mi ha permesso di evolvere il business. Sono indipendente su attività che prima avrei dovuto delegare a persone da gestire, da onboardare, da pagare anche nei mesi in cui non c’erano abbastanza progetti da giustificarle. L’AI ha reso il mio business più sostenibile, più piccolo e forse ancora più mio.

E qui c’è una seconda riflessione che mi gira in testa da quando ho letto una newsletter recente di Elena Verna (se non sai chi è, male). Elena ha ribadito un concetto di cui si parla da un pò: la HI-C, High-Impact Individual Contributor. L’idea è che il vecchio modello di carriera (più persone sotto di te, più impatto hai) sta diventando obsoleto. La nuova carriera ad alto impatto può essere quella di un IC che ha le competenze e gli strumenti per portare un progetto end-to-end senza un team intero dietro. Lei stessa è tornata IC dopo essere stata VP, e racconta che dopo qualche mese di disorientamento (la classica domanda “ma mi sto promuovendo o mi sto demolendo lo status?”) ha capito che è stata la scelta più giusta della sua carriera recente.

Leggendola mi sono accorto che è esattamente quello che sta succedendo a me, in piccolo. Senza un cambio di titolo, senza un annuncio, ho avuto una mini epifania: dove posso, sto tornando IC. Non ho rinunciato al ruolo di Fractional CTO, ma alcune cose che prima mi serviva delegare per averle, adesso conviene farle io con un coding agent o con uno stack di skill custom. È un altro modo di fare impatto, e probabilmente è più allineato a come mi piace davvero lavorare di quanto lo fosse il modello “salgo nella scala, gestisco più persone, tocco meno mestiere”.

E non è solo qualcosa che riguarda me. Qualche giorno prima di leggere quella newsletter di Elena, in una chat su Slack con un cliente che mi chiedeva come strutturare il team di prodotto avevo scritto quasi alla lettera lo stesso concetto (alla brutta).

Poi quando ho letto quella newsletter di Elena, qualche giorno dopo, mi sono accorto che stavo proponendo esattamente la stessa cosa: spostare l’impatto dalle scale gerarchiche al singolo che porta a termine il progetto end-to-end, con l’AI come moltiplicatore di possibilità. Quindi è un pattern che non sto solo vivendo in prima persona, è un pattern che sto consigliando attivamente anche nei team dei miei clienti.

Penso che oggi un business di questo tipo (fractional, consulenza, freelance, scegli il termine che preferisci) sia molto più facile da far partire da soli rispetto a cinque anni fa. La parte operativa la deleghi, la parte di giudizio la tieni. Ed è la parte di giudizio quella che il cliente sta comprando.

Però attenzione, perché il rovescio della medaglia esiste eccome.

L’AI è un moltiplicatore. Moltiplica quello che già sai fare. Se hai vent’anni di esperienza tecnica, l’AI ti fa lavorare come se ne avessi quaranta. Se di esperienza ne hai poca, ti fa sembrare un junior dignitoso quando i task sono semplici, e crolla subito quando i problemi diventano interessanti. Quello che viene moltiplicato sono sempre le tue competenze e il tuo giudizio. Senza la base, lo stack che ti ho raccontato è inutile, e probabilmente anche pericoloso.

E resta che sono ancora io quello che decide cosa costruire, per chi, in che ordine, con che criterio. Il giorno in cui l’AI si avvicinerà bene a quella parte là, dovrò ripensare di nuovo tutto. Ma non è oggi. E preoccuparmi adesso di quel giorno mi sembra solo un modo per non sfruttare la finestra che ho davanti.

Lo stack, per chi lo vuole copiare

Per chi è arrivato fin qui e vuole la lista pulita: Claude Code e Codex per il coding agent, Cursor free per la review del codice generato, Fathom per le call con i clienti, Gemini come chat classica (incluso in Google Workspace), Higgsfield per le thumbnail di newsletter e YouTube, Notion come database condiviso (senza Notion AI, non l’ho mai trovato all’altezza), più due repository markdown costruiti su misura (Content OS per i contenuti, Business OS per il resto) sopra una serie di skill scritte da me.

Niente di tutto questo è copiabile uno a uno. Il valore non sta nei tool, sta nelle quattro fasi che applichi sopra. I tool cambieranno tra sei mesi, garantito. Il framework lo costruisci solo tu, su misura del tuo lavoro, dei tuoi clienti, del tuo modo di pensare. Però se ti aspettavi di vedere “i 5 tool AI che usa un fractional CTO”, almeno adesso li hai.

Rispondi a questa mail e condividilo agli amici, sono davvero curioso di sentire come la stai vivendo dal tuo lato. Soprattutto se la stai vivendo diversamente da me.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.