Introduzione
GPT-5 dimostra capacità pratiche nel coding: in un test reale è stato guidato a scrivere un parser per il formato binario EVTX in Zig, mostrando precisione, steerability e minime edizioni invasive.
Contesto
EVTX è il formato binario dei Windows Event Logs; il parsing è complesso per via di template, sostituzioni e ambiguità tra tipi length-prefixed e null-terminated. L'autore mantiene un parser Rust di riferimento e ha usato questa base come litmus test per valutare la qualità del codice prodotto da modelli LLM.
GPT-5: perché conta
Rispetto a modelli precedenti, GPT-5 tende a produrre modifiche minimali e mirate, è più steerable e meno incline a "deception": preferisce diagnosticare, loggare e iterare anziché introdurre workaround evasivi. Questo comporta patch più piccole e facilmente integrabili nel codice esistente.
Il problema: perché EVTX è difficile
Il formato include TemplateDefinition e TemplateInstance con token BinXML e descrittori di sostituzione. Due classi di difficoltà emergono:
- Micro-debugging: un singolo errore di interpretazione (es. trattare un BinaryType come UTF-16 length-prefixed) causa disallineamento e crash difficili da isolare.
- Macro-architettura: senza una rappresentazione intermedia diventa complicato rifattorizzare il parser per gestire casi complessi e template ricorrenti.
Approccio e soluzione
La metodologia che ha funzionato con GPT-5 includeva:
- Fornire il contesto: spec, esempi hexdump, e output di riferimento (Rust).
- Incitare la generazione di logging dettagliato e hexdump per ogni modulo di parsing.
- Favorire modifiche minimali e incrementalità: iterare finché l'output non corrisponde a quello del parser di riferimento.
- Creare un'IR (rappresentazione intermedia) per separare parsing binario e serializzazione finale, riducendo il rischio di errori globali.
Questa strategia ha permesso a GPT-5 di identificare bug sottili (mis-reading di lunghezze, interpretazione contestuale di stringhe) e proporre patch mirate, spesso una o poche righe, invece di riscritture massicce.
Best practice emerse
- Log modulare e livelli di verbosità per isolare i fallimenti di template.
- Test incrementali con hexdump e confronto bitwise con output di riferimento.
- Evita heuristics non specificate dalla spec: preferire controlli espliciti di bound e validità.
- Usare un IR quando il codice cresce oltre poche centinaia di righe per facilitare refactor.
Risultati e limiti
GPT-5 ha prodotto un parser utilizzabile e performante in Zig, capace di arrivare a uscita quasi equivalente a quella del parser Rust di riferimento. Limiti pratici: per produzione si raccomanda usare implementazioni consolidate; il codice generato va sottoposto a review e test estesi su corpus reali.
Conclusione
Il test mostra come, con istruzioni chiare e iterazioni controllate, GPT-5 possa risolvere problemi di media complessità nel dominio del parsing binario, producendo modifiche mirate e utili strumenti di debug. Per lavori critici restano necessari test, revisione umana e stabilità del codice nel tempo.
FAQ
1. Come misura il test la capacità di GPT-5 nel parsing EVTX?
Confrontando l'output bitwise del parser generato con quello del parser Rust di riferimento e usando hexdump e logging per isolare differenze.
2. In che modo GPT-5 riduce le modifiche al codice rispetto ad altri modelli?
Preferisce patch mirate e refactor locali: spesso corregge bug con poche righe invece di riscritture estese.
3. Quali rischi principali emergono nel parsing EVTX con GPT-5?
I rischi sono errori di interpretazione dei tipi (es. stringhe vs binary) che causano disallineamento del cursore; per questo servono test e log approfonditi.
4. Perché usare Zig per un parser EVTX?
Zig è adatto ai parser binari per controllo low-level della memoria e poche dipendenze, rendendolo interessante per implementazioni performanti.
5. Quando non usare il parser generato da GPT-5 in produzione?
Se non è stato validato su un ampio corpus reale e sottoposto a review critica; in quel caso preferire librerie consolidate.