This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.
From what I can gather, Miyamoto never wrote a single line of code for his games. In an old Iwata Asks, lead programmer Toshihiko Nakago describes how it worked. Miyamoto and Takashi Tezuka would sketch levels in pencil on enormous sheets of graph paper. Nakago’s team would then enter the data by hand, block by block. In the evenings they’d burn everything onto a ROM, and the two designers would play through the level. Corrections would come back as pencilled notes on the sheet. “We could barely manage one round of changes a day,” Nakago recalls.
One cycle a day. Today, with a language model open alongside the editor, I can run one every two minutes.
I’ve written before that the lone genius is a myth and I still believe it: without Nakago there would have been no Super Mario. Today, a language model handles part of what used to be that dialogue between designer and programmer. But the dialogue itself remains — and the way Miyamoto engaged with it says a lot about what our craft is becoming.
The designer as director
I like to picture Miyamoto as someone who knew what he wanted and knew how to communicate it. His job was to describe: where the block goes, how high the jump reaches, what the Goomba does when it hits a pipe. Translating that into assembly was someone else’s problem.
Something similar happens with AI. I can describe a mechanic, a character’s states, the edge cases, and get back a script for Godot or Unity that implements them. The quality of the output depends on how clearly I’ve thought things through — the more precise I am, the fewer tokens I’ll burn.
The designer decides what should happen, why, and what it should feel like. Writing the code becomes a part of the process you can hand off. I touched on this recently when writing about junior devs: the job has always been to instruct a machine until it becomes a game.
The limits of today
The NES had 2 KB of working RAM. Nakago describes hunting for free memory: with twenty bytes to spare, you could add ten more blocks to a level. Some of the most enduring solutions in gaming came out of those constraints — like the clouds and bushes in Super Mario Bros., which are the same sprite recoloured.
Miyamoto didn’t program, but he knew those limits inside out. That’s why what he asked for was always actually buildable.
AI has its own limits, and anyone using it needs to know them just as well. The model forgets whatever falls outside its context window. It gives different answers to the same question. If it’s running in real time inside a game, every call has a latency and a cost. Knowing these things lets you design around them — and sometimes turn them into mechanics: a character with a faulty memory, an unpredictable oracle, a world that shifts every time you visit it.
Ten cycles a day, then a hundred
In the same interview, Nakago mentions that with later tools they could iterate on a level ten or twenty times a day. Today the loop between idea, implementation, and playtest is compressed almost to nothing. I tweak the gravity, play it, tweak it again.
That shifts the bottleneck. Before, the constraint was how fast someone could implement a change. Now, the constraint is how fast I can tell whether the change actually works. And to figure that out, I have to play, feel, compare. The feel of a jump only reveals itself with a controller in your hands.
What AI doesn’t know
AI can write code, sketch dialogue, generate assets in seconds. But it doesn’t know when a level has gone on too long, when an enemy arrives at exactly the wrong moment, when a jump tips over from challenging into frustrating. It doesn’t experience joy, boredom, or tension. It’s good at imitating solutions others have already found; deciding which ones to keep is down to whoever’s actually playing.
That’s why I think the game designer’s value is shifting even further towards taste, pacing, and an understanding of player psychology. Those are the qualities that made Miyamoto’s work timeless — and he honed them with a pencil and a sheet of squared paper.
Three things to practise starting tomorrow
- Write specs that someone else can execute. Take a mechanic you know well — Mario’s jump, say — and describe it in ten lines. Then hand it to a model and see what comes out. Every gap between what you had in your head and what you see on screen is a place where your description was fuzzy.
- Learn your tool’s limits. Miyamoto knew the NES’s memory; learn what the model gets wrong — where it gets confused, what it forgets, when it starts making things up. That’s design-relevant information.
- Play more than you generate. When an iteration takes two minutes, it’s easy to crank out fifty of them without actually playing any. Set aside time to pick up the controller and make a proper judgement — and write down what you felt before you ask for the next change.