# Cosa è cambiato nel nuovo Codex e perché sembra più un ambiente di sviluppo

> Canonical: https://vxi.me/it/posts/what-changed-in-the-new-codex/
> Locale: it-it
> Published: 2026-03-27
> Updated: 2026-03-27
> Markdown: https://vxi.me/it/posts/what-changed-in-the-new-codex.md

Se la tua immagine di Codex è rimasta ferma a maggio 2025, tornarci oggi può essere un po' disorientante. Non sembra più lo stesso tipo di prodotto.

Nel [post di lancio di Codex del 16 maggio 2025](https://openai.com/index/introducing-codex/), il messaggio era piuttosto chiaro: Codex era un agente di software engineering basato sul cloud. Era già un cambiamento importante, ma il modello mentale con cui molti sviluppatori ne uscirono rimaneva semplice. Gli affidavi del lavoro, lo eseguiva nel cloud e tornava con un risultato. Il baricentro era ancora l'esecuzione del task.

Oggi questa non è più l'intera storia. Non è cambiato soltanto il fatto che Codex sappia programmare un po' meglio. Il passaggio più grande è che il prodotto ha iniziato a crescere attorno al workflow: terminale, IDE, app desktop, skills, automations, agent multipli, worktree e punti di ingresso persistenti. Quando questi pezzi compaiono insieme, Codex smette di sembrare un coding agent da usare una volta e inizia a somigliare a un livello d'ingresso per un ambiente di sviluppo.

Per uno sviluppatore, o per chi oggi fa qualche forma di vibe coding, la distinzione conta. Cambia il modo in cui usi lo strumento. Smetti di trattarlo come qualcosa che risponde soltanto ai prompt e inizi a considerarlo qualcosa che può assorbire gradualmente parti del tuo modo di lavorare.

## La timeline rende il cambiamento abbastanza evidente

Secondo me è più facile vederlo se smetti di cercare una singola feature spettacolare e metti in fila le tappe del prodotto.

- Il 16 maggio 2025 OpenAI pubblica [Introducing Codex](https://openai.com/index/introducing-codex/). L'attenzione è su un agente cloud di software engineering capace di svolgere task di programmazione in un ambiente isolato.
- Il 15 settembre 2025 arriva [Introducing upgrades to Codex](https://openai.com/index/introducing-upgrades-to-codex/). È qui che l'esperienza inizia a diventare molto più unificata tra terminale, IDE, web e telefono.
- Il 2 febbraio 2026 OpenAI pubblica [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/). A quel punto la forma del prodotto diventa più chiara: app, agent in parallelo, worktree, task inbox, skills e automations. Inizia a sembrare meno una superficie di chat e più un command center.
- Il 4 marzo 2026 arriva anche il supporto Windows. La direzione multi-surface diventa ancora più evidente.

Quindi, quando qualcuno dice che “il nuovo Codex ha aggiunto skill e funzionalità app simili ai plugin”, capisco cosa intende, ma non lo descriverei semplicemente come un classico sistema di plugin. È più preciso dire che Codex sta passando da un'esperienza a singolo agente a un livello di workflow per sviluppatori più riutilizzabile, integrabile e orchestrabile. Il linguaggio di OpenAI è più vicino a `Skills`, `Automations`, app surfaces e integrazione IDE che a un tradizionale marketplace di estensioni.

## I Skills sono probabilmente il cambiamento pratico più importante

Quando si confrontano strumenti di AI coding, la discussione parte quasi sempre dalla forza del modello: qualità del codice, latenza, capacità di completare un task end to end. Sono tutte cose importanti, ma non sono la parte che trovo più interessante qui.

Nel tempo pesa di più tutto ciò che non vuoi rispiegare continuamente: regole del repository, standard di coding, stile di review, vincoli di deploy, controlli prima di operazioni rischiose e convenzioni specifiche del progetto. Nei workflow più vecchi gran parte di queste informazioni finiva in prompt lunghi da ripetere a ogni sessione, e non era mai particolarmente stabile.

È per questo che `Skills` conta. Non è solo un'altra feature aggiunta al modello. Permette di impacchettare un modo ripetibile di lavorare in qualcosa che puoi richiamare di nuovo. Per un team significa catturare il processo invece di doverlo spiegare ogni volta. Per una persona significa meno spreco di prompt e meno deriva.

Ecco anche perché molti paragonano spontaneamente l'idea ai plugin. Il confronto è comprensibile, ma fino a un certo punto. Un plugin classico significa spesso “installa una capacità”. Un skill è più vicino a “conserva un metodo”. Non si tratta semplicemente di aggiungere un pulsante, ma di insegnare allo strumento come ci si aspetta che venga svolto il lavoro in un determinato ambiente.

La distinzione conta per pubblici diversi in modi diversi. Gli sviluppatori vogliono che il tool rispetti il repository invece di muoversi liberamente al suo interno. Chi fa vibe coding è stanco di ricostruire lo stesso contesto da zero a ogni esecuzione.

Fermarsi ai Skills, però, sottovaluterebbe cosa è cambiato. OpenAI ha ormai un livello plugin dedicato a Codex, e la descrizione ufficiale è più concreta di quanto molti si aspettino. Nella documentazione [Codex Plugins](https://developers.openai.com/codex/plugins), i plugin vengono descritti come bundle installabili per workflow Codex riutilizzabili. Questa formulazione conta: non è “aggiungi una piccola estensione e basta”, ma un modello di packaging per distribuire modi di lavorare ripetibili.

![Screenshot ufficiale della directory plugin di Codex](https://developers.openai.com/images/codex/plugins/directory.png)

Lo screenshot è già un buon indizio. Il nuovo Codex non è più soltanto “puoi scrivere qualche file skill, se vuoi”. Ora esistono una directory plugin, superfici di installazione, categorie e voci orientate ai workflow. Quando GitHub, Slack, Linear, Figma, Netlify, Cloudflare e Sentry compaiono tutti nella stessa directory, il prodotto smette di sembrare un chatbot per programmare e inizia a sembrare un ambiente con distribuzione incorporata.

Ancora più importante è ciò che un plugin può raggruppare. Secondo la documentazione, un plugin può impacchettare insieme tre livelli:

- skills
- apps, cioè integrazioni opzionali o mapping di connector
- server MCP per strumenti o contesto condivisi

Ecco perché continuo a descrivere questa evoluzione come uno spostamento verso un ambiente di sviluppo e non come un semplice upgrade del modello. Quando esistono i plugin, la riusabilità non vive più soltanto a livello di prompt. I team possono impacchettare un workflow invece di rispiegarlo. Le persone possono rendere portabile il comportamento della propria toolchain invece di ricostruirlo da capo.

## I plugin trasformano i skill in qualcosa che puoi davvero distribuire

Probabilmente è la parte più sottovalutata dell'aggiornamento.

Prima, anche un ottimo skill rimaneva spesso personale. Potevi sapere come salvarlo, richiamarlo e riutilizzarlo localmente, ma ciò non lo rendeva automaticamente facile da scoprire o installare per qualcun altro. Il livello plugin cambia questo.

La struttura ufficiale è piuttosto esplicita. Un plugin minimo parte da `.codex-plugin/plugin.json` come entry point. Da lì, la root del plugin può includere anche:

- `skills/`
- `.app.json`
- `.mcp.json`
- `assets/`

È developer-friendly in modo molto concreto. Non condividi più un prompt isolato nascosto in una nota. Condividi un pacchetto con manifest, metadata, capability raggruppate, eventuale testo per la superficie di installazione e perfino screenshot. La documentazione arriva fino a campi come `displayName`, `shortDescription`, `defaultPrompt`, `brandColor` e `screenshots`, segno che installazione e discovery sono già trattate come vere superfici di prodotto e non come un concetto futuro vago.

Un altro dettaglio utile: OpenAI non limita i plugin alla directory ufficiale. Codex può leggere marketplace da tre posizioni:

- la directory curata di OpenAI
- `$REPO_ROOT/.agents/plugins/marketplace.json`
- `~/.agents/plugins/marketplace.json`

Questa cosa conta più di quanto sembri. Significa che puoi costruire un marketplace locale al repository per workflow di team, skill specifici del progetto e bundle di connector senza aspettare che esista un ecosistema pubblico completo. Per sviluppatori individuali e piccoli team è probabilmente anche la forma di valore più realistica.

OpenAI include persino un skill `@plugin-creator` per generare lo scaffold di plugin locali. Mi piace questo dettaglio perché mostra che la feature è pensata per essere usata, non soltanto raccontata.

![Screenshot ufficiale del skill plugin-creator](https://developers.openai.com/images/codex/plugins/plugin-creator.png)

Vale la pena citare un altro segnale ufficiale. Nel post [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/), OpenAI afferma che l'utilizzo complessivo di Codex è raddoppiato dal lancio di GPT-5.2-Codex a metà dicembre e che più di un milione di sviluppatori ha usato Codex nell'ultimo mese. Questo aiuta a capire perché packaging e distribuzione siano diventati improvvisamente così importanti. A quella scala “scrivi un buon prompt” non basta più. I livelli di workflow riutilizzabili diventano infrastruttura di prodotto.

## La vera differenza tra vecchio e nuovo è la memoria del workflow

La mia lettura è abbastanza semplice.

Il vecchio Codex sembrava un cloud agent molto capace a cui affidare del lavoro. Era utile, a volte sorprendentemente utile, ma continuava a comportarsi come aiuto esterno. Molto contesto rimaneva legato al momento. Finito il task, spesso bisognava ricominciare la volta successiva con nuove istruzioni.

Il Codex più recente sembra puntare ad altro. Continua ovviamente ad accettare task, ma inizia anche ad assorbire regole, superfici, routine e azioni ricorrenti. Puoi muoverti tra più punti di ingresso. Puoi conservare skill riutilizzabili. Puoi delegare lavoro ricorrente alle automations. L'intera forma è più persistente.

Per gli sviluppatori significa meno frizione ingegneristica. Si passa meno tempo a rispiegare il repository e più tempo a far avanzare lavoro reale. Per chi fa vibe coding la differenza è altrettanto evidente. Molte persone non avevano difficoltà con le idee; avevano difficoltà a ricostruire lo stesso setup a ogni esecuzione. La riusabilità cambia questo.

Sotto c'è un altro cambiamento importante. Molte esperienze di AI coding precedenti sembravano “modello forte, ambiente sottile”. Il nuovo Codex sta chiaramente provando a correggere la seconda metà della frase. Non vuole soltanto dimostrare di poter scrivere codice: vuole dimostrare di poter operare dentro un ciclo di sviluppo più realistico.

È un cambiamento molto più grande di quanto sembri all'inizio.

## Se avevi già usato Codex, oggi ha senso rileggerlo

Io guarderei il nuovo Codex in modo diverso.

Non lo giudicherei soltanto in base alla capacità di scrivere una funzione o chiudere una piccola feature. Così si perde il movimento reale. La domanda migliore è se riesce ad assorbire le tue regole di lavoro e a ridurre progressivamente il setup ripetuto.

E se con “plugin” intendi davvero “modi per estendere o collegare workflow”, ha più senso guardare `Skills`, `Automations`, integrazione IDE e app surfaces che mettersi a cercare un classico extension store. La direzione nuova è più vicina a un livello d'integrazione che a un semplice catalogo di plugin.

Dopo aver letto la documentazione ufficiale dei plugin, farei un passo ulteriore. Il nuovo Codex non è più soltanto “simile a un sistema di plugin”. Ha già un vero modello di packaging e marketplace per plugin. Semplicemente non corrisponde uno a uno al modello mentale di un'estensione browser o VS Code. È molto più vicino a bundle di workflow e pacchetti d'integrazione.

È per questo che penso che il cambiamento conti sia per gli sviluppatori sia per chi fa vibe coding. La parte interessante non è solo che Codex risponde meglio. È che sta iniziando a comportarsi come un luogo in cui il lavoro può continuare. Quando succede, il valore non è più soltanto in una singola risposta, ma nel modo cumulativo in cui lo strumento si adatta al processo.

Questo, per me, è il vero upgrade. Non il fatto che scriva un po' più velocemente, ma che stia diventando migliore nel mantenere **come lavori**.