Più codice generato dall'AI non significa meno debito nel tuo repository

Generare più codice non ripaga il debito tecnico

C'è una convinzione che gira parecchio in questi mesi: se il modello scrive il codice al posto tuo, allora hai chiuso il ticket e ridotto il lavoro arretrato. L'articolo More Generated Code Is Not Less Debt: A Myth FAQ smonta questa idea con una frase che vale la pena rileggere: la generazione economica di codice ha cambiato solo il costo di scrivere, non chi possiede quel codice, chi lo rivede e quale sia il suo raggio d'impatto in caso di guasto.

È un punto che tocca chi costruisce prodotti veri. Aggiungere dodici file in venti minuti sembra progresso, ma le righe di codice non sono ticket chiusi. L'inventario può crescere mentre la board resta verde. E ogni file senza un proprietario chiaro non è produttività: è debito che aspetta di presentare il conto, di solito nel momento peggiore.

Cosa significa se il tuo codice l'ha scritto Cursor

Se hai sviluppato e pubblicato con Cursor, la questione non è la qualità del modello. Cursor produce codice sintatticamente corretto, spesso leggibile, che gira al primo colpo in locale. Il problema è un altro: nessuno ha stabilito quali invarianti quel codice non deve mai rompere, e nessuno ha messo il proprio nome accanto alle scelte fatte.

Un caso concreto è quello dei test generati. Cursor ti propone file di test insieme al codice, la suite diventa verde, e la sensazione è di essere coperti. Ma un test scritto per rispecchiare l'implementazione non verifica il comportamento che l'utente si aspetta: congela i bug di oggi trasformandoli in specifica. È debito travestito da spunta verde.

Pensa a un modulo di fatturazione generato con l'assistente. Il file prorate.py esiste, il test test_prorate.py pure, tutto sembra fatto. Poi apri il test e scopre che controlla solo il valore restituito da una funzione di supporto, non se un utente rischia di essere addebitato due volte al cambio di piano. La spunta verde c'è. La garanzia sul comportamento no.

Perché ora ti serve un audit

Il motivo per cui un audit conta è semplice: la velocità con cui l'AI produce codice ha spostato il collo di bottiglia dalla scrittura alla comprensione. Prima il limite era battere sulla tastiera. Oggi il limite è sapere che cosa hai davvero in produzione, chi ne risponde e dove può fare danni.

Quando parti da uno ZIP del tuo repository e lo sottoponi a un audit come VibeInspect, ottieni una cosa che il flusso di generazione non ti dà: un verdetto esterno. Non un altro turno del modello che rigenera il codice con parole diverse, ma un'analisi che ti dice in che stato è il progetto e quali punti meritano attenzione prima che diventino un problema notturno.

Questo è utile soprattutto se non hai avuto tempo di rivedere riga per riga tutto ciò che l'assistente ha prodotto. La rigenerazione sembra gratis finché il contesto è caldo, ma il prompt di tre mesi fa è sparito e la forma del codice in produzione è già cambiata sotto gli stessi nomi. Un audit fotografa il presente, non la sessione di chat che non c'è più.

Con VibeInspect il codice sorgente non resta su nessun server: viene analizzato e poi cancellato al termine. Non è un pentest, non corregge il codice e non promette sicurezza assoluta. Ti dà evidenze su cui decidere, che è esattamente quello che manca quando ti affidi al fatto che "il modello l'ha scritto".

Cosa un linter non vede

Un linter è prezioso, ma opera sulla superficie. Controlla stile, import inutilizzati, variabili non usate, formattazione. Non ha idea di cosa il tuo codice debba fare per l'utente. Nel caso della fatturazione, un linter fa passare senza fiatare una funzione che addebita due volte, perché sintatticamente è perfetta.

Quello che sfugge a un linter è il livello semantico: se un test verifica un comportamento reale o solo il proprio riflesso, se una scelta di autorizzazione è coerente, se il file appena aggiunto ha davvero un proprietario. Un linter conta le righe, non risponde alla domanda "chi possiede questo codice alle due di notte?".

Allo stesso modo, un check che verifica solo l'esistenza di un file di test passa sempre: basta che ci sia un file con "test" nel nome. Ma la presenza di un test non è una garanzia di comportamento corretto. Serve qualcuno, o qualcosa, che guardi il merito e non solo la forma. È la differenza tra un controllo automatico di superficie e un verdetto che tiene conto di cosa quel codice fa davvero.

Cosa fare questa settimana

Parti da un gesto concreto. Prendi il ramo su cui l'assistente ha lavorato di più e chiediti, file per file, chi ne risponde. Se non riesci a mettere un nome accanto a un modulo critico, quel modulo è debito, non progresso.

Poi apri i test generati insieme al codice e leggili come li leggerebbe un utente: verificano un comportamento visibile oppure ricopiano l'implementazione? Se ricopiano, riscrivili o cancellali, perché una copertura di facciata resta debito.

Infine, dai al tuo repository un verdetto esterno. Comprimi il progetto in uno ZIP e lancia un audit Diagnostic di VibeInspect: ottieni file, riga ed evidenze sui punti che meritano attenzione, così puoi discutere del ticket e non dell'autocompletamento. Il codice viene analizzato e poi cancellato, senza restare su alcun server.