Claude Code e Codex insieme: 3 modelli di lavoro

Materiali pratici sul lavoro con gli agenti e sul vibe coding: documentazione Ailoot.

Perché nel 2026 un solo strumento non basta più?#

A maggio 2026, OpenAI è entrata nel territorio di Anthropic con il modello GPT-5.5 in Codex CLI. Nei benchmark recenti, Codex è nettamente avanti nelle attività da terminale e nella modalità SWE-bench Verified. Anthropic ha risposto con Opus 4.8 e Dynamic Workflows, mantenendo il vantaggio su SWE-bench Pro (un test progettato per prevenire la fuga di dati, in cui addestrare un modello sul benchmark non è d’aiuto). Un confronto dettagliato è disponibile nella guida Codex vs Claude Code; qui passiamo direttamente all’abbinamento.

Nel 2026 non c’è un vincitore assoluto. Prevale un modello: i team usano Codex per il lavoro autonomo a basso costo e Claude Code per le decisioni architetturali rischiose.

La differenza fondamentale che determina come dividere il lavoro:

• Claude Code è il ricercatore. Sostiene un dialogo lungo e approfondito, mette in discussione le supposizioni e valuta diversi approcci prima di scegliere una soluzione. È adatto alle situazioni in cui la decisione giusta non è evidente fin dall’inizio.
• Codex è l’esecutore. Riceve un’attività e punta al risultato in un ambiente sandbox. È adatto alle attività ben definite che richiedono un ciclo rapido di «richiesta e risultato».

Se hai a disposizione entrambi gli strumenti, non devi scegliere tra «pensare» e «fare». Deleghi in base al tipo di attività. Se non hai ancora deciso quale dei due installare per primo, trovi un confronto diretto nella guida Codex vs Claude Code.

Modello 1: Claude Code scrive il codice, Codex lo revisiona#

In questo modello, Claude Code rimane l’editor principale. Codex interviene solo a livello di PR tramite la modalità cloud (Codex viene eseguito direttamente da ChatGPT o dall’app GitHub, quindi non serve un secondo terminale).

Ecco come funziona nella pratica:

1. Passaggio 1: scrivere la funzionalità in Claude Code

   Apri il repository in VS Code, avvia Claude Code, passa a Plan Mode e discuti l’architettura della funzionalità. Otterrai una bozza del codice, i test e le migrazioni. Esegui il commit su un branch dedicato alla funzionalità.

2. Passaggio 2: creare una PR su GitHub

   Apri una pull request dal branch della funzionalità a main. Nella descrizione inserisci @codex review this PR for edge cases, security issues, and test coverage gaps.

3. Passaggio 3: Codex esegue la revisione in modo asincrono

   In modalità cloud, Codex clona il repository nel proprio ambiente sandbox, legge il diff, esegue i test e il linter, e cerca vulnerabilità. Dopo 5-15 minuti, lascia commenti direttamente sulla PR.

4. Passaggio 4: apportare modifiche in Claude Code

   Torna a Claude Code e fornisci i commenti di Codex come contesto: «Ecco cosa ha rilevato la revisione; correggi i punti 1, 3 e 5». Claude apporta le modifiche e le pubblica nel repository.

Questo modello funziona perché Claude e Codex sono stati addestrati su dataset diversi e hanno filosofie differenti. Codex nota ciò che Claude non ha visto a causa del punto cieco del suo modello, e viceversa.

Rischi del modello 1:

• Codex potrebbe approvare e chiudere una PR senza rilevare un problema architetturale. Verifica personalmente le decisioni importanti.
• Doppio costo in token: Claude e Codex analizzano lo stesso codice. Conviene per le funzionalità complesse, ma è costoso per quelle piccole.
• Codex in modalità cloud non può vedere l’ambiente locale, per esempio le variabili d’ambiente o i database locali. Se la funzionalità li coinvolge, passa a un’esecuzione manuale.

Modello 2: Codex prepara una bozza, Claude Code sistema l’architettura#

Questo modello è stato usato nel progetto descritto nel 2026, quando si doveva realizzare in una sera un prototipo di funnel di registrazione con notifiche email. In questo scenario, si sarebbe potuta passare un’ora a discutere l’architettura con Claude Code. Codex ha prodotto una bozza funzionante in 12 minuti.

Come funziona:

Funziona così: Codex svolge il lavoro più meccanico per i primi 15 minuti, poi Claude porta il risultato a livello di produzione.

Se chiedi a Codex di rifinire subito il risultato, si bloccherà davanti alle ambiguità. Se chiedi a Claude Code di procedere subito in fretta, inizierà a rimettere tutto in discussione. Affida a ciascuno il lavoro per cui è stato pensato.

Rischi del modello 2:

• Codex genera una bozza basata su supposizioni che in seguito possono essere difficili da correggere. Se la bozza prende la direzione sbagliata, è più economico scartarla e ricominciare che cercare di sistemarla.
• Claude Code potrebbe passare mezz’ora a rinominare variabili e dimenticarsi il vero problema architetturale. Indica modifiche specifiche, non limitarti a dire «sistema tutto».
• Il contesto si perde da una sessione all’altra. Per far capire a Claude Code cosa intendesse Codex, serve un file AGENTS.md (vedi il modello 5) oppure un commento dettagliato all’inizio del file.

Modello 3: Codex per l’infrastruttura, Claude Code per la logica aziendale#

L’idea è semplice: parti diverse di una codebase richiedono modi di lavorare diversi.

Questo modello completa l’approccio che consiste nell’eseguire più istanze di Claude Code in parallelo: in quel caso lo stesso modello gestisce attività diverse tramite worktree git; qui, due agenti diversi si dividono le aree di responsabilità.

Livello infrastrutturale (Codex):

• GitHub Actions: aggiungere un nuovo job, modificare la cache, velocizzare CI.
• Test: scrivere una suite di test d’integrazione dopo un refactoring.
• Migrazioni Prisma: generare una migrazione e verificare che possa essere annullata.
• Configurazioni Docker / Coolify: aggiungere variabili d’ambiente, aggiornare il controllo dello stato.
• Cron job: scrivere una serie di handler per cron.

Codex eccelle qui perché le attività infrastrutturali spesso comportano molti file piccoli con codice boilerplate. Codex non si blocca perché «deve pensarci meglio»: porta il lavoro fino alla fine.

Logica aziendale (Claude Code):

• Funnel di registrazione: cosa mostrare all’utente in ogni passaggio.
• Calcolo dei prezzi tenendo conto di sconti, rate e codici promozionali regalo.
• Flussi di notifica automatizzati: quali trigger e condizioni.
• Integrazioni con API esterne: gestione degli errori, nuovi tentativi, cache.
• Modelli finanziari: calcoli dell’economia unitaria e previsioni dei ricavi.

Claude Code eccelle qui perché queste attività richiedono dialoghi approfonditi e capacità di ragionamento sul prodotto. Senza discutere gli scenari, si finisce con una soluzione tecnica che non tiene conto dei reali problemi degli utenti.

Come si divide il lavoro nel repository:

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

Non è una regola ferrea. Ci possono essere sovrapposizioni: per esempio, Claude Code può modificare un GitHub Action se quell’azione ha un significato per il prodotto (come inviare una notifica dopo la pubblicazione). Ma l’80% delle attività rientra bene in questa divisione.

Come si sincronizzano CLAUDE.md e AGENTS.md?#

Nell’esperienza descritta sull’uso parallelo di Claude Code e Codex è emerso un problema inaspettato. Claude Code seguiva le regole di CLAUDE.md («non toccare le migrazioni senza conferma»). Codex non poteva vedere queste regole e ha eseguito le migrazioni senza esitazione in un ambiente di lavoro. Dopo il terzo database danneggiato, è stato necessario capire come mantenere correttamente sincronizzati entrambi i file.

Entrambi i file possono includere contesto, preferenze conversazionali, comandi di test, esclusioni di directory e standard di commit. Riusa ciò che vale per entrambi e separa comandi e configurazioni specifici. Per esempio, un divieto sulle migrazioni appartiene a entrambe le istruzioni se vale per entrambi gli agenti.

Cosa hanno in comune i due file:

• Stack: quali framework, database e ORM vengono usati.
• Descrizione del progetto: che cos’è, a chi si rivolge e quali sono le sue entità principali.
• Divieti: quali cartelle non toccare e quali comandi non eseguire.

Cosa cambia:

• Hook, livelli di impostazioni e configurazioni MCP specifici di Claude Code appartengono ai relativi file di configurazione. CLAUDE.md può rimandare alla prosa che descrive queste convenzioni; copiarla non la rende configurazione portabile.
• AGENTS.md è uno standard aperto. Lo leggono Codex, Cursor, Aider, Continue, Cline e Factory Droid: oltre 25 agenti. La guida dedicata spiega più nel dettaglio il formato AGENTS.md. Le configurazioni MCP di Codex sono archiviate in ~/.codex/config.toml (TOML, non JSON come nel caso di Claude).

Un modello diffuso nel 2026 è una fonte canonica di regole nella cartella /context/ del monorepo, da cui uno script di sincronizzazione genera CLAUDE.md, .cursor/rules/*.mdc e AGENTS.md. I file specifici degli strumenti sono contrassegnati come di sola lettura; si modifica soltanto la fonte.

Esegui lo script di sincronizzazione tramite un hook pre-commit o un’azione GitHub. Se le modifiche vengono apportate direttamente a CLAUDE.md, CI fallisce. In questo modo si evita che le regole divergano tra strumenti.

Un’altra opzione è il plugin Codex ufficiale per Claude Code (annunciato il 30 marzo 2026, versione 1.0.4). Aggiunge i comandi /codex:review, /codex:adversarial-review e /codex:rescue a Claude Code. Codex viene eseguito come sub-agente, usando il proprio ~/.codex/config.toml e AGENTS.md. Così non serve un secondo terminale, ma AGENTS.md resta necessario.

Quanto costa mantenere entrambi e dove si risparmia?#

Ecco i prezzi di giugno 2026 (dati dalle pagine ufficiali degli abbonamenti Anthropic e OpenAI e dalla pagina ufficiale di Codex):

Abbinamento minimo funzionante: Claude Pro ($20) + ChatGPT Plus ($20) = $40/mese. Sufficiente per progetti individuali con un paio di sessioni al giorno.

Un abbinamento concreto per chi fa vibe coding con continuità: Claude Max 5x ($100) + ChatGPT Plus ($20) = $120/mese. Nell’esperienza descritta, questa combinazione è stata usata negli ultimi 2 mesi: nel frattempo sono stati avviati tre progetti e non si sono mai raggiunti i limiti di Claude.

Un abbinamento per un team: Claude Max 20x ($200) + Codex Pro ($200) = $400/mese. Ha senso quando c’è un flusso costante di revisioni PR e attività cloud eseguite in parallelo al lavoro locale.

Da dove derivano i risparmi:

• Meno tempo per funzionalità. La misurazione dell’autore: su 12 funzionalità sviluppate tra maggio e giugno, il tempo da «mi è venuta un’idea» a «in produzione» è sceso da 4 ore (un solo Claude Code) a 2.5 ore (l’abbinamento). La misurazione riguarda le attività dell’autore; i tuoi risultati saranno diversi.
• Meno difetti. Secondo le osservazioni descritte, le revisioni PR di Codex individuano 2-3 problemi su 10 che sfuggono a Claude. Ogni problema in produzione richiede un’ora o due per essere risolto, oltre a potenziali tempi di inattività.
• Parallelismo. Codex lavora sulla funzionalità A in modalità cloud mentre l’utente lavora con Claude sulla funzionalità B. Questo raddoppia la produttività.

Non conviene se scrivi 1-2 funzionalità a settimana. In tal caso, basta Claude Code Pro.

Quando non serve un secondo strumento?#

L’abbinamento non è per tutti. Spesso aggiunge solo rumore. Ecco quattro situazioni in cui non serve un secondo strumento:

1. Progetto individuale all’inizio. Se hai un’idea e la stai solo testando, per un mese sarà sufficiente Claude Code con Plan Mode. Aggiungi l’abbinamento quando la velocità diventa un collo di bottiglia.

2. Budget rigido. Se il limite è $20 al mese, scegli Claude Pro e non preoccupartene. Claude da solo copre l’80% delle attività di chi fa vibe coding.

3. Architettura semplice. Un sito web con un modulo, un bot con un paio di scenari, uno script che fa da wrapper a un’API: dividere il lavoro per livelli non aggiunge nulla. Claude Code da solo può gestirlo.

4. Tutto funziona già. Se usi Claude Code da un mese e non c’è stata neanche un’attività che non sia riuscito a completare o che lo abbia bloccato, non aggiustare ciò che funziona. Aggiungi Codex quando ne emerge chiaramente la necessità.

E, al contrario, ecco i segnali chiari che è ora di introdurre un secondo strumento:

• Claude Code è diventato un collo di bottiglia: aspetti lui invece di lavorare.
• È comparso molto lavoro infrastrutturale boilerplate (migrazioni, CI, test) che non vuoi affrontare con Claude.
• Le persone del team usano già strumenti diversi: serve un linguaggio comune.
• I benchmark mostrano che Codex gestisce più rapidamente le tue attività tipiche (per esempio, le operazioni da terminale).

Come configurare l’abbinamento in una sera#

Un piano concreto per la prima sera:

1. Passaggio 1: installare Codex CLI

   Nel terminale: npm install -g @openai/codex. Accedi con codex login: si aprirà un browser e potrai autenticarti con il tuo account ChatGPT. Codex rileverà il tuo abbonamento (Plus / Pro) e userà i relativi limiti.

2. Passaggio 2: scrivere AGENTS.md come documento operativo

   Esamina CLAUDE.md e riusa in AGENTS.md le regole applicabili a entrambi: test e lint, formato dei commit, cartelle vietate e stack. Anche le preferenze conversazionali possono essere condivise. Adatta i riferimenti ai comandi specifici e conserva impostazioni eseguibili di hook e MCP nelle configurazioni proprie di ciascuno: copiare Markdown da solo non le configura.

3. Passaggio 3: scegliere un modello per il progetto

   Se sei uno sviluppatore individuale con CI, usa il modello 1 (Claude scrive, Codex revisiona). Se il progetto è nuovo e ti serve velocità, usa il modello 2 (Codex prepara la bozza, Claude la rifinisce). Se il progetto è consolidato e ha un livello infrastrutturale, usa il modello 3 (divisione per livelli).

4. Passaggio 4: sperimentare per una settimana

   Usa il modello scelto su 5-7 funzionalità. Tieni traccia del tempo e annota quale strumento ha gestito meglio ciascuna attività. Dopo una settimana avrai un quadro reale del tuo utilizzo.

5. Passaggio 5: configurare la sincronizzazione delle regole

   Aggiungi uno script scripts/sync-agent-rules.sh (vedi la sezione sulla sincronizzazione). Collegalo come hook pre-commit o con un’azione GitHub. Da quel momento le regole verranno propagate automaticamente a entrambi i file.

L’abbinamento non è magia. Sono semplicemente due menti anziché una, ciascuna capace di compensare i punti deboli dell’altra. L’importante è non restare bloccati a discutere «Claude o Codex» quando la risposta giusta da tempo è «sia Claude sia Codex, per attività diverse».

Materiali pratici sul lavoro con gli agenti: documentazione Ailoot.

Altri materiali e strumenti: Ailoot.