Costruire invece di rincorrere

Ho 33 anni, due figlie piccole, e un lavoro che paga bene ma non mi soddisfa più. Come molti professionisti della mia generazione, ho passato l'ultimo anno a guardare la rivoluzione AI con un misto di eccitazione e terrore. La paura di restare indietro è costante e sfiancante: ogni mattina porta notizie di un nuovo breakthrough, un altro strumento che promette di cambiare tutto, un'altra startup che sembra aver capito il futuro mentre io sono ancora fermo al presente.

Così ho iniziato a fare quello che sembrava naturale: lunghe conversazioni con i sistemi AI sull'AI stessa. Brainstorming infiniti, esplorando possibilità, cercando di identificare l'opportunità che mi stavo perdendo. Ero convinto che da qualche parte, in quelle conversazioni, avrei trovato la chiave per il mio posto in questo nuovo mondo.

Quello che ho trovato invece è stato qualcosa di inaspettato.

La domanda sbagliata

Per mesi mi ero ossessionato con "come sfrutto l'AI?" quando la vera domanda—quella che stavo evitando—era molto più semplice: "cosa voglio davvero costruire?"

La realizzazione scomoda è arrivata lentamente: la maggior parte del mio lavoro professionale non ha bisogno dell'intelligenza artificiale. Lavoro con dati finanziari, e i dati finanziari richiedono precisione. I numeri devono essere deterministici, riproducibili, verificabili. Non puoi consegnare un report a un cliente dicendo "l'AI pensa che il tuo fatturato sia più o meno questa cifra". Un sistema che ti dà una risposta leggermente diversa ogni volta che chiedi non è solo inutile—è pericoloso.

I miei veri strumenti sono sempre stati fogli di calcolo e script. Non sono glamour, non mi faranno invitare a conferenze, ma funzionano esattamente allo stesso modo ogni singola volta che li eseguo.

Il problema dietro il problema

Una volta smesso di rincorrere opportunità AI, ho finalmente visto cosa mi stava davvero disturbando. La FOMO non riguardava una rivoluzione tecnologica. Riguardava il tempo—specificamente, come lo stavo spendendo.

Stavo riempiendo le mie giornate con lavoro che paga bene ma non crea nulla di duraturo. Raccolta di documenti. Checkbox di compliance. Task che non richiedono alcun pensiero ingegneristico, nessun problem-solving creativo, nessuna costruzione vera. Solo processare input e produrre output identici a quelli di tutti gli altri.

Ogni ora che spendo su quel tipo di lavoro è un'ora che non spendo su quello che voglio davvero fare. E quelle ore diventano settimane, poi mesi, poi anni di una carriera che sembra di successo sulla carta ma si sente vuota nella pratica.

Questo sito

Questo sito è nato così: da una conversazione con Claude sulla frustrazione professionale e la voglia di costruire qualcosa invece di spingere carta.

Quello che è successo dopo non me l'aspettavo: ho smesso di essere uno sviluppatore (che non sono) e ho iniziato a essere un manager (che invece sono).

Durante quella sessione avevo Claude come sviluppatore senior—scriveva codice, debuggava problemi di deployment, implementava feature. Quando il sito ha dato un errore 500, Claude ha diagnosticato il problema, proposto fix, iterato finché non ha funzionato. Ho fatto fare una review del codice che ha dato un 6.5 su 10. Duro ma giusto: ha segnalato antipattern, rate limiting mancante, problemi SEO. Debito tecnico che non avrei saputo cercare.

Tutto AI. Tutto coordinato da me, un ragazzo di finanza che ha passato l'ultimo decennio a fare audit e FP&A.

Il ruolo dell'umano

Cosa ho fatto io concretamente? Ho preso decisioni.

"Sì, rimuovi la versione italiana." "Usiamo un volume Railway invece di Postgres." "La pagina 404 stile terminale sembra figa, facciamola." "Metti il titolo in grassetto."

Ho anche fatto domande. Tante. "Dove trovo le impostazioni del volume?" "È questa la schermata giusta?" "Funziona adesso?" L'AI non poteva cliccare i bottoni nella dashboard di Railway per me. Non poteva vedere il mio schermo finché non gli mostravo screenshot. L'umano restava essenziale—ma come coordinatore, non come artigiano.

Era come gestire un team remoto, solo che il team lavora a velocità sovrumana e non si scoccia mai quando faccio domande banali.

Cosa significa

Credo che stiamo vedendo un'anteprima di come evolve il lavoro intellettuale. Il valore non sta nel sapere come fare le cose—sta nel sapere cosa fare e nell'essere capaci di valutare se è fatto bene.

Quando la review del codice è tornata critica, non l'ho respinta sulla difensiva. Ho chiesto a Claude di sistemare i problemi. Quando il testing ha trovato bug, non sono andato nel panico. Ho passato il report indietro e ho lasciato che il debugging accadesse. Il mio lavoro era tenere il progetto in movimento, fare trade-off, mantenere standard di qualità che non potevo verificare personalmente attraverso ispezione tecnica.

Questo è management. Management vero. Non la parodia del management fatta di calendari e riunioni, ma il lavoro reale: dare direzione, allocare risorse, assicurare qualità, sbloccare il progresso.

La parte scomoda

C'è qualcosa di disorientante nel costruire qualcosa che non capisci completamente. Posso leggere il codice Python di questo progetto. Capisco più o meno cosa fa. Ma avrei potuto scriverlo da zero? No. Potrei debuggare una race condition sottile nell'analytics? Probabilmente no.

Sto pubblicando software in produzione che non potrei mantenere da solo. Questo sembra simultaneamente potente e precario. Come guidare una macchina senza sapere come funziona il motore—che, a pensarci, è esattamente quello che la maggior parte di noi fa ogni giorno.

Forse va bene così. Forse il futuro appartiene a chi sa orchestrare capacità invece di incarnarle. O forse sto costruendo un castello di carte che crollerà nel momento in cui qualcosa si rompe in un modo che l'AI non sa sistemare.

Non lo so davvero. Ma ho costruito questo sito, e tu lo stai leggendo. Questa parte è reale.

Da qui in avanti

Questo blog nasce per documentare un percorso che sto iniziando: da professionista della finanza a—come lo chiamano ora—"vibe coder". Qualcuno che non scrive codice riga per riga, ma che sa orchestrare strumenti e AI per costruire cose funzionanti.

Non ho la presunzione di essere una guida. Sto imparando anche io, e questo mondo si muove troppo velocemente perché qualcuno possa davvero dire di averlo capito. Ma se stai facendo un percorso simile—se vieni da un background "non tecnico" e ti stai chiedendo come navigare questa transizione—forse leggere di qualcun altro che ci prova può essere utile. Quantomeno per sentirti meno solo.