[{"data":1,"prerenderedAt":636},["ShallowReactive",2],{"has-blog-posts":3,"post-ai-codice-commodity-documentazione":4,"related-ai-codice-commodity-documentazione":206,"datemod-ai-codice-commodity-documentazione":185},true,{"id":5,"title":6,"body":7,"category":184,"date":185,"description":186,"extension":187,"image":188,"meta":189,"navigation":3,"path":190,"published":3,"seo":191,"seoTitle":192,"slug":193,"stem":194,"tags":195,"updated":204,"__hash__":205},"blog/blog/2026-05-07-ai-codice-commodity-documentazione.md","Con l'AI il codice diventa commodity: la documentazione è l'asset",{"type":8,"value":9,"toc":171},"minimark",[10,14,17,25,30,33,36,39,43,46,57,61,64,67,70,74,77,80,84,87,90,97,101,104,110,113,117,120,123,126,130,133,136,155,158,162,165,168],[11,12,13],"p",{},"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,15,16],{},"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,18,19,20,24],{},"Il codice non sparisce. Semplicemente, smette di essere la parte più rara del sistema. La parte rara si sposta altrove: si sposta sul ",[21,22,23],"strong",{},"perché",".",[26,27,29],"h2",{"id":28},"il-codice-non-è-più-la-cosa-costosa","Il codice non è più la cosa costosa",[11,31,32],{},"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,34,35],{},"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,37,38],{},"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.",[26,40,42],{"id":41},"cosa-resta-raro","Cosa resta raro",[11,44,45],{},"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,47,48,49,52,53,56],{},"Questa roba non vive nel codice. Il codice mostra ",[21,50,51],{},"cosa hai fatto",", molto raramente spiega ",[21,54,55],{},"perché l’hai fatto",". Ed è proprio lì che sta l’asset.",[26,58,60],{"id":59},"il-problema-dei-sistemi-che-nessuno-capisce-più","Il problema dei sistemi che nessuno capisce più",[11,62,63],{},"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,65,66],{},"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,68,69],{},"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.",[26,71,73],{"id":72},"il-perché-è-lunica-cosa-che-sopravvive-alla-riscrittura","Il perché è l’unica cosa che sopravvive alla riscrittura",[11,75,76],{},"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,78,79],{},"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.",[26,81,83],{"id":82},"ecco-perché-la-documentazione-smette-di-essere-overhead","Ecco perché la documentazione smette di essere “overhead”",[11,85,86],{},"Qui bisogna intendersi: non sto parlando della wiki aziendale piena di pagine morte che nessuno apre da mesi. Quella è arredamento, non documentazione.",[11,88,89],{},"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,91,92,93,96],{},"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: ",[21,94,95],{},"il contesto va estratto dalle teste e messo accanto al codice",". Altrimenti, alla prima riscrittura seria, lo perdi.",[26,98,100],{"id":99},"il-cambiamento-strategico-per-chi-decide","Il cambiamento strategico per chi decide",[11,102,103],{},"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,105,106,107,24],{},"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 è ",[21,108,109],{},"cosa conviene proteggere di più",[11,111,112],{},"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.",[26,114,116],{"id":115},"i-due-errori-ugualmente-pericolosi","I due errori ugualmente pericolosi",[11,118,119],{},"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,121,122],{},"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,124,125],{},"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.",[26,127,129],{"id":128},"dove-conviene-investire-oggi","Dove conviene investire oggi",[11,131,132],{},"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,134,135],{},"Questo significa:",[137,138,139,143,146,149,152],"ul",{},[140,141,142],"li",{},"ADR per le decisioni vere, non per ogni dettaglio",[140,144,145],{},"explanation documentata per i moduli strani o sensibili",[140,147,148],{},"reference accurata dove serve davvero",[140,150,151],{},"commit e pull request che spieghino il motivo del cambiamento, non solo il cambiamento",[140,153,154],{},"review che valutino anche la qualità del ragionamento, non solo del codice",[11,156,157],{},"Sembrano dettagli. In realtà sono la differenza tra un sistema che può essere rigenerato e uno che deve essere scavato.",[26,159,161],{"id":160},"la-scelta-si-fa-adesso","La scelta si fa adesso",[11,163,164],{},"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,166,167],{},"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,169,170],{},"Il codice è il cosa di oggi. Il perché è il capitale che ti permette di ricostruire il cosa domani.",{"title":172,"searchDepth":173,"depth":173,"links":174},"",2,[175,176,177,178,179,180,181,182,183],{"id":28,"depth":173,"text":29},{"id":41,"depth":173,"text":42},{"id":59,"depth":173,"text":60},{"id":72,"depth":173,"text":73},{"id":82,"depth":173,"text":83},{"id":99,"depth":173,"text":100},{"id":115,"depth":173,"text":116},{"id":128,"depth":173,"text":129},{"id":160,"depth":173,"text":161},"Sviluppo","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.","md","/images/blog/ai-codice-commodity-documentazione.jpg",{},"/blog/2026-05-07-ai-codice-commodity-documentazione",{"title":6,"description":186},"AI e sviluppo software: il codice si svaluta, il contesto no","ai-codice-commodity-documentazione","blog/2026-05-07-ai-codice-commodity-documentazione",[196,197,198,199,200,201,202,203],"ai","documentazione","strategia","architettura","adr","diataxis","debito-tecnico","futuro-del-software",null,"taiwaYV7ebj8GD-3dcq2NPGnbZz0u1Z4_nt_z-e_4bg",[207,406,516],{"id":208,"title":209,"body":210,"category":184,"date":390,"description":391,"extension":187,"image":392,"meta":393,"navigation":3,"path":394,"published":3,"seo":395,"seoTitle":396,"slug":397,"stem":398,"tags":399,"updated":204,"__hash__":405},"blog/blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo.md","Bus factor reale: come misurarlo davvero e costruire un secondo",{"type":8,"value":211,"toc":379},[212,225,228,232,235,242,245,248,252,255,261,274,277,281,284,287,291,294,297,301,304,307,313,316,319,323,326,329,340,344,347,350,353,357,360,363,366,370,373,376],[11,213,214,215,220,221,224],{},"In un articolo precedente ho spiegato perché il ",[216,217,219],"a",{"href":218},"/blog/bus-factor-developer-indispensabile","bus factor è una delle metriche di rischio più ignorate nello sviluppo software",". Questo articolo parte da lì, ma va un passo oltre: non tanto perché il bus factor conta — quello ormai dovrebbe essere chiaro — ma ",[21,222,223],{},"come si misura davvero",". Perché il numero che quasi tutti hanno in testa è quasi sempre falso.",[11,226,227],{},"Il motivo è semplice. Quando un team guarda sé stesso da dentro, tende a sovrastimare quanto la conoscenza sia distribuita. Quattro sviluppatori che lavorano sullo stesso progetto sembrano un bus factor di quattro. Sulla carta è rassicurante. Nella pratica, spesso è uno.",[26,229,231],{"id":230},"il-bus-factor-che-racconti-e-quello-che-hai-davvero","Il bus factor che racconti e quello che hai davvero",[11,233,234],{},"Il bus factor apparente è facile da raccontare. Si calcola così: quante persone lavorano sul progetto? Quante sanno aprire il repository, fare una modifica, chiudere un bug, scrivere una feature? Se la risposta è “quattro”, allora ci si convince che il rischio sia basso.",[11,236,237,238,241],{},"Il bus factor reale è un’altra cosa. La domanda giusta non è “quante persone sanno contribuire?”, ma ",[21,239,240],{},"quante persone possono tenere in piedi il progetto da sole quando succede qualcosa di non previsto?"," Non eseguire task già definiti, non fare il compitino assegnato, non portare avanti il lavoro finché tutto fila liscio. Sto parlando di decidere: che trade-off fare, dove mettere mano, cosa sacrificare, come spiegare la scelta allo stakeholder, come tenere insieme il tutto quando il progetto si piega sotto un problema vero. Lì il numero si abbassa brutalmente.",[11,243,244],{},"Nella maggior parte dei team c’è una persona che tiene in testa il sistema intero. Le altre conoscono bene le parti su cui lavorano, abbastanza quelle adiacenti, poco o nulla il resto. Finché il lavoro è ordinario, sembra che tutto funzioni. Quando arriva l’imprevisto, tutti tornano da quella persona.",[11,246,247],{},"Quella persona è il tuo bus factor reale.",[26,249,251],{"id":250},"il-test-che-non-perdona","Il test che non perdona",[11,253,254],{},"Il modo migliore per capire se ti stai raccontando una favola è molto semplice: sparisci per una settimana. Non ferie vere, non “scrivimi se succede qualcosa di grave”. Proprio una settimana in cui, su quel progetto, tu non ci sei, e le decisioni vanno prese senza di te.",[11,256,257,258],{},"Il punto non è se qualcuno ti cerca — quello succederà comunque. Il punto è un altro: ",[21,259,260],{},"al tuo ritorno trovi decisioni già prese oppure una pila di cose lasciate in sospeso perché “dovevi vederle tu”?",[11,262,263,264,267,268,270,271,273],{},"Se trovi la seconda, il tuo bus factor è 1.",[265,266],"br",{},"\nAnche se il team è di cinque persone.",[265,269],{},"\nAnche se tutti sono bravi.",[265,272],{},"\nAnche se il progetto “va bene”.",[11,275,276],{},"Questo è il test che separa la ridondanza reale dalla semplice sensazione di avere una squadra.",[26,278,280],{"id":279},"il-bug-notturno-è-sempre-più-sincero-dei-processi","Il bug notturno è sempre più sincero dei processi",[11,282,283],{},"C’è un altro momento in cui il bus factor smette di mentire: il problema notturno. Se alle due di notte succede qualcosa in produzione, quante persone possono davvero diagnosticare il problema e risolverlo? Non alzare il telefono e farsi guidare, non “tamponare finché domani si vede”. Risolverlo.",[11,285,286],{},"È lì che capisci quanta conoscenza del sistema è superficiale e quanta invece è strutturale. Molti team scoprono in quel momento che il loro progetto è, di fatto, una monarchia tecnica travestita da organizzazione distribuita.",[26,288,290],{"id":289},"il-sintomo-più-sottovalutato-lonboarding","Il sintomo più sottovalutato: l’onboarding",[11,292,293],{},"C’è poi un test ancora più subdolo, perché non ha il pathos del bug in produzione ma dice la verità con la stessa precisione: il tempo che serve a una persona senior per diventare operativa.",[11,295,296],{},"Se domani entra qualcuno molto bravo, quanto ci mette a muoversi sul progetto senza appoggiarsi continuamente alla stessa persona? Se la risposta vera è “mesi”, allora la conoscenza è ancora quasi tutta in una testa sola. Se invece in due settimane riesce a orientarsi leggendo, facendo qualche domanda e prendendo mano ai moduli giusti, vuol dire che una parte della conoscenza è stata esternalizzata. Ed è lì che entra in gioco la documentazione fatta bene.",[26,298,300],{"id":299},"la-documentazione-aiuta-quella-finta-no","La documentazione aiuta. Quella finta no.",[11,302,303],{},"Qui serve una distinzione brutale. La documentazione non alza il bus factor solo perché esiste una wiki: quella roba, nella maggior parte dei casi, serve solo a far sentire il team più ordinato di quanto sia davvero. La documentazione utile è quella che permette a qualcuno di entrare, capire e fare, non quella che spiega genericamente il sistema con belle parole e diagrammi dimenticati da sei mesi.",[11,305,306],{},"Il principio giusto è semplice: una documentazione sana separa le cose per quello che sono. C’è la parte che ti aiuta a capire il perché, quella che ti dice come fare una cosa specifica, quella che ti serve da riferimento quando cerchi un dettaglio preciso. Mischiare tutto nello stesso documento produce solo confusione.",[11,308,309,310,24],{},"Il nome del framework conta relativamente. Il punto vero è un altro: ",[21,311,312],{},"la conoscenza deve uscire dalle teste e finire in artefatti che qualcuno può usare davvero",[11,314,315],{},"Il problema è che la documentazione decade. Sempre. Oggi è corretta, tra diciotto mesi no. E decade nel modo peggiore: in silenzio. Nessuno se ne accorge finché qualcuno prova a seguirla e si schianta.",[11,317,318],{},"Per questo la documentazione non va trattata come un progetto a parte da fare “quando c’è tempo”. Va trattata come parte del lavoro normale. Se cambi il sistema e non aggiorni la documentazione che serve a capirlo, stai solo spostando il problema in avanti.",[26,320,322],{"id":321},"perché-il-bus-factor-resta-basso-anche-nei-team-forti","Perché il bus factor resta basso anche nei team forti",[11,324,325],{},"Questo è il punto che confonde più persone. Puoi avere un team bravo, serio, capace, e avere comunque un bus factor reale di 1. Perché contribuire bene non significa poter sostituire davvero: sono due cose diverse.",[11,327,328],{},"Un team funziona quando ognuno sa fare bene il proprio pezzo. Il bus factor sale quando almeno un’altra persona sa fare anche il tuo. E questo richiede un investimento esplicito, che spesso non si fa perché sembra inefficiente: in apparenza è uno spreco, stai chiedendo a qualcuno di imparare cose che già un altro sa fare. In realtà è esattamente il contrario. Stai pagando ridondanza oggi per non trovarti paralizzato domani.",[11,330,331,332,339],{},"Il problema è che questo investimento andrebbe fatto proprio dalla persona più sovraccarica del sistema. E quella persona, quasi sempre, non ha tempo. È lo stesso meccanismo che ho raccontato in ",[216,333,335],{"href":334},"/blog/troppi-ruoli-una-persona-rischio",[336,337,338],"em",{},"Quando una persona copre troppi ruoli, l’organizzazione è fragile",": il sistema dipende da qualcuno proprio perché quel qualcuno non ha mai avuto il margine per costruire un’alternativa.",[26,341,343],{"id":342},"costruire-un-secondo-non-significa-passare-task","Costruire un secondo non significa passare task",[11,345,346],{},"Qui c’è l’errore più comune. Molti pensano che costruire un secondo significhi iniziare a distribuire lavoro. Non basta: passare task produce supporto operativo, non ridondanza reale.",[11,348,349],{},"Se vuoi costruire un secondo, devi dare a qualcuno un pezzo intero di sistema. Un’area con responsabilità vera. Qualcosa su cui quella persona debba decidere, sbagliare, capire, difendere scelte e portarne il peso. Se continui a dare compiti singoli, il modello mentale resta nel tuo cervello: l’altra persona impara a eseguire, non a sostituire.",[11,351,352],{},"Poi c’è il passaggio più difficile: smettere di correggere tutto. All’inizio la review serve. Poi arriva un punto in cui tu continui a rivedere tutto solo per rassicurarti, e lì la review smette di essere uno strumento di qualità e diventa una tassa sulla crescita dell’altro. Il momento in cui capisci che stai facendo sul serio è questo: l’altra persona prende una decisione diversa da quella che avresti preso tu, ma ragionevole. Se la tua reazione è correggerla comunque, non stai costruendo un secondo. Stai costruendo una copia minore di te.",[26,354,356],{"id":355},"da-1-a-2-cambia-quasi-tutto","Da 1 a 2 cambia quasi tutto",[11,358,359],{},"Non serve inseguire la perfezione. Non serve un bus factor di 5 ovunque. Nella maggior parte dei casi, la vera soglia è passare da 1 a 2 sulle parti critiche.",[11,361,362],{},"Con una sola persona, l’indisponibilità è un rischio costante. Con due, la resilienza cambia drasticamente. Non in modo lineare: proprio di ordine di grandezza.",[11,364,365],{},"È qui che molte aziende sbagliano. Vedono la costruzione del “secondo” come un lusso organizzativo. In realtà è una forma di assicurazione. Costa prima, salva dopo.",[26,367,369],{"id":368},"il-punto-di-partenza-se-il-tuo-bus-factor-è-1","Il punto di partenza, se il tuo bus factor è 1",[11,371,372],{},"Se leggendo questo articolo ti sei reso conto che il tuo progetto gira davvero intorno a una sola persona, non serve fare teorie. Serve iniziare da qualcosa di estremamente concreto.",[11,374,375],{},"Scegli una persona specifica. Non “il team”, non “nei prossimi mesi distribuiremo meglio la conoscenza”. Una persona con nome e cognome. Dagli un’area precisa. Lasciale prendere decisioni. Lasciale sbagliare in modo controllato. Costringiti a non intervenire su tutto. Poi pianifica la settimana in cui non ci sarai.",[11,377,378],{},"Perché finché non fai quel test, puoi raccontarti quello che vuoi. Il bus factor, come la sicurezza o il debito tecnico, sembra sotto controllo finché non lo metti davvero alla prova. E quando cede, di solito cede tutto insieme.",{"title":172,"searchDepth":173,"depth":173,"links":380},[381,382,383,384,385,386,387,388,389],{"id":230,"depth":173,"text":231},{"id":250,"depth":173,"text":251},{"id":279,"depth":173,"text":280},{"id":289,"depth":173,"text":290},{"id":299,"depth":173,"text":300},{"id":321,"depth":173,"text":322},{"id":342,"depth":173,"text":343},{"id":355,"depth":173,"text":356},{"id":368,"depth":173,"text":369},"2026-05-05","Il bus factor apparente quasi sempre inganna: nella maggior parte dei team è 1. Come capire quello reale e alzarlo senza allargare il team.","/images/blog/bus-factor-reale-come-misurarlo-e-alzarlo.jpg",{},"/blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo",{"title":209,"description":391},"Come calcolare e alzare il bus factor nello sviluppo software","bus-factor-reale-come-misurarlo-e-alzarlo","blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo",[400,401,402,197,403,404],"bus-factor","gestione-team","rischio","delega","organizzazione","8jZciW65ZitXOJQ89-xTYOZSttNrjOaHsSPvVsXQAQY",{"id":407,"title":408,"body":409,"category":184,"date":503,"description":504,"extension":187,"image":505,"meta":506,"navigation":3,"path":507,"published":3,"seo":508,"seoTitle":509,"slug":510,"stem":511,"tags":512,"updated":204,"__hash__":515},"blog/blog/2026-04-30-codice-funziona-non-significa-buona-idea.md","Il codice funziona. Non significa che sia una buona idea.",{"type":8,"value":410,"toc":496},[411,417,421,424,427,430,434,437,440,443,447,455,463,471,475,478,486,490,493],[11,412,413,416],{},[21,414,415],{},"Uno sviluppatore di medio livello entra in un progetto nuovo."," Invece di passare le prime settimane a capire il codice esistente e come funziona il dominio, apre un assistente AI e inizia a produrre feature. I ticket si chiudono, le pull request arrivano, i test passano. Tutto sembra ottimo. Dopo un mese, i numeri parlano: questa persona produce il doppio di chi è entrato con lo stesso ruolo un anno fa. Un anno fa sarebbe stato un mezzo disastro, oggi sembra una notizia entusiasmante. Non lo è, e la differenza tra le due cose si paga in produzione.",[26,418,420],{"id":419},"una-scena-che-si-ripete","Una scena che si ripete",[11,422,423],{},"In un punto del prodotto c'è un'operazione che, quando l'utente salva, deve aspettare un calcolo in background prima di aggiornare una parte della pagina. Ci sono due modi ovvi di farlo. Il primo: aspettare qualche decimo di secondo in più, salvare, rileggere il dato, mostrarlo. Venti righe di codice. Il secondo: salvare subito, far girare il calcolo in modo asincrono, notificare la pagina quando il calcolo finisce e aggiornare il DOM in tempo reale. Un sistema di code, un canale di notifica real-time al browser, logica di reconnect, gestione degli stati intermedi. È anche molto più interessante da scrivere.",[11,425,426],{},"Lo sviluppatore sceglie il secondo. L'AI lo aiuta, il codice esce pulito, ordinato, testato, e la PR passa la review. Arriva in produzione e non succede nulla. Per qualche settimana.",[11,428,429],{},"Il problema emerge dopo: il calcolo in background, nel sistema reale, non dura mezzo secondo. Dura minuti, a volte ore — il backend lo gestisce in una coda che dipende dal carico. Nel frattempo l'utente ha cambiato pagina, aperto altro, riaperto lo stesso schermo in un'altra scheda. Quando finalmente la notifica arriva, trova un DOM che non esiste più, o peggio ne aggiorna uno che non doveva aggiornare. L'utente vede la pagina rompersi in modo incomprensibile. A volte perde dati.",[26,431,433],{"id":432},"lerrore-non-era-nel-codice","L'errore non era nel codice",[11,435,436],{},"Il codice era scritto decentemente. La review non ha trovato nulla perché tecnicamente era tutto corretto. L'errore era una scelta architetturale che nessuno ha mai discusso esplicitamente: non serviva un sistema real-time per un problema che si risolveva aspettando mezzo secondo al salvataggio. La soluzione semplice era anche quella giusta, la soluzione sofisticata ha introdotto una classe di bug che nel modello banale non poteva nemmeno esistere.",[11,438,439],{},"Lo sviluppatore non l'ha visto perché non conosceva ancora il prodotto — era da poco sul progetto e aveva saltato la fase di studio. Non sapeva che quei calcoli potevano durare ore, non aveva osservato come gli utenti usavano davvero quella pagina. L'AI non poteva vederlo: ha risposto alla domanda \"come aggiorno una pagina in modo asincrono\" con la risposta più sofisticata disponibile, non con quella più adatta al contesto. Nessuno dei due aveva il contesto, e il contesto è l'unica cosa che l'AI non può ricostruire da sola.",[11,441,442],{},"La review non l'ha intercettato per un motivo strutturale: una PR review guarda il codice, non l'architettura. Controlla che i test passino, che lo stile sia giusto, che non ci siano errori evidenti. Raramente chiede \"ma serviva davvero fare così?\". Quando il codice è pulito e viene da qualcuno che usa l'AI, la review diventa ancora meno sensibile, perché quel codice è indistinguibile da qualsiasi altro codice dello stesso tipo.",[26,444,446],{"id":445},"velocità-di-produzione-superficie-di-decisioni","Velocità di produzione, superficie di decisioni",[11,448,449,450,454],{},"Questa non è una scena isolata. È quello che sta succedendo in tantissimi team che hanno adottato l'AI senza ripensare come lavorano. ",[216,451,453],{"href":452},"/blog/sviluppare-con-ai","La produttività sale"," ed è facilmente misurabile: più PR, più ticket chiusi, più codice in arrivo. Sotto la superficie si accumulano scelte architetturali che nessuno ha mai vagliato, e ognuna di quelle scelte è una piccola bomba a tempo.",[11,456,457,458,462],{},"La bomba non esplode nelle settimane di sviluppo. Esplode in produzione, mesi dopo, quando gli utenti iniziano a segnalare ",[216,459,461],{"href":460},"/blog/software-fragile-regressioni","bug che si moltiplicano quando tocchi qualcosa",", data loss a bassa frequenza ma alto impatto, comportamenti strani che in ambiente di test non si riproducono. Casi limite che non corrispondono mai alla documentazione, perché la documentazione non esiste: chi ha scritto il codice non aveva tempo, e l'AI lo ha seguito sulla velocità.",[11,464,465,466,470],{},"Il costo lo paga chi ha commissionato il software. Lo paga nel crescere dei ticket di produzione, nei tempi di risposta del team su problemi che \"non capiamo da dove vengano\", nel momento in cui qualcuno deve ",[216,467,469],{"href":468},"/blog/riscrivere-software-da-zero","smantellare un'architettura inutilmente complicata e rimetterla semplice"," — una seconda volta, con un altro team.",[26,472,474],{"id":473},"lai-amplifica-quello-che-già-cè","L'AI amplifica quello che già c'è",[11,476,477],{},"L'AI nelle mani di uno sviluppatore senior amplifica il giudizio: chi già sa riconoscere quando una soluzione semplice batte una soluzione impressionante usa l'AI per andare più veloce su quella strada. L'AI nelle mani di uno sviluppatore meno esperto amplifica l'ottimismo: la fiducia che, siccome il codice funziona nei test, allora la soluzione è giusta. Più aumenta la velocità con cui il team produce, più aumenta la superficie di decisioni non controllate.",[11,479,480,481,485],{},"La contromisura non è togliere l'AI al team, cosa che nessuna azienda con un minimo di senso farà. È cambiare il criterio con cui si valuta il lavoro. Il mestiere oggi non è produrre codice: quello l'AI lo fa in fretta, pulito, spesso meglio di un umano. Il mestiere è capire il problema, scegliere la ",[216,482,484],{"href":483},"/blog/semplicita-nel-software","soluzione più semplice che risolve davvero",", proteggere le scelte architetturali nei momenti in cui conta farlo.",[26,487,489],{"id":488},"la-domanda-da-fare-al-team","La domanda da fare al team",[11,491,492],{},"Chi guida o commissiona un team che usa l'AI dovrebbe smettere di chiedere \"quanto producete in uno sprint?\" e iniziare a chiedere \"quanto di quello che avete prodotto negli ultimi tre mesi pensate di tenere tra un anno?\". È la domanda che filtra la velocità utile dalla velocità pericolosa. Oggi molti team non sanno rispondere, o peggio rispondono \"tutto\" senza averci pensato sopra.",[11,494,495],{},"Il fatto che il codice funzioni non significa che sia una buona idea. È una distinzione che l'AI ha reso molto più importante, perché il codice che funziona ma è una cattiva idea oggi si produce dieci volte più in fretta di prima. In produzione si paga esattamente uguale.",{"title":172,"searchDepth":173,"depth":173,"links":497},[498,499,500,501,502],{"id":419,"depth":173,"text":420},{"id":432,"depth":173,"text":433},{"id":445,"depth":173,"text":446},{"id":473,"depth":173,"text":474},{"id":488,"depth":173,"text":489},"2026-04-30","Con l'AI i team chiudono più ticket e producono più PR. Ma 'funziona nei test' non dice se la decisione architetturale era quella giusta — e il conto arriva in produzione.","/images/blog/codice-funziona-non-significa-buona-idea.jpg",{},"/blog/2026-04-30-codice-funziona-non-significa-buona-idea",{"title":408,"description":504},"Codice che funziona ma è sbagliato: il rischio dell'AI nei team","codice-funziona-non-significa-buona-idea","blog/2026-04-30-codice-funziona-non-significa-buona-idea",[196,199,513,514,202,401],"qualita-codice","code-review","S9dwvPH4gBOQB7bWM_hOf_UjWPuDhtH69y7hZihINoA",{"id":517,"title":518,"body":519,"category":184,"date":620,"description":621,"extension":187,"image":622,"meta":623,"navigation":3,"path":624,"published":3,"seo":625,"seoTitle":626,"slug":627,"stem":628,"tags":629,"updated":204,"__hash__":635},"blog/blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo.md","L'AI progetta il software in cinque minuti. Costruirlo richiede ancora sei mesi.",{"type":8,"value":520,"toc":612},[521,527,531,534,537,541,544,547,551,558,561,565,568,576,579,583,586,594,602,606,609],[11,522,523,526],{},[21,524,525],{},"Hai un'idea di prodotto."," La racconti a ChatGPT, Claude o al modello di turno. Dopo qualche scambio ottieni un documento tecnico: architettura a box, database vettoriale, pipeline di ingestion dei dati, i nomi di ogni tecnologia al posto giusto. Sembra un deliverable da studio di consulenza. Arrivi con quel documento a chiedere un preventivo, con un budget di qualche migliaio di euro in testa. E qualcuno ti deve spiegare che il progetto descritto in quel documento costa uno zero in più. È la scena più comune degli ultimi mesi, e quella che due anni fa non esisteva.",[26,528,530],{"id":529},"il-pattern-si-ripete","Il pattern si ripete",[11,532,533],{},"Negli anni 2000 bastavano 3.000 euro per chiedere \"un sito come Amazon\" anzi, a dire il vero \"un sito come eBay\", senza nessuna idea di cosa significasse costruire un e-commerce a quella scala. Poi è toccato a \"un'app come Airbnb\" con WordPress e plugin, poi a \"una piattaforma no-code in un weekend\". Oggi la cifra richiesta è simile — tipicamente tra i 2 e i 5K — ma l'idea coinvolge tecnologie che fino a ieri richiedevano mezza Silicon Valley per essere tenute in piedi: database vettoriali, modelli linguistici in API, pipeline di OCR, crawler distribuiti.",[11,535,536],{},"Ogni generazione di astrazioni produce lo stesso effetto: la superficie diventa accessibile, il sotto resta un casino. Chi sta sopra non lo vede finché non ci sbatte la testa. L'AI ha semplicemente spinto l'astrazione un piano più in alto, e il divario tra aspettativa e realtà di sviluppo è diventato più grande di quanto sia mai stato.",[26,538,540],{"id":539},"cosa-fa-davvero-lai-quando-progetta-un-software","Cosa fa davvero l'AI quando \"progetta un software\"",[11,542,543],{},"Un modello linguistico mette in fila nomi che sembrano pertinenti. Prende la descrizione del tuo problema, la associa a pattern visti in miliardi di documenti tecnici, produce un diagramma plausibile. Postgres con pgvector, crawler headless, modelli in API, microservizi dove servono, pipeline di OCR per i documenti. Frecce giuste, box giusti. A colpo d'occhio è indistinguibile dal lavoro di un professionista con anni di esperienza alle spalle.",[11,545,546],{},"Il problema è che il modello non ha mai messo un sistema del genere in produzione. Non sa che l'OCR su un documento sporco rende una volta su tre. Non sa che fare web scraping è complesso perchè il sito può cambiare struttura senza preavviso, o mettere una protezione antibot. Non sa che il 70% del costo di un sistema come quello che ha disegnato non è nel codice: è nella pulizia dei dati, nella manutenzione continua delle regole di business, nella difficoltà quotidiana di tenere aggiornato un database che descrive un mondo che cambia.",[26,548,550],{"id":549},"lottimismo-strutturale-dei-modelli","L'ottimismo strutturale dei modelli",[11,552,553,554,24],{},"C'è un'altra caratteristica importante di come rispondono questi modelli. L'AI dice quasi sempre che si può fare. La domanda \"è fattibile?\" riceve una risposta ottimistica perché il modello non ha mai pagato un mese di debug in produzione, non ha mai visto un cliente abbandonare per un bug ricorrente, non ha mai dovuto coordinare quattro persone che parlano linguaggi diversi del progetto. Risponde \"ottima idea, iniziamo lo sviluppo\" con la stessa fiducia con cui ti darebbe una ricetta di cucina. Poi inizi a costruire e scopri che il 10% del progetto occupa il 90% del tempo, e ",[216,555,557],{"href":556},"/blog/stime-sviluppo-sbagliate-perche","le stime diventano imprecise proprio per questo",[11,559,560],{},"A questo si somma un secondo fenomeno: le allucinazioni. Il modello cita librerie che non esistono, API che non fanno quello che dice, pattern che sembrano standard ma nessuno ha mai davvero usato in quel modo. Nel documento iniziale non si vedono. Si vedono dopo, in sviluppo, quando per ogni pezzo dell'architettura tocca verificare che esista e funzioni come promesso.",[26,562,564],{"id":563},"larchitettura-è-diventata-gratis-la-costruzione-no","L'architettura è diventata gratis. La costruzione no.",[11,566,567],{},"Fino a poco tempo fa, un documento tecnico di quel tipo richiedeva giornate di lavoro a qualcuno che lo stack lo aveva usato davvero. Oggi chiunque lo ottiene in cinque minuti. Questa parte si è commoditizzata, ed è giusto riconoscerlo.",[11,569,570,571,575],{},"Il lavoro di costruzione, invece, non si è ridotto nella stessa proporzione. Chi sa far girare quei box in produzione, con dati reali e sporchi, con sistemi esterni che si comportano male, con eccezioni che emergono solo dopo il lancio, non è stato sostituito. È diventato meno visibile, perché la patina del documento AI fa sembrare che il lavoro sia quasi finito quando in realtà non è ancora iniziato. ",[216,572,574],{"href":573},"/blog/quanto-costa-un-software-custom","Il grosso del costo nello sviluppo software si nasconde proprio lì",", e nessun documento generato in cinque minuti può raccontarlo.",[11,577,578],{},"Un architetto che non sa quanto costa davvero costruire un muro è un architetto inutile: disegna palazzi che non stanno in piedi. L'AI oggi produce esattamente questo genere di architetti, e tantissime aziende si trovano in mano progetti elegantissimi sulla carta e infattibili nella sostanza.",[26,580,582],{"id":581},"il-confronto-utile-per-chi-deve-commissionare","Il confronto utile per chi deve commissionare",[11,584,585],{},"Chi arriva a un colloquio con un documento generato dall'AI ha bisogno di una cosa nuova, anche se sembra vecchia: qualcuno che quel documento lo sappia leggere e dire dove si romperà in produzione. Qualcuno che sappia distinguere l'idea fattibile con questo budget da quella che richiede dieci volte tanto o che semplicemente non può esistere in quella forma.",[11,587,588,589,593],{},"Il confronto economico utile è diverso da quello che l'AI suggerisce implicitamente. Il costo di un software custom non si paragona al costo di un software pronto: si paragona al costo del lavoro tecnico senior necessario per costruirlo. Mesi di qualcuno che ha visto cosa succede quando un box diventa codice, quando una freccia diventa un'integrazione, quando un nome di tecnologia diventa un mese di debug. ",[216,590,592],{"href":591},"/blog/preventivo-software-partire-dal-budget","Partire dal budget reale, non dall'ambizione del documento, rende la conversazione utile",": si decide cosa costruire prima, cosa rimandare, cosa non fare.",[11,595,596,597,601],{},"Chi commissiona software oggi dovrebbe diffidare del primo che risponde \"partiamo subito\" al documento AI. È il segnale che sta leggendo quel documento con lo stesso sguardo con cui l'AI l'ha scritto. Chi vale davvero fa domande fastidiose sul processo, sui dati veri, sulle eccezioni, sui volumi. Propone fasi e trade-off espliciti invece di una versione \"completa\". ",[216,598,600],{"href":599},"/blog/scope-creep-progetti-agile","Fa emergere lo scope prima che esploda"," a metà progetto. Presenta numeri che sembrano alti confrontati alle promesse dell'AI, e sono solo realistici.",[26,603,605],{"id":604},"il-gap-lavora-a-favore-di-chi-sa-costruire","Il gap lavora a favore di chi sa costruire",[11,607,608],{},"La parte interessante è che l'asimmetria di oggi lavora a favore di chi costruisce davvero. Più l'AI rende facile produrre documenti impressionanti, più sottostime cresceranno, più progetti partiranno con premesse sbagliate, più chi riesce a portarli a casa diventerà raro.",[11,610,611],{},"Il valore, come succede a ogni salto di astrazione, si sposta un piano più giù — sul muratore, non sull'architetto. Sul mestiere che nessuno vede finché non c'è più.",{"title":172,"searchDepth":173,"depth":173,"links":613},[614,615,616,617,618,619],{"id":529,"depth":173,"text":530},{"id":539,"depth":173,"text":540},{"id":549,"depth":173,"text":550},{"id":563,"depth":173,"text":564},{"id":581,"depth":173,"text":582},{"id":604,"depth":173,"text":605},"2026-04-28","Farsi progettare un software dall'AI oggi costa cinque minuti. Perché il costo di sviluppo non è sceso con la stessa proporzione del costo di disegnarne l'architettura.","/images/blog/ai-progetta-software-costo-reale-sviluppo.jpg",{},"/blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo",{"title":518,"description":621},"AI che progetta software: quanto costa davvero svilupparlo","ai-progetta-software-costo-reale-sviluppo","blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo",[196,199,630,631,632,633,634],"budget","preventivi","chatgpt","scope-creep","software-custom","mY036ZKkGvlx6OtGElHue_WsUut7WgYIkPc9Nqm1W00",1778133697418]