Nell'era dell'IA serve ancora partire da un MVP? 211 milioni di righe di codice dicono che il rilavoro è passato dal 3,3% al 7,1%

Lanci un’idea a un’IA e otto volte su dieci la prima cosa che ti risponde è «partiamo da una versione minima funzionante».

Suona come un giudizio. È un ricordo. L’Agile Manifesto è del 2001, The Lean Startup del 2011, e quei due testi più le centinaia di migliaia di articoli, corsi e retrospettive che ne sono derivati stanno tutti nei dati di addestramento. Se raccomanda l’iterazione non è perché abbia fatto i conti in tasca a se stessa.

Li ha fatti a noi. E le due fatture sono costruite in direzioni opposte.

Le quattro premesse su cui poggia l’MVP: tre reggono ancora

L’iterazione non è una legge di natura. È la soluzione ottima sotto un insieme preciso di vincoli, e l’insieme è questo:

• Scrivere codice è lento e caro. Una funzionalità passa da «capita» a «funzionante» in giorni-uomo.
• Modificare costa più che scrivere. Per modificare bisogna prima leggere, e leggere significa rientrare nella testa di qualcun altro — o nella propria di tre mesi fa.
• I requisiti si mettono a fuoco strada facendo. L’utente capisce cosa vuole solo vedendo qualcosa, quindi mostrargli presto qualcosa rende.
• Quella decisiva: fra un’implementazione grezza e una completa c’è un divario di costo enorme.

Quest’ultima è il basamento economico dell’MVP. Per ora salviamo in localStorage, per ora niente permessi, per ora tre valori di configurazione scritti a mano — le settimane risparmiate erano vere, e spenderle a validare un’ipotesi era davvero l’affare migliore.

Tre di quei quattro vincoli reggono ancora oggi. Il quarto non c’è più.

localStorage e PostgreSQL: nelle mani di un’IA sono minuti di differenza

Un thread su V2EX lo dice nel modo più pulito (t/1216691, dal titolo «Il pensiero MVP ha smesso di funzionare nell’era del coding con IA?»). Le parole dell’autore: descrivere a Cursor «salva i dati in localStorage» e descrivere «usa PostgreSQL con un connection pool» differisce di pochi minuti di generazione.

Se il costo è lo stesso, perché fare la versione semplificata?

Questa sola frase toglie metà del basamento. Quello che risparmi non sono più settimane, sono minuti; mentre tutto ciò che contrai in cambio non è diminuito di un’unghia: uno strato di persistenza destinato a essere sostituito, una serie di chiamate scritte sopra di esso, una migrazione da rifare.

Il grezzo non è più economico. È soltanto incompleto.

La fattura dell’IA: la voce principale è il contesto, non il compito

L’altra metà del basamento crolla sul piano della struttura di costo, e questo strato si vede meno.

Quando lanci un task agentico, la maggior parte dei token in ingresso non è mai la tua descrizione del compito. Sono il system prompt, la mappa del repository, la cronologia della conversazione, i file che ha letto. La descrizione del compito, lì dentro, è un arrotondamento.

Quello che ne discende è tutto misurato:

• A ogni nuovo tentativo l’intero contesto viene rispedito. Due tentativi bastano a triplicare il costo di una sessione.
• Contando l’overhead di contesto, il costo reale è 3–5 volte la stima ingenua — da 0,27 a 3,25 dollari per PR, e superare i 20 dollari su un singolo task in un repository complesso non ha nulla di eccezionale.
• Il paper su arXiv Cheap Code, Costly Judgment (2607.01087) ha misurato che i task agentici consumano 1000 volte i token di una normale conversazione sul codice, con una varianza fino a 30 volte fra esecuzioni ripetute dello stesso task.

Ora mettiamo affiancate l’iterazione umana e quella dell’IA.

Una persona che divide un lavoro in tre fasi paga più o meno lo stesso per fase, perché ricorda cosa ha fatto nella precedente. Il contesto le sta in testa e richiamarlo non costa nulla.

L’IA non ricorda. Il contesto se lo ricompra a ogni fase.

L’iterazione è un’assicurazione per una persona e una commissione di attrito per un’IA.

GitClear ha misurato il rilavoro: 3,3% → 7,1%

Fin qui è ragionamento. Da qui è misura.

GitClear ha analizzato 211 milioni di righe di codice modificato, seguendo un indicatore chiamato churn: la quota di codice riscritto in modo sostanziale o cancellato entro pochi giorni dal merge. Misura esattamente una cosa: non averlo fatto giusto la prima volta.

Più del doppio in due anni. Gli altri indicatori della stessa ricerca puntano nella stessa direzione:

• Copia-incolla all’interno dello stesso commit +41%
• Blocchi di codice duplicati +81%
• Costrutti che mascherano gli errori +47%
• Chiamate di funzione fra file diversi, indicatore di riuso: −35%
• Spostamenti di righe dovuti a refactoring: −70%

GitClear divide il rilavoro amplificato dall’IA in tre tipi, e ognuno è la conseguenza diretta dell’aver consegnato prima qualcosa a metà:

1. Posto sbagliato — logica e sintassi corrette, ma collocate nel punto sbagliato dell’architettura; qualcuno poi le sposta
2. Costruito due volte — reimplementare una funzionalità che esisteva già invece di riusarla
3. Riscritto giorni dopo — mergiato e poi modificato pesantemente per un caso limite o una convenzione violata

Nella stessa ricerca, le PR scritte dall’IA portano in media 10,83 problemi contro i 6,45 di quelle scritte da persone. Un fattore 1,7.

L’esperienza degli sviluppatori combacia con questi numeri. Dalla Stack Overflow Developer Survey 2026:

• L’84% usa strumenti di IA
• Il 45% dice che fare debug di codice generato dall’IA richiede più tempo che scriverlo da sé
• Il 66% indica come frustrazione principale un risultato «quasi giusto, ma non del tutto»
• E la fiducia negli output dell’IA si ferma al 3%

Un’altra indagine quantifica nel 43% le modifiche di codice generate dall’IA che richiedono debug in produzione.

«Quasi giusto» è l’espressione decisiva. Significa che il problema non emerge nel momento in cui collaudi, ma dopo il merge — e quindi ricade in pieno sull’iterazione successiva. Il giro che credevi di aver risparmiato ti viene fatturato più avanti.

«Farlo bene una volta» non è «farlo tutto in una volta»: granularità di consegna e di esecuzione

È qui che si scivola più facilmente in uno slogan: basta iterare, fate tutto in una volta. È sbagliato, e pericolosamente sbagliato.

Vanno tenute distinte due granularità:

• Granularità di esecuzione: una modifica alla volta, verificata prima della successiva. Vale ancora oggi, anzi più di prima — un’IA che tocca dieci file insieme supera quello che riesci a rivedere.
• Granularità di consegna: se quello che consegni in questo giro è un prodotto finito.

«Farlo bene una volta» riguarda la seconda. Ciò che viene vincolato è il grado di completezza, non il numero di funzionalità.

L’ambito può essere stretto — stretto quanto una pagina, un endpoint. Ma la parte che ti sei impegnato a fare in questo giro deve essere completa: strutture dati vere, non segnaposto; tutti e quattro gli stati presenti, caricamento, vuoto, errore e successo, non solo il percorso ideale; qualcosa che gira davvero e che una persona può usare, non uno screenshot.

Il problema più grosso della parola MVP è aver venduto «ambito stretto» e «fatto grezzo» in un unico pacchetto. Un tempo erano davvero legati — risparmiare voleva dire risparmiare su entrambi. Ora si separano: l’ambito deve restare stretto, ma il grezzo ha smesso di far risparmiare.

«L’MVP serve a validare ipotesi, non c’entra con l’IA» — due obiezioni su quattro reggono

Le risposte sotto quel thread di V2EX valgono più del post iniziale. Una alla volta:

1. «Il cuore dell’MVP è validare un’ipotesi. Non c’entra col codice, e non c’entra col fatto che ci sia o meno l’IA.»

Regge — e indica esattamente dove sta il problema. La parola MVP ha sempre impacchettato due cose: validare un’ipotesi e consegnare un’implementazione incompleta. Prima erano inseparabili, perché l’unico modo economico di validare un’ipotesi era costruire qualcosa di grezzo. Adesso si sono separate. L’ipotesi validala pure — solo che ora puoi farlo con qualcosa di completo.

2. «Non potrai mai conoscere in una volta sola tutti i bisogni dei potenziali utenti.»

Regge, e non è in conflitto con «farlo bene una volta». Nessuno chiede di costruire tutte le funzionalità in un solo passaggio. Si chiede che la parte costruita in questo passaggio non resti a metà.

3. «Su progetti a logica complessa, soprattutto sistemi con cicli di business intricati e macchine a stati, farlo tutto in un colpo produce un pasticcio.»

Problema vero, ma di granularità di esecuzione. Una macchina a stati complessa si costruisce ovviamente passo per passo, verificando a ogni passo. Non è un argomento per consegnare una versione che già si sa di dover riscrivere.

4. «Con l’IA iterare è velocissimo e costa pochissimo.»

Questa non regge. Le due sezioni precedenti ne sono il controesempio: a diventare veloce è la generazione, non la convergenza. Il churn che sale dal 3,3% al 7,1% misura esattamente quel divario.

Dopo aver scritto «vietato lo sviluppo per fasi» nelle mie regole globali

Nelle mie regole globali c’è una riga fissa: vietato lo sviluppo per fasi, consegnare significa prodotto finito, niente MVP e niente tappe parziali.

Tradotto in azioni concrete:

• Strutture dati vere e contenuti veri fin dal primo passaggio — niente Lorem ipsum, niente dati finti
• I quattro stati consegnati insieme: caricamento, vuoto, errore, successo
• Provarlo di persona prima di considerarlo consegnato — aprirlo nel browser, eseguirlo da riga di comando, colpire l’endpoint con curl

Il prezzo è reale: la prima descrizione diventa molto più lunga. Devi pensare a fondo confini, stati e strutture dati prima di cominciare. Quel lavoro non se l’è preso l’IA: si è solo spostato da «costretto a pensarci al terzo giro di rilavoro» a «pensato prima che il primo giro cominci».

Il ritorno è altrettanto diretto: non spieghi la stessa cosa una seconda e una terza volta. E rispiegare è proprio la voce più cara della fattura qui sopra.

Quanto stretto tagliare l’ambito: qui l’IA non aiuta

Questa domanda continua a non avere risposta.

«Farlo bene una volta» presuppone che l’ambito sia stato tagliato bene. Tagliato troppo largo, «una volta» diventa «una volta molto lunga». Tagliato troppo stretto, quello che hai costruito non valida più niente. Dove cade quel taglio dipende dal giudizio su utenti e situazioni — e il titolo di quel paper aveva già detto tutto: il codice è diventato economico, il giudizio no.