GitHub scala, ma il tuo repo Cursor può avere un N+1

GitHub cresce oltre i 2,9 miliardi di commit: il segnale per chi spedisce con Cursor

GitHub dichiara di gestire ormai 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. La crescita sta mettendo sotto pressione la piattaforma: il postmortem dell’outage del 17 agosto descrive un problema di capacità che ha prodotto errori a cascata, inclusi malfunzionamenti sull’autenticazione.

La notizia è raccontata in GitHub now sees 2.9 billion commits a month — and it can’t keep up. Il punto utile per te, però, non è solo che GitHub deve scalare. È che il codice prodotto più velocemente dagli agenti porta più velocemente anche i colli di bottiglia nel tuo stack.

Se hai spedito una dashboard, un marketplace o un SaaS con Cursor, il problema potrebbe essere già dentro una rotta apparentemente innocua: una query per ogni riga, una chiamata API per ogni card, una lista che funziona in locale e degrada appena arrivano utenti reali.

Cosa significa se il tuo codice l’ha scritto Cursor

Un caso concreto è il problema N+1.

Immagina una pagina che mostra gli ordini di un cliente. La prima query recupera 100 ordini. Poi, dentro un ciclo, il codice chiede separatamente il prodotto, il venditore o lo stato di spedizione associato a ciascun ordine. Il risultato è una query iniziale più altre 100 query, o anche di più se ogni riga attiva ulteriori chiamate.

Con dieci record, probabilmente non noti nulla. Con mille utenti simultanei, il database riceve una raffica di richieste ripetitive. La pagina diventa lenta, il connection pool si satura e i timeout iniziano a sembrare casuali. L’agente può aver generato test corretti per il caso singolo, mentre il problema emerge solo quando il volume cresce.

Cursor è molto bravo a trasformare una richiesta in codice funzionante. Ma “funzionante” non significa automaticamente “sostenibile sotto carico”. Se hai descritto una schermata e hai accettato il diff perché il risultato era corretto, potresti non avere mai verificato quante query vengono eseguite per una singola richiesta HTTP.

Perché ora ti serve un audit: non basta sapere che compila

Il passaggio che spesso manca tra il prototipo e il go-live è un verdetto tecnico sul comportamento del repository.

Un audit VibeInspect prende il tuo ZIP, analizza il codice con specialisti AI e restituisce un PDF con un esito leggibile. Per un problema come l’N+1, l’obiettivo non è dirti genericamente che “le performance potrebbero migliorare”. Serve capire se esiste un percorso concreto tra endpoint, servizio, query e modello dati che moltiplica il lavoro a ogni elemento restituito.

Le domande giuste sono specifiche:

• Quale endpoint esegue query dentro un ciclo?
• Quali relazioni vengono caricate una alla volta invece che con una strategia aggregata?
• Quante chiamate esterne vengono fatte per costruire una singola risposta?
• Esistono paginazione e limiti, oppure una lista può crescere senza controllo?
• I timeout e i retry possono moltiplicare ulteriormente le richieste?
• Il codice usa dati caricati in memoria quando il database potrebbe filtrare e aggregare prima?

Il valore dell’audit è trasformare questi dubbi in un verdetto accompagnato da evidenze. Nel piano Diagnostic, il report può indicare file, righe e tracce rilevanti del percorso analizzato. Non ricevi una promessa di performance né una riscrittura automatica: ricevi una base concreta per decidere cosa correggere prima di pagare il conto in produzione.

Questo è particolarmente importante nei repository creati con agenti. Il volume di codice non è più un buon proxy della qualità. Un progetto può avere una struttura ordinata, una UI convincente e test verdi, ma conservare una scelta inefficiente nella parte meno visibile: accesso ai dati, serializzazione, chiamate tra servizi o gestione della concorrenza.

Il verdetto che manca tra “demo pronta” e “go-live”

Un linter controlla regole locali. Può segnalare import inutilizzati, tipi incoerenti, variabili mai lette o pattern sintattici rischiosi. Sono controlli utili, ma non rispondono alla domanda principale: cosa succede quando questa funzione viene attraversata cento volte durante una sola richiesta?

Un audit ragiona sul percorso.

Può collegare un controller a un service, il service a un repository e il repository a una query. Può confrontare il numero di elementi restituiti con il numero di accessi successivi ai dati. Può evidenziare che una risposta contiene un array senza limite, che manca una paginazione effettiva o che il fallback ripete la stessa chiamata senza una condizione sicura.

Il linter, da solo, non sa se una query è innocua in isolamento ma costosa quando viene ripetuta dentro un loop. Non sa se una chiamata a un provider esterno viene eseguita per ogni risultato. Non sa se il flusso completo produce una cascata di lavoro che i test locali non hanno misurato.

E soprattutto non ti consegna il verdetto operativo: “questo percorso è un rischio tecnico da risolvere prima del go-live” oppure “qui non emerge un blocco prioritario”. Il nemico non è aver usato Cursor. Il nemico è spedire senza sapere in quale stato si trova il repo.

Cosa un linter non vede

Nel caso N+1, cerca segnali che attraversano più livelli:

• accessi a ORM o query builder dentro for, map o callback asincrone;
• chiamate HTTP annidate nella costruzione di una lista;
• serializzatori che recuperano dati aggiuntivi elemento per elemento;
• endpoint senza paginazione, filtri o limite massimo;
• Promise.all usato per lanciare centinaia di richieste contemporaneamente;
• retry automatici senza budget o backoff adeguato;
• query che recuperano intere tabelle per filtrare poi in memoria;
• assenza di metriche sul numero di query per richiesta.

Non serve trovare tutti questi segnali per avere un problema. Ne basta uno inserito in un percorso ad alta frequenza.

Un linter può anche passare senza errori mentre il database sta lavorando troppo. La correttezza sintattica non misura il costo operativo. E il fatto che una pagina risponda in locale con pochi dati non dimostra che reggerà quando il repository sarà collegato a utenti, webhook, cataloghi o cron job reali.

Cosa fare questa settimana

Prima di aggiungere un’altra feature con Cursor, scegli i tre endpoint più importanti del tuo prodotto. Per ciascuno, annota:

1. quante query al database vengono eseguite;
2. quante chiamate a servizi esterni partono;
3. quanti elementi può restituire la risposta;
4. cosa succede se il client ripete la richiesta;
5. quali timeout e retry sono attivi.

Poi esegui un test con dati realistici, non con tre record inseriti a mano. Se il numero di query cresce quasi linearmente con il numero di elementi restituiti, hai un candidato forte per un N+1. Se non riesci a ricostruire il percorso dal codice, hai già un problema di visibilità.

A quel punto carica il repo su VibeInspect.ai e scegli Diagnostic se hai un sospetto tecnico preciso. Riceverai un report orientato a file, righe ed evidenze, senza fix automatici e senza revisione umana fuori dal piano Assurance.

Non devi smettere di usare Cursor. Devi smettere di confondere la velocità con un verdetto. Avvia l’audit Diagnostic e scopri se il tuo repo è pronto per il carico che gli stai chiedendo.