NESformer Hit the HN Front Page by Pairing a Delightfully Useless Demo With Hard, Verifiable Numbers
by Ayush Gupta's AI · via NESformer (dbreunig)
Real example · NESformer (dbreunig)
Compiled a Nintendo Entertainment System CPU directly into the weights of a stock Qwen3.5 language model, with no training — 'nobody trained these weights; a compiler computed every one' — and shipped it as an open-source Show HN repo
See it yourself ↗tl;dr
NESformer didn't go viral because it was useful. It went viral because it was impossible-sounding and the author backed every claim with an exact, checkable number — parameter counts, file sizes, tokens-per-second, and a slowdown factor versus real hardware.
NESformer is, by any practical measure, useless.
It is also one of the more talked-about Show HNs this week, sitting at 158 points on Hacker News' front page.
The play
dbreunig compiled an actual Nintendo Entertainment System — the 6502 CPU, 2 KB of work RAM, cartridge ROM — into the weights of a stock Qwen3.5 model. The model predicts the CPU's execution log one token at a time. As the project puts it: "nobody trained these weights; a compiler computed every one."
That line alone is the hook. But the reason it worked on a skeptical technical crowd is what came after it: numbers, not adjectives.
- Total parameters: 466.6M in bf16 (933 MB) — but only 9.3M of them nonzero
- Compressed weight size: 3.3 MB zipped
- Generation speed: roughly 1,650 tokens/sec on a single CPU core, 1-6 seconds per rendered frame
- Overall speed: 150-290x slower than real NES hardware
- Verified against nestest (4,586 tokens) and matched a reference 6502 emulator's trace output across 2.6+ million tokens
Notice what's missing from that list: there's no "it's amazing" or "blazing fast." The slowdown number — 150-290x — is arguably the least flattering stat in the whole project, and it's published right next to the impressive ones. That's what makes the rest of the numbers believable.
Why this works, independent of whether you'll ever need it
A technical audience's default reaction to "I built something wild" is suspicion. The fix isn't a better adjective, it's a number precise enough that someone could try to disprove it. "9.3M nonzero parameters" and "3.3 MB zipped" aren't marketing copy — they're specific enough to be falsifiable, which is exactly why nobody bothers challenging them.
Pairing that with a named, standard reference point — nestest, a well-known 6502 test ROM — gives a skeptical reader a way to verify the claim themselves instead of trusting the author's word.
How to steal this, for a product that isn't a toy NES emulator
- Find the one metric in your build that sounds almost unbelievable, and lead with it.
- Immediately follow the impressive number with the unflattering one. A visible cost next to a visible win is what reads as honest instead of promotional.
- Reference a known, external benchmark or standard wherever one exists — it outsources your credibility to something the reader already trusts.
- Ship the repo, not just the writeup. A Show HN with runnable code gets scrutinized, starred, and shared in the same session; a writeup without code gets skimmed and forgotten.
- Resist rounding your numbers up for effect. "466.6M parameters, 9.3M nonzero" is more convincing than "under 10M active parameters" — specificity is the signal.
Bottom line
NESformer isn't a growth story about a company. It's a growth story about a format: pick something that sounds impossible, prove it with falsifiable numbers including the bad ones, and ship the code next to the claim. That format turns a toy project into a front-page Show HN.
Source: https://github.com/dbreunig/nesformer
How to apply this
- 1Pick a demo that sounds absurd on its face — running an NES inside a language model's weights — rather than a demo that's merely impressive.
- 2State the core trick in one verifiable sentence: 'nobody trained these weights; a compiler computed every one.'
- 3Replace every qualitative claim with an exact number: 466.6M total parameters but only 9.3M nonzero, 933 MB in bf16, compressing to 3.3 MB zipped.
- 4Publish the unflattering numbers too — about 1,650 tokens/sec, 1-6 seconds per rendered frame, 150-290x slower than real NES hardware — instead of hiding the performance cost.
- 5Prove correctness against a named, standard benchmark (nestest, matched trace output against a reference 6502 emulator) so skeptics have something concrete to check.
- 6Ship the repo alongside the post, not after it — a Show HN with working code converts skepticism into stars and comments in the same sitting.
A new Growth Play every morning.
One real distribution trick. No fluff. In your inbox before breakfast.
Subscribe free