Il benchmark che smonta gli agenti rivela il rischio N+1 nel tuo repo Replit

Gli agenti sembrano veloci finché il lavoro resta piccolo

Un nuovo benchmark dedicato al refactoring su larga scala mette in discussione l’idea che un coding agent capisca davvero un intero repository. SWE-Bench ProMax raccoglie 170 attività reali distribuite su sette linguaggi e, secondo la fonte, il modello migliore arriva a un resolve rate del 41,2%. Il punto non è soltanto il punteggio: le attività più difficili attraversano più file, dipendenze e comportamenti collegati.

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

Se hai spedito un prodotto costruito con un agent, la domanda da portarti dietro è concreta: il codice funziona anche quando il numero di dati cresce, oppure sembra corretto soltanto perché finora hai provato pochi record?

Cosa significa se il tuo codice l’ha scritto Replit

Replit ti permette di passare rapidamente da idea a prodotto: autenticazione, database, dashboard, pagine pubbliche e API possono prendere forma in una singola sessione di lavoro. È un vantaggio reale. Il problema nasce quando una scelta locale diventa costosa lungo tutto il percorso di una richiesta.

Prendi una dashboard che mostra gli ordini di un cliente. Il backend recupera la lista degli ordini con una query. Poi, per ogni ordine, esegue una query separata per caricare il cliente, gli articoli, lo stato della spedizione o gli allegati.

Con dieci ordini, tutto sembra accettabile. Con cento, il server esegue centinaia di query per una sola pagina. Con più utenti contemporanei, il database passa più tempo a ripetere richieste che a servire il prodotto.

Questo è il problema N+1: una query iniziale per ottenere una lista, seguita da una nuova query per ogni elemento della lista. Non è necessariamente un errore di sintassi. È un difetto di comportamento che spesso resta invisibile durante il prototipo.

In un repo creato o ampliato con Replit, può comparire quando:

• un ciclo chiama un repository, un ORM o un endpoint per ogni elemento;
• una relazione viene caricata in modo implicito dentro una serializzazione;
• una pagina esegue richieste separate per ogni card visualizzata;
• un resolver GraphQL recupera i figli senza batching;
• un endpoint restituisce dati corretti ma senza limite, paginazione o filtro;
• una funzione server ripete la stessa lettura durante il rendering di una lista.

Replit può aiutarti a costruire il flusso. Non può trasformare automaticamente una schermata funzionante in una prova che il flusso abbia un costo prevedibile. Una dashboard vuota non dimostra che la query regga quando la tabella contiene migliaia di righe.

Perché ora ti serve un audit: il verdetto che manca

Il benchmark sul refactoring mette in evidenza un limite preciso: gli agenti possono gestire bene una modifica locale, ma perdere il quadro quando il comportamento dipende da molte parti del sistema. N+1 è proprio questo tipo di problema. La riga sospetta può stare nel controller, mentre l’effetto reale nasce nell’ORM, nel serializer, nel componente frontend o in una funzione chiamata indirettamente.

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

una richiesta che restituisce una lista esegue un numero di accessi al database proporzionato al flusso, oppure cresce una query alla volta con ogni elemento?

Per arrivare al verdetto bisogna ricostruire il percorso completo:

1. quale endpoint o pagina riceve la richiesta;
2. quale query iniziale recupera la lista;
3. quali funzioni vengono chiamate mentre i risultati vengono trasformati;
4. se ogni elemento attiva una lettura aggiuntiva;
5. quali relazioni vengono caricate implicitamente;
6. se esistono paginazione, limiti e filtri;
7. cosa succede quando la lista è grande o il database risponde lentamente.

Un audit VibeInspect prende il repository ZIP, lo analizza con specialisti AI e restituisce un PDF con score e verdetto. Nel piano Diagnostic trovi evidenze riferite a file e righe, utili per collegare il punto in cui nasce la query al percorso che la moltiplica.

Non è un test di carico e non modifica il codice. Non misura la latenza reale del tuo ambiente di produzione. Ti dà però la risposta che spesso manca dopo il prototipo: il rischio N+1 è presente nel percorso analizzato, è mitigato oppure non è dimostrato?

Il nemico non è avere usato Replit. Il nemico è confondere una pagina che funziona con una pagina che ha un costo di esecuzione sotto controllo.

Le evidenze che distinguono un N+1 reale da una semplice ripetizione

Un audit non dovrebbe segnalare ogni ciclo come problema. Una ripetizione può essere necessaria. Il rischio emerge quando la ripetizione causa accessi esterni o query dipendenti dalla quantità di risultati.

Le combinazioni più importanti sono queste:

• Query dentro un ciclo. Il codice recupera una collezione e poi chiama database o API per ogni elemento.
• Lazy loading durante la serializzazione. Il controller sembra eseguire una sola query, ma l’accesso a una relazione attiva letture aggiuntive mentre l’oggetto viene convertito in JSON.
• Resolver o componenti senza batching. Ogni card, riga o nodo richiede separatamente gli stessi dati correlati.
• Liste senza limite. Anche una query ben strutturata può diventare un problema se restituisce tutti i record senza paginazione o filtro.
• Richieste duplicate. Frontend, backend e funzione di composizione possono recuperare la stessa informazione più volte nello stesso flusso.
• Dati corretti ma costo non osservabile. Senza conteggio delle query, log o metriche, il problema resta nascosto finché il database non rallenta.

L’evidenza più forte non è “c’è un for”. È una catena: endpoint, query iniziale, iterazione, chiamata dipendente dall’elemento, numero di risultati e assenza di un limite efficace.

Cosa un linter non vede

Un linter può segnalare una variabile inutilizzata, un tipo incoerente, un import non valido o alcune chiamate potenzialmente rischiose. Non sa però se una query viene eseguita una volta o cento volte dopo che il framework ha risolto una relazione.

Non vede, da solo, che:

• il serializer attiva lazy loading per ogni record;
• una lista pubblica restituisce migliaia di righe senza paginazione;
• una query dell’endpoint viene ripetuta da più componenti durante il rendering;
• un cache miss trasforma ogni richiesta in una sequenza di letture duplicate;
• un resolver figlio interroga il database anche quando i dati erano già disponibili;
• il caso nominale funziona perché il dataset di sviluppo contiene soltanto pochi elementi.

Nemmeno i test felici bastano. Puoi verificare che una dashboard mostri correttamente cinque ordini senza misurare quante query siano state eseguite. Puoi avere test verdi e un percorso che degrada rapidamente quando la lista cresce.

Il linter controlla la forma locale. L’audit ricostruisce il costo comportamentale del flusso.

Cosa fare questa settimana

Scegli una sola pagina o API che restituisce una lista: ordini, utenti, fatture, messaggi o documenti.

Poi annota:

• query iniziale;
• numero massimo di elementi restituiti;
• relazioni caricate per ogni elemento;
• chiamate a database o servizi esterni dentro i cicli;
• presenza di paginazione, filtri e batching;
• metrica o log che mostra quante query vengono eseguite per richiesta.

Prova lo stesso percorso con tre dataset: piccolo, medio e grande. Non limitarti a guardare se la risposta è corretta. Conta il lavoro che il sistema compie per produrla.

Se non sai indicare il file, la funzione e il punto in cui il numero di query smette di essere prevedibile, non aggiungere ancora un’altra 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 problema è tecnico e hai bisogno di evidenze su query, chiamate ripetute e percorso di esecuzione.

L’obiettivo non è dimostrare che Replit abbia scritto codice “sbagliato”. È sapere se il tuo prodotto continua a comportarsi bene quando la lista non è più vuota e il database deve davvero lavorare.