[{"data":1,"prerenderedAt":622},["ShallowReactive",2],{"has-blog-posts":3,"post-segnali-progetto-software-fallira":4,"related-segnali-progetto-software-fallira":162,"datemod-segnali-progetto-software-fallira":144},true,{"id":5,"title":6,"body":7,"category":143,"date":144,"description":145,"extension":146,"image":147,"meta":148,"navigation":3,"path":149,"published":3,"seo":150,"seoTitle":151,"slug":152,"stem":153,"tags":154,"updated":160,"__hash__":161},"blog/blog/2026-05-19-segnali-progetto-software-fallira.md","Segnali che un progetto software fallirà prima di iniziare",{"type":8,"value":9,"toc":131},"minimark",[10,14,17,22,25,28,32,35,38,41,44,48,57,60,64,67,70,74,82,85,89,92,96,99,107,111,114,124],[11,12,13],"p",{},"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,15,16],{},"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.",[18,19,21],"h2",{"id":20},"quando-il-problema-non-è-chiaro","Quando il problema non è chiaro",[11,23,24],{},"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,26,27],{},"Se il problema non è definito, ogni soluzione sarà interpretata. E ogni interpretazione diversa diventa un potenziale conflitto.",[18,29,31],{"id":30},"quando-tutto-sembra-semplice","Quando tutto sembra semplice",[11,33,34],{},"Ci sono richieste che, raccontate a parole, sembrano banali.",[11,36,37],{},"\"Basta prendere questi dati e tirar fuori queste informazioni.\"",[11,39,40],{},"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,42,43],{},"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.",[18,45,47],{"id":46},"quando-una-demo-diventa-una-promessa","Quando una demo diventa una promessa",[11,49,50,51,56],{},"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 ",[52,53,55],"a",{"href":54},"/blog/cos-e-un-mvp-software","trattare l'MVP come un prodotto mal fatto",".",[11,58,59],{},"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.",[18,61,63],{"id":62},"quando-i-limiti-non-vengono-accettati","Quando i limiti non vengono accettati",[11,65,66],{},"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,68,69],{},"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.",[18,71,73],{"id":72},"quando-il-costo-non-torna","Quando il costo \"non torna\"",[11,75,76,77,81],{},"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 ",[52,78,80],{"href":79},"/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,83,84],{},"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.",[18,86,88],{"id":87},"un-disallineamento-di-partenza","Un disallineamento di partenza",[11,90,91],{},"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.",[18,93,95],{"id":94},"fermarsi-prima-costa-meno","Fermarsi prima costa meno",[11,97,98],{},"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,100,101,102,106],{},"E invece la perdita è andare avanti. È lo stesso meccanismo che porta tante ",[52,103,105],{"href":104},"/blog/agenzia-abbandona-progetto-software","agenzie a mollare a metà progetto",": il punto di rottura era già visibile mesi prima.",[18,108,110],{"id":109},"riconoscere-i-segnali-per-quello-che-sono","Riconoscere i segnali per quello che sono",[11,112,113],{},"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,115,116,117,120,121,123],{},"\"Poi si sistema.\"",[118,119],"br",{},"\n\"Partiamo e vediamo.\"",[118,122],{},"\n\"Non sarà così complicato.\"",[11,125,126,127,56],{},"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 ",[52,128,130],{"href":129},"/blog/quando-dire-no-a-un-progetto-software","non tutti i progetti vanno iniziati",{"title":132,"searchDepth":133,"depth":133,"links":134},"",2,[135,136,137,138,139,140,141,142],{"id":20,"depth":133,"text":21},{"id":30,"depth":133,"text":31},{"id":46,"depth":133,"text":47},{"id":62,"depth":133,"text":63},{"id":72,"depth":133,"text":73},{"id":87,"depth":133,"text":88},{"id":94,"depth":133,"text":95},{"id":109,"depth":133,"text":110},"Sviluppo","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.","md","/images/blog/segnali-progetto-software-fallira.jpg",{},"/blog/2026-05-19-segnali-progetto-software-fallira",{"title":6,"description":145},"Progetti software: come riconoscere i segnali di fallimento","segnali-progetto-software-fallira","blog/2026-05-19-segnali-progetto-software-fallira",[155,156,157,158,159],"segnali-fallimento","rischi-progetto","scelta-fornitore","valutazione-progetto","prevenzione",null,"P2WIvcLcSRjXpL5G59BjMdFrp4DeVEnSAiP5ZYw2vmE",[163,283,450],{"id":164,"title":165,"body":166,"category":143,"date":269,"description":270,"extension":146,"image":271,"meta":272,"navigation":3,"path":273,"published":3,"seo":274,"seoTitle":275,"slug":276,"stem":277,"tags":278,"updated":160,"__hash__":282},"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":167,"toc":261},[168,175,178,182,185,188,192,195,198,205,209,212,215,222,226,229,237,241,244,247,251,258],[11,169,170,171,56],{},"C'è un equivoco che torna sempre, soprattutto quando si parla di sviluppo software: ",[172,173,174],"strong",{},"se una cosa si può fare, allora si deve fare",[11,176,177],{},"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.",[18,179,181],{"id":180},"fattibile-non-significa-sostenibile","Fattibile non significa sostenibile",[11,183,184],{},"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,186,187],{},"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.",[18,189,191],{"id":190},"lallineamento-conta-più-del-codice","L'allineamento conta più del codice",[11,193,194],{},"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,196,197],{},"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,199,200,201,56],{},"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 ",[52,202,204],{"href":203},"/blog/scope-creep-progetti-agile","scope creep continuo travestito da agilità",[18,206,208],{"id":207},"il-vero-lavoro-di-un-consulente","Il vero lavoro di un consulente",[11,210,211],{},"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,213,214],{},"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,216,217,218,221],{},"E a un certo punto capisci che il tuo lavoro non si esaurisce nel costruire software: comprende anche ",[172,219,220],{},"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.",[18,223,225],{"id":224},"il-costo-dei-progetti-sbagliati","Il costo dei progetti sbagliati",[11,227,228],{},"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,230,231,232,236],{},"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 ",[52,233,235],{"href":234},"/blog/preventivo-software-partire-dal-budget","partire da una conversazione sul budget invece che da un preventivo"," salva entrambe le parti dal disastro.",[18,238,240],{"id":239},"il-no-come-atto-professionale","Il no come atto professionale",[11,242,243],{},"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,245,246],{},"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.",[18,248,250],{"id":249},"il-segnale-da-leggere","Il segnale da leggere",[11,252,253,254,56],{},"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 ",[52,255,257],{"href":256},"/blog/segnali-progetto-software-fallira","segnali che un progetto software finirà male",[11,259,260],{},"Non tutti i progetti vanno iniziati. E una delle competenze più sottovalutate, in questo mestiere, è saperlo riconoscere prima.",{"title":132,"searchDepth":133,"depth":133,"links":262},[263,264,265,266,267,268],{"id":180,"depth":133,"text":181},{"id":190,"depth":133,"text":191},{"id":207,"depth":133,"text":208},{"id":224,"depth":133,"text":225},{"id":239,"depth":133,"text":240},{"id":249,"depth":133,"text":250},"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":165,"description":270},"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",[158,279,280,157,281],"consulenza-tecnica","segnali-rischio","responsabilita","SfB_bs4o-G7b9tTMLR6IrDBtIDTPLdfh9UlIeWXVKDQ",{"id":284,"title":285,"body":286,"category":143,"date":432,"description":433,"extension":146,"image":434,"meta":435,"navigation":3,"path":436,"published":3,"seo":437,"seoTitle":438,"slug":439,"stem":440,"tags":441,"updated":160,"__hash__":449},"blog/blog/2026-05-12-successione-tecnica-conoscenza-tacita.md","Successione tecnica: cosa si può davvero trasferire a chi viene dopo",{"type":8,"value":287,"toc":422},[288,291,296,299,302,306,309,312,316,319,322,326,329,336,340,343,346,349,353,361,364,368,376,384,388,391,394,398,401,404,407,410,413,416,419],[11,289,290],{},"C’è una domanda che chi guida tecnicamente un team, prima o poi, si fa davvero.",[11,292,293],{},[172,294,295],{},"Se domani me ne vado, cosa resta?",[11,297,298],{},"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,300,301],{},"E non resta non perché hai delegato male. Non resta perché quella parte, semplicemente, non si trasferisce del tutto.",[18,303,305],{"id":304},"il-problema-non-è-la-documentazione","Il problema non è la documentazione",[11,307,308],{},"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,310,311],{},"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.",[18,313,315],{"id":314},"lerrore-è-voler-lasciare-una-copia-di-sé","L’errore è voler lasciare una copia di sé",[11,317,318],{},"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,320,321],{},"È 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.",[18,323,325],{"id":324},"quello-che-puoi-lasciare-davvero","Quello che puoi lasciare davvero",[11,327,328],{},"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,330,331,332,335],{},"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 ",[172,333,334],{},"ragionevoli",". Ed è questo il punto: non perpetuare il tuo gusto, ma costruire un contesto in cui non serva.",[18,337,339],{"id":338},"come-capisci-se-hai-lasciato-un-sistema-o-solo-dipendenza","Come capisci se hai lasciato un sistema o solo dipendenza",[11,341,342],{},"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,344,345],{},"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,347,348],{},"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.",[18,350,352],{"id":351},"il-bus-factor-qui-non-basta","Il bus factor qui non basta",[11,354,355,356,360],{},"Il ",[52,357,359],{"href":358},"/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,362,363],{},"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.",[18,365,367],{"id":366},"la-documentazione-serve-ma-non-fa-miracoli","La documentazione serve, ma non fa miracoli",[11,369,370,371,375],{},"Qui conviene essere onesti. ADR, explanation, reference ben scritta, commit message decenti: tutto questo aiuta moltissimo, e chi ha letto l’articolo su ",[52,372,374],{"href":373},"/blog/ai-codice-commodity-documentazione","il codice come commodity e il perché come asset"," sa già perché.",[11,377,378,379,383],{},"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 ",[380,381,382],"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.",[18,385,387],{"id":386},"il-passaggio-più-difficile-della-carriera-tecnica","Il passaggio più difficile della carriera tecnica",[11,389,390],{},"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,392,393],{},"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.",[18,395,397],{"id":396},"il-conforto-giusto","Il conforto giusto",[11,399,400],{},"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,402,403],{},"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,405,406],{},"Chi verrà dopo non farà il lavoro come lo avresti fatto tu.",[11,408,409],{},"Meno male.",[11,411,412],{},"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.",[414,415],"hr",{},[11,417,418],{},"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,420,421],{},"Puoi però lasciare qualcosa di più utile: un sistema che continui a prendere decisioni ragionevoli anche quando tu non ci sei più.",{"title":132,"searchDepth":133,"depth":133,"links":423},[424,425,426,427,428,429,430,431],{"id":304,"depth":133,"text":305},{"id":314,"depth":133,"text":315},{"id":324,"depth":133,"text":325},{"id":338,"depth":133,"text":339},{"id":351,"depth":133,"text":352},{"id":366,"depth":133,"text":367},{"id":386,"depth":133,"text":387},{"id":396,"depth":133,"text":397},"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":285,"description":433},"Conoscenza tacita: cosa resta quando te ne vai","successione-tecnica-conoscenza-tacita","blog/2026-05-12-successione-tecnica-conoscenza-tacita",[442,443,444,445,446,447,448],"conoscenza-tacita","gestione-team","leadership","documentazione","successione","cultura-tecnica","bus-factor","i6G1K-EzP4QlOmd81G3t8-jai6wQpyZl0OCUrSnwzrg",{"id":451,"title":452,"body":453,"category":143,"date":604,"description":605,"extension":146,"image":606,"meta":607,"navigation":3,"path":608,"published":3,"seo":609,"seoTitle":610,"slug":611,"stem":612,"tags":613,"updated":160,"__hash__":621},"blog/blog/2026-05-07-ai-codice-commodity-documentazione.md","Con l'AI il codice diventa commodity: la documentazione è l'asset",{"type":8,"value":454,"toc":593},[455,458,461,467,471,474,477,480,484,487,498,502,505,508,511,515,518,521,525,528,531,538,542,545,551,554,558,561,564,567,571,574,577,580,584,587,590],[11,456,457],{},"Per anni abbiamo trattato il codice come l’asset principale di un prodotto software. Lo misuravamo, lo difendevamo, lo versionavamo con cura, lo consideravamo il cuore del valore. Se un’azienda aveva tanto codice proprietario, sembrava avere un patrimonio. Se un team produceva tanto codice, sembrava stare costruendo qualcosa di solido.",[11,459,460],{},"Questa idea sta diventando rapidamente falsa. Con gli strumenti AI che ormai fanno parte del lavoro quotidiano — Claude Code, Codex, Cursor e tutto quello che arriverà dopo — il costo di scrivere codice sta scendendo in modo molto netto. Non a zero, ma abbastanza da cambiare la gerarchia delle cose che vale la pena proteggere.",[11,462,463,464,56],{},"Il codice non sparisce. Semplicemente, smette di essere la parte più rara del sistema. La parte rara si sposta altrove: si sposta sul ",[172,465,466],{},"perché",[18,468,470],{"id":469},"il-codice-non-è-più-la-cosa-costosa","Il codice non è più la cosa costosa",[11,472,473],{},"Per capire cosa sta cambiando, basta guardare come lavorava un team anche solo due anni fa. Una nuova feature significava analisi, implementazione, test, rifinitura, refactoring, magari qualche giorno perso su dettagli secondari. Il codice costava tempo, e il tempo costava soldi. Quindi quel codice diventava qualcosa da preservare, da ottimizzare, da non buttare.",[11,475,476],{},"Oggi la situazione è diversa. Un senior con strumenti AI produce in un’ora quello che fino a poco tempo fa richiedeva una giornata. Chi usa davvero questi strumenti lo vede tutti i giorni, e non serve farne una religione per riconoscere che la produttività sulla parte esecutiva è salita tantissimo.",[11,478,479],{},"Quando il costo marginale di produrre codice crolla, il codice si svaluta. Non nel senso che diventa inutile, ma nel senso che diventa meno raro. E quando una cosa diventa meno rara, smette di essere il centro del valore.",[18,481,483],{"id":482},"cosa-resta-raro","Cosa resta raro",[11,485,486],{},"Se il codice si può rigenerare, cosa non si può rigenerare facilmente? Non il repository, non la sintassi, non nemmeno la struttura superficiale del sistema. La cosa davvero difficile da ricostruire è il contesto che ha portato a una decisione: perché quel modulo è fatto così, perché quella dipendenza non è stata sostituita, perché quel flusso apparentemente brutto esiste, perché una soluzione più elegante è stata scartata, perché una certa stranezza non è un errore ma la risposta a un vincolo reale.",[11,488,489,490,493,494,497],{},"Questa roba non vive nel codice. Il codice mostra ",[172,491,492],{},"cosa hai fatto",", molto raramente spiega ",[172,495,496],{},"perché l’hai fatto",". Ed è proprio lì che sta l’asset.",[18,499,501],{"id":500},"il-problema-dei-sistemi-che-nessuno-capisce-più","Il problema dei sistemi che nessuno capisce più",[11,503,504],{},"Chiunque abbia lavorato su un software con qualche anno sulle spalle conosce la scena. Apri un modulo e trovi una scelta strana, e la prima reazione è: “questa cosa va rifatta”. Poi chiedi a chi c’era allora, e scopri che quella scelta era legata a un bug in produzione, a un cliente enorme, a un vincolo fiscale, a un’integrazione esterna assurda, a una limitazione del sistema di allora.",[11,506,507],{},"Quella informazione non era nel codice. Era nella testa di qualcuno. Se quella persona se ne va, il sistema perde valore anche se il repository resta identico.",[11,509,510],{},"Ed è qui che il discorso AI diventa serio: se domani rigeneri quel modulo da capo con un assistente che scrive codice meglio e più velocemente di te, ma non hai il contesto dietro quella scelta, rigeneri qualcosa di più pulito e probabilmente più sbagliato. Il rischio vero è perdere il motivo per cui il codice era fatto in quel modo, più che il codice stesso.",[18,512,514],{"id":513},"il-perché-è-lunica-cosa-che-sopravvive-alla-riscrittura","Il perché è l’unica cosa che sopravvive alla riscrittura",[11,516,517],{},"Questa è la vera inversione. Per anni abbiamo pensato: il codice è l’asset, la documentazione è un costo. Oggi il rapporto si sta ribaltando: il codice si può rigenerare, il perché no. O meglio: il perché si può ricostruire solo se qualcuno lo ha registrato mentre prendeva la decisione. Se non l’ha fatto, sparisce. E quando sparisce, il progetto entra in modalità archeologia.",[11,519,520],{},"Ogni modifica diventa più lenta, ogni refactoring è più rischioso, ogni nuovo ingresso nel team richiede mesi, ogni AI lavora su un sistema formalmente leggibile ma sostanzialmente muto. Il codice di oggi serve a produrre il software di oggi; il perché di oggi serve a produrre il software di domani.",[18,522,524],{"id":523},"ecco-perché-la-documentazione-smette-di-essere-overhead","Ecco perché la documentazione smette di essere “overhead”",[11,526,527],{},"Qui bisogna intendersi: non sto parlando della wiki aziendale piena di pagine morte che nessuno apre da mesi. Quella è arredamento, non documentazione.",[11,529,530],{},"Sto parlando di artefatti che catturano decisioni mentre sono ancora vive: un ADR scritto bene, che spiega quale scelta architetturale è stata fatta e perché; una sezione di explanation che chiarisce il contesto di un modulo; un commit message che non dice “fix bug”, ma spiega quale problema reale è stato corretto e cosa si è scelto di non fare. Queste cose sembrano piccole, in realtà sono l’unico modo per conservare il valore vero del sistema.",[11,532,533,534,537],{},"Diátaxis è utile proprio per questo: perché separa i tipi di documentazione e impedisce di mischiare tutto in un blob inutile. Ma il framework, in fondo, è secondario. Il punto è un altro: ",[172,535,536],{},"il contesto va estratto dalle teste e messo accanto al codice",". Altrimenti, alla prima riscrittura seria, lo perdi.",[18,539,541],{"id":540},"il-cambiamento-strategico-per-chi-decide","Il cambiamento strategico per chi decide",[11,543,544],{},"Se questa lettura è corretta, cambia anche il modo in cui un’azienda dovrebbe investire. Per anni il budget è andato quasi tutto nella produzione di codice; la documentazione, quando andava bene, era il 5% del lavoro. Il ragionamento era semplice: il codice è il prodotto, il resto è supporto.",[11,546,547,548,56],{},"Ora quel ragionamento non regge più. Il codice conta ancora, ovviamente: un codice scritto male resta un problema. Ma il punto non è se il codice conta. Il punto è ",[172,549,550],{},"cosa conviene proteggere di più",[11,552,553],{},"E oggi conviene proteggere il contesto decisionale, perché è quello che non puoi ricomprare dopo: non con un altro team, non con un assistente AI, non con una settimana di reverse engineering. Se un’azienda accumula per anni comprensione del dominio, eccezioni dei clienti, vincoli normativi, ragioni dietro le scelte, e lascia tutto dentro le teste dei senior, sta trattando come sottoprodotto il suo asset principale.",[18,555,557],{"id":556},"i-due-errori-ugualmente-pericolosi","I due errori ugualmente pericolosi",[11,559,560],{},"Qui vedo due estremi. Il primo è continuare come prima: trattare il codice come patrimonio duraturo, sottovalutare la documentazione, lasciare che le decisioni restino implicite. È l’errore più diffuso, e il più costoso nel medio periodo.",[11,562,563],{},"Il secondo è l’errore opposto: pensare che allora basti documentare tutto e lasciare il resto all’AI. Neanche questo funziona, perché il fatto che il codice si svaluti non significa che il gusto tecnico si svaluti. Anzi: se hai persone che non sanno riconoscere una buona decisione da una cattiva, documenteranno male, leggeranno male la documentazione, useranno male l’AI e produrranno rumore a velocità maggiore.",[11,565,566],{},"Il codice diventa commodity, il giudizio no. Il perché diventa asset, ma solo se c’è qualcuno capace di scriverlo, leggerlo e rimetterlo in discussione quando serve.",[18,568,570],{"id":569},"dove-conviene-investire-oggi","Dove conviene investire oggi",[11,572,573],{},"Se dovessi semplificarlo brutalmente, direi così: meno energia nel proteggere il codice come oggetto da museo, più energia nel catturare il contesto che permette di rigenerarlo bene.",[11,575,576],{},"Questo significa scrivere ADR per le decisioni che contano davvero, non per ogni dettaglio. Significa tenere una explanation documentata per i moduli strani o sensibili, e una reference accurata dove serve sul serio. Significa scrivere commit e pull request che spieghino il motivo del cambiamento, non solo il cambiamento; e fare review che valutino anche la qualità del ragionamento, non solo la qualità del codice.",[11,578,579],{},"Sembrano dettagli. In realtà sono la differenza tra un sistema che può essere rigenerato e uno che deve essere scavato.",[18,581,583],{"id":582},"la-scelta-si-fa-adesso","La scelta si fa adesso",[11,585,586],{},"Il modo in cui un team documenta oggi determina quanto sarà facile usare bene l’AI tra uno, due o tre anni. Chi avrà contesto ben catturato potrà rigenerare velocemente codice buono; chi avrà solo montagne di codice e poco perché dovrà prima ricostruire la storia del sistema, e quella parte sarà lenta, costosa e piena di errori.",[11,588,589],{},"La scelta, in fondo, è molto semplice. Puoi continuare a trattare il codice come il bene da proteggere, oppure puoi iniziare a proteggere quello che rende il codice sostituibile senza perdere il sistema.",[11,591,592],{},"Il codice è il cosa di oggi. Il perché è il capitale che ti permette di ricostruire il cosa domani.",{"title":132,"searchDepth":133,"depth":133,"links":594},[595,596,597,598,599,600,601,602,603],{"id":469,"depth":133,"text":470},{"id":482,"depth":133,"text":483},{"id":500,"depth":133,"text":501},{"id":513,"depth":133,"text":514},{"id":523,"depth":133,"text":524},{"id":540,"depth":133,"text":541},{"id":556,"depth":133,"text":557},{"id":569,"depth":133,"text":570},{"id":582,"depth":133,"text":583},"2026-05-07","Con l'AI il costo di scrivere codice crolla. Quello che resta davvero raro è il perché delle decisioni: architettura, trade-off, vincoli, contesto.","/images/blog/ai-codice-commodity-documentazione.jpg",{},"/blog/2026-05-07-ai-codice-commodity-documentazione",{"title":452,"description":605},"AI e sviluppo software: il codice si svaluta, il contesto no","ai-codice-commodity-documentazione","blog/2026-05-07-ai-codice-commodity-documentazione",[614,445,615,616,617,618,619,620],"ai","strategia","architettura","adr","diataxis","debito-tecnico","futuro-del-software","3G6lTUKmqd5iGfk6RX9n17tR1qo8G8g5qqa6ZZlyquQ",1779171758161]