He Wanted This for Twenty Years. Claude Helped Him Finish It.

A software engineer working on security operations has just proven a point most AI commentary gets backwards: the value of the tool is entirely dependent on the expertise of the person directing it. His proof is unusual. He built an integrated PlayStation development stack from the ground up, using Claude to accelerate the work, not to author it.

Emanuele Bonura is based in London, where he's a Senior Software Engineer on the Security Operations Centre (SOC) team at Fastly. Indie developer by night. The project he has released is called PSoXide, a full PlayStation 1 development stack written entirely in Rust.

The idea is older than the tool that finally made it possible. 'The roots of the idea go back more than 20 years, when I began creating maps for games such as Doom, Quake, and Tomb Raider,' Bonura told us. 'I became fascinated by how developers constructed 3D worlds and guided players through them.' That fascination outlasted a career in professional programming. It found its specific target in 2023, when Armored Core VI sent him back through the whole series, starting with its original PS1 entry. FromSoftware's Souls games are among his all time favourites too, though they only arrived with the PS3. That gap raised the question the whole project exists to answer: what would a Souls like game have looked like on the original PlayStation? Would it even have been possible?

‍

The Toolchain Existed. It Just Wasn't Integrated.

Bonura's problem was never quality. Mature PS1 development tools already existed, and PSoXide isn't a rejection of the work that came before it. The problem was fragmentation. The SDK, the emulator, the debugger, asset converters, the editor, and disc building tools were generally separate parts of the process. What he wanted was a single, coherent environment connecting authoring, asset processing, compilation, debugging, emulation, and deployment to real hardware, in a language he actually likes. According to PSoXide's own GitHub documentation, that stack now includes:

• An emulator and debugger
• A bare metal SDK
• A runtime engine
• An asset editor
• Disc tooling

That is the full pipeline. First line of code to a disc that plays on original 1994 hardware.

The hardware was validated bit for bit against an extensive real hardware test suite, covering every opcode and register of the GTE, the Geometry Transformation Engine and the PS1's dedicated maths coprocessor. The rasteriser was checked against actual VRAM readbacks photographed off real hardware. This is not an approximate emulation. It is an attempt to match 1994 silicon down to the bit.

‍

What Claude Actually Did, and What It Didn't

Bonura built an MCP server exposing roughly 25 debug endpoints, giving Claude direct access to the emulator's CPU state, VRAM, and hardware registers while a game was running. Asked what a typical day working with Claude looked like, he described a structured process: he would provide a detailed plan of what he wanted to achieve, then review the output carefully, both at the code level and from the player's perspective.

The moment that stopped feeling like a tool and started feeling like something stranger came later. Bonura built a hardware telemetry system that encodes timing, register, and precision measurements into QR codes, displayed on screen when a test disc runs on his original PlayStation. He photographs those codes off the television, imports them into his development environment, and reconstructs a complete report automatically, no manual transcription, no comparing screenshots by eye. Claude compared the real hardware's output against the emulator's and helped refine the next round of tests. 'That feedback loop between me, Claude, the emulator, and a real PlayStation felt genuinely unreal and futuristic,' he said.

The project's own documentation is explicit about who was driving. A human directed the architecture, the debugging, and the hardware verification throughout. Claude did not design the emulator or decide how the sound processor should behave. Bonura did that. Claude made the debugging loop faster. Nothing more, and nothing less.

‍

Celeste Proved the Pipeline. Half-Life Is Proving Its Limits.

Bonura used the toolchain to rebuild the two original PICO-8 Celeste games, Celeste Classic and Celeste 2: Lani's Trek, as native PS1 code, not as PICO-8 running inside an emulator layer. Genuine Rust code, compiled for the PS1's MIPS processor, ran at 60 frames per second on original 1994 hardware, with audio generated live by the console's own sound chip. He has packaged that as the Celeste Classic Collection PSX, available now on itch.io.

Celeste was the first public proof the pipeline could produce a polished native release, particularly for 2D games. The project testing it hardest now is a ground up reimplementation of Half-Life for the original PlayStation, built using assets extracted locally from a legitimately owned PC copy and based on Valve's own released Half-Life source. It already includes level traversal, streaming, NPCs, enemies, AI, weapons, animation, audio, and level transitions, all within the PlayStation's 2MB of RAM, and it is already running on real hardware. Bonura's performance target is a consistent 20 frames per second.

‍

The Correction That Mattered Most Wasn't His

A framing had started doing the rounds: 'someone used Claude to build a full PS1 game dev environment from scratch with just a few AI prompts.' Someone unconnected to the project pushed back on LinkedIn, insisting Bonura be credited by name. Bonura thanked them for it, then made the correction sharper himself: 'I'd have found it a sad story too if that's what had happened,' he said, meaning the shortcut version. What he was actually proud of wasn't the speed. It was what he'd learned.

‍

What He's Building Next

Bonura is now working on something more ambitious: an original game called Cortex Ignition, souls like in style, built for the same platform, using the same pipeline. He has brought on a dedicated 3D artist and a music artist to help turn it into a complete game rather than a tech demo.

The research behind it spans two different traditions. He studied PS1 games with large environments, starting with Tomb Raider and the techniques its developers used to work around the console's limitations. He was equally interested in games built on level streaming, such as Crash Bandicoot and Soul Reaver. The new project combines both approaches into one continuous, interconnected world.

'Ultimately, I want players to feel that same sense of mystery, danger, and discovery that makes interconnected Souls-like worlds so compelling,' he said, 'but on hardware where nobody would expect it.'

‍

What This Means, Whatever You Build

Bonura is not writing management advice, and PSoXide was not built as a lesson. But the pattern underneath it holds well beyond retro game development:

• Bring AI a detailed brief, not a vague prompt, and review what it returns properly.
• Use it to accelerate the parts you already understand. Do not use it to substitute for the parts you do not.
• Build a real feedback loop between the work and reality. Bonura's feedback loop runs through a PlayStation and a set of QR codes photographed off a television. Yours will look different, but the principle transfers directly.

‍

The Question Worth Asking

Next time a headline tells you AI built something remarkable, ask a more precise question: who wanted this badly enough to spend years understanding it properly, and what did AI actually remove from their path? Usually it is not vision. It is the distance between knowing what needs to happen and having the time to do it.

That is the gap Bonura closed. Claude did not close it for him.

Sources: PSoXide on GitHub, Celeste Classic Collection on itch.io, reporting from Xataka Brasil, and direct correspondence with Emanuele Bonura. If you'd like to support his work, he has a Buy Me a Coffee page.

‍