[{"data":1,"prerenderedAt":627},["ShallowReactive",2],{"has-blog-posts":3,"post-codice-funziona-non-significa-buona-idea":4,"related-codice-funziona-non-significa-buona-idea":128,"datemod-codice-funziona-non-significa-buona-idea":109},true,{"id":5,"title":6,"body":7,"category":108,"date":109,"description":110,"extension":111,"image":112,"meta":113,"navigation":3,"path":114,"published":3,"seo":115,"seoTitle":116,"slug":117,"stem":118,"tags":119,"updated":126,"__hash__":127},"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":9,"toc":99},"minimark",[10,18,23,26,29,32,36,39,42,45,49,58,66,74,78,81,89,93,96],[11,12,13,17],"p",{},[14,15,16],"strong",{},"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.",[19,20,22],"h2",{"id":21},"una-scena-che-si-ripete","Una scena che si ripete",[11,24,25],{},"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,27,28],{},"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,30,31],{},"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.",[19,33,35],{"id":34},"lerrore-non-era-nel-codice","L'errore non era nel codice",[11,37,38],{},"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,40,41],{},"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,43,44],{},"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.",[19,46,48],{"id":47},"velocità-di-produzione-superficie-di-decisioni","Velocità di produzione, superficie di decisioni",[11,50,51,52,57],{},"Questa non è una scena isolata. È quello che sta succedendo in tantissimi team che hanno adottato l'AI senza ripensare come lavorano. ",[53,54,56],"a",{"href":55},"/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,59,60,61,65],{},"La bomba non esplode nelle settimane di sviluppo. Esplode in produzione, mesi dopo, quando gli utenti iniziano a segnalare ",[53,62,64],{"href":63},"/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,67,68,69,73],{},"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 ",[53,70,72],{"href":71},"/blog/riscrivere-software-da-zero","smantellare un'architettura inutilmente complicata e rimetterla semplice"," — una seconda volta, con un altro team.",[19,75,77],{"id":76},"lai-amplifica-quello-che-già-cè","L'AI amplifica quello che già c'è",[11,79,80],{},"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,82,83,84,88],{},"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 ",[53,85,87],{"href":86},"/blog/semplicita-nel-software","soluzione più semplice che risolve davvero",", proteggere le scelte architetturali nei momenti in cui conta farlo.",[19,90,92],{"id":91},"la-domanda-da-fare-al-team","La domanda da fare al team",[11,94,95],{},"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,97,98],{},"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":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107],{"id":21,"depth":101,"text":22},{"id":34,"depth":101,"text":35},{"id":47,"depth":101,"text":48},{"id":76,"depth":101,"text":77},{"id":91,"depth":101,"text":92},"Sviluppo","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.","md","/images/blog/codice-funziona-non-significa-buona-idea.jpg",{},"/blog/2026-04-30-codice-funziona-non-significa-buona-idea",{"title":6,"description":110},"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",[120,121,122,123,124,125],"ai","architettura","qualita-codice","code-review","debito-tecnico","gestione-team",null,"S9dwvPH4gBOQB7bWM_hOf_UjWPuDhtH69y7hZihINoA",[129,250,424],{"id":130,"title":131,"body":132,"category":108,"date":234,"description":235,"extension":111,"image":236,"meta":237,"navigation":3,"path":238,"published":3,"seo":239,"seoTitle":240,"slug":241,"stem":242,"tags":243,"updated":126,"__hash__":249},"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":133,"toc":226},[134,140,144,147,150,154,157,160,164,172,175,179,182,190,193,197,200,208,216,220,223],[11,135,136,139],{},[14,137,138],{},"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.",[19,141,143],{"id":142},"il-pattern-si-ripete","Il pattern si ripete",[11,145,146],{},"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,148,149],{},"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.",[19,151,153],{"id":152},"cosa-fa-davvero-lai-quando-progetta-un-software","Cosa fa davvero l'AI quando \"progetta un software\"",[11,155,156],{},"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,158,159],{},"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.",[19,161,163],{"id":162},"lottimismo-strutturale-dei-modelli","L'ottimismo strutturale dei modelli",[11,165,166,167,171],{},"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 ",[53,168,170],{"href":169},"/blog/stime-sviluppo-sbagliate-perche","le stime diventano imprecise proprio per questo",".",[11,173,174],{},"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.",[19,176,178],{"id":177},"larchitettura-è-diventata-gratis-la-costruzione-no","L'architettura è diventata gratis. La costruzione no.",[11,180,181],{},"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,183,184,185,189],{},"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. ",[53,186,188],{"href":187},"/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,191,192],{},"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.",[19,194,196],{"id":195},"il-confronto-utile-per-chi-deve-commissionare","Il confronto utile per chi deve commissionare",[11,198,199],{},"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,201,202,203,207],{},"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. ",[53,204,206],{"href":205},"/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,209,210,211,215],{},"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\". ",[53,212,214],{"href":213},"/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.",[19,217,219],{"id":218},"il-gap-lavora-a-favore-di-chi-sa-costruire","Il gap lavora a favore di chi sa costruire",[11,221,222],{},"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,224,225],{},"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":100,"searchDepth":101,"depth":101,"links":227},[228,229,230,231,232,233],{"id":142,"depth":101,"text":143},{"id":152,"depth":101,"text":153},{"id":162,"depth":101,"text":163},{"id":177,"depth":101,"text":178},{"id":195,"depth":101,"text":196},{"id":218,"depth":101,"text":219},"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":131,"description":235},"AI che progetta software: quanto costa davvero svilupparlo","ai-progetta-software-costo-reale-sviluppo","blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo",[120,121,244,245,246,247,248],"budget","preventivi","chatgpt","scope-creep","software-custom","mY036ZKkGvlx6OtGElHue_WsUut7WgYIkPc9Nqm1W00",{"id":251,"title":252,"body":253,"category":108,"date":407,"description":408,"extension":111,"image":409,"meta":410,"navigation":3,"path":411,"published":3,"seo":412,"seoTitle":413,"slug":414,"stem":415,"tags":416,"updated":126,"__hash__":423},"blog/blog/2026-04-23-troppi-ruoli-una-persona-rischio.md","Troppi ruoli su una persona: il rischio organizzativo nascosto",{"type":8,"value":254,"toc":398},[255,258,265,269,272,278,281,285,292,295,311,314,318,321,324,327,338,341,345,348,351,354,358,361,364,367,371,377,385,389,392,395],[11,256,257],{},"Nelle aziende che sviluppano software c’è una situazione molto comune che viene spesso scambiata per un punto di forza: una persona sola tiene insieme tutto. Parla con lo stakeholder, decide cosa costruire, tiene il piano, guida le scelte tecniche, mette mano al codice quando serve. Se c’è un problema, lo risolve. Se serve decidere, decide.",[11,259,260,261,264],{},"Dall’esterno sembra una fortuna.",[262,263],"br",{},"\nDall’interno, è una fragilità.",[19,266,268],{"id":267},"non-è-un-problema-di-talento","Non è un problema di talento",[11,270,271],{},"La lettura più comoda è: “è una persona molto brava”. Quella meno comoda è: l’azienda non ha costruito le funzioni di cui ha bisogno e le ha scaricate tutte su chi riesce a reggerle. Quasi sempre è la seconda.",[11,273,274,275],{},"C’è un modo semplice per capirlo: se quella persona sparisce per una settimana, cosa succede? Non se qualcuno la chiama — quello succede sempre. La domanda è: ",[14,276,277],{},"le decisioni vanno avanti o si fermano?",[11,279,280],{},"Se si fermano, non hai una risorsa preziosa. Hai un collo di bottiglia.",[19,282,284],{"id":283},"il-problema-non-è-il-carico-di-lavoro","Il problema non è il carico di lavoro",[11,286,287,288,171],{},"Chi vive questa situazione spesso regge. Lavora tanto, si organizza, trova il tempo. Il problema è il tipo di attenzione richiesta, più che il numero di ore. Pensare al prodotto richiede un certo tipo di testa, gestire il progetto un altro, prendere decisioni architetturali un altro ancora, scrivere codice richiede concentrazione profonda. Non sono attività che convivono bene nella stessa giornata, e ogni volta che cambi contesto paghi un costo: non in tempo, ma in qualità. È lo stesso problema delle interruzioni: ",[53,289,291],{"href":290},"/blog/ogni-interruzione-costa-23-minuti","ogni cambio di contesto costa più di quanto pensi",[11,293,294],{},"Quando tutto passa da una persona, succede questo:",[296,297,298,302,305,308],"ul",{},[299,300,301],"li",{},"il codice si scrive di corsa",[299,303,304],{},"le decisioni si prendono a metà",[299,306,307],{},"il prodotto si capisce superficialmente",[299,309,310],{},"la visione di lungo periodo sparisce",[11,312,313],{},"Non perché la persona non sia capace, ma perché sta facendo cinque lavori insieme.",[19,315,317],{"id":316},"il-tentativo-che-peggiora-le-cose","Il tentativo che peggiora le cose",[11,319,320],{},"A un certo punto l’azienda se ne accorge, e prova a “scaricare un po’ di lavoro”: arriva qualcuno a fare project management, oppure qualcuno sul prodotto. Sulla carta, il problema è risolto. Nella pratica, no.",[11,322,323],{},"Le riunioni si fanno, i report girano, i task sono tracciati. Ma le decisioni continuano a passare dalla stessa persona di prima, perché chi è entrato non ha mandato reale: gestisce la superficie, non la sostanza.",[11,325,326],{},"Risultato:",[296,328,329,332,335],{},[299,330,331],{},"la persona centrale continua a decidere tutto",[299,333,334],{},"in più deve aggiornare qualcun altro",[299,336,337],{},"chi è entrato capisce di non contare davvero e si adatta o se ne va",[11,339,340],{},"È peggio di prima. Hai aggiunto overhead senza togliere il collo di bottiglia.",[19,342,344],{"id":343},"delegare-davvero-è-scomodo","Delegare davvero è scomodo",[11,346,347],{},"Uscire da questa situazione è difficile per un motivo semplice: richiede fare cose contro-intuitive.",[11,349,350],{},"La prima è smettere di delegare quello che pesa di più e iniziare da quello che è più visibile. Molti partono dal codice, ed è un errore: il codice è ciò che ti tiene agganciato alla realtà. Le prime cose da lasciare sono le funzioni di coordinamento: gestione progetto, comunicazione, parte operativa del prodotto.",[11,352,353],{},"La seconda è accettare che chi prende in carico una funzione la farà diversamente. È qui che la maggior parte delle deleghe fallisce: se continui a correggere ogni decisione, non hai delegato, hai solo creato un passaggio in più. La delega inizia quando qualcuno prende una decisione che tu non avresti preso — ma è comunque sensata — e tu la lasci passare.",[19,355,357],{"id":356},"il-punto-vero-cosa-tieni-e-cosa-molli","Il punto vero: cosa tieni e cosa molli",[11,359,360],{},"Non devi distribuire tutto. Devi scegliere cosa tenere. Per chi ha costruito un prodotto tecnico, la cosa più difficile da delegare è quasi sempre la guida tecnica sul core. È normale.",[11,362,363],{},"Tienila.",[11,365,366],{},"Ma tutto il resto — progetto, coordinamento, parte di prodotto — deve uscire. Altrimenti non stai proteggendo il sistema: stai solo rallentando il punto in cui smetterà di reggere.",[19,368,370],{"id":369},"il-test-che-non-perdona","Il test che non perdona",[11,372,373,374],{},"C’è un modo semplice per capire se hai davvero risolto il problema: per una settimana, sparisci. Non completamente — non è quello il punto. La domanda è: ",[14,375,376],{},"quali decisioni verrebbero rimandate al tuo ritorno?",[11,378,379,380,384],{},"Se la risposta è “quasi tutte”, sei esattamente dove eri prima. Se sono poche, stai migliorando. Se tutto va avanti tranne quello che hai deciso consapevolmente di tenere, allora l’organizzazione sta funzionando. È il ",[53,381,383],{"href":382},"/blog/bus-factor-developer-indispensabile","bus factor"," applicato alle decisioni, non solo al codice.",[19,386,388],{"id":387},"il-punto-scomodo","Il punto scomodo",[11,390,391],{},"Se stai guidando un’azienda e hai una persona che copre tre o quattro ruoli, non sei fortunato. Sei esposto.",[11,393,394],{},"Finché quella persona regge, sembra tutto sotto controllo. Poi succede qualcosa di normale — ferie, stanchezza, cambio lavoro — e lì scopri che non avevi costruito un sistema: avevi costruito una dipendenza.",[11,396,397],{},"Il costo per sistemarlo è reale: assunzioni, affiancamento, un periodo in cui le cose rallentano. Il costo di non farlo arriva tutto insieme, e quando arriva non hai margine per gestirlo.",{"title":100,"searchDepth":101,"depth":101,"links":399},[400,401,402,403,404,405,406],{"id":267,"depth":101,"text":268},{"id":283,"depth":101,"text":284},{"id":316,"depth":101,"text":317},{"id":343,"depth":101,"text":344},{"id":356,"depth":101,"text":357},{"id":369,"depth":101,"text":370},{"id":387,"depth":101,"text":388},"2026-04-23","Se una persona sola tiene insieme tecnica, progetto e prodotto, l'organizzazione accumula un rischio che non si vede finché non esplode.","/images/blog/troppi-ruoli-una-persona-rischio.jpg",{},"/blog/2026-04-23-troppi-ruoli-una-persona-rischio",{"title":252,"description":408},"Troppi ruoli su una persona sola: il rischio nascosto","troppi-ruoli-una-persona-rischio","blog/2026-04-23-troppi-ruoli-una-persona-rischio",[125,417,418,419,420,421,422],"leadership","delega","bus-factor","burnout","organizzazione","ruoli","CmlSLXqSh8HZW2B1aHBu1T9turx2H7asgaUU47sY-Vs",{"id":425,"title":426,"body":427,"category":108,"date":612,"description":613,"extension":111,"image":614,"meta":615,"navigation":3,"path":616,"published":3,"seo":617,"seoTitle":618,"slug":619,"stem":620,"tags":621,"updated":126,"__hash__":626},"blog/blog/2026-04-21-outsourcing-software-low-cost.md","Outsourcing software in India: perché finisce quasi sempre male",{"type":8,"value":428,"toc":601},[429,434,437,443,446,450,457,464,468,471,474,478,481,484,490,494,497,503,514,517,521,524,527,535,539,542,546,549,555,558,561,575,579,586,590,593,598],[11,430,431],{},[14,432,433],{},"\"Abbiamo trovato un team in India che fa lo stesso lavoro a un terzo del costo.\"",[11,435,436],{},"L'outsourcing software low-cost — con l'India in testa, ma non solo — è una tentazione ricorrente: negli ultimi vent'anni, questa frase ha dato il via a centinaia di progetti. Molti sono partiti con entusiasmo. Molti, dopo un anno, si sono ritrovati con codice che \"funziona\" ma che nessuno riesce più a toccare senza rompere qualcosa.",[11,438,439,440,171],{},"È un problema di ",[14,441,442],{},"modello organizzativo",[11,444,445],{},"Il modello delle software farm low-cost è costruito per produrre tanto codice, in poco tempo, al costo più basso possibile. Funziona bene quando il problema è scrivere task. Funziona molto meno quando il problema è rappresentare fedelmente il tuo business, far evolvere il software nel tempo e mantenerlo sano per anni.",[19,447,449],{"id":448},"come-funziona-davvero-il-modello","Come funziona davvero il modello",[11,451,452,453,456],{},"Lo schema è quasi sempre lo stesso. L'azienda vuole ridurre i costi di sviluppo, si affida a una software farm con molti sviluppatori, la comunicazione passa attraverso uno o due project manager, il team tecnico è numeroso, junior e intercambiabile, e l'incentivo principale diventa ",[14,454,455],{},"chiudere ticket velocemente",", non capire il problema a fondo.",[11,458,459,460,463],{},"Questo modello ha senso industriale. È pensato per scalare. Ma ha un effetto collaterale enorme: il codice prodotto è ",[14,461,462],{},"scollegato dal contesto reale del tuo business",". E quando il codice è scollegato dal contesto, diventa fragile.",[19,465,467],{"id":466},"il-vero-ostacolo-è-la-comunicazione","Il vero ostacolo è la comunicazione",[11,469,470],{},"Quando lavori con un team a migliaia di chilometri di distanza, con poche ore di sovrapposizione e una comunicazione mediata da documenti e task, succede una cosa prevedibile: le sfumature si perdono. Le conversazioni veloci diventano thread di email, i chiarimenti immediati diventano messaggi che ricevono risposta il giorno dopo, i requisiti vengono interpretati alla lettera e non nel loro intento. Nessuna malafede: è la conseguenza naturale del contesto.",[11,472,473],{},"Nel software, però, un requisito frainteso non produce una piccola differenza. Produce un comportamento completamente diverso da quello che ti aspettavi.",[19,475,477],{"id":476},"il-fuso-orario-impedisce-la-collaborazione-vera","Il fuso orario impedisce la collaborazione vera",[11,479,480],{},"Quando il tuo team lavora mentre tu dormi, e tu lavori mentre loro dormono, la collaborazione diventa asincrona forzata.",[11,482,483],{},"Scompaiono le sessioni di analisi fatte bene, le discussioni architetturali spontanee e i chiarimenti rapidi sulle decisioni ambigue. Resta uno scambio di documenti e ticket. Il software, però, nasce bene dal confronto continuo, non da una catena di passaggi intermedi.",[11,485,486,487,171],{},"Questo non rallenta solo il progetto. Peggio: ",[14,488,489],{},"impedisce al team di capire davvero cosa sta costruendo",[19,491,493],{"id":492},"il-vero-problema-nessuno-possiede-il-codice","Il vero problema: nessuno possiede il codice",[11,495,496],{},"Nelle software farm low-cost, il turnover è spesso alto. Le persone cambiano progetto, cliente, azienda. Dopo sei mesi, chi ha scritto quel modulo potrebbe non esserci più. Dopo un anno, può capitare che nessuno del team originale sia ancora sul progetto.",[11,498,499,500,502],{},"Il codice resta. La conoscenza no. È il problema del ",[53,501,383],{"href":382}," portato all'estremo.",[11,504,505,506,513],{},"È una versione amplificata del problema descritto in ",[53,507,509],{"href":508},"/blog/aggiungere-sviluppatori-progetto",[510,511,512],"em",{},"The Mythical Man-Month",": aggiungere persone non crea comprensione, crea frammentazione.",[11,515,516],{},"Quando quel software passa in mano a un nuovo team — interno o esterno — sembra scritto da qualcuno che non conosceva il tuo business. Perché, di fatto, è così.",[19,518,520],{"id":519},"perché-allinizio-sembra-funzionare","Perché all'inizio sembra funzionare",[11,522,523],{},"Nei primi mesi tutto fila liscio: le feature arrivano, i ticket si chiudono, il costo è contenuto. Sembra una scelta brillante.",[11,525,526],{},"Il problema emerge dopo, quando devi fare modifiche non previste, il business cambia oppure serve aggiungere una logica nuova che interagisce con quelle esistenti. È lì che scopri che il codice è una somma di task chiusi, non un sistema pensato per evolvere. E ogni modifica diventa un rischio.",[11,528,529,530],{},"È il momento in cui inizi a dire:\n",[53,531,532],{"href":63},[14,533,534],{},"\"Ogni volta che tocchiamo qualcosa, si rompe qualcos'altro.\"",[19,536,538],{"id":537},"un-problema-di-incentivi-non-di-geografia","Un problema di incentivi, non di geografia",[11,540,541],{},"Il modello non è esclusivo dell'India: esiste ovunque il lavoro venga organizzato con tanti sviluppatori intercambiabili, poca ownership, comunicazione filtrata e focus sulla velocità più che sulla comprensione — dall'Europa dell'est al Sud-est asiatico. Il risultato tende a essere sempre lo stesso: codice che fa quello che c'è scritto nel ticket, ma non quello che serve davvero al business.",[19,543,545],{"id":544},"perché-oggi-questo-modello-ha-ancora-meno-senso","Perché oggi questo modello ha ancora meno senso",[11,547,548],{},"Per vent'anni, il vantaggio competitivo delle software farm low-cost era semplice:",[550,551,552],"blockquote",{},[11,553,554],{},"tanto codice a basso prezzo.",[11,556,557],{},"Anche accettando inefficienze e fragilità architetturale, il conto tornava. Perché il collo di bottiglia era sempre lo stesso: servivano tante ore uomo per scrivere codice.",[11,559,560],{},"Oggi questo presupposto sta saltando: strumenti come Claude Code o Codex producono codice in minuti, senza fuso orario, senza incomprensioni linguistiche e a un costo marginale quasi nullo.",[11,562,563,564,567,568,574],{},"Il valore si è spostato: da ",[14,565,566],{},"chi scrive il codice al prezzo più basso"," a ",[53,569,571],{"href":570},"/blog/ai-impatto-business-software",[14,572,573],{},"chi sa decidere cosa scrivere, come strutturarlo e come farlo evolvere",". Ed è esattamente la parte che il modello low-cost non copre.",[19,576,578],{"id":577},"il-paradosso-umano","Il paradosso umano",[11,580,581,582,585],{},"C'è un paradosso che vale la pena riconoscere. Per anni questo modello ha funzionato perché il mercato chiedeva quantità di codice, e moltissimi sviluppatori hanno lavorato esattamente per soddisfare quella richiesta. Oggi la richiesta è cambiata — da \"scrivi questo ticket\" a \"capisci questo sistema\" — e la cosa ",[14,583,584],{},"per cui vengono pagati"," sta perdendo valore molto velocemente.",[19,587,589],{"id":588},"la-lezione-per-chi-commissiona-software","La lezione per chi commissiona software",[11,591,592],{},"Alla base di questo modello c'è un'idea pericolosa:",[550,594,595],{},[11,596,597],{},"che il software sia un problema di manodopera.",[11,599,600],{},"Finché sembrava vera, l'outsourcing low-cost in India aveva senso economico. Oggi si vede chiaramente che il valore non era lì. Il software riguarda comprensione del business, decisioni architetturali, comunicazione continua e responsabilità sul sistema nel tempo: cose che non si possono spacchettare in ticket da mandare dall'altra parte del mondo, e oggi non si possono nemmeno delegare a un'AI.",{"title":100,"searchDepth":101,"depth":101,"links":602},[603,604,605,606,607,608,609,610,611],{"id":448,"depth":101,"text":449},{"id":466,"depth":101,"text":467},{"id":476,"depth":101,"text":477},{"id":492,"depth":101,"text":493},{"id":519,"depth":101,"text":520},{"id":537,"depth":101,"text":538},{"id":544,"depth":101,"text":545},{"id":577,"depth":101,"text":578},{"id":588,"depth":101,"text":589},"2026-04-21","Outsourcing software in India a un terzo del costo: il modello produce codice scollegato dal business, con incentivi sbagliati. E con l'AI ha ancora meno senso.","/images/blog/outsourcing-software-low-cost.jpg",{},"/blog/2026-04-21-outsourcing-software-low-cost",{"title":426,"description":613},"Outsourcing software India: rischi e costi nascosti","outsourcing-software-low-cost","blog/2026-04-21-outsourcing-software-low-cost",[622,623,624,625,120],"outsourcing","scelta-fornitore","rischi-software","qualita","AEWykOP8KGCSfFP_ZVMsctJkUIzP64BE-2BzD5c4QtU",1777528843954]