Cherny: il codice di produzione scritto da Claude va valutato con standard più alti

“Quando il codice lo scrive Claude, la soglia deve alzarsi.” Così, l’11 settembre 2026, Boris Cherny indica la regola interna: più controlli, più spesso, più a fondo. E avverte che senza guardrail “finisci con un pasticcio difficile da mantenere nel tempo”¹.

Cherny colloca la pratica in Anthropic. Dice che l’azienda ha “molte guardrail” per far rispettare quello standard. L’elenco è secco: “molte regole di lint”, “molti test”, test end‑to‑end guidati da Claude, fuzzing quotidiano alimentato da Claude, revisioni di codice automatizzate, revisioni di sicurezza automatizzate, refactoring automatizzato. Sottolinea la quantità (“lots of”), non fornisce numeri. L’unico ritmo temporale esplicito riguarda i fuzzers: “running daily”¹.

Due voci mostrano l’uso diretto del modello nella verifica: test end‑to‑end generati dal modello e fuzzing quotidiano alimentato dal modello. Il messaggio è operativo: Claude può scrivere codice, ma anche creare test e casi anomali per stressarlo. L’obiettivo è tenere alta l’affidabilità e la manutenibilità del software in produzione¹.

Il perimetro resta intenzionale, non metrico. La fonte non entra in coperture di test, soglie di lint, policy di approvazione, tassi di bug, tempi di risoluzione o stabilità in esecuzione. Non cita linguaggi, stack, progetti o percentuali. Non fornisce esempi di incidenti evitati o regressioni trovate. La formulazione “and so on” indica che l’elenco non è esaustivo, senza aggiungere altri elementi nominabili¹.

Questa mancanza conta. Per valutare l’efficacia dei controlli servirebbero, ad esempio, metriche aggregate (copertura, difetti per KLOC, MTTR), campioni di test generati dal modello con esito, o descrizioni di configurazioni tipo. Anche un confronto A/B tra codice umano e codice assistito chiarirebbe dove la “soglia più alta” migliora i risultati e dove no. La fonte non li offre: chi decide l’adozione dovrà richiederli o costruirli in casa con benchmark, audit su pull request e reporting periodico.

Il messaggio di Cherny, però, è chiaro su un punto: non propone un divieto d’uso. Propone una condizione di qualità. Se il codice arriva da un modello, il processo deve alzare l’asticella con regole, test, fuzzing e revisioni automatizzate. L’assenza di dettagli operativi non indebolisce il principio; indica piuttosto un approccio prudente che insiste sui controlli ripetibili più che su una singola tecnica risolutiva¹.

Implica anche scelte organizzative. Alzare la soglia richiede tempo, tooling e disciplina: pipeline che eseguano i fuzzers ogni giorno, integrazioni per test e review automatiche, responsabilità chiare su chi approva e monitora. Chi introduce generazione di codice in produzione deve pianificare governance e budget prima di dare al modello accesso al repository. In caso contrario, il rischio evocato da Cherny — debito che si accumula e codice che invecchia male — arriva in silenzio e resta a lungo¹.