GitHub non regge il codice degli agenti: cosa controllare nel tuo repo Cursor

GitHub cresce più velocemente dei suoi sistemi

GitHub oggi gestisce 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. Il 17 agosto, però, una componente infrastrutturale nel data center Central US non ha retto il picco: la pressione sulla capacità si è propagata fino a causare errori di autenticazione e un’interruzione durata quasi otto ore.

Il dato interessante non è solo l’outage. È il motivo per cui la pressione sta aumentando: gli agenti di coding stanno generando software, commit e automazioni a una velocità che i sistemi progettati per team umani non avevano previsto. La fonte descrive anche problemi come contesa sul database e sovraccarico dei webhook. Puoi leggere il resoconto completo in “GitHub now sees 2.9 billion commits a month — and it can’t keep up”.

Per chi ha un prodotto costruito con Cursor, la domanda pratica è un’altra: il tuo repo è pronto a ricevere eventi, retry e richieste concorrenti senza trasformare un rallentamento in un incidente applicativo?

Cosa significa se il tuo codice l’ha scritto Cursor

Quando sviluppi con Cursor, è facile collegare rapidamente repository, deploy, preview, CI, webhook e servizi esterni. Il flusso funziona: apri una issue, l’agente modifica il codice, crea un branch, apre una pull request e una pipeline fa il resto.

Il punto cieco arriva quando un evento non è più un’eccezione ma diventa traffico. Un webhook di GitHub può essere consegnato più volte. Un provider può ritentare dopo un timeout. Una pipeline può ricevere due notifiche quasi simultanee. Un job può partire mentre il precedente sta ancora lavorando.

Il buco tecnico di oggi è concreto: webhook non idempotenti con retry incontrollati.

Esempio tipico: arriva un evento push, il tuo endpoint aggiorna un record, avvia un deploy e invia una notifica. La risposta impiega troppo tempo, il provider ritenta, il secondo evento ripete l’operazione. Se il codice non riconosce l’evento già elaborato, puoi ottenere deploy duplicati, righe duplicate nel database, code che crescono senza limite o un effetto domino tra servizi.

Cursor può scrivere un endpoint che “funziona” in locale. Può anche aggiungere un test con una singola richiesta. Ma il comportamento reale dipende da concorrenza, timeout, ordine degli eventi e failure parziali: condizioni che spesso non compaiono nella demo.

Perché ora ti serve un audit

Un audit non serve a dimostrare che hai usato male Cursor. Serve a togliere dal repo l’incertezza che resta dopo che il codice ha superato il percorso felice.

Nel caso dei webhook, il verdetto deve rispondere a domande verificabili:

• l’endpoint controlla la firma e l’autenticità dell’evento?
• esiste un identificatore univoco dell’evento?
• lo stesso evento può essere elaborato due volte?
• il record viene marcato come processato prima o dopo l’azione esterna?
• cosa accade se il deploy parte ma il salvataggio nel database fallisce?
• i retry hanno un limite, un backoff e una coda separata?
• il sistema risponde rapidamente e sposta il lavoro pesante fuori dalla richiesta HTTP?
• due eventi concorrenti possono modificare la stessa risorsa in modo incoerente?

Il valore dell’audit è produrre un verdetto leggibile: il rischio è assente, limitato oppure richiede attenzione prima del go-live. Se il problema esiste, un audit tecnico deve collegarlo alle evidenze nel repository: endpoint coinvolto, flusso di elaborazione, controllo mancante e conseguenza plausibile.

Questo è il passaggio che spesso manca nei progetti vibe-coded. Non un altro “sembra tutto ok”, ma una decisione documentata su ciò che hai spedito.

Un linter non può sostituire questo lavoro. Può segnalare una promessa non attesa, una variabile inutilizzata o una regola di stile violata. Non sa, da solo, se un webhook è idempotente rispetto al modello dati, se il retry di un provider può duplicare un’azione o se due consumer stanno elaborando lo stesso evento.

Cosa un linter non vede

Un linter guarda soprattutto la forma locale del codice. Il rischio dei webhook è spesso distribuito tra più punti:

1. il controller che riceve la richiesta;
2. la tabella che registra gli eventi;
3. il job asincrono che esegue il lavoro;
4. il client che chiama il servizio esterno;
5. la configurazione dei retry;
6. il modo in cui il deploy reagisce a un errore parziale.

Ogni file può sembrare ragionevole. Il problema nasce dalla combinazione.

Anche una suite di test verde può dare una falsa sicurezza se verifica solo il primo tentativo. Dovresti provare almeno questi scenari: stesso evento ricevuto due volte, due eventi ricevuti insieme, timeout dopo l’azione esterna, risposta lenta del database, riavvio del worker e retry dopo un errore temporaneo.

Un audit VibeInspect legge il repo come un sistema. Non corregge il codice, non esegue un pentest e non promette che tutto sia sicuro. Ti consegna invece un’analisi specialistica con un verdetto e, nel piano Diagnostic, evidenze riferite a file e righe. È diverso dal chiedere a Cursor di rileggere la propria implementazione: l’obiettivo non è ottenere un’altra modifica, ma capire se quella che hai già spedito regge condizioni meno favorevoli.

Il report è utile anche quando il verdetto è positivo. Sapere che il flusso ha una chiave di idempotenza, una gestione dei retry e una separazione corretta tra risposta HTTP e lavoro asincrono riduce il rischio di intervenire alla cieca durante il prossimo incidente.

Cosa fare questa settimana

Se hai un’app spedita con Cursor, dedica questa settimana a un controllo mirato:

• elenca tutti gli endpoint che ricevono webhook;
• identifica chi invia gli eventi e quali retry applica;
• verifica se ogni evento ha un ID persistente e un vincolo univoco;
• controlla che l’endpoint risponda rapidamente senza eseguire tutto il lavoro in linea;
• simula duplicati, timeout e richieste concorrenti;
• misura la lunghezza della coda e il numero di retry;
• separa gli eventi già processati da quelli falliti e da quelli ancora in lavorazione;
• documenta cosa succede quando un servizio esterno risponde lentamente o non risponde.

Poi smetti di chiederti se “probabilmente va bene”. Chiediti quale verdetto puoi sostenere davanti a un cliente, a un co-founder o al prossimo picco di traffico.

Se il problema è tecnico e il repo è già vicino al go-live, scegli Diagnostic: è il piano che produce evidenze su file e righe. Puoi caricare il repository su VibeInspect.ai e ottenere un report PDF con score, verdetto e dettagli utili per decidere cosa affrontare prima.

Il codice generato dall’AI non è il nemico. Il nemico è spedire senza sapere come reagisce quando gli eventi arrivano due volte, i servizi rallentano e il sistema deve scegliere cosa fare.