Il tuo repo Bolt è lento per un N+1 che il linter non vede

Gli agenti non hanno solo un problema di modello: hanno un problema di latenza

Il 50% dei deployment enterprise di AI non raggiunge il proprio obiettivo di latenza nei momenti di picco. L’82% delle organizzazioni intervistate richiede risposte end-to-end entro 500 millisecondi per i casi più importanti. È il quadro riportato da “Agentic AI has a latency problem that more compute won’t solve”, pubblicato il 18 agosto 2026.

Il punto per un founder è semplice: aggiungere potenza al modello non risolve una pipeline che fa troppe chiamate, interroga il database una volta per ogni riga o aspetta servizi lontani a ogni passaggio. La latenza non vive sempre nel modello. Spesso vive nel codice che lo circonda.

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina di aver usato Bolt per costruire una dashboard operativa con utenti, progetti e attività recenti. La pagina principale mostra trenta progetti, il proprietario, l’ultimo evento e il conteggio delle attività aperte.

La prima query recupera i progetti. Poi, per ogni progetto, il codice chiama separatamente il database per ottenere proprietario, ultimo evento e conteggio. Con dieci progetti sembra tutto accettabile. Con cento, la pagina produce centinaia di query per una singola richiesta.

Questo è il buco tecnico: un N+1 query problem. Il server esegue una query iniziale e poi una o più query aggiuntive per ogni elemento restituito. Il risultato può essere una dashboard lenta, un consumo database inutile e una coda che peggiora proprio quando arrivano più utenti.

In un’app vibe-coded il problema può nascondersi dietro componenti apparentemente innocui: una funzione chiamata dentro un ciclo, un resolver che carica dati collegati uno alla volta, una richiesta fetch per ogni card o un conteggio calcolato separatamente per ogni riga.

Bolt non è il nemico. Ti consente di trasformare rapidamente un’idea in un prodotto funzionante. Ma “funziona con cinque record” non significa “regge quando il dataset e il traffico crescono”.

Perché ora ti serve un audit: la latenza va ricostruita, non indovinata

Un audit VibeInspect serve a ricostruire il percorso completo di una richiesta: dal caricamento della pagina alla route API, dalla route alle query, dalle query al database e dalla risposta al rendering.

Nel caso di un N+1, il verdetto deve rispondere a domande concrete:

1. Quante query partono per una singola richiesta?
2. Il numero cresce linearmente con il numero di righe visualizzate?
3. Le relazioni vengono caricate una alla volta dentro un ciclo?
4. Esistono endpoint che fanno fetch multipli dal browser per costruire una sola vista?
5. I conteggi e gli ultimi eventi vengono calcolati separatamente per ogni elemento?
6. Le query hanno filtri, paginazione e limiti coerenti?
7. Il codice usa join, aggregazioni o caricamento in batch quando il caso lo richiede?
8. La risposta contiene più dati del necessario?
9. Esistono timeout e metriche per capire quale passaggio consuma il budget di latenza?

Questa analisi non si limita a trovare una funzione sospetta. Deve collegare il loop al comportamento finale: quante richieste vengono generate, quali tabelle vengono toccate, come cresce il tempo al crescere dei dati e se il problema si presenta solo nella UI o anche in altri client.

È qui che l’audit pesa davvero. Un punteggio generico può dirti che il repository merita attenzione. Un verdetto tecnico deve spiegare se la latenza è causata da un N+1, da payload sovradimensionati, da query senza indice o da chiamate seriali verso servizi esterni.

Per un problema tecnico di performance, il piano coerente è il Diagnostic da €499: restituisce file, righe ed evidenze. Lo Snapshot da €49 offre uno score iniziale, ma non localizza il percorso lento. L’audit produce un PDF con il verdetto; non modifica il codice e non è un pentest.

Cosa un linter non vede

Un linter può segnalare una promessa non gestita, un import inutilizzato o una regola di stile violata. Non sa che una pagina esegue 301 query invece di 4.

Per il linter, questo codice può essere perfettamente valido:

projects.map(project => loadOpenTasks(project.id))

Il problema emerge solo quando si osservano il flusso e la scala. Una funzione può essere corretta localmente e produrre un comportamento pessimo quando viene invocata dentro un ciclo.

Un linter non conosce automaticamente:

• il costo reale di una query sul tuo schema;
• la cardinalità delle tabelle;
• la presenza o assenza di indici utili;
• la latenza tra frontend, backend e database;
• il numero di utenti concorrenti;
• la differenza tra sviluppo e produzione;
• il fatto che un endpoint venga chiamato una volta per card.

Non vede nemmeno quando il browser orchestra una raffica di richieste apparentemente separate. La pagina può essere composta da componenti puliti, tipizzati e ben formattati, ma il risultato può restare lento perché ogni componente interroga il backend per conto proprio.

La differenza è tra correttezza locale e comportamento del sistema. L’audit collega codice, query, cardinalità e percorso di esecuzione. Se il tuo prodotto deve rispettare un budget di latenza, questa è la prova che manca.

Cosa fare questa settimana

Prima del prossimo go-live del tuo progetto Bolt, esegui queste verifiche:

1. Apri la pagina più importante e conta le richieste. Usa gli strumenti del browser per capire quante chiamate partono da un singolo caricamento.
2. Controlla i loop. Cerca query, fetch o funzioni di caricamento dentro map, forEach, for e resolver annidati.
3. Misura con dati realistici. Dieci record non bastano: prova con una quantità vicina a quella prevista in produzione.
4. Verifica la paginazione. Non caricare una lista completa se la UI ne mostra solo una parte.
5. Cerca caricamenti in batch. Recupera le relazioni necessarie con una query progettata per la vista, invece di una query per elemento.
6. Controlla gli indici. Una query ben aggregata può restare lenta se il database deve scandire tabelle intere.
7. Imposta un budget. Definisci un tempo massimo per la risposta e misura il percorso reale, non solo il tempo del modello.
8. Chiedi un verdetto prima del go-live. Se non sai quante query produce una schermata con cento elementi, non hai ancora misurato il rischio.

Se hai spedito con Bolt e una dashboard, un report o un flusso AI diventa lento appena crescono dati e utenti, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente verrà cancellato a fine analisi.

Scegli il Diagnostic se vuoi file, righe ed evidenze sul possibile N+1. Il problema non è aver costruito velocemente con l’AI: è scoprire la latenza solo quando i primi utenti sono già dentro.