La programmazione intuitiva, che consiste nel descrivere ciò che si desidera e accettare il codice generato da un modello senza un'analisi approfondita, permette di realizzare prototipi in poche ore e sistemi fragili in mesi. Non è una tecnica illegittima: è un'ottima tecnica per esplorare un'idea, ma pericolosa per costruire qualcosa da cui un'azienda dipenderà.
Il problema sta nella confusione tra i due. Ciò che emerge da una sessione di sviluppo di un prodotto generato dagli utenti assomiglia molto a un prodotto reale: ha un'interfaccia, risponde, fa ciò che gli è stato richiesto di fronte alla persona che lo ha richiesto. La differenza con un prodotto reale non sta in ciò che fa, ma in tutto ciò che non è stato deciso: cosa succede in caso di errore, chi può vedere cosa, come verrà modificato tra un anno e chi capisce perché è stato scritto in quel modo.
|
Dimensione |
Prototipo generato |
Sistema in produzione |
|---|---|---|
|
Scopo |
Per dimostrare che l'idea è possibile |
Funziona in modo affidabile per anni |
|
Errori |
Vengono corretti rigenerando |
Sono fissati senza rompere il resto |
|
Dati |
Testato, pulito |
Reale, incompleto, contraddittorio |
|
Sicurezza |
Fuori portata |
Permessi, crittografia, audit |
|
Manutenzione |
Non applicabile |
Il 60-70% del costo totale |
|
Titolarità del criterio |
Il modello ha determinato la struttura |
Qualcuno lo ha deciso e sa perché. |
L'ultima riga è quella che ha più peso nel medio termine. Quando nessuno ha deciso la struttura, nessuno può difenderla o farla evolvere. Diventa un testo che deve essere interpretato ogni volta che viene toccato, e tale interpretazione richiede tempo a ogni futura modifica.
Non si tratta solo di un'intuizione del settore. GitClear, analizzando 211 milioni di righe di codice tra il 2020 e il 2024, ha scoperto che il lavoro di refactoring, ovvero la riorganizzazione del codice esistente per renderlo comprensibile, è diminuito da circa 251 TP3T di modifiche totali nel 2021 a meno di 101 TP3T nel 2024, mentre il copia-incolla è aumentato da 8,31 TP3T a 12,31 TP3T e i blocchi duplicati sono aumentati di otto volte.
Il report DORA 2024 di Google Cloud, basato su un sondaggio condotto su circa 39.000 professionisti, ha misurato l'impatto sulla distribuzione: un aumento del 25% nell'adozione dell'IA è risultato correlato a una diminuzione dell'1,5% nel throughput e a una diminuzione del 7,2% nella stabilità. Nello stesso studio, il 39,2% degli sviluppatori ha dichiarato di avere poca o nessuna fiducia nel codice generato.
Lo schema che entrambi descrivono è coerente: si produce di più, si rivede la stessa quantità e si riorganizza di meno. La conseguenza non si manifesta nella prima settimana, ma quando è necessario apportare delle modifiche.
Sarebbe sciocco rinunciare a uno strumento che aumenta significativamente la velocità di esplorazione. Ecco le applicazioni in cui il vibe coding è chiaramente la scelta giusta:
In tutti e quattro i casi c'è una caratteristica comune: il risultato non deve sopravvivere. Nel momento in cui qualcuno dice "funziona quasi, mettiamolo in produzione", l'utilizzo cambia categoria e i criteri dovrebbero cambiare di conseguenza.
Prima di mettere in produzione qualcosa generato in questo modo, è consigliabile rispondere a questa domanda:
Un prototipo che risponde a cinque domande non è più un prototipo: è un sistema costruito rapidamente, che è esattamente ciò a cui puntiamo. La velocità non è mai stata un problema.
Lo schema che riscontriamo negli audit è sempre lo stesso. Un piccolo team realizza in tre settimane ciò che prima richiedeva tre mesi. Il management conclude, a ragione, che lo sviluppo è stato reso più economico. Vengono approvate altre iniziative utilizzando gli stessi criteri.
Sei mesi dopo, ogni modifica richiede più tempo della precedente, nessuno vuole toccare due moduli specifici e le stime non sono più affidabili. Questo è il quadro clinico del debito tecnico, e ne abbiamo discusso in dettaglio in Il collo di bottiglia è ancora una volta l'architettura.
Ciò che colpisce è che la diagnosi raramente ne individua l'origine, perché la velocità iniziale era reale e tutti la ricordano come un successo.
Lo schema che riscontriamo negli audit è sempre lo stesso. Un piccolo team realizza in tre settimane ciò che prima richiedeva tre mesi. Il management conclude, a ragione, che lo sviluppo è stato reso più economico. Vengono approvate altre iniziative utilizzando gli stessi criteri.
Sei mesi dopo, ogni modifica richiede più tempo della precedente, nessuno vuole toccare due moduli specifici e le stime non sono più affidabili. Questo è il quadro clinico del debito tecnico, e ne abbiamo discusso in dettaglio in Il collo di bottiglia è ancora una volta l'architettura.
Ciò che colpisce è che la diagnosi raramente ne individua l'origine, perché la velocità iniziale era reale e tutti la ricordano come un successo.
Non c'è bisogno di scegliere tra generare velocemente e costruire bene. Le due fasi devono essere separate e bisogna specificare chiaramente in quale ci si trova.
Fase di esplorazione. Genera quello che vuoi, senza un'attenta revisione, con dati falsi e senza pensare alla manutenzione. L'obiettivo è imparare.
Punto decisionale. Qualcuno dichiara che l'idea è valida. È qui che viene presa la decisione che quasi nessuno prende: Ciò che è stato esplorato viene buttato via. Ciò che viene preservato è la conoscenza, non il codice.
Fase di costruzione. L'architettura viene definita, il modello dati viene stabilito, i contratti vengono redatti e quindi si ricorre alla generazione assistita, ora all'interno di una struttura definita da una persona.
Buttare via il prototipo potrebbe sembrare uno spreco, ma non lo è: il prototipo ha già assolto al suo scopo, ovvero rispondere a una domanda. Preservarlo è ciò che trasforma uno strumento di esplorazione nelle fondamenta di un edificio.
Questa separazione è il motivo per cui in TCG-SAF™ l'architettura precede la costruzione. Non per ragioni cerimoniali: perché è l'unico modo per sfruttare la velocità di generazione senza ereditare il disordine.
Si tratta della pratica di generare software descrivendo ciò che si desidera e accettando il codice prodotto da un modello senza esaminarlo a fondo. È molto efficace per esplorare idee e costruire prototipi, ma problematico quando il risultato viene implementato in produzione senza essere riprogettato.
Solo se risponde a cinque domande: qualcuno sa spiegare perché è strutturato in questo modo? Esistono test che rilevano le regressioni? È definito quali dati vengono elaborati e chi può visualizzarli? Esiste una registrazione e un meccanismo per ripristinare il normale funzionamento? E c'è qualcuno che può occuparsene entro un anno?.
I dati indicano un cambiamento di tendenza piuttosto che un peggioramento diretto. GitClear ha documentato che il refactoring è diminuito da circa 25% di modifiche totali nel 2021 a meno di 10% nel 2024 e che la duplicazione è aumentata di otto volte. DORA ha misurato un calo della produttività e della stabilità nel 2024, in concomitanza con l'aumento dell'adozione dell'IA.
Per convalidare un'idea prima di investire, esplora alternative di interfaccia, crea strumenti interni usa e getta o impara un nuovo ambito. La caratteristica comune è che il risultato non deve necessariamente durare nel tempo.
Separare le fasi: preservare la conoscenza e scartare il codice. Quindi definire l'architettura, il modello dati e i contratti, e riutilizzare la generazione assistita all'interno di tale struttura decisa da una persona.
Perché la velocità iniziale è reale e viene ricordata come un successo, mentre il costo diventa evidente quando qualcosa deve essere modificato: le modifiche richiedono sempre più tempo, ci sono moduli che nessuno vuole toccare e le stime smettono di essere affidabili.
Avete in produzione qualcosa che è nato come prototipo? La nostra analisi tecnica vi dirà, in 10 giorni lavorativi e a un prezzo fisso, cosa si può conservare, cosa necessita di una ristrutturazione e cosa comporta costi aggiuntivi mensili. Richiedi la verifica →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
