Code review AI con Cursor Bugbot: costi e configurazione

Il mio parere: Bugbot merita un posto tra le opzioni da valutare se il team vuole collegare le segnalazioni sulle PR al flusso di correzione di Cursor. L'approvazione umana e i controlli automatici già in uso restano necessari. Su Azure DevOps, il valore del revisore va valutato da solo, perché Bugbot Autofix non è disponibile. Su GitLab e Bitbucket, prima di attivare Autofix occorre decidere se consentire correzioni direttamente sul branch della PR è compatibile con il proprio modo di lavorare.

Code review AI con Cursor Bugbot: cosa controlla

Bugbot cerca bug, problemi di sicurezza e difetti di qualità del codice nel diff di una pull request, cioè nelle modifiche proposte per il merge. È come un tecnico che ispeziona una ristrutturazione: parte dai lavori eseguiti, mentre le regole del repository gli indicano i requisiti specifici dell'edificio.

Le revisioni possono partire quando la PR viene aggiornata oppure quando qualcuno scrive il commento cursor review o bugbot run. I commenti già presenti nella PR, sia generali sia in linea sul codice, forniscono contesto e aiutano Bugbot a tenere conto delle osservazioni precedenti. Le segnalazioni includono spiegazioni e proposte di correzione, con link per proseguire in Cursor o sul web. Come funziona Bugbot.

Il vantaggio concreto è portare prima all'attenzione un difetto che altrimenti potrebbe superare la revisione. Il numero di commenti non misura questo vantaggio. Le segnalazioni vanno giudicate in base alla loro capacità di individuare un errore reale, spiegare quando si verifica e portare a una correzione utile. Test, scansioni di sicurezza e revisione da parte dei responsabili del codice devono restare attivi.

Come configurare Cursor Bugbot per ogni repository

Collega il servizio che ospita il codice dalla dashboard delle integrazioni di Cursor, poi apri Bugbot in Automations e abilita i repository da sottoporre a revisione. Collegare il servizio e abilitare i repository sono passaggi distinti. La configurazione di Cursor supporta GitHub, GitLab, Bitbucket e Azure DevOps Services, comprese le varianti self-hosted documentate dei primi tre. Configurazione di Bugbot.

GitHub

Servono i permessi di amministratore sia in Cursor sia nell'organizzazione GitHub. In Integrations, seleziona Connect accanto a GitHub, oppure Manage Connections se il collegamento esiste già. Scegli All repositories o Selected repositories, completa il collegamento, quindi torna in Cursor e abilita in Bugbot i repository scelti. GitHub Enterprise Server dispone di una scheda di configurazione dedicata e di indicazioni specifiche per la rete. Integrazione GitHub di Cursor.

GitLab

Per GitLab.com servono i permessi di amministratore in Cursor, il ruolo di maintainer in GitLab e un piano a pagamento GitLab Premium o Ultimate. Cursor richiede token di accesso al progetto, che GitLab Free non offre. In Integrations, seleziona Connect o Manage Connections, completa l'installazione GitLab, quindi usa Manage → Sync Repos prima di abilitare i repository in Bugbot. Le installazioni self-hosted hanno istruzioni di collegamento separate. Integrazione GitLab di Cursor.

Bitbucket

Bitbucket Cloud è attualmente in beta pubblica. Collega l'account da Integrations e autorizza Cursor. Nel workspace deve essere installata anche l'app Cursor: un amministratore del workspace Bitbucket apre il menu di gestione di Bitbucket in Cursor, seleziona Install Cursor app e la installa nel workspace. Un amministratore del team Cursor con accesso al workspace apre poi Forge Apps → Cursor nelle impostazioni del workspace Bitbucket, seleziona Connect to Cursor e collega il team. Solo dopo si abilitano i repository in Bugbot. Il collegamento del solo account personale non crea l'identità dell'app necessaria per i commenti di revisione. Bitbucket Data Center segue una procedura di configurazione separata. Integrazione Bitbucket di Cursor.

Azure DevOps

Per Azure DevOps Services va seguita la configurazione specifica di Bugbot, che richiede il consenso di un amministratore del tenant Microsoft Entra. Un Project Collection Administrator collega Azure DevOps e attiva Bugbot per un repository: questo passaggio crea il service principal di Cursor, un'identità applicativa all'interno dell'organizzazione. Un amministratore di progetto deve aggiungere tale identità a Project Administrators per ogni progetto da sottoporre a revisione, così da consentirle di gestire i service hook, ossia le notifiche che avviano le revisioni.

Le modifiche ai permessi possono richiedere tempo per propagarsi: risolvi eventuali errori di configurazione e riprova ad attivare il repository. Bugbot supporta i repository del team, non quelli nell'ambito personale. Configurazione di Bugbot per Azure DevOps in Cursor.

Come scegliere quando eseguire le revisioni

Per ogni repository abilitato, decidi se rivedere gli aggiornamenti o eseguire la revisione una sola volta per PR, e configura eventuali elenchi di autori inclusi o esclusi. Le impostazioni personali permettono a ciascun autore di limitare le revisioni alle sole menzioni, eseguirle una volta per PR o includere le bozze. Nei repository abilitati, Bugbot può rivedere anche i contributi di persone esterne al team Cursor. Impostazioni del repository e personali.

Su Azure DevOps l'avvio manuale ha un requisito aggiuntivo: l'indirizzo usato da chi commenta per accedere ad Azure DevOps deve corrispondere a un account Cursor del team proprietario del repository. Le revisioni automatiche non hanno questa restrizione. Avvio delle revisioni su Azure DevOps.

Come configurare .cursor/config/bugbot.yaml

Salva la configurazione delle revisioni nel repository se vuoi che anche le sue modifiche passino dalla code review. Questo è l'esempio pubblicato nella documentazione di Cursor sulla configurazione del repository:

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Esegui commit e push del file nel percorso indicato, a partire dalla radice del repository. Bugbot lo legge dal branch di base della PR, quello che riceve le modifiche. Non usa la versione presente nel branch di origine della PR: una modifica proposta non può quindi riscrivere la configurazione della propria revisione. Usa CODEOWNERS, il meccanismo con cui il repository assegna la responsabilità dei file, per stabilire chi deve rivedere le modifiche alla configurazione.

Tutti i campi sono facoltativi. Per quelli mancanti o non validi, Bugbot passa alla fonte di impostazioni successiva; i file superiori a 64 KB vengono ignorati. L'ordine di priorità è:

1. Le impostazioni personali dell'autore per le proprie PR.
2. Il file YAML del repository.
3. Le impostazioni del team e dell'organizzazione nella dashboard.

L'ordine conta: controllare solo lo YAML non basta a dimostrare quali impostazioni verranno applicate a un autore. Inoltre, autofix.mode può restringere ciò che la dashboard consente, ma non può attivare Autofix se la dashboard lo ha disabilitato. Comportamento e priorità della configurazione.

L'esempio sceglie di inserire il riepilogo in un commento; non elenca tutti i valori predefiniti della dashboard. Senza questa impostazione esplicita, i riepiloghi delle PR vengono inseriti per impostazione predefinita nella descrizione. La revisione incrementale esamina le modifiche successive all'ultima revisione di Bugbot. Un livello di impegno maggiore può richiedere più tempo e aumentare i consumi nella ricerca dei bug; con Smart, sono le istruzioni fornite a determinare il livello di impegno. Riepiloghi, revisioni incrementali e livello di impegno.

Le istruzioni di revisione vanno in BUGBOT.md

Usa .cursor/BUGBOT.md per raccogliere ciò che un revisore deve sapere sul progetto. Il file alla radice viene sempre incluso. Bugbot cerca anche i file .cursor/BUGBOT.md annidati, risalendo dalle directory dei file modificati: una directory backend può così avere istruzioni diverse da quelle del frontend. Le regole dell'editor Cursor in .cursor/rules/*.mdc non si applicano a Bugbot. Regole di progetto per Bugbot.

Una regola utile specifica un'invariante e l'errore da cercare. Un team che gestisce pagamenti potrebbe, per esempio, precisare che ripetere un'operazione non deve generare un secondo addebito al cliente. Un team backend potrebbe indicare quali transizioni di stato richiedono una registrazione di audit. Sono spunti per scrivere le regole, non garanzie che Bugbot rilevi ogni violazione.

Le regole del team, i file di regole del progetto, le regole apprese e quelle aggiunte manualmente al repository vengono combinate. Per usare le regole apprese e manuali della dashboard, l'apprendimento deve essere abilitato sia per l'organizzazione sia per il repository. Mantieni le istruzioni mirate: ogni regola viene troncata a 30,000 caratteri e l'insieme delle regole di revisione non può superare 100,000 caratteri. Per verificare cosa è stato effettivamente caricato, scrivi il commento bugbot run verbose=true o cursor review verbose=true: la risposta indica le regole incluse, troncate o omesse. Regole e limiti.

Cursor Bugbot: prezzi e fatturazione a consumo

Il budget di Bugbot va calcolato a consumo, contabilizzando Autofix separatamente. Le formulazioni attualmente usate da Cursor sono:

Queste sono le condizioni attuali di fatturazione di Bugbot. Non dare per scontato che la quota inclusa nell'abbonamento all'editor del team copra le revisioni di Bugbot. Autofix consuma crediti Cloud Agent, addebitati alle tariffe del piano già sottoscritto. Fatturazione di Autofix.

La modifica dei prezzi annunciata a maggio si applica agli abbonamenti esistenti al primo rinnovo successivo all'8 giugno 2026. Un abbonamento annuale preesistente può quindi mantenere le condizioni precedenti fino al rinnovo. Annuncio di Cursor sulla modifica dei prezzi.

La documentazione attuale di Bugbot non fornisce una tariffa fissa per revisione da inserire nel budget. Complessità delle PR, frequenza delle revisioni e livello di impegno incidono sul lavoro svolto. Il costo medio per esecuzione indicato da un fornitore è un riferimento, non una tariffa garantita per il proprio repository.

Per valutarne la convenienza, confronta spesa per le revisioni + spesa per Autofix + tempo degli sviluppatori dedicato a valutare le segnalazioni con il lavoro di revisione e correzione che il team evita. Il budget già destinato alla revisione umana resta necessario. La decisione dipende dall'utilità delle segnalazioni e dall'attenzione risparmiata, non dalla capacità di un altro bot di produrre commenti.

Autofix e MCP: requisiti diversi

Autofix avvia un Cloud Agent, un agente che lavora sul codice da remoto, per intervenire sulle segnalazioni di Bugbot e riportare l'esito nella PR. Richiede che siano abilitati sia l'utilizzo on-demand sia l'archiviazione; Legacy Privacy Mode non soddisfa il requisito di archiviazione. In Bugbot Automations va scelta una modalità supportata. Requisiti di Autofix.

Queste sono le modalità Autofix documentate da Cursor. Per evitare cicli ripetitivi, la modalità sul branch esistente consente al massimo 3 tentativi per PR. Come punto di partenza, consiglio di lasciare Autofix disattivato finché il team non concorda come rivedere le correzioni generate; i team che usano GitHub possono poi scegliere la modalità su un nuovo branch per esaminarle separatamente.

MCP, un protocollo che consente a uno strumento AI di accedere ad altri strumenti e al contesto, può ampliare il processo di revisione di Bugbot. Configura il server MCP e aggiungi i suoi strumenti a Bugbot in Automations. Il supporto MCP di Bugbot è disponibile solo nei piani Team ed Enterprise. Disponibilità di MCP.

Bugbot, CodeRabbit e Greptile a confronto

La scelta dipende dalla compatibilità con il flusso di lavoro e dal modello di costo che si riesce a gestire. Quelli riportati sono prezzi pubblicati, non risultati di una prova comparativa.

Fonti: Cursor Bugbot, prezzi di CodeRabbit, prezzi di Greptile. Gli importi annuali di CodeRabbit sono equivalenti mensili con fatturazione annuale. I crediti Greptile non sono intercambiabili con l'utilizzo Cursor o con gli addebiti di CodeRabbit per file revisionato.

Il confronto dei budget è chiaro: CodeRabbit combina un abbonamento per postazione con eventuali addebiti per revisioni oltre i limiti; Greptile combina postazioni e crediti; nel modello attuale di Bugbot, la variabile centrale è il consumo delle revisioni. Dai soli prezzi per postazione non si può stabilire seriamente quale opzione costi meno al proprio team.

Per un confronto diretto più approfondito, leggi Greptile vs CodeRabbit. Per ampliare la scelta, consulta le alternative a CodeRabbit e i migliori strumenti AI per la code review nei piccoli team.

In quali casi Bugbot può dare più valore a un team

Darei la precedenza ai flussi in cui un difetto non rilevato costa più dell'attenzione necessaria per valutare una segnalazione. Quelli che seguono sono impieghi possibili, ordinati secondo le mie priorità di partenza: non sono risultati misurati.

I meccanismi di revisione, contesto, regole e Autofix alla base di questi esempi sono descritti nella guida a Bugbot di Cursor. Il loro valore dipende dal codice e da chi lo revisiona.

Cosa vale la pena sviluppare attorno a Bugbot

L'opportunità più solida è aiutare un responsabile tecnico a capire costi e risultati delle revisioni. Proporre un altro generatore di commenti è più difficile quando la revisione è già coperta da strumenti affermati.

Un registro dei costi e dei risultati delle revisioni

Un team di piattaforma potrebbe realizzare una dashboard che colleghi la spesa per repository alle segnalazioni accettate, scartate o risolte dagli sviluppatori. I potenziali acquirenti sarebbero i responsabili tecnici. Il prezzo Pro di Greptile, $30/postazione/mese, dimostra che esiste una categoria consolidata di strumenti di revisione a pagamento; non dimostra che quegli stessi clienti pagherebbero per questo componente aggiuntivo. Prezzi di Greptile.

La versione minima utile unirebbe segnalazioni e dati di fatturazione a un giudizio di utilità espresso da una persona. L'API di revisione Enterprise di Cursor espone dati analitici sulle revisioni, comprese le segnalazioni e il costo addebitato; il campo del costo può non riportare alcun importo fatturato. Una versione per clienti non Enterprise avrebbe bisogno di dati inseriti manualmente e autorizzati, senza dare per scontato l'accesso a quell'API. API e analisi di Bugbot.

Il limite: i commenti risolti sono un indicatore imperfetto dei bug che valeva la pena correggere, e un'attribuzione incompleta dei costi può rendere fuorviante la dashboard. Svilupperei questa soluzione per prima, perché risponde alla domanda che torna a ogni rinnovo: questo revisore vale il suo costo complessivo?

Uno strumento per verificare le policy di revisione dei repository

Un gruppo di platform engineering potrebbe usare uno strumento che controlli se i repository hanno la configurazione Bugbot approvata, se mancano regole di progetto e se ci sono modifiche alle policy non sottoposte a revisione. Il prezzo mensile di CodeRabbit Team, $60/sviluppatore/mese, colloca la gestione delle revisioni di team in una categoria di prodotti a pagamento; la disponibilità ad acquistare uno strumento separato per le policy andrebbe comunque verificata. Prezzi di CodeRabbit.

La versione minima potrebbe leggere i file dei repository e produrre un rapporto da far esaminare ai responsabili. Il limite: le impostazioni personali hanno precedenza sullo YAML, quindi un controllo dei soli file non può certificare il comportamento effettivo delle revisioni. Questo limite va reso evidente, integrando nel processo le impostazioni della dashboard dove l'accesso autorizzato lo consente. Priorità della configurazione di Bugbot.

L'approvazione del merge deve restare esplicita

Rendere obbligatorio il controllo Bugbot non significa automaticamente che le segnalazioni irrisolte blocchino il merge. Per impostazione predefinita, le segnalazioni producono un esito neutro. Richiedere lo stato del controllo garantisce che venga eseguito; quando disponibile per l'organizzazione, l'opzione fail-on-unresolved-issues fa sì che le segnalazioni producano uno stato di errore. Verifica questa impostazione prima di fare affidamento sulla protezione dei branch. Stati dei controlli Bugbot.

Consiglio di usare Bugbot come fonte di elementi aggiuntivi per chi revisiona il codice. Un rapporto senza segnalazioni non dimostra che la funzionalità soddisfi i requisiti, e una patch generata automaticamente richiede lo stesso esame riservato al resto del codice.

Da dove cominciare lunedì

Scegli un repository i cui responsabili sappiano definire gli errori da intercettare. Chiedi all'amministratore competente di completare il collegamento al servizio che ospita il codice, abilita Bugbot per quel repository, esegui il commit della configurazione sul branch di base e scrivi regole di revisione mirate. Assegna la responsabilità del budget e decidi separatamente se usare Autofix. Durante le normali revisioni, registra le segnalazioni utili, i suggerimenti scartati e il tempo speso a valutare entrambi, prima di estendere l'adozione.

Se ti servono report sulle revisioni o controlli sui repository integrati nel flusso di rilascio, possiamo aiutarti con l'automazione AI.