← Blog

Come valutare Claude Code prima di darlo a un team

Marco Masut

La maggior parte delle recensioni di Claude Code risponde a una sola domanda: è bravo a scrivere codice, da solo, dentro una sessione. È la metà facile della valutazione. La metà difficile si vede solo quando lo strumento smette di essere l'assistente di un singolo sviluppatore e diventa qualcosa da cui dipende un intero team, e la software house responsabile di quello che il team consegna.

Cosa cambia in un team, non in una sessione

Dentro una singola sessione, Claude Code si giudica come qualsiasi altro agente di coding: capisce il repository, usa le convenzioni giuste, finisce il task senza bisogno di essere seguito passo passo. Sono domande a cui esistono già risposte discrete, e il confronto con Cursor copre bene quel terreno.

Portalo su un team e l'unità di lavoro cambia. Non è più una persona che lancia una sessione e legge da sola il diff. Sono più persone, su più codebase cliente, che lanciano sessioni che nessun altro ha visto in diretta, producendo modifiche che qualcun altro deve fidarsi di prima che vadano in produzione. Lo strumento non è diventato peggiore a scrivere codice. È diventato più grande il problema che deve risolvere: non più "questa sessione ha prodotto codice buono", ma "chi non c'era può verificare cosa è successo e perché".

Il divario dello Stack Overflow Survey: velocità contro collaborazione

Lo Stack Overflow Developer Survey 2025 è diretto sulla dimensione di questo divario: il 69% di chi usa agenti di coding dichiara una produttività individuale più alta, ma solo il 17% dichiara una collaborazione di team migliorata. Individualmente lo strumento funziona. Collettivamente manca qualcosa tra la sessione di una persona e ciò su cui il resto del team può agire.

Altri due dati del 2025 puntano sulla stessa faglia da angolazioni diverse. Il trial randomizzato di METR ha fatto completare task reali, su codebase che conoscevano bene, a 16 sviluppatori open source esperti, con e senza strumenti AI: con l'AI erano il 19% più lenti, nonostante prima prevedessero un'accelerazione del 24% e dopo dichiarassero di essere stati il 20% più veloci. Il divario tra velocità percepita e velocità misurata era abbastanza ampio da rendere inaffidabile persino l'autovalutazione di chi il lavoro lo aveva fatto. E il report DORA 2025 trova che il 30% di chi risponde dichiara poca o nessuna fiducia nel codice generato dall'AI, con l'AI che alza l'asticella della review invece di abbassarla: il tempo risparmiato scrivendo il codice si spende verificandolo.

Niente di tutto questo significa che Claude Code sia uno strumento scadente. Significa che l'output individuale e la fiducia a livello di team non sono la stessa metrica, e un rollout valutato solo sulla prima sembrerà un successo fino al giorno in cui qualcuno chiede chi può garantire per una modifica specifica, sei mesi dopo.

Cosa controllare prima del rollout (contesto, permessi, review, prove)

Una valutazione a livello di team deve andare oltre "scrive codice buono" e controllare quattro cose che una prova individuale di solito salta:

  • Contesto. L'agente riceve le stesse convenzioni di repository, le stesse linee guida di stile e gli stessi vincoli ogni volta che viene invocato, indipendentemente da chi lo lancia, o la qualità dipende da quanto bene ogni persona sa scrivere il prompt.
  • Permessi. Si può delimitare cosa l'agente può toccare, per progetto o per cliente, e quella delimitazione è imposta da qualcosa di diverso dalla buona volontà di chi digita le istruzioni.
  • Review. C'è un passaggio umano, su ogni modifica, prima che arrivi su un branch su cui qualcun altro costruisce, ed è un passaggio uguale per tutto il team o facoltativo per ogni sviluppatore.
  • Prove. Quando la sessione si chiude, resta qualcosa di duraturo, fuori dalla chat dello strumento, che mostra cosa è stato chiesto, cosa è stato autorizzato, cosa è stato eseguito e con quale risultato, ispezionabile da una seconda persona, o da un cliente, senza dover chiedere a chi ha lanciato la sessione originale.

I primi tre sono decisioni di processo che un team può prendere con Claude Code così com'è oggi: permessi delimitati, review obbligatoria, file di contesto condivisi. Il quarto è dove la maggior parte delle valutazioni smette di guardare, perché lo strumento non è mai stato costruito per rispondere a quella domanda. Non è una critica specifica a Claude Code: nessun agente di coding sul mercato produce ancora quel registro in modo nativo.

Una checklist di valutazione breve

Prima di dare Claude Code a un team invece che a un singolo sviluppatore, vale la pena confermare, su una prova pilota:

  1. Lo stesso task, lanciato da due persone diverse, produce un output confrontabile in fase di review, non solo un codice che funziona in modo confrontabile.
  2. Un revisore che non ha scritto il prompt riesce a capire cosa è stato chiesto e perché, senza scrivere a chi ha lanciato la sessione.
  3. Permessi e percorsi vietati sono imposti dalla configurazione, non dalla disciplina di chi scrive il prompt.
  4. Esiste un registro della sessione che sopravvive alla cronologia della chat, consultabile direttamente da un cliente o da un auditor.
  5. Se il team passasse a un altro agente il trimestre prossimo, il registro di questo trimestre avrebbe ancora senso.

La maggior parte dei team supera i primi due punti e fallisce sugli ultimi tre, non perché Claude Code sia carente, ma perché quei tre punti non sono mai stati parte di quello che si chiede a un agente di coding.

Cosa resta quando lo strumento cambia

Gli strumenti cambiano più in fretta dei team. Una software house che valuta Claude Code oggi deve aspettarsi di usare un agente diverso, o un mix di agenti, entro un anno o due. Quello che sopravvive al cambio non è la cronologia dello strumento, è quello che il team ha costruito in modo indipendente da esso: la disciplina di review, la delimitazione dei permessi, e un registro di intento, autorizzazione, esecuzione e prova che non vive dentro il log di un singolo agente.

È il livello che Detent Bench è costruito per misurare, sulla stessa linea dalla richiesta al production-ready su cui una decisione di rollout dovrebbe già interrogarsi, che lo strumento a scrivere sia Claude Code, Cursor, o qualunque cosa li sostituisca entrambi.