I would further point out that before LLMs existed, this was the kind of thing where the kid alone, or parent+kid together, would have almost always reached for some premade genre-specific game-development toolkit that tries as hard as possible to abstract away any kind of programming at all. RPG Maker, Game Maker Studio, RenPy, etc.

In these toolkits, as long as you're making the idiomatic kind of game they're designed to produce, then you don't end up needing to learn a single thing about programming. Your game can be expressed 100% within the higher-level abstraction, with no reference to things like "variables" or "states".

And in some ways, that's good! (RPG Maker 95 was a good entry point into game development for 11-year-old me, way back when, as I didn't know any programming at that point [and found myself bouncing off of tools like QBASIC that required it.] I found toolkits like these a great "gateway drug": one that let me try out simple ideas, that fed an addiction to thinking about game design, leading to my ambitions gradually growing, wanting to make gradually-more-complex experiences, and so running up against the limits of the tools, where the "escape hatch" of [visual] programming became very gradually required, leading to a very gentle and gradual exposure to those concepts.)

But of course, if this isn't just a kid doing a self-motivated dive into "game dev", but a parent trying to give their kid a view into "what makes a computer a special thing, different from other tools" [i.e. that it is an infinitely-extensible tool, one that can be programmed by the end user to do anything they want], then these game-dev toolkit apps are still just "apps" (they even show up on game consoles!) and so don't quite tap into the feeling of "having an idea for literally anything you might want the computer to do, and being able to make that happen" that actual programming does. The "magic" of these toolkits feels like it lives in the app, not in what you're doing with it. There's no sense, when employing these toolkits, that (as Abelson and Sussman might say) you're casting a spell upon reality with the computer as your wand.

---

But that being said, when I've seen a parent trying to instil that particular feeling into a child of theirs, they rarely do so by trying to put the kid into the critical path for "doing the actual programming."

Learning to program, and experiencing "getting a computer to do exactly what you want", are two very different things; and I think a lot of people hold the opinion that kids generally won't care about / have patience for the former, until after you get them hooked on the feeling of the latter. (Until then, "programming" is just weird algebra that can print text on the screen, i.e. something they likely won't see what's so exciting about.)

So the general approach I've seen, before LLMs, was essentially for the parent to play the role of a coding-agent LLM, at the same time that they're also playing the role of a guide/educator. The parent prompts the kid to specify what they want to happen on the screen; and the parent themselves then codes that up (ideally in as high-abstraction-level a language+framework for this as possible, and so requiring as little fiddly glue code as possible, so as to get the change done before the kid loses interest.)

The parent can certainly then point to the code on screen and explain how each line makes what happens, happen; but first they have to run the program. For the wonder comes only when the spell is cast: the runes on the screen disappear, and in their place comes the actual result, a particular experience pulled from the space of all possibility by that particular configuration of words and symbols.

In that framing, the only thing that changes from the kid's perspective, when the parent is using a coding-agent LLM, is that the parent can take what the kid is suggesting should happen, formalize it, punch it into a tool, and come back with the "right" runes to make it happen, very quickly.

A child doesn't care where the runes were sourced from. A child doesn't yet understand that there is an art and a craft to programming at all; that some code is more maintainable than others; that there exist any structural or stylistic choices to be made, beyond just "saying that which is required to cast that spell from among all spells." The closest analogy they'll be aware of in their everyday life is math, and math (at elementary-school level) is all about canonical forms. They'll assume that the coding-agent LLM, as a tool, is simply automating "getting the right answer" for the choice of runes, in a similar way to how a calculator automates "getting the right answer" for an arithmetic problem.

The awareness that source code is not just a language spoken to machines, but a language programmers speak to each-other and to themselves in the future, just isn't relevant to this kind of early lesson. It's not something they'd notice or think about, or understand if you tried to explain it to them.

The magic, at that early point in one's life, is that "mere text on a screen" can make things happen at all; can make the sorts of cool things happen that their imagination is full of; and is in fact responsible for making happen every cool thing (and all the boring things, too) they've ever seen a computer or other bit of consumer electronics do.

And also, that those symbols aren't simply a communication to some fancy toolkit app; that those symbols can be written in regular old Notepad if you like, and they'll still be just as potent, for it's the symbols themselves that have power. (This lesson being especially potent if you demonstrate with a scripting language built into the OS, e.g. Windows batch files, such that you can simply "Save As" the text file and then double-click it.)

Teaching my kid to code with a modern MUD