What Happens When a 10-Year-Old Directs an AI Game Builder

Last updated: June 2026

A 10-year-old directing an AI game builder does not look like what most parents imagine. There is no kid sitting passively while a robot writes code. The kid is in charge. The AI is the assistant. As a result, when it works, the child watches their imagination become a working game in real time. That is something I had never been able to deliver before this year.

This is the story of Cameron, a long-time game-dev student of mine, asking AI to put a "nasty SpongeBob burger" into a skateboarding game as a jump-over object. The AI did it. Cameron's head exploded. The session changed how I think about teaching kids with AI, and I want every parent reading this to understand the difference between AI replacing a kid and AI executing a kid's direction.

Key Takeaways

• Kid-directed AI is when the child decides what to build and the AI handles the implementation, the opposite of AI tutoring.
• The motivation impact is enormous: kids stay engaged for sessions twice as long when they are the creative lead.
• This works best in game development, where every idea has a visible result on screen within seconds.
• The skill being built is not coding syntax. It is specification, decision-making, and creative direction, all transferable to real software work.
• Parents should worry less about "is AI doing the work for my kid" and more about "is my kid driving the direction." If they are, it is teaching them something a normal curriculum cannot.

Table of Contents

• The SpongeBob Burger Moment
• What Cameron Was Actually Learning
• Kid-Directed AI vs Other Learning Models
• Why This Format Engages Kids So Hard
• Where Kid-Directed AI Stops Working
• How I Run These Sessions
• Related Articles
• Frequently Asked Questions
• The Bottom Line

The SpongeBob Burger Moment

Cameron is about 10. He has been a game-dev student of mine for a while. In short, he loves skateboarding, video games, and chaos in roughly that order.

I had built him a skateboarding game from scratch in front of him during our session: a character on a board, parallax background scrolling behind, a menu screen, music. The bones were there. Then I asked him the question I always ask: "What do you want to add?"

This is where Cameron took over. He started rattling off ideas the way only a 10-year-old can. Bigger jumps. A second character. A rocket. Then he pulled out his phone, found a screenshot of "this very nasty looking burger from SpongeBob," sent it to me, and said: I want to jump over that.

We put the image into our AI pipeline, asked it to add the burger to the game as a jump-over obstacle, and within a few minutes the burger was sliding across the bottom of the level. The character jumped over it. The burger was real, in the game, doing what Cameron had imagined three minutes earlier.

His head exploded. I have been teaching kids for 20 years and I have rarely seen a face do what his face did. Not because the technical achievement was hard. Because the speed from "thing I imagined" to "thing on screen" was small enough for him to feel like the author of the game.

What Cameron Was Actually Learning

A parent might watch that session and worry that Cameron was not coding. He was not, in the strict sense. He was not typing variable names or writing if-statements that day.

But here is what he was learning, and these are the skills that matter for the rest of his life as a person who builds things:

He was learning to specify clearly. Vague requests give terrible output. For example, "Make it cooler" produces nothing. "Add the burger as a jump-over object that resets when the player passes it" produces a working feature. That gap is the entire job of a software engineer, and Anthropic's own guidance on prompting Claude is essentially a primer on the same skill. Most adults are bad at it.

He was learning to evaluate output. When the burger first appeared, it was the wrong size. Cameron noticed instantly. He said make it bigger. We did. He noticed it was passing through the character, not registering a collision. We fixed it. Each cycle was him exercising judgment about whether the result matched his intent. That is engineering thinking.

More importantly, he was learning to direct creatively. He decided what the game became. The AI was the tool, the same way a paintbrush is a tool. Nobody worries that a paintbrush is taking the artist's job. Common Sense Media's 2024 report on kids and AI makes the same point about the importance of kids being authors, not passive consumers, of AI output.

And on the days when Cameron does write code (most of our sessions, in fact), all of these skills make him a sharper coder than he would otherwise be. The AI-directed sessions are a multiplier on the foundational ones, not a replacement.

Kid-Directed AI vs Other Learning Models

Parents tend to think of "kids and AI" as one thing. It is at least four very different things, and only one of them is what Cameron did. Here is the breakdown.

Model	What the kid does	What the AI does	Learning outcome
AI tutoring (chat AI as teacher)	Asks questions, receives explanations	Explains concepts	Passive, often shallow; depends entirely on whether the kid can self-check
AI as code generator (kid asks for code)	Pastes code into a project	Writes the code	Almost zero learning; kid is a courier
AI pair-programming (kid codes, AI assists)	Writes most of the code, asks AI for help on stuck parts	Suggests fixes for specific issues	Strong; kid is the author, AI is the rubber duck
Kid-directed AI building (Cameron's session)	Designs, specifies, decides, judges output	Builds the specified thing	Strong; kid learns specification, judgment, and creative direction

The two strong rows are what good kid-and-AI use looks like. The two weak rows are what most parents are accidentally setting up when they hand a kid a chat AI and walk away.

Why This Format Engages Kids So Hard

Cameron will sit through a 90-minute session like the one I just described and ask if we can keep going. He will not sit through 20 minutes of debugging a print statement gone wrong.

The difference is not "AI is fun and coding is boring." Plenty of my students love writing Python code. The difference is the feedback loop length.

In a typical coding session, a kid types a line, runs the file, sees a result or an error, fixes it, runs again. That loop is fine, but it has dead time in it. In a kid-directed AI session, the loop is: kid says what they want, sees it appear, judges it, asks for the next thing. The dead time is gone. Their creative energy goes into directing instead of typing brackets.

For kids, the bottleneck on engagement is almost always the gap between an idea and its visible result. The smaller that gap, the longer they stay. In practice, across 200+ kids I have taught, this pattern has held for every single one. Pew Research's 2024 survey on teens and AI found a similar dynamic in school settings: engagement spikes when the AI is treated as a tool, not a teacher.

This is also why game development specifically works so well for this format. Every change is visible immediately. Add the burger, the burger appears. Change the jump height, the character jumps differently. There is no abstract thinking about whether your code "worked." It either looks right or it doesn't.

If you have a kid who is creative but bored by typing code, this format may unlock them. I have written more about that broader pattern in The 30-Second Trick That Makes Kids Care About Code.

Where Kid-Directed AI Stops Working

I am not going to pretend this is a magic format that always works. It fails in two specific ways and parents should know both.

It fails when the kid has no creative direction of their own. If a kid sits down and shrugs when asked what they want to build, an AI assistant cannot fill that gap. The format depends on the kid being the author. With no author, you get an AI generating random output and a kid losing interest in five minutes.

It also fails as a substitute for fundamentals. Cameron can do this because he has spent months understanding what a function is, what a loop does, what collision detection means. Without that foundation, he cannot evaluate what the AI produces. For example, he cannot say "the collision is wrong" because he does not yet know what a collision is. The kid-directed AI session amplifies what a kid already knows. It does not create knowledge from nothing. This matches the conclusion of MIT's 2023 research on generative AI in education, which found AI amplifies existing skill, it does not replace the work of acquiring it.

That is why my standard sequence is: build the foundations in normal sessions, then layer in AI-directed building once the kid has enough to direct from. Skipping the first step is the same mistake parents make when they give an 11-year-old a Claude Code subscription with no scaffolding around it, which I wrote about in I Gave an 11-Year-Old a Claude Code Subscription.

How I Run These Sessions

For parents curious about what this looks like in practice, here is the structure of a session like Cameron's.

The first ten minutes are pure conversation. What does the kid want to build today? Not a one-line answer. A real spec. What kind of game. What kind of character. What environment. The kid talks, I take notes that become the prompt or task list.

The next chunk is the build itself. I am at the keyboard for parts that need real code judgment. The kid is directing throughout, suggesting features, evaluating what appears on screen, making decisions. The AI is the executor in the middle.

The last ten minutes are reflection and what-next. What worked. What did the kid want that we couldn't pull off. What they are going to think about for next session.

The pedagogy point in one sentence: the kid drives the design, the tutor and AI execute, and the kid develops judgment through repeated cycles. That is the model, and I think it is one of the most important shifts in how kids can learn to build software in the next decade.

However, it is also a model that does not work without a real teacher in the loop. That is the gap most parents are about to discover when they hand their kid a consumer AI subscription and hope for the best. The AI is powerful. It is not a teacher. That role still has to be filled by a human, ideally one who has worked with hundreds of kids and knows what each one needs next.

Related Articles

• I Gave an 11-Year-Old a Claude Code Subscription, a different AI-with-kid setup, the Stacy story.
• Can Kids Learn AI? What Parents Need to Know in 2026, the pillar guide on AI literacy for kids.
• What I Tell Parents About Kids Using AI for Homework, the harder question parents ask me most.

---

Frequently Asked Questions

Isn't the AI doing all the work in a session like Cameron's? No. The AI is doing the implementation. Cameron is doing the design, the specification, the judgment, and the iteration. Those are the harder skills and the ones that transfer. Implementation is the cheap part now; direction is the valuable part.

How old does a kid need to be for this to work? Around 9 or 10 at the earliest, and only if they already have some coding foundation (basic Scratch or Python). Without the foundation, they cannot evaluate the AI's output, which means they cannot direct it meaningfully.

Will my kid learn to actually code this way, or just to prompt? Both, if it is paired with normal coding sessions. The kid-directed AI sessions teach specification, judgment, and creative direction. The normal coding sessions teach syntax and fundamentals. You need both, not one.

What tools do you actually use for this? A mix depending on the project. For game development specifically, we often use Pygame or browser-based engines and direct the AI to write the game code. The tool matters less than the workflow. The workflow is the kid in charge, the AI executing, the tutor steering.

Can I do this with my kid at home without a tutor? You can try, and some parents will succeed. The honest answer is that most parents do not have the coding background to catch when the AI is producing junk or when the kid is faking comprehension. A tutor in the loop is what turns this from "fun toy" into "actual learning."

Is this the future of coding education for kids? Part of it, yes. The future is not "AI replaces coding teachers." The future is "coding teachers use AI to let kids build things 10x bigger than they could on their own, and kids spend their time learning to direct rather than typing brackets." That shift is already happening in my sessions this year.

---

The Bottom Line

Cameron's session is not a one-off magic moment. It is the start of how kids will learn to build software for the next decade. The skills being built (specification, judgment, creative direction) are exactly the skills that matter when AI handles implementation. The kids who learn this early will have a head start of years on the ones who didn't.

Want to see what a session like Cameron's would look like for your child? Book a free Discovery Call and we will walk you through what their first kid-directed AI build could be.