When an AI Bakes a Nintendo Into Its Own Brain: What the NESformer Teaches You About Claude’s Capabilities
Drew Breunig used Claude Opus 5.5 prompts to build NESformer — a working NES CPU emulator encoded into the weights of the Qwen3.5-4B language model. Simon Willison's coverage of the project reveals a prompting approach — explore first, then build with loosened constraints — that non-technical professionals can adapt to their own Claude workflows today.
A Working Nintendo Emulator — Living Inside an AI Model’s Weights
Something unusual landed on the internet at the end of October 2026. A developer named Drew Breunig managed to bake a working emulator for the Nintendo Entertainment System’s 6502 CPU directly into the weights of a language model called Qwen3.5-4B. The project, called NESformer, means you can now theoretically run classic NES ROMs — including Super Mario Bros — inside a neural network. Not alongside it, not connected to it, but inside it.
Simon Willison’s blog at simonwillison.net covered this project and surfaced the detail that makes it directly relevant to anyone following Claude: Drew Breunig built the entire system using Claude Opus 5.5 as his coding and reasoning partner. The prompts he shared on Hacker News reveal something important about how a skilled user can direct Claude toward genuinely novel technical territory.
What Actually Happened Here — In Plain Language
To understand why this is remarkable, you need a mental model of what an LLM’s “weights” actually are. When a language model is trained, it compresses enormous amounts of knowledge and pattern into billions of numerical parameters — those are the weights. Normally, those weights encode things like grammar, facts, reasoning patterns, and conversational ability.
What the NESformer project does is different: it fine-tunes a smaller model (Qwen3.5-4B, which has 4 billion parameters) so that the weights themselves encode the logic of a specific hardware chip — the MOS 6502 processor that powered the original Nintendo Entertainment System. The model doesn’t just describe how the chip works; it behaves like the chip, processing instructions the way the real hardware would.
This was inspired by an earlier project called qwenputer by Divyansh Agrawal, which demonstrated that you could simulate computational logic inside model weights. Breunig took that concept and asked: could you go further and emulate an actual gaming console’s CPU?
The answer, apparently, is yes — though slowly.
The Claude Prompts That Built This
Here is where the story becomes directly instructive for how you should think about working with Claude. Breunig shared the actual prompts he used on Hacker News, and Simon Willison’s coverage highlights them because they demonstrate something important: even highly technical outputs can begin with surprisingly conversational, exploratory prompting.
The first prompt Breunig used was essentially a research brief:
Read this article and any relevant source code: https://divagr.com/blog/qwenputer. Then explore if you could emulate the chip and ram in a Nintendo Entertainment System (as people do today with FPGAs in MISTRs) using this technique. If so, what size model would you have to build and if you could use smaller faster ones, could you get it to be at the standard clockspeed.
This is not a command. It is a question. Breunig gave Claude a reference point (the qwenputer article), a domain analogy (FPGAs in MiSTer devices), and a goal (explore feasibility). He did not write a technical specification. He asked Claude to think first.
The follow-up prompt was even simpler:
I think we should build it! Just for fun. It’s okay if it’s not fast. We want to be able to have the weights, and a cli to run them that we can point at a ROM.
That second message is remarkable for what it removes from the requirement: perfection. Breunig explicitly told Claude that speed was not a hard constraint, and that the deliverable was a set of weights and a command-line interface. By narrowing the definition of success, he gave Claude a achievable, concrete target.
According to Willison’s coverage, Claude Opus then independently found and used a collection of NES CPU conformance tests released fifteen years ago by a developer named Christopher Pow. Claude did not just write code — it sourced a validation framework to check whether the emulation was actually correct.
What This Tells You About How Claude Reasons
For a non-technical professional, the mechanics of weight training are not the point. The lesson here is about how Claude handles open-ended creative-technical briefs.
When you give Claude a well-scoped question with a clear end goal but deliberately loosened constraints — “it’s okay if it’s not fast” — you are freeing it to find a viable path rather than optimize for the wrong metric. This is a prompting principle worth internalizing regardless of whether you are building software or simply asking Claude to draft a strategy document.
Notice also that Breunig’s prompt included an analogy: FPGAs in MiSTer devices. He translated the abstract concept (hardware emulation in silicon) into a domain Claude could reason about. You can do the same in any domain — when asking Claude to help with a complex business problem, anchoring your prompt to a concrete analogy or reference example consistently improves output quality.
A Scenario Closer to Home: What This Means for a Team in Pune
Imagine you manage a small product team at a fintech startup in Pune. You want to explore whether an AI model could be fine-tuned to simulate a specific internal business logic engine — say, a loan eligibility scoring system that currently lives in a legacy codebase that nobody fully understands anymore.
The NESformer project is proof-of-concept evidence that this kind of “baking logic into weights” is now in the domain of the possible, not just theoretical. You would not do it the way Breunig did — his project required model training infrastructure — but the idea that a language model can internalize computational logic rather than just describe it is the insight that matters.
More practically, the prompting approach Breunig used with Claude Opus is immediately applicable to your work today. If you are asking Claude to help you reverse-engineer a legacy process, structure a feasibility analysis, or explore whether a new approach is viable, his two-prompt structure — first ask Claude to explore, then ask it to build with explicit constraints loosened — is a workflow you can adopt this week.
The Honest Limitations You Should Know
Before you get carried away, the NESformer has real, significant constraints that Simon Willison’s coverage does not obscure.
What to Watch For Next
The NESformer sits at the intersection of two trends worth tracking. The first is model distillation and specialization — the idea that smaller, cheaper models can be made highly capable at narrow tasks by encoding specific knowledge directly into their weights during training. The second is Claude as an architectural partner — using Opus-class models not just to write code but to design entire technical systems, source their own validation frameworks, and reason about feasibility before committing to a build direction.
If you follow AI development in India’s startup ecosystem, keep an eye on how fine-tuning costs continue to fall. Projects like NESformer that required meaningful cloud compute in 2026 may become accessible to a much wider range of teams within the next two to three years. When that happens, the prompting discipline Breunig demonstrated — exploratory research question first, constrained build brief second — will be the differentiating skill, not access to compute.
For now, the most actionable thing you can take from this story is a mindset shift: Claude Opus is capable of being a genuine design partner on ambitious technical projects, not just a code autocomplete tool. The NESformer exists because someone asked it an honest, curious question and then said, simply, “let’s build it.”
