Il benchmark smonta il mito del codice AI: controlla il tuo repo Replit

Gli agenti scrivono codice: il problema arriva quando devono capirlo tutto insieme

Un nuovo benchmark dedicato al refactoring su larga scala mette un limite concreto all’entusiasmo per gli agenti di coding: il modello migliore ha raggiunto un resolve rate del 41,2%. Il test raccoglie 170 casi reali distribuiti su sette linguaggi e prova a misurare ciò che molte valutazioni più semplici lasciano fuori: cambiamenti che attraversano più file, dipendenze e comportamenti.

La notizia completa è Most coding agent benchmarks skip large-scale refactoring. Not this one.

Il punto non è che gli agenti siano inutili. È che un codice può compilare, superare i test disponibili e restare sbagliato quando più parti del sistema si muovono insieme. Nel software reale, il rischio spesso compare proprio lì: nel tempo, nella concorrenza e nell’ordine con cui arrivano le operazioni.

Cosa significa se il tuo codice l’ha scritto Replit

Replit ti permette di trasformare rapidamente un’idea in un’app funzionante: interfaccia, API, database, autenticazione e deploy possono prendere forma nello stesso flusso. È un vantaggio reale, soprattutto quando vuoi validare un prodotto senza passare settimane a preparare l’infrastruttura.

Il buco concreto che devi verificare oggi è uno solo: la race condition nei flussi che aggiornano lo stesso stato.

Immagina un’app di prenotazioni. Due utenti vedono un posto ancora disponibile e inviano la richiesta quasi nello stesso momento. Oppure un utente fa doppio clic su “Conferma”, mentre un worker sta già elaborando la prima richiesta. Se il codice legge lo stato, decide che la risorsa è libera e solo dopo la modifica, due operazioni possono superare entrambe il controllo.

Il risultato può essere una prenotazione duplicata, un saldo aggiornato due volte, un ordine marcato come completato mentre un rimborso è già partito o un record scritto in modo parziale.

Non serve un traffico da grande piattaforma. Basta che due richieste arrivino abbastanza vicine da interlevarsi nel modo sbagliato.

In un repo costruito con Replit, la race condition può nascondersi in:

• un controllo if seguito da un aggiornamento separato;
• due endpoint che modificano lo stesso record con regole diverse;
• un job asincrono che lavora mentre la richiesta HTTP non è ancora terminata;
• un contatore aggiornato senza transazione o lock;
• un webhook elaborato due volte perché lo stato viene salvato dopo l’azione;
• un retry che ripete un’operazione non idempotente;
• una cache che restituisce uno stato vecchio proprio mentre il database cambia.

Replit non è il problema. Il problema è confondere un flusso che funziona in condizioni normali con un flusso che mantiene le proprie invarianti quando due attori agiscono contemporaneamente.

Perché ora ti serve un audit: il verdetto sul comportamento concorrente

Il benchmark citato in apertura è utile perché sposta l’attenzione dalla generazione locale alla comprensione del sistema. Una modifica che coinvolge più componenti non si valuta soltanto guardando se il codice nuovo è sintatticamente corretto. Devi capire cosa succede quando gli eventi si sovrappongono.

Per il tuo repo Replit, l’audit deve rispondere a una domanda precisa:

se due richieste tentano di modificare la stessa risorsa nello stesso momento, il sistema garantisce un solo risultato valido oppure lascia che l’ordine delle operazioni decida l’esito?

Un audit VibeInspect serve a ricostruire il percorso completo:

1. quale endpoint o job riceve la richiesta;
2. quale stato legge prima della modifica;
3. dove viene applicata la regola di business;
4. quando avviene la scrittura sul database;
5. se esiste una transazione o un vincolo atomico;
6. cosa succede quando la richiesta viene ripetuta;
7. se worker, webhook e frontend possono eseguire lo stesso flusso in parallelo.

Il verdetto non dovrebbe essere “c’è una funzione che aggiorna il record”. Dovrebbe essere qualcosa di operativo: il flusso protegge l’invariante anche con richieste concorrenti, oppure esiste un percorso in cui due operazioni possono leggere lo stesso stato e produrre un risultato incompatibile.

VibeInspect prende il repository ZIP, lo analizza con specialisti AI e restituisce un PDF con score e verdetto. Nel piano Diagnostic il report include evidenze riferite a file e righe. Non modifica il codice, non esegue un test di carico e non sostituisce una verifica dell’ambiente reale. Ti aiuta però a capire se il comportamento concorrente è governato dal repo o lasciato a condizioni fortunate.

Il nemico non è aver usato Replit. Il nemico è spedire un flusso critico senza sapere cosa succede quando due utenti fanno la stessa cosa nello stesso istante.

Perché ora ti serve un audit: le evidenze che devi collegare

Una race condition raramente appare in una singola riga. Si dimostra collegando lettura, decisione e scrittura.

Cerca soprattutto queste combinazioni:

• Read-then-write separati. Il codice legge “disponibile”, esegue controlli e aggiorna in un secondo momento senza una condizione atomica.
• Controllo applicativo senza vincolo sul database. Un if nel backend non basta se due richieste possono superarlo prima della scrittura.
• Transazioni assenti o troppo corte. Una transazione che copre solo l’insert, ma non la verifica dello stato, può lasciare scoperto il passaggio decisivo.
• Endpoint duplicati. Il percorso web, il webhook e il job in coda possono applicare la stessa regola senza condividere una protezione.
• Retry non idempotenti. Se un timeout non chiarisce se l’operazione sia stata completata, il tentativo successivo può duplicare l’effetto.
• Stato derivato dalla cache. Un valore cached può guidare una decisione mentre il database contiene già uno stato diverso.
• Assenza di identificatori di operazione. Senza una chiave o un riferimento univoco, diventa difficile riconoscere che due richieste rappresentano lo stesso comando.

L’audit serve a distinguere il semplice sospetto dal rischio dimostrabile. Non cerca soltanto “manca un lock”. Cerca il percorso in cui una decisione dipende da uno stato che può cambiare prima che l’operazione finisca.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, un tipo incoerente, una promessa non gestita o una regola di stile violata. Può individuare alcuni pattern sospetti, ma non conosce da solo l’invariante che il tuo prodotto deve proteggere.

Non vede, da solo, che:

• due richieste leggono entrambe un saldo prima che una delle due scriva;
• un endpoint aggiorna lo stato senza verificare il valore attuale;
• il worker e la richiesta web possono eseguire la stessa azione;
• un retry parte dopo un timeout senza sapere se il primo tentativo sia arrivato a destinazione;
• un vincolo esiste per gli insert ma non per gli update;
• un test usa una sola richiesta alla volta e quindi non esercita la concorrenza;
• una risposta positiva viene restituita prima che la scrittura definitiva sia confermata.

Nemmeno una suite di test verde è sufficiente se prova soltanto il caso nominale. Il caso importante è spesso: due richieste simultanee, un database lento, una risposta che arriva fuori ordine, un doppio clic o un worker che riparte dopo un errore.

Il linter controlla regole locali. L’audit verifica se il sistema mantiene il comportamento promesso quando il tempo entra in gioco.

Cosa fare questa settimana

Scegli un solo flusso che modifica valore o stato: prenotazione, pagamento, saldo, ordine, disponibilità, invito o cambio di ruolo.

Disegna il percorso in sei passaggi:

• input ricevuto;
• stato letto;
• regola applicata;
• scrittura eseguita;
• risposta restituita;
• eventuale retry o job successivo.

Poi chiediti cosa succede se due richieste entrano tra il secondo e il quarto passaggio. Verifica se il database protegge davvero la condizione, se l’operazione è idempotente e se tutti i punti di ingresso usano la stessa regola.

Prova anche a trovare un test che simuli due richieste concorrenti. Se non esiste, non assumere che il flusso sia corretto soltanto perché una richiesta singola funziona.

Se non sai indicare file, funzione e vincolo che impediscono il doppio effetto, non aggiungere ancora una feature generata dall’AI. Ti serve prima un verdetto sul repo.

Carica lo ZIP su VibeInspect.ai. Per questo caso sceglierei il piano Diagnostic, perché il rischio è tecnico e hai bisogno di evidenze su file, righe e percorso concorrente.

L’obiettivo non è dimostrare che Replit abbia scritto codice “sbagliato”. È sapere se il tuo prodotto mantiene la stessa promessa quando due utenti, due worker o due retry arrivano insieme.