Idea principale

Aggiornare un artefatto di prodotto ha sempre significato correggerne la versione precedente: si riapre la specifica scritta diciotto mesi fa, si cercano i paragrafi toccati dall'ultimo rilascio e li si riscrive. Il documento eredita così tutto ciò che non è stato riletto — comportamenti rimossi nel frattempo, schermate che non esistono più, ipotesi smentite dallo sviluppo.

L'altra strada consiste nel buttare la versione precedente e rigenerare l'artefatto a partire dal repository: la documentazione di supporto dopo un rilascio, il changelog, la specifica funzionale dello stato attuale. Il documento non porta più con sé l'accumulo delle sue versioni, ma la data in cui il codice è stato letto.

Il guadagno non è la velocità di scrittura. È che l'artefatto smette di essere uno stock da manutenere per diventare una proiezione che si rilancia. Una proiezione non diverge: o è scaduta o viene rifatta.

La regola si applica all'interno di uno stesso documento non appena mescola due materiali. In una scheda di oggetto di prodotto, il corpo descrive la realtà così com'è nel codice: si butta e si rifà senza perdere nulla. Gli scostamenti tra questa realtà e ciò che si vorrebbe, invece, nascono da una decisione umana, non si ritrovano da nessuna parte se li si perde, e vanno quindi in un blocco separato che nessuna rigenerazione tocca. Ciò che si rigenera e ciò che si mantiene possono convivere solo se sono visibilmente separati.

Contributo di «Ho scritto l'ontologia di un prodotto. Tre volte ho creduto di aver finito.» (2026-08-11).

Contributo di «Quattro giorni di vibe coding…» (2026-07-28). L'inversione non riguarda solo l'aggiornamento di un documento esistente: tocca anche il momento in cui viene scritto il primo documento. Su uno strumento interno costruito direttamente da un profilo di prodotto, non c'è stata alcuna specifica preliminare — la persona si è buttata, ha costruito, ha mostrato, ha ricevuto richieste di evoluzione e ha iterato. Il comportamento è emerso nel prodotto, e la documentazione funzionale è stata generata dopo, a partire dal codice. La sequenza abituale si rovescia allora del tutto: non si rigenera un documento perché non si è riusciti a mantenerlo, lo si genera perché prima non è mai stato scritto.

Perché è importante

È ciò che rende lo scostamento tra il prodotto e la sua documentazione gestibile senza disciplina. Finché si aggiorna, la divergenza si accumula a ogni iterazione saltata; non appena si rigenera, un'iterazione saltata non lascia alcun debito — la rigenerazione successiva riparte dallo stesso punto.

Cambia anche ciò che si archivia: diventa più utile conservare la capacità di rigenerare che l'ultima versione prodotta.

Sfumature e limiti

Il codice non contiene l'intenzione. Una specifica rigenerata dice che cosa fa il prodotto, non perché quel comportamento sia stato scelto né che cosa sia stato scartato — e questa perdita è invisibile, perché il documento sembra completo.

Nemmeno la rigenerazione è gratuita: richiede una rilettura, e un output sbagliato che sembra giusto costa più di un documento palesemente scaduto.

Domande aperte

• Come ci si accorge che una rigenerazione ha cancellato una decisione umana, visto che restituisce un documento perfettamente formato?