Si può davvero creare una ricompilazione senza sapere un cazzo?
Sì.
S'apra i'dibattito.
Ma siccome non ci credevo al 100%, o comunque volevo capire fino a che punto, ho fatto degli esperimenti.
Un paio di settimane fa, dopo l'ennesima news che qualche vecchio gioco era stato rilasciato in versione ricompilata per tutte le piattaforme moderne, e dopo aver notato una disparità qualitativa importante tra certi progetti "curati" e altri apparentemente un po' vibe-codati, mi sono chiesto quanto ci fosse di vero nella classica conclusione che si legge in giro: "Eh ma con l'IA sono capaci tutti". Avendo sempre dato per scontato che servisse un minimo di orchestrazione consapevole per tirar fuori un progetto di ricompilazione dal nulla, ho pensato di aprire ChatGPT e documentarmi. Avevo iniziato dal percorso del saggio, ossia chiedendo qualcosa di simile a
"Vorrei studiare come vengono sviluppati progetti di ricompilazione di giochi di vecchie console come Nintendo 64 o Xbox 360, creami una documentazione chiara che possa dare a un incompetente un'idea delle tecnologie coinvolte, delle conoscenze che uno sviluppatore dovrebbe avere etc etc", poi ho cancellato tutto e pensato che in fin dei conti, se c'è da sperimentare, tanto vale farlo per step, partendo non dal saggio ma dalla testa di cazzo.
Step 0: a cazzo de cane
La ricompilazione di Monster Hunter Portable 3rd mi ha incuriosito, perché mi pareva un po' tutta vibe-codata ma aveva degli spunti interessanti, dato che non usava nessuno dei tool già esistenti per la recomp dei giochi PSP e nonostante questo sembrava migliore in quasi tutto. Quindi senza rifletterci troppo ho provato a partire con un gioco PSP. Ne ho scelto uno abbastanza a caso, i requisiti erano: che lo conoscessi, che avesse un engine 3D ma non troppo complesso, che non ci fossero già progetti di ricompilazione pubblici. Ho scelto
Jeanne D'Arc. Via al primo prompt, con l'obiettivo di creare un briefing che includesse tutto il necessario per partire in un secondo momento con il lavoro vero e proprio.
Make a JEANNE_BRIEF.md file containing a very detailed briefing of a PSP recompilation project for Jeanne D'Arc (USA version), which will be used as a starting point for the project in a future Codex session. Refer mostly to jessicanataliagta/PSPRecomp + Yakumo as it's the most promising path for PSP recompilation. Don't be shy of details, carefully consider all possibilities and write all steps extensively in the brief so that the future agent can work without wasting additional effort. Assume having a working ISO file of the game.
The project should be mostly LLM driven, with little to no human assistance. It will be developed with Codex on a M1 Mac Mini and target platforms are Windows 10/11, Linux x64 and macOS (x64 and ARM). The first priority should be the macOS ARM port so it can be tested on the development machine.
Make sure that the brief also includes instructions for testing and self-reporting, so that the agent can work and then test its own work independently.
The brief must also contain all instructions for extracting the assets from the game's ISO, because the requirement for the user should be to only provide the ISO itself.
Quando mi è venuta l'idea del prompt avevo a disposizione solo la chat web, dove non è disponibile GPT-6 Astra (il modello attualmente "più intelligente") al quale volevo far fare l'analisi iniziale in modo da partire con un briefing migliore e farlo lavorare con meno ragionamenti dopo. Quindi sticazzi l'ho fatto fare a GPT-5.6 Sol con effort High. In 15 minuti mi ha generato un briefing ENORME ed estremamente dettagliato, volendo seguibile anche da un umano (o meglio da un team di 10 umani a tempo pieno). Il giorno dopo l'ho fatto revisionare ad Astra ed è stato migliorato ulteriormente, fino a raggiungere il risultato finale:
LINK AL BRIEFING
Ho avviato Codex e con Astra Medium ho fatto partire la grande opera, usando il prompt che era già presente nel briefing, quindi tutta farina del suo sacco:
Read JEANNE_BRIEF.md completely, then inspect the repository's current AGENTS.md and current upstream-derived architecture before making changes.
This is a PSP static recompilation project for Jeanne d'Arc USA (UCUS98700 1.00), using PSPRecomp and Yakumo as the preferred base, subject to the feasibility gates in section 0.3. Yakumo targets the PS3 HD release NPJB-40001, so audit its installer and profile assumptions before reuse.
Primary development is on a 2019 Intel MacBook Pro (x86-64), with work potentially alternating to an M1 Mac mini (arm64). Required product targets are macOS x86-64, macOS arm64, Windows 10/11 x86-64, and Linux x86-64. I have a working Jeanne d'Arc USA ISO locally. The ISO is the only game input you may require from me: automate ISO inspection, executable preparation, and optional asset extraction inside the project. Never commit or redistribute game files or derived copyrighted assets.
Work evidence-first. Do not hand-edit generated C++. Keep Jeanne-specific addresses and patches under profiles/jeanne. Generic PSP fixes belong in framework code with tests. Keep interpreter fallback enabled during bring-up.
Use the session's configured model/effort and section 76's evidence-driven workflow. Its effort recommendations are advisory; do not claim to change a setting unavailable to you. Reproduce, narrow, and instrument failures, and preserve enough evidence for continuation.
This prompt authorizes local development. Before coding, determine the current project stage from the repository and status docs, preserve existing work, pin the base, and follow section 0.3's dependency order. Resolve executable-preparation feasibility early. Keep game-derived native code local under the initial policy and include generation plus native compilation in the section 73 workflow. Then execute the next smallest verifiable milestone. Follow the autonomous testing and self-reporting protocol in section 76: reproduce before fixing, build and test every code change, run Jeanne itself whenever the affected path is currently runnable, check regressions, and never equate compilation with runtime verification. Do not ask me to supervise routine build/test/debug iterations.
When you finish a substantial step, update the persistent project status/handoff with exact commands and PASS/FAIL results, what was verified, per-target status for macOS x86-64, macOS arm64, Windows x86-64, and Linux x86-64, current blocker/first divergence, evidence paths, rejected hypotheses, unverified items, and the next smallest actions. If an experiment fails, revert it when appropriate and record what the failure taught us instead of hiding it.
Quello che non sapevo, dato che Astra era stato appena rilasciato, è che è un buco nero di token. Dopo 10 minuti di lavoro finiva la riserva delle successive 5 ore e si fermava. Dopo 5 ore lo facevo ripartire per altri 10 minuti e così via. Dopo circa 4-5 giorni per fortuna è stato rilasciato GPT-6.1 Sol, che promette un grado di intelligenza paragonabile ad Astra ma consuma mille volte meno, e infatti una volta switchato ha iniziato a lavorare per più tempo, e stava facendo progressi: ha imparato a estrarre gli asset dalla ISO, a compilare il font, a far partire il codec del video di apertura, a caricare i salvataggi... continuava ad avviare PPSSPP per capire cosa doveva succedere per poi replicarlo nativamente, in ordine di esecuzione. Molto affascinante vedere il processo, sorprendentemente "umano" nel modo in cui andava per tentativi osservando gli errori inaspettati e correggendo il tiro di conseguenza.
Poi gli ho chiesto "Ma per curiosità, a che percentuale stimi di essere rispetto ad un prototipo funzionante?". Alla risposta "Ventaglio approssimativo tra il 10% e il 20%" dopo quasi due settimane di lavoro, ho deciso di mettere da parte il progetto perché di sto passo si finiva nel 2040.
Quando l'ho interrotto, la stima di costo in API se non avessi avuto un account flat, sarebbe stata di $180, escluso il briefing iniziale. Il codice è comunque chiaro e umanamente gestibile, in caso uno volesse continuare potrebbe seguire il briefing e finire il lavoro.
Step 1: libero arbitrio
Evidentemente è stata una cazzata cominciare con la PSP, senza tool maturi e con un unico progetto ben documentato ma tutto custom (MHP3rd). Sapendo che i tool per PS1 e N64 sono molto maturi, ho provato a virare su quelli.
Visto che sono tanto intelligenti queste IA, facciamolo scegliere a loro il progetto.
Apro ChatGPT e Claude, e a entrambi chiedo:
Quale progetto di ricompilazione statica riterresti più facilmente completabile, se ti venisse assegnato come lavoro da svolgere in autonomia totale?
- Jeanne D'Arc per PSP
- Hogs of War per PS1
- Sin & Punishment per N64
GPT-6.1 Sol High risponde "Senza dubbio PS1 non c'è manco gara"
Claude Opus 5.5 High risponde "Senza dubbio N64 che cazzo di domande sono bro"
Abbiamo scelto.
Prompt per GPT-6.1 Sol xhigh:
Make a HOGS_BRIEF.md file containing a very detailed briefing of a PS1 recompilation project of Hogs of War (PAL Italian version), which will be used as a starting point for the project in a future Codex session. Search for existing tools and frameworks for PS1 recompilation that would make the job easier and include them in the brief if you consider them valid and useful for the job. Don't be shy of details, carefully consider all possibilities and write all steps extensively in the brief so that the future agent can work without wasting additional effort. Assume having a working image file of the game inside the "image" folder, called "hogs_ita.sbi" with relative .cue and .bin files.
The project should be mostly LLM driven, with little to no human assistance. It will be developed with Codex on a M1 Mac Mini and target platforms are Windows 10/11, Linux x64 and macOS (x64 and ARM). The first priority should be the macOS ARM port so it can be tested on the development machine.
Make sure that the brief also includes instructions for testing and self-reporting, so that the agent can work and then test its own work independently.
The brief must also contain all instructions for extracting the assets from the game's image, because the requirement for the user should be to only provide the image itself.
Prompt per Claude Opus 5.5 xhigh:
Make a SIN_BRIEF.md file containing a very detailed briefing of a Nintendo 64 recompilation project of Sin & Punishment (NTSC Japanese version), which will be used as a starting point for the project in a future Claude Code session. Search for existing tools and frameworks for Nintendo 64 recompilation that would make the job easier and include them in the brief if you consider them valid and useful for the job. Don't be shy of details, carefully consider all possibilities and write all steps extensively in the brief so that the future agent can work without wasting additional effort. Assume having a working ROM file of the game inside the "rom" folder, called "sinpunishment.n64".
The project should be mostly LLM driven, with little to no human assistance. It will be developed with Claude Code on a M1 Mac Mini and target platforms are Windows 10/11, Linux x64 and macOS (x64 and ARM). The first priority should be the macOS ARM port so it can be tested on the development machine.
Make sure that the brief also includes instructions for testing and self-reporting, so that the agent can work and then test its own work independently.
The brief must also contain all instructions for extracting the assets from the game's rom, because the requirement for the user should be to only provide the rom itself.
Qui si può iniziare a paragonare i due LLM, anche se ci sono mille differenze più o meno grandi tra i due progetti che rendono il paragone quasi solamente aneddotico. Comunque GPT, che in questo momento storico mi sembra il più efficace, diretto e meno dispendioso, con effort Extra High ha lavorato per 20 minuti con un consumo stimato di circa 10$ e prodotto un briefing parecchio dettagliato e senza andare fuori dal seminato. Claude invece, forse sempre per colpa dell'effort Extra High che a volte è un'arma a doppio taglio e inizia ad andare in paranoia e a fare giri su sé stesso invece di essere semplicemente più attento ai ragionamenti, si è impallato a ragionare per oltre 40 minuti ($11.54) e ha prodotto un briefing dettagliato ma pure troppo, e nel mentre mi ha fatto bannare l'IP da no-intro perché è andato a fare richieste sbagliate per avere informazioni sulla ROM del gioco, e ha installato delle dipendenze sul pc nonostante il lavoro di briefing sarebbe dovuto essere in sola lettura e analisi. Quindi Claude bocciato con riserva in questa fase, anche se il risultato è comunque ottimo.
LINK AL BRIEFING DI HOGS OF WAR
LINK AL BRIEFING DI SIN & PUNISHMENT
Al via i lavori, stavolta con due semplici prompt scritti da me, un misero e insignificante umano.
GPT-6.1 Sol Medium:
Read HOGS_BRIEF.md and start the development process of a recompilation of Hogs of War for PS1. Closely follow the instructions in the brief. Don't update the brief unless it's to correct wrong information. Keep a JOURNAL.md where you list the result of each meaningful step of the development process, expected percentage of completion of the first running prototype and approximate time taken to reach that point.
Claude Opus 5.5 Medium
Read SIN_BRIEF.md and start the development process of a recompilation of Sin & Punishment for N64. Closely follow the instructions in the brief. Don't update the brief unless it's to correct wrong information. Keep a JOURNAL.md where you list the result of each meaningful step of the development process, expected percentage of completion of the first running prototype and approximate time taken to reach that point.
Stavolta i lavori sono andati molto più lisci: zero interruzioni, uso moderato di token e soprattutto risultati immediatamente visibili dato che, memore dell'esperienza precedente, ho detto a entrambi di
mantenere un diario in cui segnare tutte le fasi dello sviluppo con relativa percentuale stimata di completamento e tempo impiegato.
Risultati:
Claude in
93 minuti ha prodotto il primo prototipo funzionante della ricompilazione di Sin&Punishment, testato da me e confermato come funzionante. Purtroppo non mi sono segnato il costo in token al momento del completamento, ma penso fosse molto basso. Dopo altre 10-12 ore di lavoro per finalizzare il progetto, siamo a $175,40.
LINK AL DIARIO DI SIN&PUNISHMENT
Codex su Hogs of War ha raggiunto il 97% di stima dopo circa 4h30, poi è rimasto fermo parecchio sugli ultimi step, quindi forse aveva semplicemente calcolato male la percentuale di progresso; l'ho fatto proseguire con l'obiettivo del 100% ma dopo circa 12 ore è ancora a 97% e sta continuando a fixare inaccuratezze che trova a ogni test. Comunque è giocabile e funzionante, per cui lo ritengo un pareggio con Claude, dato che probabilmente GPT è stato più "onesto" nel dire di essere al 97% perché c'erano ancora delle inaccuratezze mentre Claude ha millantato un 100% appena il gioco era avviabile e ha posticipato il polishing a fasi successive.
LINK AL DIARIO DI HOGS OF WAR
Comunque è stato molto divertente leggere i ragionamenti durante le fasi di test, non tutti riportati nel diario, in cui passavano nel terminale frasi tipo
"Ho premuto X e gli HP del maiale avversario sono scesi da 50 a 30. Nel turno successivo il maiale avversario ha svolto un'azione e gli HP del mio maiale sono scesi da 50 a 40. Il test è terminato con successo". 
Step 2: Quindi?
Quindi niente, lo sapevamo già ma volevo fare come san tommaso. Nel 2026 è già possibile realizzare delle ricompilazioni in maniera completamente automatizzata e senza sapere assolutamente nulla di sviluppo software, e si continuerà ad andare sempre più in questa direzione.
È un bene? Sì, perché per scopo di preservazione anche la ricompilazione più basilare che replichi semplicemente il codice originale 1:1 ma funzioni nativamente su altre piattaforme è un sogno ed è bellissimo che esista.
È un male? Sì, perché nonostante il risultato apparentemente positivo siamo invasi da progetti di bassissimo valore, portati avanti senza la conoscenza necessaria per capire cosa va bene e cosa non va bene nel progetto stesso, fidandosi esclusivamente del giudizio tecnico di entità in evoluzione rapidissima e delle quali non possiamo indagare il ragionamento.
Secondo me qui il problema diventa il modo in cui finora sono stati gestiti progetti di questo tipo, andando di default a creare una repository su Github per la collaborazione open source su un progetto di valore comunitario, come si fa con i progetti "artigianali" (fun fact: Claude, nonostante non gli abbia dato nessuna istruzione in merito, ha ovviamente impostato tutto come una repository Github perché è scontato che si faccia così). Con l'avanzare degli LLM diventa obsoleto e superfluo che io condivida con il mondo del codice che non capisco, che ho generato in 93 minuti senza pagare un centesimo, che chiunque può rigenerare a suo piacimento in pochissimo tempo e con le proprie personalizzazioni, soprattutto per poi ricevere contribuzioni da chi? Da altri agenti uguali agli infiniti che posso far già girare io. Il codice libero è sempre importante e può essere una base anche per gli agenti, ma l'evoluzione è talmente veloce che forse si fa prima a generare codice nuovo e più efficiente oggi piuttosto che partire da una base scritta peggio ieri.
Sono seriamente in dubbio.
