Cursor ha spedito il refactor. Ma il tuo backend ora interroga il database 200 volte

Il benchmark che misura il lavoro che l’AI tende a saltare

Un nuovo benchmark prova a misurare una parte del lavoro software che le demo spesso evitano: i refactor grandi, distribuiti su più file e con il vincolo di non cambiare il comportamento dell’app.

Secondo l’articolo Most coding agent benchmarks skip large-scale refactoring. Not this one., il miglior modello testato ha raggiunto un resolve rate del 41,2% su SWE-Bench ProMax, una raccolta di 170 attività reali in sette linguaggi. Il benchmark è stato progettato proprio per mettere sotto pressione la comprensione cross-file, la compatibilità comportamentale e la qualità dei test.

Il punto interessante non è il numero in sé. È quello che rivela sul tuo repository: un’app può compilare, superare i test principali e avere comunque un problema strutturale che emerge solo quando il traffico cresce o i dati diventano realistici.

Cosa significa se il tuo codice l’ha scritto Cursor

Prendiamo un caso concreto: hai usato Cursor per aggiungere una pagina di dashboard con utenti, ordini e attività recenti. Il risultato funziona. La pagina si apre, i dati sono corretti e il test end-to-end passa.

Poi arriva il primo cliente con migliaia di record.

Il componente principale carica l’elenco degli utenti con una query. Per ogni utente, un’altra funzione recupera gli ordini. Per ogni ordine, una terza chiamata carica lo stato o il dettaglio associato. La richiesta che sembrava una sola operazione diventa una sequenza di query ripetute: il classico problema N+1.

Con dieci utenti non lo noti. Con cento utenti la risposta rallenta. Con migliaia, il database lavora molto più del necessario, il pool di connessioni si satura e l’endpoint diventa il collo di bottiglia dell’intera applicazione.

Cursor può aver prodotto codice ordinato, tipizzato e perfettamente coerente con il pattern già presente nel repository. Proprio per questo il problema può restare invisibile: localmente tutto sembra ragionevole. Il difetto non è una parentesi mancante. È una scelta distribuita tra query, resolver, servizi, serializzazione e dati reali.

Perché ora ti serve un audit del repository

Un linter controlla regole locali. Un test controlla scenari che qualcuno ha deciso di codificare. Un audit deve rispondere a una domanda diversa: il repository contiene un problema concreto che può diventare un incidente di performance quando il software viene usato davvero?

Per un N+1, il punto non è cercare la stringa “for” o contare quante query compaiono in un file. Serve ricostruire il percorso completo della richiesta:

• quale endpoint o pagina avvia il caricamento;
• quale servizio recupera il primo insieme di dati;
• quali funzioni vengono richiamate per ogni elemento;
• se le query vengono ripetute dentro loop, resolver o serializer;
• se esistono batch query, eager loading, join o cache;
• quale dimensione dei dati può trasformare il comportamento normale in degrado.

Il verdetto che ti serve non è “il codice sembra buono”. È qualcosa di operativo: PASS, oppure FAIL con la catena di evidenze che spiega dove nasce il costo e quale flusso utente lo attiva.

Con un audit VibeInspect puoi caricare lo ZIP del repository e ottenere un PDF con score, verdetto e, nel piano Diagnostic, file, righe ed evidenze. Non devi preparare un ambiente server e il sorgente viene cancellato a fine analisi. È un modo per trasformare il dubbio “forse Cursor ha introdotto una regressione” in una decisione verificabile prima del prossimo rilascio.

Per capire il formato e il perimetro dell’analisi puoi visitare VibeInspect.ai.

Il peso dell’audit è nelle evidenze, non nel commento generico

Un audit utile non si limita a elencare pattern sospetti. Deve separare i rischi plausibili dai falsi positivi.

Nel caso dell’N+1, un’evidenza forte collega almeno tre elementi: il punto in cui nasce la collezione, la funzione che viene richiamata per ogni elemento e la query o chiamata remota eseguita dentro quel percorso. Se il report trova solo una funzione iterativa senza dimostrare l’accesso ripetuto al database, non hai ancora un verdetto affidabile.

Lo stesso vale per la severità. Un N+1 su una lista interna di cinque elementi non pesa come un N+1 sull’endpoint pubblico che alimenta la home page di ogni account. L’audit deve quindi mettere il difetto nel contesto del repository: quale superficie tocca, quali dati attraversa e quanto è vicino al percorso di produzione.

Questo è il passaggio che manca spesso nei progetti vibe-coded. L’AI ha ottimizzato la velocità con cui una feature arriva nel branch. Ma nessuno ha prodotto una prova indipendente che il comportamento resti sostenibile fuori dal caso felice.

Cosa un linter non vede

Un linter può segnalare import inutilizzati, tipi incoerenti o regole di stile violate. Può anche individuare alcuni pattern rischiosi, se configurato per farlo.

Ma non sa necessariamente che una query viene eseguita una volta per ogni riga restituita da un endpoint. Non conosce sempre la cardinalità reale dei dati. Non ricostruisce il costo complessivo di una richiesta che passa da controller, service, ORM e serializer. E soprattutto non emette da solo un verdetto sul rischio operativo della combinazione.

Anche i test possono non bastare. Se il fixture contiene tre utenti, la suite può confermare che il risultato è corretto senza misurare il numero di query. Se non esiste un test di carico o un limite esplicito sulle query per richiesta, il problema passa senza rumore.

Il linter ti dice che il codice rispetta certe regole. L’audit ti dice se, nel contesto del tuo repository, c’è un buco che merita una decisione prima del go-live.

Cosa fare questa settimana

1. Scegli una sola superficie critica: dashboard, ricerca, checkout o API principale.
2. Traccia il percorso dati completo, dal punto di ingresso fino alla risposta.
3. Conta le query con un dataset piccolo e poi con uno realistico.
4. Cerca accessi al database o chiamate API dentro loop, resolver e serializer.
5. Verifica se esistono batch, join, eager loading o cache e se sono davvero attivi nel percorso usato.
6. Se hai usato Cursor per il refactor e non sai formulare un verdetto, congela il prossimo rilascio di quella superficie e fai un audit Diagnostic.

Non devi vergognarti di aver usato Cursor. Il problema non è chi ha scritto le righe. Il problema è spedire senza sapere se il repository regge il comportamento che gli stai chiedendo.

Carica lo ZIP, ottieni un verdetto sulle aree che contano e porta il report nel prossimo ciclo tecnico: avvia un audit Diagnostic.