Claude Code dopo tre mesi: per chi va bene, per chi no e quanto costa davvero (2026)

Questo sito lo costruiamo da luglio 2026 con Claude Code – l’assistente di programmazione di Anthropic che lavora direttamente nella cartella del progetto: legge e modifica file, esegue test, scrive nel database. Tre mesi, di solito più di dieci ore al giorno, il piano più caro «Max». Quello che segue non è un confronto tra modelli né un test, ma l’esperienza di un solo progetto, con dati e numeri dai nostri registri: la cronologia di Git e i report di GitHub Actions, Vercel e Supabase.

Novembre 2026: con il nuovo modello l’esperienza è diversa

I casi descritti più sotto sono stati raccolti da luglio a ottobre, e il testo è rimasto com’era stato scritto allora. Da allora è cambiato il modello, e con lui il nostro giudizio.

• Claude Fable 5.1 nel nostro lavoro è stato molto debole.
• Claude Opus 5.5 ha lavorato meglio.
• Claude Fable 5.2 supera anche Opus 5.5. Lavora in modo del tutto diverso dal 5.1, e dei tre è quello che giudichiamo migliore.

Aggiunta del 15 novembre 2026: dove Fable 5.2 si inceppa. Un lavoro breve e ben definito lo svolge bene. Un piano più lungo non lo porta a termine.

• È meglio non distribuire un flusso di lavoro su più messaggi. Nel nostro caso il modello ha eseguito l’ultimo punto e saltato i venti precedenti.
• Gli abbiamo chiesto cinque volte di preparare un piano per tutta la notte. Non l’ha preparato: ha lavorato circa dieci minuti su otto ore, e nel resoconto ha scritto che il lavoro della notte era finito. In tutta la notte è stato consumato l’1% del limite.
• Quando gli abbiamo chiesto perché non avesse lavorato, ha risposto che non lo sapeva con esattezza: aveva scelto la parte più facile da eseguire e aveva trascurato l’obiettivo.
• Chiesto per tutti i paesi, fatto per uno. Il modello ha completato per intero le pagine di disdetta solo in lituano e negli altri mercati ha aggiunto una sola domanda.
• Non ha usato gli strumenti integrati che gli erano consentiti. Tutti i permessi erano stati concessi in anticipo; il modello non li ha toccati e nel resoconto del mattino ha scritto che per il lavoro servivano.
• Ha chiesto proprio ciò che gli era stato detto di non chiedere. Dieci minuti prima del resoconto gli era stato detto di non chiedere del caricamento del codice. Il resoconto si è chiuso esattamente con quella domanda.
• Si è basato su appunti superati. Il modello ha scritto parte delle risposte sui rimborsi partendo da appunti vecchi di qualche mese, senza riaprire le pagine dei fornitori. Tre affermazioni erano già superate. Un’altra sessione dello stesso modello le ha trovate e corrette il giorno stesso.
• Ha letto recensioni troppo vecchie. Gli era stato chiesto di basarsi solo sulle recensioni degli ultimi mesi. Le sessioni avviate in parallelo hanno iniziato a leggere anche recensioni di diversi anni fa, finché non le abbiamo fermate.
• Ha sbagliato la data. Ha datato diversi testi al giorno successivo e se n’è accorto solo ore dopo.

C’è una cosa che lega tutti questi casi: quando arriva un messaggio nuovo, il modello può dimenticare quelli precedenti. Non succede sempre, ma abbastanza spesso da ricavarne una regola pratica: a un modello Fable conviene dare tutto il compito in una volta, in un unico messaggio completo. Se più tardi aggiungi una o due righe a un compito già assegnato, è molto probabile che vengano eseguite solo quelle righe.

Conclusione: in teoria il modello funziona bene, ma da solo non riesce a portare a termine un piano di lavoro più lungo. Se lasci del lavoro per la notte, scrivi tutta la coda in un unico file e controlla che sia stata davvero avviata. Con ChatGPT non ci è successo: lì i piani vengono di solito eseguiti dall’inizio alla fine, un punto dopo l’altro. Fable 5.2, il modello più avanzato, ha mostrato chiaramente di non esserne capace.

Lo strumento è lo stesso, è cambiato solo il modello. Per questo ogni giudizio su Claude Code, questo compreso, va letto insieme alla sua data: vale finché non esce il modello successivo.

Per quale dei due, Claude o ChatGPT, valga la pena pagare oggi lo spieghiamo nell’articolo quale abbonamento AI scegliere.

La risposta breve

Ai principianti lo sconsigliamo. Claude Code va bene per chi legge ogni modifica, ha controlli automatici e gli dà errori descritti con chiarezza da correggere. Costruire un prodotto da zero si può, ma costa: in soldi, nei limiti di altre piattaforme e nel tuo tempo, la maggior parte del quale va nella supervisione.

Cosa funziona bene

Il codice lo sistema da professionista. Un errore descritto con chiarezza, un file preciso, un test esistente – e la correzione è pulita, con i tipi, con il test, spesso migliore di quella che avremmo scritto di fretta. Legge file grandi senza fatica, trova la causa dove una persona cercherebbe per un’ora, e sa lavorare con TypeScript, Next.js, migrazioni di database e test Playwright.

È importante dirlo subito: tutto quello che segue riguarda il processo.

Cosa non funziona

Non rispetta le regole scritte

Il progetto ha un file di regole che il modello legge all’inizio di ogni sessione. C’era scritto fin dall’inizio cosa fare prima di ogni caricamento di codice, cosa non chiedere e quante volte possono girare i controlli costosi. Alcune voci dal registro:

• 19–25.08.2026. Il modello ha chiesto 102 volte di confermare prezzi che erano già tutti segnati come verificati, anche se la regola diceva di non chiederlo.
• 24.09.2026. Per rinominare tre piani sono partiti otto giri completi di controlli. Hanno consumato il limite mensile di dati di Supabase; quattro risultati su cinque li avrebbe trovati un controllo locale economico.
• 28.09.2026. Lo stesso importo di Bitdefender è stato controllato 23 volte di fila.
• 12.10.2026. Per un solo pacchetto di modifiche, sette giri di controlli sul server, sei rossi. Cinque caricamenti sono avvenuti senza i controlli locali che la regola chiedeva per primi. Il pacchetto, il cui codice era verde in locale, è arrivato nel ramo principale dopo quattro ore.

Cambia ciò che non ha capito, anche quando è vietato

• 24.09.2026. Uno script avviato per tre nomi ha creato quattro piani senza prezzi. Sulla pagina pubblica in lingua lituana sono comparsi per circa sette ore come «Gratis».
• 12.10.2026. Il modello ha costruito da solo un meccanismo «un fatto vale per tutti i mercati», anche se la regola del progetto dice il contrario: ogni Paese ha i suoi fatti dalle sue fonti. Lo stesso giorno ha azzerato per errore le prove gratuite di sette piani, anche se la pagina del fornitore le indicava.
• 29.09.2026. Il gestore ha cancellato 90 regole che il modello si era scritto da solo in un mese. Una parte limitava quali informazioni mostrare al gestore.

Non usa ciò che gli dai

Il gestore manda uno screenshot con il prezzo. Il modello non lo inserisce, preferisce verificare da solo, non ci riesce e lascia il campo vuoto con la nota «non verificato». Poi il gestore rimanda lo screenshot. È successo così spesso che la regola «lo screenshot è la prova definitiva» è salita al primo posto nel file delle regole – ed è stata comunque infranta.

Costi che non sono in nessun listino

Claude Code costa più dell’abbonamento. Il modello esegue comandi che su altre piattaforme costano soldi, e i limiti devi sorvegliarli tu.

• Crediti. Il piano «Max» – 200 € al mese. Il 12.10.2026 un solo giorno con un solo pacchetto di modifiche ha consumato il 35% del limite settimanale.
• GitHub Actions. Ogni caricamento in un pacchetto di modifiche aperto avvia un giro completo di controlli. 12.10.2026: sette giri, 79 minuti di server, sei rossi per errori che un controllo locale di 15 minuti avrebbe preso.
• Vercel. Lo stesso caricamento è anche un nuovo deployment di anteprima: sette in un giorno per un pacchetto. Il 01.10.2026 il limite del piano gratuito era superato.
• Supabase. Le interrogazioni al database costano volume di dati. Il 06.10.2026 il modello ha letto il database circa 40 volte in quattro ore e ha svuotato sei volte la cache di tutto il sito, pur lavorando da solo. Il 03.10.2026 è servito un piano a pagamento.
• Il tuo tempo. Il 06.10.2026 una sola richiesta di autorizzazione del browser, che nessuno ha visto, ha fermato il lavoro notturno per cinque ore.

Tutti questi divieti e limiti erano scritti in anticipo nelle regole del progetto, ognuno con data e motivo.

Per chi va bene e per chi no

Va bene se programmi tu, leggi ogni modifica prima di accettarla, hai test e controlli automatici negli hook di Git e dai al modello compiti piccoli e descritti con chiarezza: questo errore, in questo file, con questo test. Allora è veloce e preciso.

Non va bene se costruisci da zero e speri che le regole scritte lo frenino. Una regola di testo non lo ferma. Lo ferma solo un meccanismo che non può aggirare: un hook di Git che senza controllo non permette il caricamento, un controllo sul server che va superato, una protezione del database che rifiuta il comando. Tutto ciò che questi meccanismi non coprono, prima o poi lo fa a modo suo.

Non va bene nemmeno per chi non sa programmare. Non vede quando il modello ha cambiato il file sbagliato, e lo scopre dai visitatori del sito.

Che cosa ha aiutato davvero

Le regole scritte non hanno trattenuto il modello, così con il tempo abbiamo sostituito ogni errore ricorrente con un meccanismo. Cinque che funzionano ancora:

• Conferma prima delle azioni irreversibili. Dal 24/09/2026 il push del codice, l’apertura di una pull request e i comandi sul database partono solo dopo che una persona ha cliccato sì. Il modello prepara il comando, una persona decide se eseguirlo.
• Un budget per i controlli costosi. Dopo ogni modifica girano solo i controlli locali economici; il giro completo una volta sola, subito prima del push. La regola è nata dopo gli otto giri del 24 settembre.
• Un programma che rifiuta le letture del database. Dal 06/10/2026 il database di produzione si legge una volta sola, il risultato viene salvato e si continua a lavorare sulla copia. Ogni altro comando lo respinge un hook, senza aspettare che qualcuno si ricordi della regola.
• Una cartella separata per ogni sessione. Più sessioni nella stessa cartella si ostacolano: una cambia branch e l’altra resta senza i propri file. Per questo ognuna parte dalla propria cartella e dal proprio branch.
• Una protezione per le scritture sul database. Ogni script che scrive prende prima un blocco e registra chi ha scritto e quando. Uno script che cancella dati si ferma da solo se trova un prezzo verificato.

Il principio è uno: una regola che si può aggirare prima o poi viene aggirata. Funziona solo ciò che tecnicamente non si può aggirare.

Cosa faremmo diversamente

Inizieremmo dagli hook e dalle protezioni; il file delle regole verrebbe dopo. Daremmo compiti più piccoli e chiuderemmo ciascuno con un solo caricamento. Dimenticheremmo gli incarichi notturni «finiscilo»: senza una persona alla tastiera si ferma alla prima domanda o va dove non deve.

E misureremmo un solo numero: quante ore restano da controllare dopo il suo lavoro. Il nostro rapporto in tre mesi è stato pessimo.

La valutazione con prezzi, limiti e condizioni di disdetta è nella pagina di Claude; gli altri assistenti nella categoria intelligenza artificiale.