[{"data":1,"prerenderedAt":684},["ShallowReactive",2],{"has-blog-posts":3,"post-test-coverage-cosa-misura":4,"related-test-coverage-cosa-misura":174,"datemod-test-coverage-cosa-misura":683},true,{"id":5,"title":6,"body":7,"category":156,"date":157,"description":158,"extension":159,"image":160,"meta":161,"navigation":3,"path":162,"published":3,"seo":163,"seoTitle":164,"slug":165,"stem":166,"tags":167,"updated":172,"__hash__":173},"blog/blog/2026-02-05-test-coverage-cosa-misura.md","Test coverage al 100%: cosa misura davvero (e cosa no)",{"type":8,"value":9,"toc":138},"minimark",[10,17,20,25,30,33,37,40,43,47,50,53,57,61,64,67,71,74,77,81,84,87,91,94,103,107,110,113,121,125,132,135],[11,12,13],"p",{},[14,15,16],"strong",{},"\"Abbiamo il 95% di code coverage.\" Bene. Ma il test coverage 100% è davvero l'obiettivo giusto? Cosa stiamo davvero testando? Mi è capitato di vedere suite di test con coverage altissima che non intercettavano bug critici in produzione. E suite con coverage molto basse che coprivano i flussi che contavano davvero.",[11,18,19],{},"La code coverage, cioè la percentuale di codice che viene eseguita mentre girano i test, rischia di diventare una metrica fine a se stessa. Un numero da mostrare nelle dashboard, da mettere nei badge del repository, da esibire nelle code review. Un numero alto non dice nulla sulla qualità dei test. Dice solo che del codice è stato eseguito durante i test.",[21,22,24],"h2",{"id":23},"perché-la-coverage-è-una-metrica-ingannevole","Perché la coverage è una metrica ingannevole",[26,27,29],"h3",{"id":28},"coverage-misura-lesecuzione-non-la-verifica","Coverage misura l'esecuzione, non la verifica",[11,31,32],{},"Se scrivo un test che chiama una funzione ma non verifica il risultato, la coverage aumenta. La funzione è stata “coperta”: il codice è stato eseguito. Ma il test non protegge nulla. Il test passa, la coverage sale, e il bug resta lì.",[26,34,36],{"id":35},"i-test-facili-alzano-i-numeri-quelli-difficili-salvano-il-prodotto","I test facili alzano i numeri, quelli difficili salvano il prodotto",[11,38,39],{},"Testare un getter che restituisce un campo è facile. La coverage aumenta. Testare il flusso di pagamento completo con gestione degli errori, retry, e rollback è difficile. Aggiunge poca coverage, ma è il test che ti salva quando qualcosa va storto.",[11,41,42],{},"La tendenza naturale è scrivere molti test facili, veloci da scrivere e utili ad alzare la metrica, e pochi test difficili che richiedono setup e ragionamento. Il risultato è una suite che dà una falsa sensazione di sicurezza.",[26,44,46],{"id":45},"il-100-è-un-obiettivo-che-raramente-ha-senso-economico","Il 100% è un obiettivo che raramente ha senso economico",[11,48,49],{},"Passare dal 70% all’80% è relativamente economico. Dall’80% al 90% lo sforzo cresce in modo significativo. Dal 90% al 100% lo sforzo tende a diventare sproporzionato rispetto al valore aggiunto.",[11,51,52],{},"Quell’ultimo tratto include casi molto rari che difficilmente vedrai in produzione. Il tempo che il team spende a inseguire il 100% è tempo che non spende a testare i flussi critici in modo più approfondito.",[21,54,56],{"id":55},"quali-test-servono-davvero","Quali test servono davvero",[26,58,60],{"id":59},"i-flussi-che-fanno-guadagnare-soldi","I flussi che fanno guadagnare soldi",[11,62,63],{},"Registrazione, login, pagamento, le azioni core del tuo prodotto. Se questi si rompono, perdi utenti e ricavi. Testali in modo approfondito: happy path, errori comuni, casi limite realistici e integrazioni reali.",[11,65,66],{},"Pochi test ben scritti qui valgono più di molti test su utilità secondarie.",[26,68,70],{"id":69},"le-integrazioni-con-sistemi-esterni","Le integrazioni con sistemi esterni",[11,72,73],{},"API di terze parti, gateway di pagamento, servizi di email, storage — tutto ciò che è fuori dal tuo controllo. Qui è dove le cose tendono a rompersi più spesso: API che cambiano, timeout diversi, formati non documentati.",[11,75,76],{},"I test di integrazione che verificano il comportamento reale — non mock — sono tra i più preziosi che puoi avere.",[26,78,80],{"id":79},"i-casi-che-ti-fanno-perdere-soldi","I casi che ti fanno perdere soldi",[11,82,83],{},"Un utente viene addebitato due volte? Un ordine viene perso? I dati personali finiscono esposti? Questi scenari hanno un costo sproporzionato rispetto alla loro frequenza. Un test che previene un doppio addebito può valere più di decine di test su logica secondaria.",[11,85,86],{},"Identifica gli scenari più rischiosi per il tuo business e dedica particolare attenzione a testarli.",[26,88,90],{"id":89},"le-regressioni-dopo-ogni-bug-in-produzione","Le regressioni dopo ogni bug in produzione",[11,92,93],{},"Ogni bug significativo che arriva in produzione dovrebbe generare un test. Non per coverage — per prevenzione. Se è successo una volta, può succedere di nuovo. Il test riduce significativamente la probabilità che si ripresenti.",[11,95,96,97,102],{},"Nel tempo, questa pratica costruisce una suite che copre i problemi reali del tuo prodotto. Ed è anche ciò che rende possibile il ",[98,99,101],"a",{"href":100},"/blog/riscrivere-software-da-zero","refactoring sicuro invece della riscrittura da zero",".",[21,104,106],{"id":105},"cosa-dire-al-team-e-al-pm","Cosa dire al team (e al PM)",[11,108,109],{},"Se gestisci un team e la coverage è diventata un obiettivo, la prima cosa da fare è smettere di fissare target numerici rigidi. Un 90% come traguardo rischia di incentivare test scritti per alzare un numero invece che per proteggere davvero il prodotto. Ha molto più senso spingere il team a coprire bene i flussi critici.",[11,111,112],{},"La domanda utile non è “quanta coverage abbiamo?”, ma “questo test che cosa protegge?”. Quando vengono aggiunti nuovi test, vale la pena chiedere quale scenario stanno prevenendo. Se la risposta è solo “alza la coverage”, probabilmente quel test non serve molto.",[11,114,115,116,120],{},"Conta anche mettere a budget il tempo per i test giusti. I test di integrazione richiedono più tempo per essere scritti e mantenuti, e proprio per questo sono i primi a saltare quando il team è ",[98,117,119],{"href":118},"/blog/stime-sviluppo-sbagliate-perche","sotto pressione sulle stime",". Infine, la metrica che conta davvero resta un’altra: quanti bug arrivano in produzione.",[21,122,124],{"id":123},"il-testing-è-un-investimento-non-una-cerimonia","Il testing è un investimento, non una cerimonia",[11,126,127,128,102],{},"I test sono codice. Vanno scritti, mantenuti, eseguiti, e ogni tanto riscritti. Sono un costo — un costo che si ripaga prevenendo problemi più costosi. Ma solo se testano le cose giuste. Senza una buona suite di test sui flussi critici, il deploy diventa una roulette e il team finisce per avere ",[98,129,131],{"href":130},"/blog/software-fragile-regressioni","paura di rilasciare",[11,133,134],{},"Un team con il 40% di coverage concentrata sui flussi critici è spesso in una posizione più solida di un team con il 95% distribuita uniformemente su codice che non ha impatto diretto sul business.",[11,136,137],{},"La coverage è un indicatore, non l’obiettivo. I test servono a proteggere il prodotto, non a riempire una metrica. L’obiettivo è un prodotto che continua a funzionare anche quando il codice cambia.",{"title":139,"searchDepth":140,"depth":140,"links":141},"",2,[142,148,154,155],{"id":23,"depth":140,"text":24,"children":143},[144,146,147],{"id":28,"depth":145,"text":29},3,{"id":35,"depth":145,"text":36},{"id":45,"depth":145,"text":46},{"id":55,"depth":140,"text":56,"children":149},[150,151,152,153],{"id":59,"depth":145,"text":60},{"id":69,"depth":145,"text":70},{"id":79,"depth":145,"text":80},{"id":89,"depth":145,"text":90},{"id":105,"depth":140,"text":106},{"id":123,"depth":140,"text":124},"Testing","2026-02-05","Il test coverage 100% non misura la qualità dei test. Puoi avere numeri altissimi e non testare nulla di utile. Quali test servono davvero.","md","/images/blog/test-coverage-cosa-misura.jpg",{},"/blog/2026-02-05-test-coverage-cosa-misura",{"title":6,"description":158},"Test coverage 100%: perché non garantisce qualità","test-coverage-cosa-misura","blog/2026-02-05-test-coverage-cosa-misura",[168,169,170,171],"testing","qualita","debito-tecnico","sviluppo-software",null,"jPiifmGGKOv__eQIs-D2EQBr8xLyrGnBmkoOdjzQ0yw",[175,359,538],{"id":176,"title":177,"body":178,"category":345,"date":346,"description":347,"extension":159,"image":348,"meta":349,"navigation":3,"path":350,"published":3,"seo":351,"seoTitle":352,"slug":353,"stem":354,"tags":355,"updated":172,"__hash__":358},"blog/blog/2026-02-24-clean-code-guida-pratica.md","Clean Code: guida utile (non dogma)",{"type":8,"value":179,"toc":332},[180,185,188,191,195,207,210,213,217,220,224,227,234,237,241,244,247,250,254,261,264,268,271,278,286,290,293,300,304,307,310,314,317,325,329],[11,181,182],{},[14,183,184],{},"Clean Code di Robert C. Martin è uno dei libri più influenti degli ultimi vent’anni nello sviluppo software. Ha aiutato moltissimi team a scrivere codice più leggibile e manutenibile.",[11,186,187],{},"Ho visto anche l’effetto collaterale: team che applicano regole “da libro” senza contesto e finiscono per produrre complessità non necessaria. Codice elegante, sì, ma costoso: più file, più livelli, più cerimonia. E tempi di consegna che si allungano.",[11,189,190],{},"Il problema non è Clean Code. Il problema è trattarlo come dogma invece che come bussola. E quella differenza, nel software, si paga in soldi, tempo e opportunità.",[21,192,194],{"id":193},"cosa-clean-code-fa-bene-molto-bene","Cosa Clean Code fa bene (molto bene)",[11,196,197,198,202,203,206],{},"Prima di criticare, vale la pena riconoscere cosa funziona davvero. I nomi che significano qualcosa sono una forma di manutenzione preventiva: ",[199,200,201],"code",{},"calculateMonthlyRevenue()"," è molto meglio di ",[199,204,205],{},"calc()",", perché riduce il tempo di comprensione, accelera l’onboarding e limita gli errori banali. Lo stesso vale per funzioni piccole e con responsabilità chiara. Non serve l’ossessione delle “5 righe massimo”, ma una funzione leggibile è più facile da testare, modificare e correggere di un blocco enorme che mescola logica, side effect e condizioni.",[11,208,209],{},"Conta molto anche la struttura prevedibile. Convenzioni condivise su stile, organizzazione ed error handling rendono il codice più navigabile e riducono la frizione: meno tempo perso a interpretare scelte arbitrarie.",[11,211,212],{},"Se un team parte dal caos, Clean Code spesso è un upgrade immediato. Il guaio inizia quando “linee guida” diventano “legge”.",[21,214,216],{"id":215},"dove-il-dogma-fa-danni","Dove il dogma fa danni",[11,218,219],{},"Il danno tipico è sempre lo stesso: ottimizzi la forma del codice prima di sapere se quella forma serve. Vale anche per principi come SOLID, cioè un insieme di regole usate per rendere il codice più ordinato e meno rigido, che diventano utili solo se applicati con giudizio.",[26,221,223],{"id":222},"astrarre-troppo-presto","Astrarre troppo presto",[11,225,226],{},"Ridurre duplicazione è utile, ma la duplicazione “piccola” a volte è un compromesso accettabile. Il rischio vero non è ripetere tre righe: è creare un’astrazione sbagliata che vincola tutto il progetto.",[11,228,229,230,233],{},"Una regola pratica: ",[14,231,232],{},"duplica finché non vedi un pattern stabile",". Se il comportamento si sta ancora chiarendo (tipico di prodotti giovani), astrarre subito è come cementare una decisione quando non hai ancora capito la strada.",[11,235,236],{},"Un po’ di duplicazione costa poco. Un’astrazione prematura costa settimane quando scopri che era quella sbagliata.",[26,238,240],{"id":239},"frammentare-il-codice-in-troppi-micro-file","Frammentare il codice in troppi micro-file",[11,242,243],{},"“Classi piccole” è un buon principio finché migliora la comprensione. Oltre una certa soglia diventa frammentazione: per seguire un flusso devi saltare tra 10 file, e la leggibilità peggiora.",[11,245,246],{},"Segnale tipico: “Per capire il login devo aprire 12 classi”. In quel caso hai solo spostato la complessità: da dentro un file a tra file.",[11,248,249],{},"A volte una classe di 150 righe ben organizzata è più leggibile di 8 classi da 20 righe che si rimbalzano responsabilità.",[26,251,253],{"id":252},"test-come-cerimonia","Test come cerimonia",[11,255,256,257,102],{},"L’enfasi sui test è positiva. Ma se diventa “testiamo tutto perché sì”, ottieni una suite enorme che non protegge i flussi critici. È facile finire a testare getter/setter e logica ovvia, mentre restano scoperti i punti dove il business perde davvero soldi (pagamenti, permessi, integrazioni). È lo stesso problema della coverage: ",[98,258,260],{"href":259},"/blog/test-coverage-cosa-misura","puoi avere numeri alti e non testare ciò che conta",[11,262,263],{},"La domanda giusta non è “quanta coverage?”. È: “che incidente stiamo prevenendo con questo test?”",[26,265,267],{"id":266},"solid-applicato-senza-contesto","SOLID applicato senza contesto",[11,269,270],{},"SOLID è utile su sistemi complessi. Applicato ovunque e subito, può trasformare un progetto semplice in un labirinto di interfacce e livelli.",[11,272,273,274,277],{},"Regola pratica: ",[14,275,276],{},"usa SOLID per ridurre rischio e accoppiamento nei punti caldi"," (moduli core, logica instabile, aree con molte modifiche). Non trasformarlo in un requisito estetico su ogni form e ogni endpoint.",[11,279,280,281,285],{},"Per un ",[98,282,284],{"href":283},"/blog/cos-e-un-mvp-software","MVP",", spesso la priorità è avere un sistema chiaro, modificabile e consegnato in tempo — più che inseguire l’architettura “da manuale”.",[21,287,289],{"id":288},"il-costo-concreto-del-dogma","Il costo concreto del dogma",[11,291,292],{},"Per chi gestisce un prodotto, questi eccessi si traducono in effetti misurabili. I tempi di consegna si gonfiano perché la “forma perfetta” diventa parte implicita del requisito, anche quando nessuno l’aveva chiesta. L’onboarding rallenta, perché più livelli e più frammentazione rendono difficile capire dove mettere mano, soprattutto quando le astrazioni non rispondono a un bisogno reale.",[11,294,295,296,299],{},"Poi c’è il refactoring infinito. Se il team viene premiato più per “pulire” che per consegnare, entra in un ciclo di perfezionamento continuo: il codice migliora marginalmente, mentre il prodotto rallenta. E naturalmente diventano più instabili anche le ",[98,297,298],{"href":118},"stime",", perché stai stimando la feature insieme a tutta la cerimonia che le viene costruita attorno.",[21,301,303],{"id":302},"dovè-il-confine-5-regole-pratiche","Dov’è il confine: 5 regole pratiche",[11,305,306],{},"Il confine pratico si può riassumere così. I nomi chiari vanno quasi sempre scelti, perché hanno un ritorno altissimo e costano poco. Le astrazioni hanno senso quando esistono insieme ripetizione e stabilità; se la logica cambia spesso, conviene aspettare. La leggibilità del flusso conta più della frammentazione elegante: se per capire una feature devi aprire troppi file, hai già perso qualcosa.",[11,308,309],{},"Anche i test vanno scelti per impatto, non per rituale. Ha senso proteggere i flussi che costano soldi quando si rompono, come pagamenti, permessi, integrazioni e regressioni. E soprattutto la qualità va misurata nel tempo, non nel gusto personale. La domanda utile è sempre la stessa: quanto ci costerà cambiare questa cosa tra tre mesi?",[21,311,313],{"id":312},"la-sensibilità-conta-più-delle-regole","La sensibilità conta più delle regole",[11,315,316],{},"Clean Code ti dà un vocabolario e una direzione. Ma la parte che fa la differenza è il giudizio: sapere quando un principio va applicato e quando diventa overhead.",[11,318,319,320,324],{},"Il codice deve servire il business, non vincere un concorso di eleganza. Una cattedrale è impressionante, ma se dovevi costruire una casa abitabile in quattro settimane, hai sbagliato obiettivo. La ",[98,321,323],{"href":322},"/blog/semplicita-nel-software","semplicità è la cosa più difficile"," da ottenere, e spesso è il segno di vera competenza.",[21,326,328],{"id":327},"come-riconoscere-il-problema","Come riconoscere il problema",[11,330,331],{},"Alcuni segnali sono chiari: feature piccole che diventano “progetti architetturali”, un team che parla spesso di “rifare bene” ma consegna poco, codice apparentemente pulitissimo insieme a onboarding lento, modifiche che richiedono di toccare troppi livelli e troppe classi. In questi casi stai comprando complessità spacciata per qualità.",{"title":139,"searchDepth":140,"depth":140,"links":333},[334,335,341,342,343,344],{"id":193,"depth":140,"text":194},{"id":215,"depth":140,"text":216,"children":336},[337,338,339,340],{"id":222,"depth":145,"text":223},{"id":239,"depth":145,"text":240},{"id":252,"depth":145,"text":253},{"id":266,"depth":145,"text":267},{"id":288,"depth":140,"text":289},{"id":302,"depth":140,"text":303},{"id":312,"depth":140,"text":313},{"id":327,"depth":140,"text":328},"Architettura","2026-02-24","Le regole di Clean Code salvano progetti dal caos. Ma applicate senza giudizio generano complessità inutile. Dove sta il confine pratico.","/images/blog/clean-code-guida-pratica.jpg",{},"/blog/2026-02-24-clean-code-guida-pratica",{"title":177,"description":347},"Clean Code: guida pratica o dogma da evitare?","clean-code-guida-pratica","blog/2026-02-24-clean-code-guida-pratica",[356,357,170,169,171],"architettura","best-practice","IO5RVZUrdpecD4fA4EsDpImbMzWkAc0KDRCQ_jIMM-I",{"id":360,"title":361,"body":362,"category":521,"date":522,"description":523,"extension":159,"image":524,"meta":525,"navigation":3,"path":526,"published":3,"seo":527,"seoTitle":528,"slug":529,"stem":530,"tags":531,"updated":172,"__hash__":537},"blog/blog/2026-01-08-sviluppare-con-ai.md","Sviluppare con l'AI: come cambia il lavoro (e i rischi)",{"type":8,"value":363,"toc":510},[364,367,374,378,381,384,387,390,393,397,401,404,407,410,416,420,423,426,429,433,436,439,446,449,453,456,459,467,470,473,477,480,483,486,494,498,501,504,507],[11,365,366],{},"Sviluppare con AI è il tema del momento, e negli ultimi due anni gira un'idea che affascina un sacco di gente: l'AI sta democratizzando la programmazione. In teoria, serve meno personale, si fa tutto più in fretta, si spende meno. Chi guida aziende e prodotti sta impostando assunzioni e strategie di crescita su questa promessa. Ma il punto è che questa storia non è completa. E quando basi le tue decisioni su una visione parziale, rischi di pagare caro.",[11,368,369,370,373],{},"Io uso Claude Code ogni giorno, Codex ogni tanto soprattutto per revisionare. Questi strumenti ti fanno andare ",[14,371,372],{},"più veloce"," nello sviluppo. Non lo rendono più facile. Sembra una sfumatura da poco, ma cambia tutto: da come strutturi il team a come pianifichi la roadmap, fino a dove metti i soldi.",[21,375,377],{"id":376},"dove-lai-fa-davvero-la-differenza","Dove l’AI fa davvero la differenza",[11,379,380],{},"Partiamo dal concreto: dove l’AI è particolarmente efficace. Lo è nella prototipazione: un prototipo funzionante che prima richiedeva una settimana oggi puoi tirarlo su in un giorno, e per testare un’idea in fretta il vantaggio è evidente.",[11,382,383],{},"Funziona molto bene anche sul lavoro ripetitivo. Ogni progetto ha una quantità enorme di codice “noioso”: configurazioni, routine standard, integrazioni, boilerplate. L’AI riduce tutto questo da ore a minuti e libera più tempo per la logica di business.",[11,385,386],{},"Aiuta poi a orientarsi nei progetti esistenti. Un nuovo sviluppatore di solito impiega settimane solo per capire dove ha messo i piedi; l’AI può ridurre sensibilmente questo tempo, rendendo l’onboarding, cioè l’ingresso operativo nel progetto, e i passaggi di consegne meno pesanti.",[11,388,389],{},"Infine accelera il refactoring. Rinominare, riorganizzare e sistemare codice vecchio diventa più veloce, anche se qui serve sempre un controllo umano perché gli errori sottili restano possibili.",[11,391,392],{},"Tutto questo è concreto. Se il tuo team sa usare questi strumenti, la produttività sale — e lo vedi. Il vero problema nasce quando “più veloce” viene confuso con “più facile”.",[21,394,396],{"id":395},"i-costi-nascosti-che-nessuno-ti-dice","I costi nascosti che nessuno ti dice",[26,398,400],{"id":399},"il-debito-tecnico-cresce-a-una-velocità-nuova","Il debito tecnico cresce a una velocità nuova",[11,402,403],{},"Il debito tecnico, cioè il costo futuro delle scorciatoie che prendi oggi, è quel conto che paghi domani per guadagnare velocità adesso. Tutti i progetti ce l’hanno, chi più chi meno. Ma con l’AI, la velocità con cui cresce non si era mai vista.",[11,405,406],{},"Il motivo è semplice: scrivere codice con l’AI costa quasi zero in termini di tempo e fatica. E allora prendi quello che arriva: “Funziona? Dai, andiamo avanti.” Il codice che ti dà l’AI spesso fa quello che chiedi, sì, ma magari in modo poco efficiente, fragile, o con problemi di sicurezza che non si vedono subito.",[11,408,409],{},"Nel concreto, il debito tecnico lo senti quando tra sei mesi il team ti dice: “Per aggiungere questa feature ci vogliono tre mesi invece di tre settimane, perché prima dobbiamo rifare le fondamenta.” O quando un bug in produzione tiene tutti fermi per giorni, perché nessuno capisce più come funziona quel pezzo di codice.",[11,411,412,415],{},[14,413,414],{},"Il debito tecnico che prima si accumulava lentamente, con l’AI può accumularsi molto più in fretta."," Più codice imperfetto, più problemi.",[26,417,419],{"id":418},"spesso-il-team-non-conosce-davvero-il-codice-che-finisce-in-produzione","Spesso il team non conosce davvero il codice che finisce in produzione",[11,421,422],{},"Qui c'è un problema che chi guida un team dovrebbe tenere bene a mente: quando uno sviluppatore usa l’AI per generare codice, quel pezzo finisce nel progetto, ma nessuno ci ha davvero ragionato sopra. Nessuno ha fatto scelte consapevoli, nessuno si è costruito un modello mentale di come funziona quel codice, riga per riga.",[11,424,425],{},"Poi, puntualmente, qualcosa si rompe. Nel software succede sempre. E invece di risolvere in fretta, ci si mette di più. Lo sviluppatore si trova a fare il detective su un pezzo di codice che, ufficialmente, è suo… ma che in realtà non ha mai davvero progettato.",[11,427,428],{},"In pratica, le stime diventano un terno al lotto. Il bug che “dovrebbe portar via un’ora” si trasforma in un giorno intero. E ripeti questa storia, tutte le settimane, tutto l’anno.",[26,430,432],{"id":431},"le-decisioni-strategiche-restano-umane","Le decisioni strategiche restano umane",[11,434,435],{},"L'AI scrive codice, sì. Ma non decide quale codice serve.",[11,437,438],{},"Che architettura regge il salto da 100 a 10.000 utenti? Quali compromessi sono accettabili per lanciare prima senza tagliarsi le gambe per il futuro? Come si struttura un sistema perché il team non si blocchi da solo quando lavora in parallelo?",[11,440,441,442,445],{},"Queste cose richiedono esperienza vera, conoscenza del contesto, una visione chiara sul prodotto. L’AI, queste cose, non le ha. Può darti una risposta generica, se gliela chiedi, ma le decisioni di architettura che separano un prodotto che scala da uno che va ",[98,443,444],{"href":100},"riscritto da zero"," tra 18 mesi sono dettagliate, dipendono dal contesto e richiedono giudizio umano.",[11,447,448],{},"Quando costruisci un prodotto software, le scelte più rischiose e costose non sono sul codice, ma sulla struttura. E qui l’AI non ti dà una mano. Almeno ancora non oggi.",[21,450,452],{"id":451},"chi-ci-guadagna-davvero-con-lai-nello-sviluppo-software","Chi ci guadagna davvero con l'AI nello sviluppo software",[11,454,455],{},"Arriviamo al punto: chi gestisce team e fa assunzioni deve capirlo bene.",[11,457,458],{},"Gli strumenti di AI aiutano di più chi ha meno bisogno di aiuto: gli sviluppatori senior. Quelli che costano di più. Il motivo è semplice. Chi ha esperienza sa fare la domanda giusta, perché l’output dell’AI dipende molto da come la interroghi; sa giudicare il codice che riceve e scartarlo se non va bene; sa dove inserirlo nel sistema e come adattarlo al resto del progetto; sa riconoscere problemi prima che diventino bug in produzione.",[11,460,461,462,466],{},"I junior spesso non hanno ancora sviluppato questi filtri. Prendono il codice generato, lo infilano nel progetto senza capirlo davvero, e costruiscono sopra fondamenta che non conoscono. Quando qualcosa si rompe, non hanno gli strumenti per venirne a capo. È il motivo per cui ",[98,463,465],{"href":464},"/blog/design-pattern-oltre-il-linguaggio","i design pattern valgono più di qualsiasi linguaggio",": servono a riconoscere se la struttura proposta dall'AI ha senso oppure no.",[11,468,469],{},"L’AI moltiplica le capacità di chi già sa cosa fare. Non sostituisce la competenza.",[11,471,472],{},"Questa cosa si riflette direttamente sulle scelte di hiring: un team di cinque senior con AI produce di più (e meglio) di dieci junior con gli stessi strumenti. E ti costa meno in manutenzione, alla lunga.",[21,474,476],{"id":475},"cosa-cambia-davvero-per-chi-decide","Cosa cambia davvero per chi decide",[11,478,479],{},"Se guidi un team, gestisci un budget o una roadmap, il primo punto è non ridurre il team ma spostarne il lavoro. L'AI non elimina il bisogno di sviluppatori: cambia il tipo di attività su cui li vuoi concentrare. Il tempo risparmiato sulle task ripetitive va investito in revisione del codice, test e ragionamento architetturale, non in una corsa cieca ad aggiungere feature.",[11,481,482],{},"Conta anche puntare sulla competenza più che sulla quantità. Uno sviluppatore senior che sa guidare e valutare l’AI vale spesso più di tre junior che si fidano ciecamente di ciò che esce. Quello che sembra un risparmio all’inizio si trasforma facilmente in un costo pesante dopo pochi mesi.",[11,484,485],{},"Va poi considerata la revisione come parte del processo. Se il flusso è “genera con AI, poi deploy”, stai accumulando debito tecnico a una velocità pericolosa. Quel codice va letto, capito e validato da qualcuno che sappia davvero cosa sta guardando. Allo stesso modo non bisogna farsi ingannare dalle demo: con l'AI è facilissimo tirare fuori un prototipo brillante in un pomeriggio, ma tra “funziona nella demo” e “regge in produzione con mille utenti contemporanei” resta un abisso.",[11,487,488,489,493],{},"Infine bisogna monitorare il debito tecnico. Chiedi al team quanto tempo passa a sistemare problemi vecchi rispetto a costruire cose nuove. Se quella percentuale cresce mese dopo mese, la velocità iniziale si sta trasformando in zavorra. E attenzione a non ",[98,490,492],{"href":491},"/blog/aggiungere-sviluppatori-progetto","aggiungere persone"," pensando che questo risolva il problema, perché spesso lo aggrava.",[21,495,497],{"id":496},"lai-amplifica-la-competenza-non-la-sostituisce","L'AI amplifica la competenza, non la sostituisce",[11,499,500],{},"L'AI non ha reso lo sviluppo software più facile. Ha velocizzato il lavoro meccanico, ma la parte che richiede giudizio, esperienza e visione è rimasta. Anzi, ora pesa ancora di più.",[11,502,503],{},"Chi costruisce software non dovrebbe chiedersi “quanta gente posso tagliare grazie all'AI”, ma piuttosto \"come posso usare l'AI per far lavorare meglio le persone giuste\".",[11,505,506],{},"Le aziende che ci arrivano prima stanno giocando d’anticipo: lanciano prodotti migliori, più robusti, e ci arrivano prima degli altri. Chi invece pensa che “più veloce” voglia dire “più facile” finisce per costruire roba che fra un anno dovrà rifare da capo.",[11,508,509],{},"E questa differenza, alla lunga, vale centinaia di migliaia di euro.",{"title":139,"searchDepth":140,"depth":140,"links":511},[512,513,518,519,520],{"id":376,"depth":140,"text":377},{"id":395,"depth":140,"text":396,"children":514},[515,516,517],{"id":399,"depth":145,"text":400},{"id":418,"depth":145,"text":419},{"id":431,"depth":145,"text":432},{"id":451,"depth":140,"text":452},{"id":475,"depth":140,"text":476},{"id":496,"depth":140,"text":497},"Sviluppo","2026-01-08","L'AI accelera lo sviluppo software ma aumenta il peso delle decisioni. Cosa cambia per chi gestisce team, budget e roadmap, e come evitare errori costosi.","/images/blog/sviluppare-con-ai.jpg",{},"/blog/2026-01-08-sviluppare-con-ai",{"title":361,"description":523},"Sviluppo software con AI: vantaggi e limiti reali","sviluppare-con-ai","blog/2026-01-08-sviluppare-con-ai",[532,171,533,534,170,535,536],"ai","gestione-team","produttivita","strategia","startup","y_sgwUwW_SJpGapyuDCUCIRi6mnEm92sEK0Bt1J4gkc",{"id":539,"title":540,"body":541,"category":345,"date":669,"description":670,"extension":159,"image":671,"meta":672,"navigation":3,"path":673,"published":3,"seo":674,"seoTitle":675,"slug":676,"stem":677,"tags":678,"updated":172,"__hash__":682},"blog/blog/2026-04-09-semplicita-nel-software.md","Semplicità nel software: perché costa più di quanto sembri",{"type":8,"value":542,"toc":658},[543,549,552,556,560,563,570,573,577,580,583,590,594,601,604,607,611,614,617,625,629,632,635,638,641,645,648,652,655],[11,544,545,548],{},[14,546,547],{},"\"Voglio un software semplice. Che basti fare click.\""," È una richiesta legittima, spesso anche la più corretta. Ma la semplicità nel software è un punto di arrivo, mai di partenza. E di solito costa più di quanto chi commissiona si aspetti, perché richiede di prendere molte decisioni al posto dell'utente e gestire in modo invisibile decine di scenari.",[11,550,551],{},"Nel software vale una regola pratica: è facile aggiungere opzioni, campi, passaggi. È più difficile toglierli senza perdere informazioni importanti, senza creare errori e senza aumentare le eccezioni.",[21,553,555],{"id":554},"perché-semplice-è-una-richiesta-costosa","Perché “semplice” è una richiesta costosa",[26,557,559],{"id":558},"dietro-ogni-click-ci-sono-molte-decisioni","Dietro ogni click ci sono molte decisioni",[11,561,562],{},"Quando l’utente preme un bottone e “succede tutto”, la complessità è stata spostata dietro le quinte.",[11,564,565,566,569],{},"Ogni scelta che l’utente ",[14,567,568],{},"non"," fa più (perché non vede un campo, non sceglie un’opzione, non legge un’istruzione) è una scelta che il sistema fa per lui. E per farla bene serve capire contesto, regole, eccezioni, priorità.",[11,571,572],{},"Esempio tipico: “un click per generare la fattura”. Dietro a quel gesto ci sono l’identificazione corretta del cliente e del contesto, i calcoli coerenti con le regole del caso, la numerazione progressiva, la generazione del formato richiesto e l’invio ai sistemi esterni, oltre alla gestione degli esiti e alla comunicazione all’utente. A chi usa il prodotto interessa un click; al team interessa che quel click non produca una fattura sbagliata, un invio fallito o uno stato incoerente. È qui che si annida il costo.",[26,574,576],{"id":575},"togliere-richiede-capire-aggiungere-richiede-soprattutto-implementare","Togliere richiede capire. Aggiungere richiede soprattutto implementare.",[11,578,579],{},"La strada “veloce” verso una prima versione spesso è: mostrare tutto e chiedere tutto all’utente (più campi, più opzioni, più passaggi). Funziona, ma scarica complessità e rischio sull’utilizzatore.",[11,581,582],{},"La strada verso la semplicità, invece, richiede analisi: capire quali informazioni sono davvero necessarie, quali si possono dedurre, quali si possono precompilare, quali si possono rimandare, quali non servono proprio.",[11,584,585,586,589],{},"Questo è il motivo per cui molte richieste di “semplicità” richiedono più iterazioni rispetto a una UI “piena di opzioni”. Perché richiede più decisione che codice. Ed è anche il motivo per cui ",[98,587,588],{"href":118},"le stime di sviluppo sono spesso imprecise",": la complessità sta nelle decisioni, prima che nel codice.",[21,591,593],{"id":592},"il-paradosso-della-semplicità","Il paradosso della semplicità",[11,595,596,597,102],{},"Una UI, cioè l’interfaccia che l’utente vede e usa, complessa è spesso il risultato “naturale” di un progetto: si aggiunge quello che serve, poi un’eccezione, poi un’altra, poi un caso particolare. Alla fine si consegna qualcosa che \"fa tutto\", ma che richiede training e supporto. È la dinamica tipica dello ",[98,598,600],{"href":599},"/blog/scope-creep-progetti-agile","scope creep",[11,602,603],{},"Una UI semplice, al contrario, è il risultato di un lavoro di riduzione: capire cosa è essenziale, togliere il superfluo, automatizzare il resto, e verificare con persone reali che ciò che sembra ovvio lo sia davvero.",[11,605,606],{},"È per questo che “semplice” è un obiettivo di prodotto, non una scorciatoia di sviluppo.",[21,608,610],{"id":609},"semplice-e-subito-raramente-convivono","“Semplice” e “subito” raramente convivono",[11,612,613],{},"Qui nasce la tensione tipica: chi commissiona vuole un’esperienza “a prova di click” e tempi stretti.",[11,615,616],{},"Quando i tempi sono compressi, la probabilità più alta è questa: si consegna una versione che funziona ma è più “carica”, perché non c’è stato spazio per iterare, testare, rivedere e togliere.",[11,618,619,620,624],{},"La soluzione più onesta, di solito, è: partire con poco, farlo funzionare bene, e semplificare in iterazioni successive. È la logica del ",[98,621,623],{"href":622},"/blog/quando-lanciare-un-prodotto","lanciare presto e migliorare",", applicata alla UX: le prime versioni devono essere affidabili, poi diventano davvero semplici.",[21,626,628],{"id":627},"come-si-costruisce-davvero-la-semplicità","Come si costruisce davvero la semplicità",[11,630,631],{},"Molte richieste nascono dal desiderio di “digitalizzare ciò che facciamo oggi”. Ma replicare un processo esistente spesso significa replicarne anche i difetti. La domanda utile è un’altra: qual è il risultato che vogliamo ottenere, e qual è il percorso più diretto per arrivarci?",[11,633,634],{},"In analisi conviene togliere prima di aggiungere. Ogni “e se” introduce complessità, e dopo dieci “e se” il software che doveva essere semplice diventa un gestionale completo. La regola pratica è chiedersi, per ogni feature proposta, se il flusso principale funzionerebbe anche senza. Se la risposta è sì, quella feature può restare fuori dalla versione 1.",[11,636,637],{},"La semplicità poi va provata con utenti reali, presto. Non si decide in riunione. Si verifica sul campo, mettendo anche un prototipo grezzo davanti alle persone che useranno davvero il prodotto. Se la cosa principale si capisce senza spiegazioni, sei sulla strada giusta. Se servono istruzioni o manuali, la complessità è ancora tutta in superficie.",[11,639,640],{},"Infine bisogna accettare che la semplicità è un processo. La versione 1 raramente è davvero semplice; la versione 3 spesso lo è di più, la versione 5 ancora di più. La differenza la fanno le iterazioni guidate da osservazione e feedback, non la quantità di feature inserite fin dall’inizio.",[21,642,644],{"id":643},"euristiche-pratiche-per-chi-commissiona-software","Euristiche pratiche per chi commissiona software",[11,646,647],{},"Quando chiedi un software “semplice”, ci sono alcune domande che aiutano a evitare metà dei fraintendimenti. Bisogna chiarire semplice per chi, perché l’esperienza di un operatore esperto non è quella di un utente occasionale o di un cliente finale. Bisogna capire dove deve essere semplice: nel flusso principale, nelle eccezioni, nella configurazione, nell’onboarding. Vale la pena chiedersi anche cosa può andare storto e come il sistema dovrebbe reagire, che cosa è accettabile rimandare per non appesantire la prima versione e soprattutto qual è il costo dell’errore. Se l’errore costa molto, come succede con fatture, pagamenti o dati delicati, la semplicità richiede più rigore e più test.",[21,649,651],{"id":650},"in-sintesi","In sintesi",[11,653,654],{},"Un’interfaccia con 30 campi spesso costa meno da costruire nel breve periodo. Un’interfaccia con 3 campi e un bottone spesso costa di più perché richiede analisi, decisioni e gestione invisibile degli edge case. Ma nel medio periodo, la seconda riduce formazione, errori, supporto e frustrazione.",[11,656,657],{},"Se il team è prudente quando sente “semplice”, è consapevolezza del lavoro necessario per farlo bene.",{"title":139,"searchDepth":140,"depth":140,"links":659},[660,664,665,666,667,668],{"id":554,"depth":140,"text":555,"children":661},[662,663],{"id":558,"depth":145,"text":559},{"id":575,"depth":145,"text":576},{"id":592,"depth":140,"text":593},{"id":609,"depth":140,"text":610},{"id":627,"depth":140,"text":628},{"id":643,"depth":140,"text":644},{"id":650,"depth":140,"text":651},"2026-04-09","La semplicità nel software è il punto di arrivo, non di partenza. Un prodotto dove basta un click richiede analisi, decisioni e gestione degli scenari.","/images/blog/semplicita-nel-software.jpg",{},"/blog/2026-04-09-semplicita-nel-software",{"title":540,"description":670},"Semplicità nel software: perché costa più di quanto pensi","semplicita-nel-software","blog/2026-04-09-semplicita-nel-software",[679,680,681,535,171],"prodotto","user-experience","analisi","eKjezR-10nziaTmheUGUAF0h9BJDF4LQ-IY3GWFP5_c","2026-03-17",1776715330966]