Se stai cercando un confronto tra Claude Code e Codex, probabilmente vuoi rispondere a una domanda molto pratica: quale usare per programmare davvero? Non in una demo, non su un benchmark sintetico, ma dentro un codebase reale, con vincoli reali, bug reali e poco tempo per sistemare quando qualcosa va storto.
Negli ultimi mesi uso sia Claude Code sia OpenAI Codex su progetti reali. Non per fare benchmark da laboratorio, ma perché quando stai lavorando su un codebase devi portare a casa una modifica: leggere codice esistente, capire vincoli, fare una scelta, implementarla, verificare che non abbia rotto altro.
In questi giorni mi sono capitati due episodi quasi speculari. Stesso tipo di lavoro: una task concreta, codebase reale, prompt dettagliato, interazioni successive per correggere la direzione. Da una parte Claude Code con Opus 4.7. Dall'altra Codex con GPT-5.5.
Il risultato è stato interessante proprio perché non ha prodotto una classifica semplice. In un caso Claude si è perso e Codex ha risolto in pochi minuti. Nell'altro Codex ha prodotto una soluzione brutta e fragile, mentre Claude ha consegnato codice pulito quasi subito.
Claude Code o Codex: risposta breve
Se devo semplificare, oggi li vedo così: Claude Code è spesso più forte quando serve progettare o modificare una feature con molto contesto; Codex è molto forte come revisore, semplificatore e secondo parere tecnico quando una soluzione sta diventando troppo complicata.
Quindi la domanda "meglio Claude Code o Codex?" è posta male. La domanda utile è: per quale fase del lavoro?
Per scrivere una feature complessa, soprattutto se il progetto ha un flusso applicativo già strutturato, tendo a preferire Claude. Per revisionare codice, togliere complessità, individuare rischi e uscire da un vicolo cieco, Codex è spesso il compagno giusto.
Il punto non è scegliere una squadra. Il punto è sapere quando cambiare strumento.
Claude Code vs Codex: dove Claude si è incartato
Il primo episodio riguardava una feature in Go e Angular: un workflow editor, cioè un'interfaccia per creare e modificare un flusso visuale simile a una macchina a stati finiti. Stati, transizioni, frecce, nodi editabili. Il tipo di interfaccia dove la parte difficile non è solo salvare i dati, ma rendere leggibile il diagramma mentre l'utente lo modifica.
Claude ha capito il problema generale. Ha iniziato a progettare la feature, ha scritto codice, ha iterato sulle modifiche. Il problema è emerso sulle frecce: più cercava di sistemarle, più il disegno diventava confuso. Linee sovrapposte, incroci poco controllati, layout difficile da seguire. Il risultato era il classico "piatto di spaghetti": formalmente c'erano tutti i collegamenti, ma visivamente il diagramma era inutilizzabile.
Dopo quasi due ore di prompt e interazioni, la situazione era peggiorata. Claude continuava a lavorare sullo stesso punto, ma ogni tentativo aggiungeva complessità senza risolvere il problema di fondo. A un certo punto ha iniziato a proporre librerie aggiuntive, astrazioni nuove, logica extra per gestire casi che in realtà erano sintomi della soluzione sbagliata. Il progetto diventava più pesante, ma il diagramma non diventava più leggibile.
Questo è uno dei failure mode più pericolosi degli assistenti AI: non falliscono sempre fermandosi. A volte falliscono continuando a lavorare. Producono codice, spiegano cosa stanno facendo, sembrano avere una strategia, ma in realtà stanno scavando più in profondità dentro una direzione sbagliata.
Alla fine ho passato il problema a Codex. Non gli ho chiesto di aggiungere un'altra pezza, ma di guardare il problema e risolverlo. In circa dieci minuti ha fatto la cosa che serviva: ha tolto dipendenze, ha semplificato il codice, ha riscritto un paio di metodi chiave e ha riportato il progetto alla forma desiderata.
La cosa importante non è che Codex abbia "vinto" quel task. La cosa importante è che ha riconosciuto una complessità inutile e l'ha tagliata. In quel momento serviva meno codice, non più codice. E Claude, dentro quel loop, non ci stava arrivando.
Quando Codex sbaglia architettura e Claude risolve
Pochi giorni dopo è successo l'inverso.
Avevo quasi esaurito il piano Claude Max e ho deciso di affidare a Codex una task su un progetto Laravel e Vue. Anche qui niente esperimento astratto: una modifica reale dentro un flusso applicativo già esistente. Prompt chiaro, contesto sufficiente, obiettivo verificabile.
Dopo circa venticinque minuti e tre iterazioni, il risultato era tecnicamente inaccettabile. Non perché mancasse completamente l'idea, ma perché l'implementazione era una somma di scorciatoie: override di un flusso già previsto dal programma, condizioni speciali infilate nei punti sbagliati, hack per forzare il comportamento invece di integrarsi con il modello esistente. E, cosa ancora più importante, il codice non funzionava bene: c'erano bug logici e problemi infrastrutturali.
Probabilmente quel codice si sarebbe potuto sistemare a mano. Ma a quel punto la domanda interessante era un'altra: cosa sarebbe successo dando lo stesso task a Claude?
Ho revertito tutte le modifiche e ho passato a Claude Code lo stesso prompt, copiato e incollato. In sette minuti e due interazioni mi ha consegnato una soluzione funzionante. L'ho revisionata a mano, riga per riga. Il codice era pulito, coerente con il progetto, inserito nel flusso corretto. Non era solo "funziona": era una soluzione che avrei fatto fatica a scrivere meglio.
Qui il risultato è stato opposto al primo episodio. Dove Codex aveva cercato una strada laterale, Claude ha capito l'architettura del flusso e ci si è infilato dentro nel modo giusto.
Quale AI per programmare? Dipende da come sbaglia
Questi due episodi raccontano una cosa che nei discorsi sull'AI nello sviluppo software viene spesso semplificata troppo: non basta chiedersi quale modello "scrive codice meglio". Bisogna chiedersi come sbaglia.
Claude, nella mia esperienza, tende a essere molto forte quando deve costruire un modello mentale del sistema. Legge bene l'intenzione, ragiona sui confini, propone soluzioni ordinate, spesso mantiene una coerenza architetturale migliore. Come sviluppatore e come architetto, quando prende la direzione giusta, è impressionante.
Il suo problema è che quando entra in un loop sbagliato può diventare difficile da fermare. Continua a raffinare la stessa direzione, aggiunge dettagli, moltiplica la struttura, propone dipendenze. Se non lo guidi con decisione, o se non hai voglia di intervenire a mano, rischi di ritrovarti con un sistema più complicato e ancora rotto.
Codex, invece, mi convince moltissimo come revisore. È molto bravo a guardare codice esistente, individuare punti fragili, togliere rumore, ridurre complessità. Nel primo episodio ha fatto esattamente questo: ha guardato una soluzione che stava collassando sotto il suo peso e l'ha resa semplice.
Come developer è assolutamente utilizzabile. Ma come architetto, almeno nei casi che ho visto, mi convince meno. Soprattutto quando il task richiede di rispettare un flusso applicativo già progettato e di inserirsi nel punto giusto, può cercare scorciatoie locali: codice che sembra risolvere il caso immediato, ma aggira il disegno del sistema. E quando succede, il costo arriva dopo, in manutenzione.
Code review con AI: la revisione manuale resta obbligatoria
La prima lezione è banale, ma va detta perché è l'unica che conta davvero: il codice generato va sempre revisionato. Sempre.
Non importa se arriva da Claude, da Codex, da Cursor o dal modello migliore del momento. Non importa se ha passato i test. Non importa se la diff sembra piccola. Un assistente AI può produrre codice elegante e sbagliato, codice brutto e funzionante, codice pulito ma incoerente con il dominio, codice che risolve il task e danneggia l'architettura.
La review non serve solo a trovare bug. Serve a rispondere a domande più importanti: questa modifica rispetta il modello del progetto? Sta introducendo una dipendenza inutile? Sta mettendo logica nel posto giusto? Sta risolvendo il problema o sta nascondendo un sintomo? Tra sei mesi qualcuno capirà perché è stata fatta così?
È lo stesso punto che torna quando si parla di sviluppare con l'AI: questi strumenti accelerano il lavoro, ma non eliminano il giudizio. Anzi, lo rendono più importante, perché producono materiale tecnico molto più velocemente di quanto un team medio riesca a valutarlo con attenzione.
Quando usare Claude Code e quando usare Codex
La seconda lezione è più pratica: non bisogna affezionarsi allo strumento. Claude non è "il migliore" in assoluto. Codex non è "il migliore" in assoluto. Sono strumenti diversi, con punti forti diversi e modi diversi di fallire.
Se Claude entra in un loop di complessità, può essere molto più efficiente fermarlo, salvare il contesto e chiedere a Codex una revisione radicale. Non per continuare ad aggiungere codice, ma per togliere quello che non serve.
Se Codex propone una soluzione che aggira il flusso del progetto, può avere senso fermarsi subito e passare il task a Claude, soprattutto quando serve una lettura più architetturale del sistema.
Questa è una competenza nuova ma concreta: saper capire quando un assistente sta ancora aiutando e quando sta solo producendo rumore. Prima lo capisci, meno tempo perdi. Il costo non è solo il tempo del modello: è il tempo che passerai tu a ripulire, debuggare, spiegare e magari revertire.
Confronto Claude Code vs Codex: cosa mi porto a casa
Da questi due episodi mi porto a casa tre cose.
La prima è che la review umana non è un rito finale, ma parte centrale del lavoro. Senza review, l'AI aumenta la velocità con cui entra codice nel progetto, ma non necessariamente la qualità del sistema.
La seconda è che Claude, quando non si perde, oggi mi sembra più forte sia come architetto sia come sviluppatore. Soprattutto su task dove bisogna capire il flusso applicativo e inserirsi nel disegno esistente. Però ha un failure mode molto riconoscibile: quando entra in un vicolo cieco, può continuare a produrre complessità invece di fermarsi e cambiare strada.
La terza è che Codex è un revisore eccellente e un buon sviluppatore, ma lo uso con più cautela quando la task richiede una decisione architetturale. Mi fido molto della sua capacità di criticare codice, semplificare, trovare problemi. Mi fido meno della sua tendenza a progettare il flusso giusto da zero o a rispettare un disegno implicito se il progetto non glielo rende evidente.
Naturalmente sono osservazioni empiriche, non una legge fisica. Versioni diverse dei modelli, prompt diversi, codebase diverse e stack diversi possono cambiare molto. Ma proprio per questo gli episodi reali sono utili: mostrano i punti in cui la teoria si sporca con il lavoro quotidiano.
Entrambi servono, ma per lavori diversi
Il punto non è tifare Claude o Codex. Il punto è costruire un modo di lavorare che sfrutti entrambi senza delegare loro il giudizio.
Io oggi li uso così: Claude quando serve costruire o modificare una feature con forte componente di contesto; Codex quando serve revisionare, semplificare, smontare una soluzione che non mi convince. Se uno dei due inizia a girare a vuoto, non insisto per principio. Revert, cambio strumento, confronto le soluzioni, poi decido io cosa tenere.
In questo senso, Codex per me ha un valore molto pragmatico anche quando non è lo strumento principale di sviluppo: è il revisore che entra quando qualcosa non torna, l'assistente da chiamare nei momenti bui, il secondo paio di occhi quando il modello che stai usando ha iniziato a complicare invece di chiarire.
Se lavori seriamente con questi strumenti, mettere a budget circa 23 euro in più al mese per avere Codex disponibile non è una spesa difficile da giustificare. Non perché sostituisca Claude, e non perché sia sempre migliore. Perché copre un bisogno diverso: revisione, contrasto, semplificazione, recupero quando l'altro assistente si è incastrato.
È meno romantico del "l'AI scrive tutto da sola", ma è molto più vicino al lavoro reale.
Entrambi sono validi. In certi flussi, entrambi sono necessari. Ma nessuno dei due firma la pull request al posto tuo.
La responsabilità del codice resta sempre del developer: del codice che scrive, del codice che accetta, del codice che lascia entrare in produzione. L'AI può scrivere codice molto buono. Può anche scrivere codice pessimo con grande sicurezza. La differenza la fa ancora chi guarda la diff e decide se quel codice merita di entrare nel progetto.
Simone Giusti
Consulente software strategico
