GPT-5.3 Codex: da assistente di coding ad agente generale per il lavoro

Test di GPT 5.3 Codex: esempi pratici

Le note di rilascio e i primi risultati dei benchmark mostrano chiaramente che i workflow agentici hanno avuto la massima priorità nello sviluppo del nuovo modello. Per questo motivo anche i nostri esempi si concentrano molto su quest’area.

Se ti interessa vedere le attuali capacità di ragionamento di GPT messe alla prova, ti consiglio di dare un’occhiata alla nostra guida su GPT-5.2.

Test 1: Full-stack builder

Per il primo test, volevo verificare quanto bene il modello gestisca le dipendenze e la documentazione per un semplice tool meteo usando FastAPI e l’API di Open-Meteo. Ho usato il seguente prompt:

Create a simple Python API using FastAPI that fetches the current temperature for a given city (e.g., Helsinki) using the Open-Meteo API.
1. Write the code in main.py using the httpx or requests library to call the API.
2. Create a Dockerfile to containerize it.
3. Write a README.md explaining how to run it.
4. Create a bash script run_local.sh that builds the image and runs it on port 8000.

In 41 secondi sono stati generati tutti e quattro i file con un unico prompt, con numeri di porta (8000) e naming coerenti.

Per quanto riguarda le dipendenze, Codex ha identificato correttamente httpx come client async moderno (una buona scelta rispetto a requests per FastAPI) e lo ha incluso nella riga di installazione del Dockerfile. Ha anche capito che FastAPI dipende da uvicorn e l’ha aggiunto alle dipendenze.

Un piccolo appunto riguarda l’installazione hardcoded nel Dockerfile: Codex ha di fatto saltato il requirements.txt installando direttamente nell’istruzione RUN. Può essere una scorciatoia valida per uno script "semplice", soprattutto dato che non abbiamo richiesto un requirements.txt, ma un file separato darebbe più chiarezza e flessibilità in seguito. Il Dockerfile è così:

FROM python:3.11-slim
WORKDIR /app
COPY main.py /app/main.py
RUN pip install --no-cache-dir fastapi uvicorn httpx
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Codex non si è limitato a scrivere il codice, ma ha chiaramente compreso il contesto della richiesta e l’architettura dell’API. Nota come ha gestito automaticamente il processo in due fasi di Open-Meteo (Geocoding -> Weather). Non gli ho detto come usare l’API, solo quale usare. Ha letto la documentazione (o la conosceva) e ha implementato la logica necessaria per far funzionare ?city=Helsinki.

Ha anche aggiunto un robusto error handling (try/except, raise per stati specifici, controlli 404 per "City not found") senza che fosse richiesto.

from fastapi import FastAPI, HTTPException, Query
import httpx

app = FastAPI(title="Simple Weather API", version="1.0.0")

GEOCODE_URL = "https://geocoding-api.open-meteo.com/v1/search"
FORECAST_URL = "https://api.open-meteo.com/v1/forecast"

@app.get("/health")
def health() -> dict:
   return {"status": "ok"}

@app.get("/temperature")
def temperature(city: str = Query(..., min_length=1)) -> dict:
   city = city.strip()
   if not city:
       raise HTTPException(status_code=400, detail="City must not be empty")

   try:
       with httpx.Client(timeout=10.0) as client:
           geo_resp = client.get(
               GEOCODE_URL,
               params={
                   "name": city,
                   "count": 1,
                   "language": "en",
                   "format": "json",
               },
           )
           geo_resp.raise_for_status()
           geo_data = geo_resp.json()

           results = geo_data.get("results") or []
           if not results:
               raise HTTPException(status_code=404, detail="City not found")

           place = results[0]
           latitude = place.get("latitude")
           longitude = place.get("longitude")
           resolved_name = place.get("name")
           country = place.get("country")

           forecast_resp = client.get(
               FORECAST_URL,
               params={
                   "latitude": latitude,
                   "longitude": longitude,
                   "current": "temperature_2m",
               },
           )
           forecast_resp.raise_for_status()
           forecast_data = forecast_resp.json()

           current = forecast_data.get("current") or {}
           units = forecast_data.get("current_units") or {}
           temperature_value = current.get("temperature_2m")
           temperature_unit = units.get("temperature_2m", "")
           current_time = current.get("time")

           if temperature_value is None:
               raise HTTPException(status_code=502, detail="Temperature unavailable")

           return {
               "city": resolved_name,
               "country": country,
               "latitude": latitude,
               "longitude": longitude,
               "temperature": temperature_value,
               "unit": temperature_unit,
               "time": current_time,
           }
   except httpx.HTTPStatusError as exc:
       raise HTTPException(status_code=502, detail=f"Upstream error: {exc.response.status_code}")
   except httpx.RequestError:
       raise HTTPException(status_code=502, detail="Upstream request failed")

Si nota almeno un’ottimizzazione possibile: ha usato httpx.Client (sincrono) all’interno di una route def standard. Per FastAPI, questo è bloccante. Un agente "esperto" perfetto avrebbe potuto usare async def e httpx.AsyncClient.

Nonostante ciò, il primo test ha restituito uno strumento funzionante. L’esecuzione di run_local.sh ha creato l’immagine Docker e avviato il container sulla porta 8000. Alla prova, ha restituito con successo la temperatura attuale a Helsinki:

curl "http://localhost:8000/temperature?city=Helsinki"

{"city":"Helsingfors","country":"Finland","latitude":60.16952,"longitude":24.93545,"temperature":-6.0,"unit":"°C","time":"2026-02-09T07:15"}

Test 2: Steering in tempo reale in azione

Per provare la funzione di steering, ho prima chiesto a Codex di creare una landing page per una caffetteria, ma poi ho cambiato il tema richiesto durante il workflow. Dato che lo sviluppo web è stato indicato esplicitamente come uno dei punti di forza di GPT-5.3-Codex, dovrebbe essere una passeggiata (con il caffè). Il prompt originale è:

Build a landing page for a coffee shop using HTML and CSS. Use a dark theme with blue accents.

Quando lavori nell’app Codex, puoi vedere due opzioni passando il mouse sul pulsante “Enter message” mentre Codex è al lavoro: 

• Queue: lascia che Codex gestisca il tuo prompt dopo che ha finito di lavorare (Enter)
• Steer: cambia subito il prompt originale o fornisci contesto immediatamente (Cmd + Enter)

Dopo aver visto che era stato creato index.html e che Codex stava lavorando al file CSS, ho cambiato idea:

Codex ha incorporato il nuovo contesto nel vecchio prompt e ha restituito il risultato finale con il nuovo tema richiesto senza interrompersi. Puoi anche vedere le modifiche effettuate dopo il comando di steering, con le righe aggiunte e rimosse evidenziate rispettivamente in verde e rosso.

Il risultato è piuttosto gradevole e pulito, include il pulsante che volevamo e il tema rispecchia la nostra ultima richiesta. Il sito sembra un po’ statico, però, ma è probabilmente ciò che ci si può aspettare dato il prompt molto leggero.

Un’altra cosa che ho provato è se Codex potesse tornare al vecchio tema che in realtà non era mai stato implementato. Dopo aver richiesto il tema originale, ha consegnato ciò che ci saremmo aspettati dal primo prompt.

Ero particolarmente curioso di vedere come Codex avrebbe gestito il pulsante per gli ordini, dato che il mio prompt riguardava il "cambiare indietro" ma chiedeva esplicitamente solo il tema originale. La soluzione è stata piuttosto carina, a mio avviso: mi ha chiesto se il pulsante dovesse essere mantenuto e lo ha rimosso solo dopo che non ho risposto.

Ecco come appariva il sito con il tema ripristinato:

Test 3: logica auto-riparante e ambiguità

Infine, volevo testare quanto bene il modello risponde a un classico errore logico. Per farlo, ho fatto creare a Codex un ciclo infinito con una condizione che non si risolve mai. Vediamo se la sua celebrata logica auto-riparante riesce a capire che lo script è bloccato, ucciderlo e riscrivere la logica senza il mio intervento.

Il prompt è piuttosto semplice e chiede un conto alla rovescia in cui il contatore non viene intenzionalmente decrementato:

Write a Python script that counts down from 10 to 0 and prints 'Blastoff!'.
Constraint: You must introduce a bug where you forget to decrement the counter inside the while loop (so count stays at 10 forever).
Execute the script and verify the output.

Questo è il test con il risultato peggiore: Codex ha eseguito il conto alla rovescia, che è rimasto al numero dieci per quasi quattro minuti, prima di interromperlo con Ctrl + C. 

Quello che non ha fatto è stato chiedersi se il prompt originale potesse produrre qualcosa di diverso da questo loop infinito di dieci. Inoltre, l’app si è bloccata, quindi ho dovuto chiuderla e riavviarla manualmente.

Quando ho modificato leggermente il prompt per rendere più evidente la contraddizione ("Esegui lo script per fare un conto alla rovescia" alla fine), Codex ha colto l’ambiguità e mi ha chiesto cosa volessi davvero:

GPT-5.3 è ancora più un soldato obbediente che un pensatore ribelle. In origine ha dato priorità alla mia istruzione ("introduci un bug") rispetto al buon senso ("questo script è bloccato"). Sebbene probabilmente riesca a sanare errori accidentali dove l’obiettivo è chiaro (ad es., "Fai passare i test") o la contraddizione è esplicitata, fatica quando le istruzioni sono in conflitto implicito.

Come posso accedere a GPT 5.3 Codex? 

OpenAI ha annunciato che GPT-5.3-Codex è ora disponibile in tutti i piani a pagamento di ChatGPT nell’app, via CLI, tramite un’estensione per IDE e sul web.

Il modello non è ancora disponibile nell’API di OpenAI, ma l’accesso API seguirà “a breve”. Non ci sono ancora dettagli sul prezzo per token.

GPT 5.3 Codex vs. Claude Opus 4.6

La principale concorrente di GPT-5.3-Codex nell’arena degli agenti focalizzati sullo sviluppo software è probabilmente Claude Opus 4.6. Vediamo come si confrontano.

Approccio generale e stile agentico

Gli approcci di OpenAI e Anthropic non sono del tutto diversi, ma ci sono alcune sfumature da notare. 

GPT-5.3-Codex è posizionato come un builder piuttosto autonomo, ottimizzato per la velocità (25% più veloce) e loop "auto-correttivi" per portare a termine task di ingegneria senza aiuto umano.  

Dall’altra parte, Claude Opus 4.6 è progettato per il pensiero profondo, con la sua enorme finestra di contesto (1M token) e il "pensiero adattivo" che lo aiutano a gestire progetti legacy complessi e disordinati.

Lo stile agentico di entrambi i modelli è incentrato sull’interazione, sebbene in modi leggermente diversi. La “governabilità” di GPT-5.3-Codex consente agli utenti di interromperlo a metà task per cambiare direzione (ad es., "Aspetta, usa invece l’API v2") senza rompere il workflow. 

Claude Opus 4.6 si comporta più come un partner senior con cui conversare, offrendo impostazioni di sforzo "Alto/Medio/Basso" per gestire costi e profondità.

Mentre GPT-5.3-Codex è stato specificamente ottimizzato per l’hardware NVIDIA GB200 NVL72 per ridurre la latenza nei loop agentici, Claude Opus 4.6 punta su ottimizzazioni lato software come la compattazione delle conversazioni per gestire in modo efficiente storici lunghi.

Benchmark e prestazioni

Sul piano dei benchmark, è difficile confrontare i due modelli. L’unico benchmark per cui abbiamo punteggi di entrambi è Terminal-Bench 2.0, dove GPT-5.3-Codex (75,1%) supera Claude Opus 4.6 (69,9%). 

Questo suggerisce che, sebbene Claude sia un pensatore più profondo, GPT-5.3-Codex è un operatore più capace “hands-on” nell’eseguire task di sviluppo in un ambiente reale, come navigare nei file system, gestire le dipendenze o eseguire build.

A parte questo, è difficile confrontarli perché le due aziende hanno fatto scelte diverse riguardo ai benchmark da includere nelle note di rilascio. Questa divergenza probabilmente riflette una scelta strategica di entrambi i laboratori di evidenziare i propri punti di forza specifici evitando confronti diretti dove potrebbero non rivendicare il primo posto. 

Ecco una panoramica di ciò che sappiamo:

Casi d’uso di GPT-5.3 Codex 

Le funzionalità chiave presentate in precedenza rendono GPT-5.3-Codex perfetto per alcuni casi d’uso:

• Infrastruttura auto-riparante: un agente che monitora i log, identifica un crash, corregge il codice e ridistribuisce senza intervento umano
• Migrazione legacy: traduzione da linguaggi legacy come COBOL a stack moderni, dove l’agente generale può riscrivere contemporaneamente la documentazione
• Cybersecurity: il primo modello valutato "Alta capacità" per compiti di sicurezza. Ottimo per penetration test e patching automatizzati

Considerazioni finali 

Bravo nel coding quanto GPT-5.2-Codex, bravo nel ragionamento quanto GPT-5.2, ma molto più di questo: con GPT-5.3-Codex, OpenAI ha compiuto il passo oltre i modelli isolati verso un agente generalista capace. Sebbene restino da fare molte valutazioni, i primi risultati dei benchmark sono promettenti. 

La collaborazione interattiva è una funzione davvero ben fatta, ma per ora è limitata all’app Codex per macOS. Gli utenti devono anche attendere l’accesso via API.

Essendo ottimizzato per velocità e creazione autonoma, GPT-5.3-Codex segue un approccio diverso da Claude Opus 4.6 e lo supera su Terminal-Bench 2.0, ma le differenze dettagliate di prestazioni sono ancora difficili da valutare, dato che entrambi i modelli sono appena usciti. Il tempo dirà quale sarà il quadro completo del confronto. 

Se vuoi approfondire i concetti e le capacità degli strumenti agentici, ti consiglio di iscriverti al nostro percorso di competenze AI Agent Fundamentals.