Il tuo repo Windsurf scala davvero o moltiplica le query?

Il refactoring è il test che separa il codice plausibile dal codice pronto

Un nuovo benchmark dedicato al refactoring su larga scala mostra un limite concreto degli agenti di coding: anche i modelli più avanzati faticano quando una modifica attraversa molti file, dipendenze e comportamenti impliciti. Il benchmark SWE-Bench ProMax raccoglie 170 casi reali in sette linguaggi e, secondo la fonte, il modello migliore ha raggiunto un resolve rate del 41,2%.

La notizia è raccontata da Most coding agent benchmarks skip large-scale refactoring. Not this one., pubblicato da The New Stack il 21 agosto 2026.

Il punto per chi costruisce prodotti non è stabilire quale modello vince il benchmark. È capire cosa succede nel tuo repository quando un agente modifica un flusso senza vedere davvero tutte le conseguenze.

Cosa significa se il tuo codice l’ha scritto Windsurf

Immagina una dashboard che mostra ordini, clienti o eventi recenti. Windsurf aggiunge una nuova vista con un componente frontend, un endpoint API e una query al database. Il risultato funziona: la pagina si apre, i dati sono corretti e i test principali passano.

Poi arrivano cinquanta utenti contemporaneamente.

Il server esegue una query per recuperare l’elenco degli ordini e, per ogni ordine, una query separata per caricare il cliente, il piano o gli elementi associati. Con dieci ordini ottieni undici query. Con mille ordini ne ottieni mille e una.

È il problema N+1.

In fase di sviluppo può restare invisibile perché il dataset è piccolo, il database è vicino all’applicazione e nessuno osserva il numero effettivo di query. In produzione diventa latenza, carico database e richieste che degradano proprio quando il prodotto inizia a essere usato.

Il bug non è necessariamente in una riga sbagliata. Spesso nasce dall’interazione tra più livelli:

• il componente chiede una lista paginata;
• il controller passa i record al servizio;
• il servizio accede a una relazione per ogni elemento;
• l’ORM esegue query lazy senza che nessuno lo abbia notato;
• il frontend ripete la richiesta quando cambia filtro o pagina.

Windsurf può completare ciascun passaggio in modo ragionevole. Il problema emerge dal comportamento complessivo. Un agente può aggiungere una feature corretta localmente e, nello stesso momento, introdurre un moltiplicatore di query che il percorso felice non mostra.

Non è una critica a chi ha usato Windsurf. È il costo di una superficie applicativa che cresce più velocemente della tua capacità di osservarla.

Perché ora ti serve un audit: il verdetto deve riguardare il comportamento

Il refactoring è difficile perché non basta dimostrare che il nuovo codice compila. Devi sapere se il sistema conserva le sue proprietà quando cambiano scala, dati e ordine delle operazioni.

Per un possibile N+1, un audit VibeInspect deve ricostruire il percorso tra richiesta, servizio, ORM e database. Le domande da chiudere sono precise:

• quali endpoint caricano collezioni di record;
• quali relazioni vengono attraversate durante la serializzazione;
• se gli accessi sono lazy o eager;
• se una query viene eseguita dentro un ciclo;
• se paginazione, filtri e ordinamenti causano query aggiuntive;
• se il conteggio delle query cresce linearmente con il numero di risultati;
• se esistono endpoint simili che replicano lo stesso schema;
• se cache e prefetching nascondono il problema soltanto in alcuni ambienti.

Il risultato utile non è “attenzione alle performance”. È un verdetto collegato al repository: questo endpoint esegue una query principale e una query per ogni elemento restituito; il caricamento della relazione avviene nel serializer; con la pagina impostata a cinquanta record, il numero di query cresce da due a cinquantuno.

Questo è il passaggio che manca spesso dopo un refactoring generato dall’AI. Il codice sembra ordinato, il diff è leggibile e la feature è visibile. Ma nessuno ha ancora misurato la proprietà che conta: quanto lavoro aggiuntivo produce il sistema quando aumenta il numero di record?

VibeInspect analizza lo ZIP del repository con specialisti AI e produce un PDF con score, verdetto ed evidenze. Non richiede un server dedicato e il sorgente viene cancellato alla fine dell’analisi.

Per un sospetto tecnico come N+1, il piano adatto è Diagnostic: ti servono file, righe e prove che colleghino il pattern al percorso applicativo. Snapshot è utile per un primo score, ma non restituisce i dettagli necessari per correggere un collo di bottiglia già identificato.

Cosa un linter non vede

Un linter può trovare errori di sintassi, import inutilizzati, tipi incoerenti o alcune chiamate sospette. Non può però sapere se una query viene eseguita una volta o cinquecento volte durante una richiesta reale.

Il codice seguente può essere valido dal punto di vista sintattico:

orders = get_orders()

for order in orders:
    order.customer = get_customer(order.customer_id)

Il linter vede due funzioni definite e una struttura corretta. Il problema è il costo runtime: get_customer() può interrogare il database a ogni iterazione.

Nemmeno una suite di test funzionali basta sempre. Un test con tre ordini dimostra che la risposta contiene i clienti corretti. Non dimostra che il sistema mantenga un numero ragionevole di query con trecento ordini.

E un benchmark sintetico può fallire nella direzione opposta: misurare una singola funzione senza attraversare autenticazione, serializzazione, middleware, cache e database. Il N+1 si manifesta spesso proprio nel collegamento tra componenti che, presi separatamente, sembrano corretti.

Per questo servono evidenze di percorso: endpoint coinvolto, relazione caricata, ciclo o serializer che la attiva, strategia dell’ORM e crescita prevista delle query. Il problema non è solo “il codice è lento”. È “il costo della richiesta cresce insieme ai dati invece di restare controllato”.

Cosa fare questa settimana

Se hai spedito con Windsurf, puoi fare un controllo mirato senza riscrivere tutto:

1. Elenca gli endpoint che restituiscono liste, feed, tabelle o risultati aggregati.
2. Per ogni endpoint, identifica tutte le relazioni caricate per ogni record.
3. Cerca accessi a proprietà o metodi di modello dentro cicli e serializer.
4. Attiva il logging delle query in ambiente di sviluppo o test.
5. Esegui la stessa richiesta con 1, 10, 50 e 200 elementi.
6. Registra numero di query, latenza e tempo trascorso nel database.
7. Controlla se paginazione e filtri riducono davvero il lavoro lato database.
8. Verifica che il fix — eager loading, join, prefetch o query aggregata — non cambi i dati restituiti.
9. Aggiungi un test che imponga un limite massimo di query per il percorso critico.
10. Ripeti la misura sugli endpoint gemelli creati durante lo stesso refactoring.

Il test decisivo non è “la pagina funziona”. È “la pagina funziona con un dataset realistico senza moltiplicare il lavoro a ogni riga?”.

Se non sai ancora dove si trova il collo di bottiglia, carica il tuo repo su VibeInspect.ai e parti da Snapshot. Se hai già visto query ripetute, latenze che crescono con la pagina o accessi lazy dentro un ciclo, scegli Diagnostic per ottenere un verdetto tecnico con evidenze.

Windsurf può accelerare un refactoring. Ma la velocità di modifica non dimostra la qualità del risultato. Prima di scalare il traffico, verifica che il tuo repository non stia trasformando ogni nuovo record in una nuova query.