Claude Code vs Cursor vs Copilot in un progetto vero: il criterio è il controllo, non l'autocomplete

Questo pezzo è per chi deve scegliere tra Claude Code, Cursor e GitHub Copilot su un repository vero: con CI, segreti, pull request e qualcuno che risponde dei merge. Vive nell'hub Vibe coding e in AI Engineering.

Non è un benchmark. Non ho cronometrato nulla e non ci sono percentuali di accettazione. È un confronto sui vincoli, costruito sulla documentazione ufficiale dei tre strumenti, verificata il 12 ottobre 2026, e sui pattern già raccontati qui su fnbit.

In breve: il codice lo scrivono bene tutti e tre, spesso con gli stessi modelli. La differenza è dove vive il controllo. In Claude Code sta nel client: permessi allow/ask/deny e hook che il modello non può aggirare a parole. In Cursor sta nella modalità di esecuzione e nella sandbox in locale, e nella VM per i Cloud Agents. In Copilot sta nella piattaforma GitHub: un branch, una pull request, approvazioni umane obbligatorie. Scegli in base a chi deve poter dire "no" e dove.

La domanda sbagliata

Non "quale autocomplete è meglio?". È: chi tiene il controllo su contesto, terminale, review e confini del repo quando l'agente lavora da solo?

L'autocomplete non è più il punto. Copilot offre modelli di più fornitori, Claude compreso. Cursor fa scegliere il modello per ogni task. VS Code permette perfino di cambiare harness, da Copilot a Claude a Codex, nello stesso editor. Se il modello si può scambiare, il criterio deve essere un altro.

Il criterio che regge è il confine. Cosa può eseguire l'agente senza chiedere, chi lo ferma, e cosa arriva su main senza che un umano lo guardi.

Tabella rapida: il vincolo, non le feature

La riga che conta di più è la terza. Le altre si negoziano.

Claude Code: il controllo sta nei permessi del client

Claude Code è un agente da terminale che legge il repo, modifica file, esegue comandi e si integra con Git. Gira anche in IDE, desktop e browser, con la stessa configurazione.

La frase chiave è nella documentazione dei permessi: le regole sono applicate da Claude Code, non dal modello. Quello che scrivi in CLAUDE.md orienta cosa l'agente prova a fare. Non cambia cosa gli è permesso fare.

Le regole si valutano in ordine fisso: deny, poi ask, poi allow. Un deny ampio vince sempre su un allow più specifico. Si possono versionare in .claude/settings.json e condividere con il team.

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)", "Read(./.env)"]
  }
}

Due limiti, sempre dalla doc. Una regola Bash confronta il testo del comando: git -C . push non corrisponde a Bash(git push *). Per un confine vero servono la sandbox o un hook PreToolUse, che può bloccare la chiamata anche in modalità bypassPermissions.

Quando vince: quando vuoi che il confine sia un file nel repo, leggibile in review, e non una preferenza nel prompt. Lavori da terminale, scrivi script con claude -p, vuoi hook deterministici.

Cursor: il controllo sta nella modalità di esecuzione

Cursor è un editor con un agente integrato che cerca nel codice, modifica file, esegue comandi e usa un browser. Il controllo sui comandi passa dalle Run Modes.

Le modalità sono tre. Auto-review esegue le chiamate in allowlist, manda in sandbox i comandi shell quando può, e fa giudicare il resto a un classificatore. Allowlist esegue solo ciò che hai elencato. Run Everything esegue tutto.

La documentazione è onesta su un punto: Auto-review non è un confine di sicurezza. Il classificatore può sbagliare in entrambe le direzioni. Le istruzioni in permissions.json sono frasi in linguaggio naturale, che orientano il classificatore. Il confine tecnico è la sandbox, configurata in sandbox.json: rete limitata a un elenco di domini, scrittura nel workspace, alcuni path protetti come .git/hooks.

Poi ci sono i Cloud Agents. Girano in una VM isolata, anche su più repository insieme, e non usano le Run Modes: non ti chiedono approvazioni. Il controllo si sposta sull'ambiente, cioè secrets, domini in uscita consentiti e hook in .cursor/hooks.json.

I checkpoint aiutano a tornare indietro, ma sono locali e separati da Git. Non sostituiscono un commit.

Quando vince: quando passi la giornata nell'editor e vuoi poche interruzioni con una sandbox sotto. Oppure quando ti servono agenti in parallelo su VM, con il confine definito dall'ambiente e non da un clic.

Copilot: il controllo sta nel flusso di GitHub

GitHub Copilot è presente in IDE, CLI e su GitHub.com. Il pezzo che cambia il confronto è il cloud agent: ricerca, pianifica e modifica in un ambiente cloud effimero, e consegna il lavoro in una pull request.

I limiti sono scritti in chiaro e sono il suo punto di forza:

• lavora su un solo repository per task e su un solo branch, di solito copilot/
• apre una pull request per task e ha una sessione massima di 59 minuti
• non può approvare né fare merge delle proprie PR, e chi l'ha avviato non può approvarle
• i workflow di GitHub Actions non partono finché una persona con accesso in scrittura non li approva
• l'accesso a internet passa da un firewall, e le nuove dipendenze vengono controllate sull'Advisory Database

Sono le mitigazioni dichiarate da GitHub. Il confine non è nel prompt né nel client: è nelle branch protection e nelle approvazioni che hai già.

L'ultimo punto si collega a un rischio concreto. Un agente che propone un pacchetto inesistente apre la porta allo slopsquatting. Un controllo sulle dipendenze nuove, prima della PR, è il posto giusto per fermarlo.

Quando vince: quando il repo vive su GitHub, la squadra lavora già per PR e vuoi che l'agente entri in quel processo, non che ne inventi uno nuovo.

Il contesto: un file, tre lettori

Sul contesto la gara è quasi chiusa. Tutti e tre leggono AGENTS.md. Claude Code può usarlo al posto di CLAUDE.md. Cursor legge entrambi. Copilot usa l'AGENTS.md più vicino nell'albero, oppure un CLAUDE.md in root.

Quindi non serve un file per strumento. Serve un solo contratto corto, con comandi veri e never-do, come spiegato in AGENTS.md, CLAUDE.md e regole di Cursor. Se lo stack deciso non è scritto lì, l'agente tornerà al suo default: è la trappola dello stack default.

Il limite è uguale per tutti. Il file di contesto è contesto, non policy. Un never-do in markdown non blocca un comando. Lo bloccano un deny, una sandbox o una branch protection.

Review: da quale branch leggono le regole

Qui c'è una differenza che non si vede nelle pagine prodotto.

Copilot code review legge le istruzioni del repository dal branch della PR, non da quello di destinazione. GitHub lo presenta come un vantaggio: puoi provare nuove istruzioni nella stessa PR. Vuol dire anche che una PR può cambiare le regole con cui viene revisionata.

Bugbot di Cursor fa l'opposto per la sua configurazione: legge .cursor/config/bugbot.yaml dal branch di destinazione. Una PR non può cambiare come Bugbot la revisiona. La doc suggerisce di proteggere quel file con CODEOWNERS. Le regole .mdc di Cursor non valgono per Bugbot: le sue stanno in .cursor/BUGBOT.md.

Claude Code non impone un flusso di review. Il diff lo guardi tu, oppure lo affidi a GitHub Actions. È più libertà e più responsabilità. La checklist per un sito vibe-coded resta valida con qualsiasi dei tre.

Costo e lock-in

Il costo dipende da quanto lavoro deleghi, non dal listino. I modelli di billing sono diversi.

Claude Code richiede un abbonamento Claude o un account Console, e la CLI accetta anche provider terzi. I Cloud Agents di Cursor si pagano a prezzo API del modello scelto, con uno spend limit da impostare al primo uso. Copilot usa crediti AI per piano: Copilot Pro costa 10 dollari al mese, e i completamenti restano illimitati sui piani a pagamento.

Il lock-in vero non è il modello. È dove hai messo le regole. Permessi in .claude/settings.json, sandbox in .cursor/sandbox.json, protezioni nei ruleset di GitHub: spostarsi vuol dire riscriverle. AGENTS.md, invece, viaggia con te.

Chi dovrebbe scegliere cosa

Sviluppatore solo, terminale e script: Claude Code. Il confine è un file JSON versionato e gli hook sono deterministici.

Chi vive nell'editor e vuole poche interruzioni: Cursor con Auto-review e sandbox attiva. Se deleghi task lunghi, Cloud Agents con domini in uscita limitati.

Team già organizzato per PR su GitHub: Copilot cloud agent. Ottieni merge solo umano, workflow da approvare e un branch per task senza configurare nulla di nuovo.

Se il lavoro è uno script che gira ogni notte: nessuno dei tre. Spesso un agente non serve, basta un cron.

Cosa conviene fare adesso

• Scrivi o accorcia un solo AGENTS.md con comandi veri e never-do. Vale per tutti e tre.
• Decidi chi deve poter dire "no" a un comando: un file di permessi, una sandbox o una branch protection. Poi scegli lo strumento che lo mette lì.
• Rendi esplicito il confine: deny su git push e .env in Claude Code, sandbox attiva in Cursor, approvazione dei workflow per Copilot.
• Se l'agente usa tool tuoi, cura prima le descrizioni dei tool: è il tool engineering a decidere se il loop sbaglia in silenzio.

L'autocomplete migliore dura una release. Il confine giusto dura quanto il progetto.