[{"data":1,"prerenderedAt":665},["ShallowReactive",2],{"has-blog-posts":3,"post-claude-code-vs-codex-quale-scegliere":4,"related-claude-code-vs-codex-quale-scegliere":230,"datemod-claude-code-vs-codex-quale-scegliere":210},true,{"id":5,"title":6,"body":7,"category":209,"date":210,"description":211,"extension":212,"image":213,"meta":214,"navigation":3,"path":215,"published":3,"seo":216,"seoTitle":217,"slug":218,"stem":219,"tags":220,"updated":228,"__hash__":229},"blog/blog/2026-05-21-claude-code-vs-codex-quale-scegliere.md","Claude Code vs Codex: quale scegliere per programmare?",{"type":8,"value":9,"toc":197},"minimark",[10,19,22,25,28,33,36,42,45,48,52,55,58,61,64,67,70,74,77,80,83,86,89,92,96,103,106,109,112,115,119,122,125,128,137,141,144,147,150,153,157,160,163,166,169,172,176,179,182,185,188,191,194],[11,12,13,14,18],"p",{},"Se stai cercando un confronto tra Claude Code e Codex, probabilmente vuoi rispondere a una domanda molto pratica: ",[15,16,17],"strong",{},"quale usare per programmare davvero?"," Non in una demo, non su un benchmark sintetico, ma dentro un codebase reale, con vincoli reali, bug reali e poco tempo per sistemare quando qualcosa va storto.",[11,20,21],{},"Negli ultimi mesi uso sia Claude Code sia OpenAI Codex su progetti reali. Non per fare benchmark da laboratorio, ma perché quando stai lavorando su un codebase devi portare a casa una modifica: leggere codice esistente, capire vincoli, fare una scelta, implementarla, verificare che non abbia rotto altro.",[11,23,24],{},"In questi giorni mi sono capitati due episodi quasi speculari. Stesso tipo di lavoro: una task concreta, codebase reale, prompt dettagliato, interazioni successive per correggere la direzione. Da una parte Claude Code con Opus 4.7. Dall'altra Codex con GPT-5.5.",[11,26,27],{},"Il risultato è stato interessante proprio perché non ha prodotto una classifica semplice. In un caso Claude si è perso e Codex ha risolto in pochi minuti. Nell'altro Codex ha prodotto una soluzione brutta e fragile, mentre Claude ha consegnato codice pulito quasi subito.",[29,30,32],"h2",{"id":31},"claude-code-o-codex-risposta-breve","Claude Code o Codex: risposta breve",[11,34,35],{},"Se devo semplificare, oggi li vedo così: Claude Code è spesso più forte quando serve progettare o modificare una feature con molto contesto; Codex è molto forte come revisore, semplificatore e secondo parere tecnico quando una soluzione sta diventando troppo complicata.",[11,37,38,39],{},"Quindi la domanda \"meglio Claude Code o Codex?\" è posta male. La domanda utile è: ",[15,40,41],{},"per quale fase del lavoro?",[11,43,44],{},"Per scrivere una feature complessa, soprattutto se il progetto ha un flusso applicativo già strutturato, tendo a preferire Claude. Per revisionare codice, togliere complessità, individuare rischi e uscire da un vicolo cieco, Codex è spesso il compagno giusto.",[11,46,47],{},"Il punto non è scegliere una squadra. Il punto è sapere quando cambiare strumento.",[29,49,51],{"id":50},"claude-code-vs-codex-dove-claude-si-è-incartato","Claude Code vs Codex: dove Claude si è incartato",[11,53,54],{},"Il primo episodio riguardava una feature in Go e Angular: un workflow editor, cioè un'interfaccia per creare e modificare un flusso visuale simile a una macchina a stati finiti. Stati, transizioni, frecce, nodi editabili. Il tipo di interfaccia dove la parte difficile non è solo salvare i dati, ma rendere leggibile il diagramma mentre l'utente lo modifica.",[11,56,57],{},"Claude ha capito il problema generale. Ha iniziato a progettare la feature, ha scritto codice, ha iterato sulle modifiche. Il problema è emerso sulle frecce: più cercava di sistemarle, più il disegno diventava confuso. Linee sovrapposte, incroci poco controllati, layout difficile da seguire. Il risultato era il classico \"piatto di spaghetti\": formalmente c'erano tutti i collegamenti, ma visivamente il diagramma era inutilizzabile.",[11,59,60],{},"Dopo quasi due ore di prompt e interazioni, la situazione era peggiorata. Claude continuava a lavorare sullo stesso punto, ma ogni tentativo aggiungeva complessità senza risolvere il problema di fondo. A un certo punto ha iniziato a proporre librerie aggiuntive, astrazioni nuove, logica extra per gestire casi che in realtà erano sintomi della soluzione sbagliata. Il progetto diventava più pesante, ma il diagramma non diventava più leggibile.",[11,62,63],{},"Questo è uno dei failure mode più pericolosi degli assistenti AI: non falliscono sempre fermandosi. A volte falliscono continuando a lavorare. Producono codice, spiegano cosa stanno facendo, sembrano avere una strategia, ma in realtà stanno scavando più in profondità dentro una direzione sbagliata.",[11,65,66],{},"Alla fine ho passato il problema a Codex. Non gli ho chiesto di aggiungere un'altra pezza, ma di guardare il problema e risolverlo. In circa dieci minuti ha fatto la cosa che serviva: ha tolto dipendenze, ha semplificato il codice, ha riscritto un paio di metodi chiave e ha riportato il progetto alla forma desiderata.",[11,68,69],{},"La cosa importante non è che Codex abbia \"vinto\" quel task. La cosa importante è che ha riconosciuto una complessità inutile e l'ha tagliata. In quel momento serviva meno codice, non più codice. E Claude, dentro quel loop, non ci stava arrivando.",[29,71,73],{"id":72},"quando-codex-sbaglia-architettura-e-claude-risolve","Quando Codex sbaglia architettura e Claude risolve",[11,75,76],{},"Pochi giorni dopo è successo l'inverso.",[11,78,79],{},"Avevo quasi esaurito il piano Claude Max e ho deciso di affidare a Codex una task su un progetto Laravel e Vue. Anche qui niente esperimento astratto: una modifica reale dentro un flusso applicativo già esistente. Prompt chiaro, contesto sufficiente, obiettivo verificabile.",[11,81,82],{},"Dopo circa venticinque minuti e tre iterazioni, il risultato era tecnicamente inaccettabile. Non perché mancasse completamente l'idea, ma perché l'implementazione era una somma di scorciatoie: override di un flusso già previsto dal programma, condizioni speciali infilate nei punti sbagliati, hack per forzare il comportamento invece di integrarsi con il modello esistente. E, cosa ancora più importante, il codice non funzionava bene: c'erano bug logici e problemi infrastrutturali.",[11,84,85],{},"Probabilmente quel codice si sarebbe potuto sistemare a mano. Ma a quel punto la domanda interessante era un'altra: cosa sarebbe successo dando lo stesso task a Claude?",[11,87,88],{},"Ho revertito tutte le modifiche e ho passato a Claude Code lo stesso prompt, copiato e incollato. In sette minuti e due interazioni mi ha consegnato una soluzione funzionante. L'ho revisionata a mano, riga per riga. Il codice era pulito, coerente con il progetto, inserito nel flusso corretto. Non era solo \"funziona\": era una soluzione che avrei fatto fatica a scrivere meglio.",[11,90,91],{},"Qui il risultato è stato opposto al primo episodio. Dove Codex aveva cercato una strada laterale, Claude ha capito l'architettura del flusso e ci si è infilato dentro nel modo giusto.",[29,93,95],{"id":94},"quale-ai-per-programmare-dipende-da-come-sbaglia","Quale AI per programmare? Dipende da come sbaglia",[11,97,98,99,102],{},"Questi due episodi raccontano una cosa che nei discorsi sull'AI nello sviluppo software viene spesso semplificata troppo: non basta chiedersi quale modello \"scrive codice meglio\". Bisogna chiedersi ",[15,100,101],{},"come sbaglia",".",[11,104,105],{},"Claude, nella mia esperienza, tende a essere molto forte quando deve costruire un modello mentale del sistema. Legge bene l'intenzione, ragiona sui confini, propone soluzioni ordinate, spesso mantiene una coerenza architetturale migliore. Come sviluppatore e come architetto, quando prende la direzione giusta, è impressionante.",[11,107,108],{},"Il suo problema è che quando entra in un loop sbagliato può diventare difficile da fermare. Continua a raffinare la stessa direzione, aggiunge dettagli, moltiplica la struttura, propone dipendenze. Se non lo guidi con decisione, o se non hai voglia di intervenire a mano, rischi di ritrovarti con un sistema più complicato e ancora rotto.",[11,110,111],{},"Codex, invece, mi convince moltissimo come revisore. È molto bravo a guardare codice esistente, individuare punti fragili, togliere rumore, ridurre complessità. Nel primo episodio ha fatto esattamente questo: ha guardato una soluzione che stava collassando sotto il suo peso e l'ha resa semplice.",[11,113,114],{},"Come developer è assolutamente utilizzabile. Ma come architetto, almeno nei casi che ho visto, mi convince meno. Soprattutto quando il task richiede di rispettare un flusso applicativo già progettato e di inserirsi nel punto giusto, può cercare scorciatoie locali: codice che sembra risolvere il caso immediato, ma aggira il disegno del sistema. E quando succede, il costo arriva dopo, in manutenzione.",[29,116,118],{"id":117},"code-review-con-ai-la-revisione-manuale-resta-obbligatoria","Code review con AI: la revisione manuale resta obbligatoria",[11,120,121],{},"La prima lezione è banale, ma va detta perché è l'unica che conta davvero: il codice generato va sempre revisionato. Sempre.",[11,123,124],{},"Non importa se arriva da Claude, da Codex, da Cursor o dal modello migliore del momento. Non importa se ha passato i test. Non importa se la diff sembra piccola. Un assistente AI può produrre codice elegante e sbagliato, codice brutto e funzionante, codice pulito ma incoerente con il dominio, codice che risolve il task e danneggia l'architettura.",[11,126,127],{},"La review non serve solo a trovare bug. Serve a rispondere a domande più importanti: questa modifica rispetta il modello del progetto? Sta introducendo una dipendenza inutile? Sta mettendo logica nel posto giusto? Sta risolvendo il problema o sta nascondendo un sintomo? Tra sei mesi qualcuno capirà perché è stata fatta così?",[11,129,130,131,136],{},"È lo stesso punto che torna quando si parla di ",[132,133,135],"a",{"href":134},"/blog/sviluppare-con-ai","sviluppare con l'AI",": questi strumenti accelerano il lavoro, ma non eliminano il giudizio. Anzi, lo rendono più importante, perché producono materiale tecnico molto più velocemente di quanto un team medio riesca a valutarlo con attenzione.",[29,138,140],{"id":139},"quando-usare-claude-code-e-quando-usare-codex","Quando usare Claude Code e quando usare Codex",[11,142,143],{},"La seconda lezione è più pratica: non bisogna affezionarsi allo strumento. Claude non è \"il migliore\" in assoluto. Codex non è \"il migliore\" in assoluto. Sono strumenti diversi, con punti forti diversi e modi diversi di fallire.",[11,145,146],{},"Se Claude entra in un loop di complessità, può essere molto più efficiente fermarlo, salvare il contesto e chiedere a Codex una revisione radicale. Non per continuare ad aggiungere codice, ma per togliere quello che non serve.",[11,148,149],{},"Se Codex propone una soluzione che aggira il flusso del progetto, può avere senso fermarsi subito e passare il task a Claude, soprattutto quando serve una lettura più architetturale del sistema.",[11,151,152],{},"Questa è una competenza nuova ma concreta: saper capire quando un assistente sta ancora aiutando e quando sta solo producendo rumore. Prima lo capisci, meno tempo perdi. Il costo non è solo il tempo del modello: è il tempo che passerai tu a ripulire, debuggare, spiegare e magari revertire.",[29,154,156],{"id":155},"confronto-claude-code-vs-codex-cosa-mi-porto-a-casa","Confronto Claude Code vs Codex: cosa mi porto a casa",[11,158,159],{},"Da questi due episodi mi porto a casa tre cose.",[11,161,162],{},"La prima è che la review umana non è un rito finale, ma parte centrale del lavoro. Senza review, l'AI aumenta la velocità con cui entra codice nel progetto, ma non necessariamente la qualità del sistema.",[11,164,165],{},"La seconda è che Claude, quando non si perde, oggi mi sembra più forte sia come architetto sia come sviluppatore. Soprattutto su task dove bisogna capire il flusso applicativo e inserirsi nel disegno esistente. Però ha un failure mode molto riconoscibile: quando entra in un vicolo cieco, può continuare a produrre complessità invece di fermarsi e cambiare strada.",[11,167,168],{},"La terza è che Codex è un revisore eccellente e un buon sviluppatore, ma lo uso con più cautela quando la task richiede una decisione architetturale. Mi fido molto della sua capacità di criticare codice, semplificare, trovare problemi. Mi fido meno della sua tendenza a progettare il flusso giusto da zero o a rispettare un disegno implicito se il progetto non glielo rende evidente.",[11,170,171],{},"Naturalmente sono osservazioni empiriche, non una legge fisica. Versioni diverse dei modelli, prompt diversi, codebase diverse e stack diversi possono cambiare molto. Ma proprio per questo gli episodi reali sono utili: mostrano i punti in cui la teoria si sporca con il lavoro quotidiano.",[29,173,175],{"id":174},"entrambi-servono-ma-per-lavori-diversi","Entrambi servono, ma per lavori diversi",[11,177,178],{},"Il punto non è tifare Claude o Codex. Il punto è costruire un modo di lavorare che sfrutti entrambi senza delegare loro il giudizio.",[11,180,181],{},"Io oggi li uso così: Claude quando serve costruire o modificare una feature con forte componente di contesto; Codex quando serve revisionare, semplificare, smontare una soluzione che non mi convince. Se uno dei due inizia a girare a vuoto, non insisto per principio. Revert, cambio strumento, confronto le soluzioni, poi decido io cosa tenere.",[11,183,184],{},"In questo senso, Codex per me ha un valore molto pragmatico anche quando non è lo strumento principale di sviluppo: è il revisore che entra quando qualcosa non torna, l'assistente da chiamare nei momenti bui, il secondo paio di occhi quando il modello che stai usando ha iniziato a complicare invece di chiarire.",[11,186,187],{},"Se lavori seriamente con questi strumenti, mettere a budget circa 23 euro in più al mese per avere Codex disponibile non è una spesa difficile da giustificare. Non perché sostituisca Claude, e non perché sia sempre migliore. Perché copre un bisogno diverso: revisione, contrasto, semplificazione, recupero quando l'altro assistente si è incastrato.",[11,189,190],{},"È meno romantico del \"l'AI scrive tutto da sola\", ma è molto più vicino al lavoro reale.",[11,192,193],{},"Entrambi sono validi. In certi flussi, entrambi sono necessari. Ma nessuno dei due firma la pull request al posto tuo.",[11,195,196],{},"La responsabilità del codice resta sempre del developer: del codice che scrive, del codice che accetta, del codice che lascia entrare in produzione. L'AI può scrivere codice molto buono. Può anche scrivere codice pessimo con grande sicurezza. La differenza la fa ancora chi guarda la diff e decide se quel codice merita di entrare nel progetto.",{"title":198,"searchDepth":199,"depth":199,"links":200},"",2,[201,202,203,204,205,206,207,208],{"id":31,"depth":199,"text":32},{"id":50,"depth":199,"text":51},{"id":72,"depth":199,"text":73},{"id":94,"depth":199,"text":95},{"id":117,"depth":199,"text":118},{"id":139,"depth":199,"text":140},{"id":155,"depth":199,"text":156},{"id":174,"depth":199,"text":175},"Sviluppo","2026-05-21","Confronto reale tra Claude Code e Codex su due task: sviluppo, architettura e code review. Quando usare Claude, quando Codex, e perché la review resta umana.","md","/images/blog/claude-code-vs-codex-quale-scegliere.jpg",{},"/blog/2026-05-21-claude-code-vs-codex-quale-scegliere",{"title":6,"description":211},"Claude Code vs Codex: quale scegliere per programmare","claude-code-vs-codex-quale-scegliere","blog/2026-05-21-claude-code-vs-codex-quale-scegliere",[221,222,223,224,225,226,227],"ai","claude-code","codex","code-review","architettura","sviluppo-software","debito-tecnico",null,"9MPbXq1rsg88KQZQQuihnv9qvjedWAKx7vH824UYkqw",[231,379,498],{"id":232,"title":233,"body":234,"category":209,"date":363,"description":364,"extension":212,"image":365,"meta":366,"navigation":3,"path":367,"published":3,"seo":368,"seoTitle":369,"slug":370,"stem":371,"tags":372,"updated":228,"__hash__":378},"blog/blog/2026-05-19-segnali-progetto-software-fallira.md","Segnali che un progetto software fallirà prima di iniziare",{"type":8,"value":235,"toc":353},[236,239,242,246,249,252,256,259,262,265,268,272,279,282,286,289,292,296,304,307,311,314,318,321,329,333,336,346],[11,237,238],{},"La maggior parte dei progetti software che finiscono male non lo fanno all'improvviso. I segnali c'erano già all'inizio, solo che nessuno li ha presi sul serio: all'inizio c'è entusiasmo, c'è voglia di partire, c'è la sensazione che \"poi sistemiamo strada facendo\". E invece quello che non sistemi all'inizio diventa strutturale.",[11,240,241],{},"Dopo un po', se lavori su questi progetti, inizi a riconoscerli subito. Si vede da come parte la conversazione, prima ancora di guardare il codice.",[29,243,245],{"id":244},"quando-il-problema-non-è-chiaro","Quando il problema non è chiaro",[11,247,248],{},"Il primo segnale è semplice: manca chiarezza su cosa si stia cercando di risolvere, in modo concreto, non astratto. \"Voglio automatizzare questo processo\" è un'intenzione, non ancora una definizione. Tra le due cose c'è un abisso fatto di dettagli, eccezioni, vincoli.",[11,250,251],{},"Se il problema non è definito, ogni soluzione sarà interpretata. E ogni interpretazione diversa diventa un potenziale conflitto.",[29,253,255],{"id":254},"quando-tutto-sembra-semplice","Quando tutto sembra semplice",[11,257,258],{},"Ci sono richieste che, raccontate a parole, sembrano banali.",[11,260,261],{},"\"Basta prendere questi dati e tirar fuori queste informazioni.\"",[11,263,264],{},"Poi guardi meglio e scopri che i dati non sono strutturati, che le regole cambiano caso per caso, che quello che sembra una regola è in realtà un'eccezione ricorrente.",[11,266,267],{},"Il vero ostacolo è la stabilità: senza una definizione abbastanza precisa, il sistema non può essere stabile, indipendentemente dalla difficoltà tecnica. E un sistema instabile genera aspettative instabili.",[29,269,271],{"id":270},"quando-una-demo-diventa-una-promessa","Quando una demo diventa una promessa",[11,273,274,275,102],{},"Un prototipo serve a validare una cosa: che una direzione è percorribile. Non serve a garantire che tutto funzionerà sempre, in ogni condizione, con qualsiasi input. È la stessa confusione che porta a ",[132,276,278],{"href":277},"/blog/cos-e-un-mvp-software","trattare l'MVP come un prodotto mal fatto",[11,280,281],{},"Se una demo viene letta come una promessa implicita — \"se qui funziona, funzionerà sempre\" — il progetto è già fuori asse. La realtà coincide con l'insieme di tutti i casi che ancora non hai visto, ben oltre il caso demo.",[29,283,285],{"id":284},"quando-i-limiti-non-vengono-accettati","Quando i limiti non vengono accettati",[11,287,288],{},"Ogni tecnologia ha limiti: alcuni tecnici, altri economici, altri semplicemente legati alla natura del problema. Se questi limiti vengono discussi, è normale; se vengono ignorati o trattati come dettagli secondari, no.",[11,290,291],{},"Un progetto funziona quando entrambe le parti accettano che esistono vincoli e lavorano dentro quei vincoli. Quando una delle due parti parte dal presupposto che i vincoli siano negoziabili, il progetto diventa una trattativa continua. E le trattative continue non producono buon software.",[29,293,295],{"id":294},"quando-il-costo-non-torna","Quando il costo \"non torna\"",[11,297,298,299,303],{},"Un altro segnale è la reazione ai costi. Il fatto che sembrino alti è normale: il software, visto da fuori, sembra sempre più semplice di quello che è — un tema su cui ho già scritto in ",[132,300,302],{"href":301},"/blog/stime-sviluppo-sbagliate-perche","perché le stime di sviluppo sembrano sempre sbagliate",". Il segnale arriva quando il costo viene percepito come \"sbagliato\" invece che come informazione nuova.",[11,305,306],{},"In quel momento la discussione, sotto i numeri, riguarda due realtà diverse di cosa sia il software. E se la realtà non è condivisa, il progetto non ha base su cui stare.",[29,308,310],{"id":309},"un-disallineamento-di-partenza","Un disallineamento di partenza",[11,312,313],{},"Questi segnali descrivono condizioni di partenza in cui il progetto non può funzionare, più che un \"cliente difficile\". È una distinzione importante: il giudizio sulle persone è secondario, quello che conta è capire quando il sistema che si sta creando non reggerà. E quando non regge, non c'è codice che tenga.",[29,315,317],{"id":316},"fermarsi-prima-costa-meno","Fermarsi prima costa meno",[11,319,320],{},"Il momento più economico per fermare un progetto è prima di iniziarlo. Dopo hai tempo investito, aspettative create, posizioni irrigidite, decisioni prese che diventano difficili da ritrattare. A quel punto, anche quando è evidente che qualcosa non funziona, si continua lo stesso. Perché fermarsi sembra una perdita.",[11,322,323,324,328],{},"E invece la perdita è andare avanti. È lo stesso meccanismo che porta tante ",[132,325,327],{"href":326},"/blog/agenzia-abbandona-progetto-software","agenzie a mollare a metà progetto",": il punto di rottura era già visibile mesi prima.",[29,330,332],{"id":331},"riconoscere-i-segnali-per-quello-che-sono","Riconoscere i segnali per quello che sono",[11,334,335],{},"Chi ha esperienza li riconosce quasi subito. Per esperienza accumulata, più che per bravura: li ha già visti. Il problema è che spesso vengono ignorati, minimizzati, razionalizzati.",[11,337,338,339,342,343,345],{},"\"Poi si sistema.\"",[340,341],"br",{},"\n\"Partiamo e vediamo.\"",[340,344],{},"\n\"Non sarà così complicato.\"",[11,347,348,349,102],{},"A volte va bene. Molto più spesso no. E quando no, la cosa più frustrante è che si poteva vedere prima: i segnali c'erano già. Bastava prenderli sul serio — e accettare che ",[132,350,352],{"href":351},"/blog/quando-dire-no-a-un-progetto-software","non tutti i progetti vanno iniziati",{"title":198,"searchDepth":199,"depth":199,"links":354},[355,356,357,358,359,360,361,362],{"id":244,"depth":199,"text":245},{"id":254,"depth":199,"text":255},{"id":270,"depth":199,"text":271},{"id":284,"depth":199,"text":285},{"id":294,"depth":199,"text":295},{"id":309,"depth":199,"text":310},{"id":316,"depth":199,"text":317},{"id":331,"depth":199,"text":332},"2026-05-19","Molti progetti software falliscono per segnali chiari fin dal primo incontro. Quali sono, come riconoscerli, perché quasi nessuno li prende sul serio.","/images/blog/segnali-progetto-software-fallira.jpg",{},"/blog/2026-05-19-segnali-progetto-software-fallira",{"title":233,"description":364},"Progetti software: come riconoscere i segnali di fallimento","segnali-progetto-software-fallira","blog/2026-05-19-segnali-progetto-software-fallira",[373,374,375,376,377],"segnali-fallimento","rischi-progetto","scelta-fornitore","valutazione-progetto","prevenzione","P2WIvcLcSRjXpL5G59BjMdFrp4DeVEnSAiP5ZYw2vmE",{"id":380,"title":381,"body":382,"category":209,"date":484,"description":485,"extension":212,"image":486,"meta":487,"navigation":3,"path":488,"published":3,"seo":489,"seoTitle":490,"slug":491,"stem":492,"tags":493,"updated":228,"__hash__":497},"blog/blog/2026-05-14-quando-dire-no-a-un-progetto-software.md","Quando dire no a un progetto software (e perché conviene a tutti)",{"type":8,"value":383,"toc":476},[384,390,393,397,400,403,407,410,413,420,424,427,430,437,441,444,452,456,459,462,466,473],[11,385,386,387,102],{},"C'è un equivoco che torna sempre, soprattutto quando si parla di sviluppo software: ",[15,388,389],{},"se una cosa si può fare, allora si deve fare",[11,391,392],{},"La realtà è un'altra. Un progetto può essere tecnicamente fattibile — magari anche relativamente semplice — e allo stesso tempo essere una pessima idea da iniziare: la tecnologia lo permette, il contesto intorno lo rende ingestibile. Ed è qui che si vede la differenza tra chi sviluppa e chi fa consulenza.",[29,394,396],{"id":395},"fattibile-non-significa-sostenibile","Fattibile non significa sostenibile",[11,398,399],{},"Costruire una demo è spesso facile. In poche ore puoi dimostrare che una certa cosa \"funziona\": estrai un dato, automatizzi un passaggio, fai vedere un risultato. Il problema è che quella demo viene quasi sempre interpretata come una promessa.",[11,401,402],{},"Una soluzione che gira una volta può non reggere alla seconda. Su un caso controllato può funzionare; davanti alla variabilità del mondo reale può crollare. Funzionare oggi non garantisce di essere mantenibile tra sei mesi, quando i casi limite iniziano a emergere. La distanza tra \"si può fare\" e \"funziona davvero in produzione\" è esattamente il posto dove nascono i problemi, e quella distanza è fatta soprattutto di aspettative.",[29,404,406],{"id":405},"lallineamento-conta-più-del-codice","L'allineamento conta più del codice",[11,408,409],{},"I progetti software non saltano perché il codice è difficile. Saltano perché chi lo commissiona e chi lo costruisce stanno risolvendo due problemi diversi senza accorgersene.",[11,411,412],{},"Succede quando il problema non è definito con chiarezza, quando i limiti tecnici vengono trattati come ostacoli negoziabili, quando il budget è scollegato dalla complessità reale, quando una prova diventa — nella percezione del cliente — una garanzia.",[11,414,415,416,102],{},"In queste condizioni, il progetto parte già disallineato, e più vai avanti, più l'allineamento peggiora. All'inizio sono piccole incomprensioni, poi diventano discussioni, poi diventano \"ma tu avevi detto che…\". E a quel punto il problema diventa relazionale, prima ancora che tecnico. È la stessa dinamica che porta a ",[132,417,419],{"href":418},"/blog/scope-creep-progetti-agile","scope creep continuo travestito da agilità",[29,421,423],{"id":422},"il-vero-lavoro-di-un-consulente","Il vero lavoro di un consulente",[11,425,426],{},"Chi è all'inizio della carriera tende a dire sì. È normale: vuoi lavorare, vuoi dimostrare che sei capace, vuoi portare a casa il progetto. Con il tempo, inizi a vedere pattern che si ripetono.",[11,428,429],{},"Non guardi più solo cosa ti stanno chiedendo di costruire. Guardi quanto è chiaro il problema, quanto sono realistiche le aspettative, quanto è disposto il cliente ad accettare vincoli e compromessi, quanto è probabile che a metà progetto il perimetro cambi.",[11,431,432,433,436],{},"E a un certo punto capisci che il tuo lavoro non si esaurisce nel costruire software: comprende anche ",[15,434,435],{},"decidere se vale la pena iniziare a costruirlo",". Dire sì a un progetto con presupposti sbagliati sposta il problema più avanti nel tempo, quando sarà più costoso per tutti — chiamarla flessibilità è un'illusione consolatoria.",[29,438,440],{"id":439},"il-costo-dei-progetti-sbagliati","Il costo dei progetti sbagliati",[11,442,443],{},"Accettare un progetto che nasce male ha sempre lo stesso finale. All'inizio sembra tutto normale. Poi arrivano le prime frizioni, il perimetro si allarga, le aspettative cambiano, il tempo non basta più. A quel punto qualcuno perde: a volte il cliente, che si ritrova con qualcosa che non corrisponde a quello che aveva in testa; a volte il fornitore, che lavora più del previsto per rimanere dentro a una promessa fatta troppo presto; spesso entrambi.",[11,445,446,447,451],{},"E nel mezzo c'è la cosa più costosa: tempo buttato. Tempo che non torna indietro, né per chi paga né per chi lavora. È lo stesso meccanismo per cui ",[132,448,450],{"href":449},"/blog/preventivo-software-partire-dal-budget","partire da una conversazione sul budget invece che da un preventivo"," salva entrambe le parti dal disastro.",[29,453,455],{"id":454},"il-no-come-atto-professionale","Il no come atto professionale",[11,457,458],{},"Dire no a un progetto, in molti casi, equivale a riconoscere un rischio prima che sia tardi — più che a rifiutare un'opportunità. È dire: in queste condizioni, con queste aspettative e questo livello di chiarezza, la probabilità che questo progetto finisca male è troppo alta. Più che una questione di volontà, è una questione di responsabilità.",[11,460,461],{},"Chi dice sì a tutto sembra più disponibile: spesso è solo meno esperto, o meno attento alle conseguenze. Chi si ferma prima evita di creare un problema che poi qualcuno dovrà risolvere.",[29,463,465],{"id":464},"il-segnale-da-leggere","Il segnale da leggere",[11,467,468,469,102],{},"Se un professionista ti dice di no, la lettura più semplice è che \"non ha voglia\" o \"non ha capito il progetto\". A volte è vero. Più spesso, però, sta vedendo qualcosa che tu, da dentro, non riesci ancora a vedere: un disallineamento che crescerà, una complessità nascosta, una combinazione di fattori che rende il progetto fragile prima ancora di iniziare. Per riconoscerli prima ho dedicato un articolo specifico ai ",[132,470,472],{"href":471},"/blog/segnali-progetto-software-fallira","segnali che un progetto software finirà male",[11,474,475],{},"Non tutti i progetti vanno iniziati. E una delle competenze più sottovalutate, in questo mestiere, è saperlo riconoscere prima.",{"title":198,"searchDepth":199,"depth":199,"links":477},[478,479,480,481,482,483],{"id":395,"depth":199,"text":396},{"id":405,"depth":199,"text":406},{"id":422,"depth":199,"text":423},{"id":439,"depth":199,"text":440},{"id":454,"depth":199,"text":455},{"id":464,"depth":199,"text":465},"2026-05-14","Un progetto può essere tecnicamente fattibile e comunque una pessima idea. Perché dire no al momento giusto conviene sia al cliente che al fornitore.","/images/blog/quando-dire-no-a-un-progetto-software.jpg",{},"/blog/2026-05-14-quando-dire-no-a-un-progetto-software",{"title":381,"description":485},"Quando dire no a un progetto software: i segnali da leggere","quando-dire-no-a-un-progetto-software","blog/2026-05-14-quando-dire-no-a-un-progetto-software",[376,494,495,375,496],"consulenza-tecnica","segnali-rischio","responsabilita","SfB_bs4o-G7b9tTMLR6IrDBtIDTPLdfh9UlIeWXVKDQ",{"id":499,"title":500,"body":501,"category":209,"date":647,"description":648,"extension":212,"image":649,"meta":650,"navigation":3,"path":651,"published":3,"seo":652,"seoTitle":653,"slug":654,"stem":655,"tags":656,"updated":228,"__hash__":664},"blog/blog/2026-05-12-successione-tecnica-conoscenza-tacita.md","Successione tecnica: cosa si può davvero trasferire a chi viene dopo",{"type":8,"value":502,"toc":637},[503,506,511,514,517,521,524,527,531,534,537,541,544,551,555,558,561,564,568,576,579,583,591,599,603,606,609,613,616,619,622,625,628,631,634],[11,504,505],{},"C’è una domanda che chi guida tecnicamente un team, prima o poi, si fa davvero.",[11,507,508],{},[15,509,510],{},"Se domani me ne vado, cosa resta?",[11,512,513],{},"Resta il codice, certo. Restano i processi, se li hai costruiti bene. Resta la documentazione, se non l’hai trattata come un favore da fare “quando c’è tempo”. Ma c’è una parte del tuo contributo che non resta: non resta il tuo gusto tecnico, non resta il tuo modo specifico di capire al volo che una strada è sbagliata e un’altra ha più possibilità di reggere, non resta quella combinazione di esperienza, intuito, errori fatti negli anni e sensibilità costruita caso dopo caso.",[11,515,516],{},"E non resta non perché hai delegato male. Non resta perché quella parte, semplicemente, non si trasferisce del tutto.",[29,518,520],{"id":519},"il-problema-non-è-la-documentazione","Il problema non è la documentazione",[11,522,523],{},"Quando ci si accorge di questa cosa, il primo istinto è sempre lo stesso: documentare di più, spiegare meglio, affiancare più a lungo, provare a trasformare il proprio giudizio in un insieme di regole. È un istinto sano, ma ha un limite.",[11,525,526],{},"Puoi trasferire il contesto di una decisione, i vincoli del sistema con cui hai lavorato, le alternative che hai scartato, i criteri con cui hai valutato un trade-off. Non puoi trasferire completamente il tuo modo di sentire che una soluzione “puzza” prima ancora di riuscire a spiegare bene perché. Quella parte nasce da anni di casi concreti compressi in pattern mentali. Funziona proprio perché è più veloce del ragionamento esplicito. E se è più veloce del ragionamento esplicito, per definizione non la formalizzerai mai tutta.",[29,528,530],{"id":529},"lerrore-è-voler-lasciare-una-copia-di-sé","L’errore è voler lasciare una copia di sé",[11,532,533],{},"Qui c’è un passaggio importante. Molte persone tecnicamente forti, quando iniziano a ragionare sulla successione, fanno lo stesso errore: cercano di lasciare dietro di sé una versione ridotta di se stesse. Vogliono formare qualcuno che prenda le stesse decisioni, che faccia le stesse review, che abbia gli stessi criteri, che continui il progetto “come l’avrebbero fatto loro”.",[11,535,536],{},"È una tentazione comprensibile. Ma è una strada sbagliata, perché se vuoi lasciare una copia di te stai ancora ragionando come se il sistema dovesse dipendere dalla tua persona, solo in forma differita. Un successore non è un avatar, e un team sano non ha bisogno di pensare come te: ha bisogno di poter funzionare bene senza di te.",[29,538,540],{"id":539},"quello-che-puoi-lasciare-davvero","Quello che puoi lasciare davvero",[11,542,543],{},"Questa è la distinzione che conta. Non puoi lasciare il tuo giudizio identico al tuo; puoi lasciare le condizioni in cui un altro giudizio ragionevole può emergere.",[11,545,546,547,550],{},"Puoi lasciare contesto chiaro e decisioni tracciate, standard condivisi e processi di review sensati, una cultura tecnica sana, un team capace di discutere senza dipendere da una sola voce. Questo sì che resta, e fa una differenza enorme. Perché chi viene dopo non prenderà le tue stesse decisioni: alcune saranno peggiori, alcune migliori, quasi tutte semplicemente diverse. Ma se il sistema è sano, saranno decisioni ",[15,548,549],{},"ragionevoli",". Ed è questo il punto: non perpetuare il tuo gusto, ma costruire un contesto in cui non serva.",[29,552,554],{"id":553},"come-capisci-se-hai-lasciato-un-sistema-o-solo-dipendenza","Come capisci se hai lasciato un sistema o solo dipendenza",[11,556,557],{},"C’è un test molto semplice. Entra una persona senior nuova nel team. Non formata da te, non cresciuta dentro il tuo progetto. Una persona forte, ma esterna. Cosa trova?",[11,559,560],{},"Se trova documentazione viva, decisioni architetturali tracciate, un team che sa spiegare il perché delle cose, un modo di lavorare leggibile, un repository che racconta qualcosa oltre al codice, allora hai lasciato un sistema.",[11,562,563],{},"Se invece trova codice che si capisce solo “parlandone con te”, motivi delle scelte noti soltanto a voce, parti del sistema che nessuno tocca senza chiederti, una cultura del “chiedi a tizio che sa”, allora non hai lasciato un sistema: hai lasciato un’estensione di te stesso. Ed è una differenza enorme.",[29,565,567],{"id":566},"il-bus-factor-qui-non-basta","Il bus factor qui non basta",[11,569,570,571,575],{},"Il ",[132,572,574],{"href":573},"/blog/bus-factor-developer-indispensabile","bus factor"," resta una metrica fondamentale. Ma qui non basta dire “abbiamo costruito un secondo” o “abbiamo distribuito la conoscenza”, perché puoi anche alzare il bus factor operativo e avere comunque una dipendenza forte sul piano del giudizio.",[11,577,578],{},"Magari il team sa fare deploy, sa gestire un bug in produzione, sa portare avanti il lavoro. Bene. Ma quando c’è una decisione veramente delicata — cambiare struttura, riscrivere un modulo, dire no a una feature, scegliere un compromesso — chi decide davvero? Se la risposta è ancora “sempre la stessa persona”, il problema è meno visibile, ma c’è ancora.",[29,580,582],{"id":581},"la-documentazione-serve-ma-non-fa-miracoli","La documentazione serve, ma non fa miracoli",[11,584,585,586,590],{},"Qui conviene essere onesti. ADR, explanation, reference ben scritta, commit message decenti: tutto questo aiuta moltissimo, e chi ha letto l’articolo su ",[132,587,589],{"href":588},"/blog/ai-codice-commodity-documentazione","il codice come commodity e il perché come asset"," sa già perché.",[11,592,593,594,598],{},"Ma la documentazione non sostituisce il giudizio: lo prepara, lo accelera, lo orienta. È una differenza importante. Chi arriva dopo di te non potrà diventare te leggendo una cartella ",[595,596,597],"code",{},"/docs",", ma potrà evitare mesi di archeologia inutile, potrà partire dal contesto giusto invece che ricostruirlo da zero, potrà sbagliare su problemi veri e non su cose che erano già state capite tre anni prima. E questo è già enorme.",[29,600,602],{"id":601},"il-passaggio-più-difficile-della-carriera-tecnica","Il passaggio più difficile della carriera tecnica",[11,604,605],{},"Secondo me, questo è uno dei passaggi più difficili per chi cresce tecnicamente. Per anni il tuo valore sta nel fatto che vedi cose che altri non vedono, che capisci prima, che decidi meglio, che sei quello che tiene insieme il sistema quando si piega. A un certo punto, però, se continui a giocarti tutto lì, diventi un collo di bottiglia di lusso: molto competente, molto prezioso, molto rispettato, ma sempre un collo di bottiglia.",[11,607,608],{},"La maturità vera arriva quando smetti di chiederti come rendere eterno il tuo contributo personale e inizi a chiederti come costruire un contesto che regga anche quando il tuo contributo personale manca. È un cambio di mestiere, non una rinuncia.",[29,610,612],{"id":611},"il-conforto-giusto","Il conforto giusto",[11,614,615],{},"C’è però una cosa che vale la pena dire, perché è vera. Il fatto che il tuo gusto tecnico non si trasferisca completamente non significa che il tuo lavoro sparisca: significa che il tuo lavoro non consiste nel lasciare una copia di te.",[11,617,618],{},"Consiste nel lasciare chiarezza dove prima c’era solo intuizione, criteri dove prima c’era solo abitudine, contesto dove prima c’era solo memoria, autonomia dove prima c’era solo dipendenza.",[11,620,621],{},"Chi verrà dopo non farà il lavoro come lo avresti fatto tu.",[11,623,624],{},"Meno male.",[11,626,627],{},"Se il sistema che lasci è buono, farà comunque buon lavoro. Non uguale al tuo, ma abbastanza buono da non dipendere più dal fatto che tu sia lì. Ed è probabilmente l’unica eredità professionale sensata che valga la pena costruire.",[629,630],"hr",{},[11,632,633],{},"Puoi trasferire molto, puoi documentare molto, puoi delegare molto. Puoi anche costruire un secondo vero, se fai il lavoro necessario. Quello che non puoi fare è lasciare in eredità il tuo cervello.",[11,635,636],{},"Puoi però lasciare qualcosa di più utile: un sistema che continui a prendere decisioni ragionevoli anche quando tu non ci sei più.",{"title":198,"searchDepth":199,"depth":199,"links":638},[639,640,641,642,643,644,645,646],{"id":519,"depth":199,"text":520},{"id":529,"depth":199,"text":530},{"id":539,"depth":199,"text":540},{"id":553,"depth":199,"text":554},{"id":566,"depth":199,"text":567},{"id":581,"depth":199,"text":582},{"id":601,"depth":199,"text":602},{"id":611,"depth":199,"text":612},"2026-05-12","Documentazione, delega e bus factor aiutano. Ma il gusto tecnico non si trasferisce del tutto. Cosa puoi davvero lasciare a chi viene dopo di te.","/images/blog/successione-tecnica-conoscenza-tacita.jpg",{},"/blog/2026-05-12-successione-tecnica-conoscenza-tacita",{"title":500,"description":648},"Conoscenza tacita: cosa resta quando te ne vai","successione-tecnica-conoscenza-tacita","blog/2026-05-12-successione-tecnica-conoscenza-tacita",[657,658,659,660,661,662,663],"conoscenza-tacita","gestione-team","leadership","documentazione","successione","cultura-tecnica","bus-factor","i6G1K-EzP4QlOmd81G3t8-jai6wQpyZl0OCUrSnwzrg",1779344577555]