Claude Code o GitHub Copilot: i dati premiano compiti diversi, non un vincitore

La scelta tra Claude Code e GitHub Copilot dipende dal lavoro prevalente: Copilot è pertinente per chi cerca completamenti mentre scrive nell’IDE, mentre Claude Code è un candidato per incarichi affidati a un agente che interviene su più file. I risultati osservati sulle pull request cambiano con il tipo di attività e non indicano un vincitore generale.

Entrambi, però, possono svolgere lavoro agentico. La distinzione utile è tra suggerimenti inline, modifiche eseguite dall’agente e risultati accettati nel repository: sono esiti diversi, da valutare separatamente insieme all’ambiente di lavoro e al costo dell’incarico concluso.

Ambiente di lavoro e autonomia

La documentazione di Claude Code descrive un agente che legge il codice del progetto, modifica file ed esegue comandi. È disponibile nel terminale, negli IDE, nell’app desktop e nel browser; nell’estensione per VS Code le modifiche possono essere esaminate direttamente nell’editor. Il terminale offre un modo diretto di usare script e strumenti locali, ma non è l’unico ambiente del prodotto.

La guida GitHub per Copilot nell’IDE distingue i suggerimenti inline dalla modalità agente. I primi propongono codice durante la scrittura; nella seconda Copilot può decidere quali file cambiare, apportare modifiche ed eseguire comandi con l’approvazione dell’utente, negli IDE che la supportano. Confrontare un suggerimento accettato con una pull request prodotta da un agente confonderebbe quindi due incarichi e due misure di successo.

Per un compito che attraversa il repository contano anche gli strumenti disponibili, le autorizzazioni e il modo in cui la modifica viene presentata alla revisione. Il modello linguistico è una componente di questo sistema: un risultato ottenuto con accesso ai file, comandi e istruzioni del progetto non misura il modello isolato. L’integrazione preferita resta una scelta pratica del team, distinta dalla qualità del codice prodotto.

Che cosa misurano le pull request reali

L’analisi di 7.156 pull request confronta cinque agenti e registra per Claude Code i tassi di accettazione più alti nella documentazione (92,3%) e nelle nuove funzionalità (72,6%) del campione. Nessun agente guida tutte le categorie. Il sottoinsieme attribuito a Claude Code comprende 139 pull request, contro 2.194 attribuite a GitHub Copilot: soprattutto il risultato sulla documentazione poggia su pochi casi.

Il tasso di accettazione indica la quota di pull request chiuse che è stata incorporata nel repository. Nell’analisi entrano solo proposte che hanno ricevuto almeno una revisione o un commento da una persona diversa dall’autore. Questo filtro dà più peso all’esito rispetto al semplice conteggio del codice generato, ma una modifica incorporata può comunque richiedere manutenzione o contenere difetti.

Le percentuali descrivono lavori assegnati in repository diversi, non un esperimento in cui Claude Code e Copilot ricevono lo stesso incarico nelle stesse condizioni. Cambiano la difficoltà dei compiti, le consuetudini di revisione e la distribuzione delle categorie; le comparazioni statisticamente significative riportate nell’analisi non stabiliscono una superiorità diretta di Claude Code su Copilot. I dati offrono dunque un motivo per distinguere le attività, non una previsione affidabile per ogni nuovo progetto.

Completamento, funzionalità e correzioni richiedono misure diverse

Se il lavoro consiste soprattutto nel completare funzioni e fare piccole modifiche mentre si scrive, la capacità pertinente di Copilot è il suggerimento inline. Una pull request incorporata non dice quante proposte inline siano rimaste nel codice dopo i test, né quanto tempo sia servito per correggerle. In questo caso una misura interna utile è il lavoro effettivamente conservato, insieme alle interruzioni e alle correzioni richieste allo sviluppatore.

Per documentazione e nuove funzionalità distribuite su più file, il campione di pull request rende Claude Code un candidato da includere nella prova, senza trasformare il suo vantaggio descrittivo in una garanzia. Le correzioni di bug chiedono un giudizio diverso: riproduzione del difetto, test che ne mostrano la soluzione e assenza di regressioni. La categoria assegnata a una pull request, da sola, non racconta quanto fosse difficile individuare la causa del problema.

Anche il perimetro dell’incarico cambia l’interpretazione del risultato. Un agente che prepara una modifica completa e un assistente che propone frammenti di codice possono entrambi essere utili allo stesso team, ma richiedono interventi umani differenti. Per questo conviene registrare separatamente il tempo di esecuzione, quello di revisione e le modifiche necessarie prima dell’accettazione.

Fatturazione: il canone non basta

La documentazione di fatturazione GitHub misura l’uso di Copilot in AI credits e assegna a ciascun credito il valore di 0,01 dollari. I piani individuali comprendono quote mensili differenti; per organizzazioni e imprese, i crediti inclusi nelle licenze assegnate possono confluire nella disponibilità dell’entità che paga. Il valore unitario del credito non è il prezzo fisso di una richiesta: il consumo dipende dall’interazione.

La pagina dei piani Claude include Claude Code nei piani a pagamento e indica che il suo uso condivide i limiti del piano con le altre attività Claude. È disponibile anche l’uso di crediti API a consumo tramite Console. Per confrontare le spese di un team occorre quindi distinguere uso compreso nell’abbonamento, eventuale consumo aggiuntivo e limiti raggiunti durante gli incarichi.

Il costo più informativo è quello per modifica accettata: spesa del servizio più tempo umano di preparazione, revisione e correzione. Un’esecuzione che costa poco ma richiede molte revisioni può essere meno conveniente di una proposta inizialmente più onerosa. Prezzo della licenza e tariffa d’uso restano dati necessari, ma non descrivono da soli il lavoro rimasto alla squadra.

Una prova interna comparabile

Una prova utile parte da incarichi rappresentativi dei repository del team, separando completamenti inline, documentazione, nuove funzionalità e correzioni. Per confrontare il lavoro agentico, i prodotti dovrebbero ricevere la stessa descrizione, partire dallo stesso stato del codice e operare con un perimetro di accesso equivalente. Prima dell’esecuzione vanno fissati comportamento atteso, test pertinenti e condizioni per considerare accettabile la modifica.

Per ogni incarico si possono registrare esito dei test, difetti emersi in revisione, interventi richiesti allo sviluppatore, tempo impiegato e consumo fatturato. Annotare anche modello selezionato, strumenti e autorizzazioni aiuta a capire quale configurazione ha prodotto il risultato. Chi revisiona dovrebbe applicare gli stessi criteri usati per il codice scritto da persone; quando è possibile, può giudicare la modifica senza conoscere il prodotto che l’ha generata.

I completamenti inline richiedono una valutazione separata, basata sui suggerimenti mantenuti dopo test e correzioni. Per gli incarichi agentici, il confronto per categoria e per modifica accettata mostra dove ciascun prodotto ripaga il costo e il tempo di revisione. È su quella distribuzione del lavoro, e non su una percentuale unica, che una squadra può fondare la scelta.