OpenAI ha presentato GPT‑5.4 il 5 marzo 2026 e lo ha reso disponibile in ChatGPT, API e Codex. In ChatGPT arriva come GPT‑5.4 Thinking, con GPT‑5.4 Pro per i casi più complessi; nell’API il modello gpt-5.4 espone una finestra di contesto da 1,05 milioni di token, fino a 128.000 token in output, e supporta function calling, structured outputs, web search, file search, code interpreter, hosted shell, apply patch, skills, MCP, computer use e tool search.
OpenAI sostiene anche di aver migliorato coding, affidabilità e capacità operative rispetto a GPT‑5.2: 57,7% su SWE‑Bench Pro contro 55,6%, 75,0% su OSWorld‑Verified contro 47,3%, e una riduzione del 33% nella probabilità che singole affermazioni siano false, oltre a un 18% in meno di risposte contenenti errori. Numeri interessanti, certo. Ma chi lavora davvero in una PMI ha una domanda più utile dei benchmark: il lunedì mattina, tra ticket, gestionale legacy e query che si trascinano, questa roba serve oppure no?
La risposta breve è: sì, serve. Però non per il motivo che piace a chi vive di demo scintillanti e keynote con parole come “trasformazione”. Serve perché riduce il tempo sprecato su lavoro noioso, ambiguo e frammentato. Non ti sostituisce. Non prende il tuo posto. Ti toglie però di mezzo una bella dose di rotture di scatole.
La vera novità non è che “scrive codice”. È che regge meglio il lavoro sporco
Nel mondo PHP, Laravel, MySQL e MariaDB, il problema raramente è scrivere da zero una funzione elegante in un pomeriggio zen. Il problema vero è un altro: capire velocemente un pezzo di software che nessuno tocca da diciotto mesi, modificare una regola di business senza rompere tutto, leggere una migration scritta in un momento di disperazione e capire se puoi davvero mandarla in produzione senza svegliare il commercialista, il magazzino e mezzo ufficio amministrazione.
È qui che GPT‑5.4 diventa interessante. Non perché abbia improvvisamente scoperto la risposta alla domanda fondamentale sulla vita, l’universo e tutto quanto. Ma perché, con più contesto, più disciplina sugli strumenti e una migliore tenuta sui task lunghi, riesce a stare più a lungo dentro il problema senza perdersi ogni tre curve. Ed è esattamente quello che serve in una PMI: meno genialità da palcoscenico, più continuità nel lavoro reale.
Dove può aiutare davvero chi sviluppa in PHP e Laravel
Il primo caso d’uso serio è la lettura del codice esistente. Un progetto Laravel medio in ambito PMI non è un giocattolo da tutorial: ha controller cresciuti male, service class nate bene e finite peggio, validazioni duplicate, job asincroni infilati dove capitava, query Eloquent dignitose alternate a raw SQL scritte “perché c’era fretta”. GPT‑5.4 qui può fare una cosa molto utile: leggere parecchio materiale insieme e restituirti una mappa. Non solo “cosa fa questo file”, ma “dove sta la logica”, “quali dipendenze tocca”, “quali parti rischi di rompere”, “quali test mancano”. Questo, in termini di tempo umano risparmiato, vale più di cento snippet generati bene.
Il secondo caso d’uso è il refactoring assistito con vincoli chiari. Gli dai una classe, gli dai il contesto, gli dici di non cambiare il comportamento esterno, gli imponi output limitati e verificabili, e lui diventa un discreto compagno di officina. Non il capocantiere. Il compagno di officina. Ti aiuta a estrarre metodi, isolare responsabilità, suggerire test, individuare duplicazioni e rendere più leggibili pezzi che oggi funzionano per pura inerzia cosmica.
Il terzo, per chi lavora con MySQL o MariaDB, è tutto il mondo delle query e dei dati. Qui GPT‑5.4 non va adorato: va usato come un consulente veloce che però bisogna contraddire spesso. Gli dai schema, query, EXPLAIN, cardinalità attese, qualche esempio reale, e può aiutarti a capire dove stai sbagliando approccio, dove ti manca un indice, dove un join è più costoso del necessario, dove l’ORM sta producendo più rumore che valore. Non sostituisce il profiling. Non sostituisce il database engineer. Ma riduce parecchio il tempo perso a ragionare da soli davanti a una query che sembra innocua e poi in produzione si trasforma in una fiera del full scan.
Il quarto caso d’uso è il debugging. Stack trace, log applicativi, errori intermittenti, job falliti, payload storti, differenze tra ambiente locale e staging: tutta roba che di solito non richiede un genio, richiede pazienza. E la pazienza, nelle software house e nei reparti IT delle PMI, è una risorsa più rara del budget. Qui un modello buono ti aiuta a fare triage: ordina le ipotesi, collega sintomi, suggerisce verifiche, ti ricorda i punti ciechi. Non ti consegna la verità. Ti restituisce un percorso più corto per arrivarci.
Il quinto caso d’uso è la documentazione tecnica, che nessuno ama ma tutti rimpiangono quando manca. GPT‑5.4 è molto più utile nel trasformare codice e decisioni sparse in documentazione leggibile che nel promettere l’automazione totale dello sviluppo. README di progetto, note di deploy, descrizione flussi, onboarding di un nuovo collega, checklist di rollback, spiegazione di una procedura per il cliente interno: tutta roba a basso prestigio e altissimo valore operativo. Ed è proprio lì che l’AI, quando usata bene, smette di essere un giocattolo e comincia a diventare infrastruttura.
Dove fa meno magia di quanto raccontano
Qui arriva la parte meno sexy, che però è quella che paga le bollette: GPT‑5.4 non elimina il bisogno di seniority. Lo rende ancora più evidente.
Un junior con un modello più forte scrive più roba. Un senior con un modello più forte prende decisioni migliori. La differenza resta lì. Anzi, diventa più visibile. Perché quando la produzione di codice accelera, il collo di bottiglia si sposta sulla comprensione del dominio, sui trade-off, sulla capacità di dire “questa soluzione è formalmente elegante ma qui non serve”, oppure “questa query sembra giusta ma sui nostri volumi farà disastri”.
C’è poi un dettaglio che evita molti entusiasmi adolescenziali: nella pagina modello dell’API OpenAI indica come knowledge cutoff il 31 agosto 2025. Tradotto in italiano operativo: se stai lavorando con release di framework, librerie, pacchetti, changelog o vulnerabilità successive a quella data, senza search o senza documentazione del progetto stai parlando con un modello molto bravo, non con la fonte della verità. E questa distinzione, nello sviluppo software, vale più di qualsiasi slogan.
Anche il costo esiste, e conviene ricordarselo prima di far partire esperimenti poetici in produzione: OpenAI indica per l’API 2,50 dollari per milione di token input, 0,25 per cached input e 15 dollari per milione di token output su GPT‑5.4. Non è un costo proibitivo per analisi mirate, review, debugging, generazione documentazione o workflow interni. Diventa invece meno simpatico quando lo usi a spruzzo, senza metodo, per farti riscrivere il mondo ogni cinque minuti.
In una PMI il valore vero è uno solo: comprimere il tempo morto
Chi sviluppa software per PMI non vive dentro benchmark accademici. Vive dentro richieste spezzate, priorità che cambiano dalla mattina all’ora della prima pausa caffè, documentazione assente, clienti che iniziano la call con “è una modifica piccola”, e basi dati che hanno visto più mani di un corrimano in stazione.
In questo contesto, GPT‑5.4 non vale perché “sa programmare”. Vale perché comprime il tempo morto tra quattro momenti che conosci fin troppo bene: “non ricordo come funziona questa parte”, “fammi capire dove intervenire”, “fammi stimare il rischio”, “fammi produrre qualcosa di utile senza sprecare un pomeriggio”. Se lo usi lì, diventa produttività reale. Se lo usi per generare 600 righe di codice che nessuno ha davvero capito, stai solo trasformando tempo presente in debito cognitivo futuro.
E questa è la differenza tra usare bene l’AI e usarla come un deodorante ambientale per coprire problemi organizzativi. Il modello non aggiusta un dominio confuso. Non aggiusta una codebase senza confini. Non aggiusta decisioni tecniche prese male. Però può aiutarti a vedere più in fretta dove sono le crepe, e in un mestiere dove spesso si lavora contro il tempo, non è poco.
Come usarlo domani mattina, senza liturgie inutili
Il modo giusto, per chi sviluppa in PHP e Laravel, è trattarlo come un secondo cervello operativo e non come un oracolo. Dagli repository o porzioni di repository; convenzioni di progetto; schema del database; query reali; log veri; ticket; esempi di input e output; vincoli espliciti. Poi chiedigli cose strette: analizza il rischio di questa modifica, proponi tre ipotesi di bug ordinate per probabilità, suggerisci test prima della patch, riscrivi questa query spiegando i trade-off, dammi una migration con rollback sensato, trova i punti in cui il dominio perde coerenza.
Quando fai così, il modello lavora bene. Quando invece lo tratti come l’ammiocuggino saputello a cui chiedere “rifammi il backend”, lui ti risponde spesso con la stessa sicurezza con cui certa gente ti propina consigli e strategie di trading la mattina al bar. E la sicurezza, nel software, non è una prova di verità.
Quindi, GPT‑5.4 vale davvero la pena?
Sì, per chi sviluppa software in PHP, Laravel, MySQL o MariaDB nelle PMI GPT‑5.4 ha potenzialità reali nell’uso di tutti i giorni. Ma non perché abbia finalmente reso inutile lo sviluppatore. Quella è narrativa da reel di Instagram o da titolo di giornale. Vale perché riduce attrito, accelera analisi, aiuta sul debugging, rende più rapida la produzione di documentazione, regge meglio contesti lunghi e si presta a workflow operativi più maturi del semplice “scrivimi una funzione”.
In altre parole: non è la bacchetta magica. È un utensile migliore.
E chi in questo mestiere lavora davvero lo sa bene: gli utensili buoni non fanno notizia. Fanno lavoro.
