La UI sembra umana. Il tuo repo v0 può nascondere un N+1

Il contenuto sembra reale, ma il segnale è un altro

LinkedIn dice che oltre un milione di persone ha già cliccato sul pulsante “Seems like AI slop”, introdotto per segnalare post percepiti come generati dall’intelligenza artificiale. La piattaforma aveva aggiunto il controllo dopo che un rilevatore aveva classificato come interamente generati dall’AI il 41% dei post lunghi analizzati.

La notizia completa è Over 1 million people have clicked LinkedIn’s AI slop button.

Il dato dice una cosa utile anche a chi costruisce software: l’apparenza non basta più come prova. Un’interfaccia può sembrare curata, coerente e “umana”, mentre il sistema sotto esegue lavoro inutile a ogni richiesta.

Nel codice vibe-coded succede spesso con le query al database. La pagina mostra i dati giusti. Il caricamento sembra accettabile. Ma dietro una singola schermata puoi avere una query per l’elenco e una query aggiuntiva per ogni elemento visualizzato.

È il problema N+1: invece di recuperare tutto con poche query, l’app ne esegue una per il contenitore e poi una per ciascun record. Con dieci elementi sembra innocuo. Con mille utenti e dati reali, diventa latenza, costi e pressione sul database.

Cosa significa se il tuo codice l’ha scritto v0

v0 è efficace nel trasformare una descrizione in un’interfaccia completa: tabelle, dashboard, filtri, pagine di dettaglio e componenti React. Il risultato può essere convincente già al primo tentativo.

Il buco concreto nasce quando la UI viene costruita prima di chiarire il percorso dei dati.

Immagina una dashboard ordini. Il server recupera gli ordini dell’utente. Poi, per ogni ordine, il componente carica separatamente cliente, righe prodotto, stato di pagamento e ultimo aggiornamento. Quattro query per ordine. La pagina funziona, ma il numero di chiamate cresce insieme ai dati mostrati.

Un’implementazione N+1 può comparire in diversi punti:

• una chiamata API dentro un .map();
• un resolver GraphQL che carica relazioni senza batching;
• un componente React che esegue un fetch quando cambia ogni riga;
• una funzione server che richiama il database dentro un ciclo;
• un ORM usato con relazioni lazy senza preloading;
• una pagina che ripete la stessa query per widget diversi.

Non è un problema di estetica e non significa che v0 abbia “scritto male” il progetto. Significa che il builder ottimizza il percorso verso una UI funzionante, non può sapere automaticamente quale volume avrà il tuo dataset o quale limite di latenza devi rispettare in produzione.

La dashboard può sembrare leggera. Il database può stare lavorando cento volte più del necessario.

Perché ora ti serve un audit: il verdetto sulla forma non basta

Il caso LinkedIn mostra quanto sia facile confondere ciò che appare con ciò che accade davvero. Nel tuo prodotto, il rischio è simile: una schermata rapida in sviluppo può nascondere un comportamento che peggiora in modo lineare con il numero di record.

Un audit VibeInspect serve a rispondere a una domanda precisa:

il percorso che alimenta questa pagina recupera i dati in modo proporzionato, oppure moltiplica le query per ogni elemento visualizzato?

Per arrivare al verdetto bisogna seguire il flusso completo:

1. quale componente avvia il caricamento;
2. quale endpoint o server action viene chiamato;
3. quale query principale recupera i record;
4. quali dati vengono caricati durante il rendering di ogni record;
5. se le relazioni sono pre-caricate o richieste una alla volta;
6. se la paginazione limita davvero il lavoro svolto;
7. cosa succede quando il numero di elementi cresce.

La ricerca non si ferma alla presenza di Promise.all, useEffect o di un ORM moderno. Anche una serie di richieste parallele può essere un N+1: più veloce in piccolo, ma ancora moltiplicata in base al numero di righe.

Il verdetto utile non è “la pagina è ottimizzata”. È qualcosa di verificabile: le query restano entro un limite prevedibile per pagina, oppure una relazione o un componente introduce chiamate proporzionali ai record caricati.

VibeInspect prende il repository ZIP, lo analizza con specialisti AI e restituisce un PDF con score e verdetto. Nel piano Diagnostic il report include evidenze su file e righe. Non modifica il codice e non sostituisce un test di carico: ti permette però di sapere se la lentezza potenziale è reale, dove nasce e quale percorso del repo la produce.

Il nemico non è aver usato v0. Il nemico è accettare una UI convincente senza sapere quanto lavoro richiede ogni volta che viene aperta.

Perché ora ti serve un audit: le evidenze che contano

Un N+1 raramente si dimostra con una singola riga. Si dimostra osservando la relazione tra ciclo, query e numero di elementi.

Cerca soprattutto queste combinazioni:

• Query dentro un ciclo. Una chiamata a database o API inserita in map, forEach, for o in una funzione chiamata da ciascun elemento è il primo segnale.
• Fetch nel componente figlio. Se ogni riga di una tabella monta un componente che carica i propri dati, il numero di richieste può crescere rapidamente.
• Relazioni lazy non controllate. Recuperare gli ordini e poi accedere a order.customer o order.items senza preloading può generare una query per record.
• Batching assente. Anche quando servono dati correlati, il backend dovrebbe valutarne il recupero aggregato, non delegarlo a chiamate ripetute.
• Paginazione soltanto visiva. Mostrare dieci righe per pagina non basta se il server carica cento record e poi ne visualizza dieci.
• Widget indipendenti sulla stessa pagina. Dashboard composte da card separate possono interrogare più volte la stessa tabella o lo stesso endpoint.

L’audit deve collegare questi segnali al comportamento atteso. Dieci query per dieci righe non sono automaticamente un incidente: dipende dal costo della query, dalla frequenza, dal caching e dal volume. Ma senza misurare il percorso, stai decidendo sulla base dell’impressione.

Cosa un linter non vede

Un linter può segnalare una dipendenza non usata, un tipo errato, una promessa non gestita o alcune regole di qualità. Può anche evidenziare pattern sospetti. Non dimostra però quante query verranno eseguite quando la pagina riceve cinquanta o cinquecento record.

Non vede, da solo, che:

• un componente figlio effettua un fetch per ogni riga;
• una query principale restituisce più dati di quelli necessari;
• la paginazione viene applicata dopo il recupero dal database;
• due widget chiamano lo stesso endpoint senza condividere il risultato;
• Promise.all esegue in parallelo una lunga serie di query duplicate;
• il caching esiste nel frontend ma non evita il lavoro sul backend;
• il percorso lento viene usato da più pagine contemporaneamente.

Nemmeno i test del caso nominale bastano. Un test con tre ordini può essere verde e non mostrare nulla. Il problema appare quando aumentano i record, quando più utenti aprono la dashboard o quando una relazione aggiunge un secondo livello di query.

Il linter controlla la forma locale. L’audit verifica il costo del comportamento.

Cosa fare questa settimana

Scegli una sola schermata con una lista: ordini, utenti, fatture, ticket o attività.

Poi costruisci una mappa semplice:

• numero massimo di elementi richiesti;
• endpoint chiamato;
• query eseguite per la pagina;
• query eseguite per ogni elemento;
• relazioni caricate;
• presenza di paginazione reale;
• tempo di risposta atteso.

Cerca nel repo i cicli che circondano chiamate a database, fetch HTTP o funzioni di caricamento. Controlla anche i componenti figli: il problema può essere distribuito tra pagina, hook e server action.

Se non sai dire quante query produce una schermata con dieci, cento e mille elementi, non aggiungere ancora un altro widget generato dall’AI. Ti serve un verdetto sul percorso dei dati.

Carica lo ZIP su VibeInspect.ai. Per questo caso sceglierei il piano Diagnostic, perché il problema è tecnico e hai bisogno di evidenze su file, righe e flussi di caricamento.

L’obiettivo non è dimostrare che v0 abbia generato una UI “finta”. È sapere se dietro una schermata convincente il tuo prodotto sta facendo lavoro inutile a ogni apertura.