Come consegniamo progetti 10× più veloci con implementazione assistita da LLM — e perché la qualità non ne soffre.
Il progetto a cascata è morto.
Dodici settimane di fase concettuale, sei settimane di specifica, poi mezzo anno di sviluppo in cui alla fine quasi nessuno ricorda più perché un requisito fosse finito nel capitolato. Chi ha acquistato software in questo modo negli ultimi vent'anni conosce lo schema — e il rischio che il risultato manchi il mercato.
Con l'implementazione assistita da LLM, consegniamo oggi il primo stato funzionante in giorni anziché mesi. Non il prototipo da buttare, ma una codebase che prosegue in produzione. Questo non sposta solo i piani temporali, cambia il modo in cui si prendono le decisioni.
Perché quando uno stato funzionante è sul tavolo dopo tre giorni anziché tre mesi, non si discute più su dei mockup — si clicca attraverso un sistema reale e ci si accorge subito di cosa manca. Requisiti che sulla carta sembravano plausibili si smascherano sul prodotto in funzione, in pochi minuti, come superflui o concepiti male.
Come nasce il fattore 10.
Il guadagno di velocità non nasce dal digitare più in fretta, ma dall'eliminazione dell'attrito. Boilerplate, modelli di dati, collegamenti alle API, impalcature di test — tutto ciò che un tempo era lavoro certosino di giorni, un modello lo genera in minuti. I nostri sviluppatori dedicano il loro tempo dove conta il giudizio: architettura, edge case, integrazione.
In un confronto tipico tratto dai nostri progetti: un portale clienti con auth, ruoli, tre sistemi collegati e reporting richiedeva un tempo circa quattro mesi fino al lancio in produzione. Con un build assistito da LLM, le prime due settimane sono bastate per un MVP utilizzabile, lo sviluppo completo dopo poco più di sei settimane.
Un punto è importante: il modello scrive codice, l'essere umano se ne assume la responsabilità. Ogni riga generata passa per review, test e i nostri gate di sicurezza. Nessuno fa merge senza aver letto.
Il collo di bottiglia si sposta così dalla produzione alla decisione. Non è più la domanda "quanto tempo ci vuole?" a determinare il ritmo, ma "cosa vogliamo costruire esattamente?" — e proprio a questa domanda si risponde più in fretta e più onestamente sul sistema in funzione che in qualsiasi workshop.
Perché la qualità sale, invece di scendere.
Il riflesso è comprensibile: veloce significa sciatto. Nella pratica è vero il contrario. Poiché copertura dei test, linting e documentazione non comportano quasi più alcuno sforzo aggiuntivo, nascono fin dall'inizio — invece di essere tagliati alla fine, quando il budget si fa stretto.
Iterazioni più rapide significano inoltre che le assunzioni errate emergono presto. Un errore concettuale che nel progetto classico si manifesta solo al collaudo dopo sei mesi, da noi salta fuori già nella prima settimana — quando la correzione costa ancora ore anziché settimane.
Lo misuriamo: la defect density e la quota di rilavorazione dopo il lancio, nei progetti costruiti in fretta, non sono più alte, ma più basse rispetto all'approccio classico.
Dove il fattore 10 non si applica.
L'onestà fa parte del gioco: non ogni progetto accelera di un fattore 10. Dove la complessità non sta nel codice, ma nel coordinamento, nelle approvazioni regolatorie o nella migrazione di sistemi legacy stratificati, il modello è solo un tassello tra molti. Lì l'implementazione non è mai stata il collo di bottiglia.
Anche con una logica fortemente specifica del dominio — tariffazione attuariale assicurativa, controllo critico per la sicurezza — la quota di lavoro umano resta alta, perché qui ogni errore è costoso e il modello, senza una profonda competenza specialistica, non giudica in modo affidabile.
Lo comunichiamo apertamente, invece di promettere ovunque lo stesso fattore. Il guadagno onesto, in media sull'intero progetto, è piuttosto un fattore da 3 a 5 — e nel build standard, dove domina l'attrito, proprio 10.
Cosa significa per i nostri clienti.
Newroom è un esecutore, non un consulente. La velocità non è per noi un fine a se stessa, ma la base per costruire, distribuire e gestire un prodotto — e per evolverlo dopo il lancio, invece di congelarlo.
Per il cliente il rischio si sposta: invece di scommettere un budget consistente contro un capitolato, dopo pochi giorni vede sostanza e decide sulla base di ciò che funziona. Le decisioni sbagliate non costano più mezzo progetto, ma un'iterazione.
Questa è la vera rivoluzione — non la velocità, ma la sicurezza che essa crea. Chi vede in giorni anziché credere per mesi, prende decisioni migliori.