Introduction

Hands-On Parent’s Guide to STEM Projects, Coding Concepts and AI-Powered Games for Ages 8–12

Your child is already doing this. You just haven’t named it.

Your child may already be doing computational thinking. They just don’t have a name for it yet.

When my daughter was 3.5, it was peak Covid. Like a lot of parents, I handed her Khan Academy Kids to keep her occupied. She played those games obsessively: sorting, matching, sequencing, spotting patterns. Then came the puzzles, legos and the mechanics set where she had to figure out which piece went where, in which order, before anything moved.

She was doing computational thinking for years before I ever used that phrase. The play had already built the intuition. All I had to do was give it a name.

That’s the first thing I’d tell any parent: if your child plays, builds, sorts, or solves anything, they’re already in the game. You’re not starting from zero. You’re naming what’s already there.

Why ages 8–12 is the right moment for this

What changes around age 8 is precision. Before that, they sort, sequence, and pattern-match through play but can’t yet hold a multi-step plan in their head, tolerate much ambiguity, or articulate why something is broken rather than just that it is.

Around 8, that changes. Suddenly they can read a design brief and argue with it — which is exactly what good engineers do. They can sit with a problem that doesn’t have an obvious solution. They can design something on paper, find the flaws in their own thinking, and revise before building.

They’re also ready to use AI as a tool — not as a magic box that produces things, but as a capable implementer that needs clear thinking to work well. The clearer their design, the better the AI’s output. They figure this out the first time they give a vague prompt and get a mess back. That lesson: garbage in, garbage out, is one of the most valuable things in the whole series, and no one has to tell them. The tool teaches it.

This is the sweet spot. Old enough to do real design work. Young enough that the habits haven’t calcified yet.

Why this summer, why 12 days

She was about to start a new academic year. We had 12 days and I wanted to do something deliberate with that time. Something that would give her a foundation she’d carry into the year and beyond.

So we made a plan. Twelve concepts from computational thinking, one per day, in whatever order felt right. No curriculum, workbooks or expensive kits. Just the two of us, a device with an AI chatbot, and a Google Doc she had to fill in before we built anything.

Some days were breakthroughs. Some were wrong turns that became the most useful sessions of the series. All twelve produced a game she designed, built using AI, and could show to anyone.

Why computational thinking, and why now

I want to be precise about this because people hear “computational thinking” and immediately picture a child hunched over a screen learning Python.

That’s not what this is.

This isn’t a coding series. She didn’t write a single line of code across twelve sessions. I didn’t either. What she did was learn to think about problems in a particular way — systematically, precisely, with attention to what breaks and why. The coding, when it happened, was the AI’s job. The thinking was entirely hers.

This distinction matters more than it used to.

Execution is getting faster and cheaper every year. The ability to turn a clear brief into working software is already nearly free. What doesn’t get cheaper is knowing what to build in the first place. Thinking it through. Expressing it precisely. Catching the gaps before they become expensive mistakes.

That’s what I was training. Not a skill set. An instinct.

The proof was in the design documents she produced before every build. A nine-year-old who can write down the goal of a system, the rules that govern it, the steps in the right order, and the conditions under which things go wrong — that child is not learning to code. She’s learning to think like someone who builds things that work.

The design rule that governs the whole series

Every single session starts the same way. Before we touch any AI tool, before any game exists, she fills in a design document. Five things minimum:

• What am I building?
• What are the rules?
• What can change?
• What’s the winning or completing condition?
• What are the steps, in order?

No building until the design is done.

If she couldn’t fill this in, the thinking wasn’t finished. The Google Doc was the algorithm.

This discipline, design before build, is exactly how professional developers think. It also reveals, immediately and ruthlessly, where the thinking is fuzzy. You can’t write down a step you haven’t actually understood. The design doc makes vague thinking visible before it becomes a broken game.

It’s the single most transferable habit in the whole series. Worth establishing on day one and never relaxing.

What you actually need

• A child who likes to argue about rules. Genuinely, this is ideal raw material.
• A device with an AI chatbot. Claude, ChatGPT, Gemini. It doesn’t matter which.
• 15–45 minutes per session. We did it daily because we had a deadline. You don’t.
• A Google Doc or notebook for design/ writing work. This is essential, not optional.
• Zero coding experience. None required.

What you don’t need

• A computer science degree.
• Expensive kits or subscriptions.
• Your child to sit still for an hour.
• Patience with boredom (if it’s boring, something’s wrong with how the concept is being introduced, not with your child)

How each session works

Each concept follows the same structure across. You can run them across a day, week, or spread them over a month. The structure is what matters, not the pace.

Anchor: A real-world activity that grounds the concept in something tangible before anything abstract. No screens. The concept has to live in the physical world first.

Explore: Deeper engagement with the same concept. Discussion, experiment, a problem to analyse. The goal is to extend the instinct, not introduce new vocabulary.

Design and Build: Design document first. The build doesn’t start until it’s complete. Then the child directs, the AI implements, you assist with execution if needed. This is the session most parents are nervous about. It’s consistently the one children look forward to most.

Remix: Take what was built and change it. Extend it, break it deliberately, improve it. Iteration is not optional polish, it’s where the deepest understanding happens.

Teach: The child explains the concept to someone else. A sibling, a grandparent on a video call or a friend. Teaching is the deepest test of understanding. If they can explain it, they have it.

Plan: The 12 concepts

Each concept has a surface definition and a deeper purpose of what it actually builds. The surface is what we practice. The deeper purpose is what we’re actually after.

How to use this series

We did it in 12 days. You might do it in 12 weeks. Some of you will do three concepts and stop and if those three concepts stick, that’s a win. The pace is yours. What matters is the direction, not the speed.

One suggestion: don’t skip the design document. Every session, every concept, every build. It will feel unnecessary the first time. By the third session your child will reach for it automatically. That automatic reach is the habit forming.

Another suggestion: follow the child, not the schedule. If Tuesday’s explore session turns into a two-hour rabbit hole she won’t surface from, let it. If a concept clicks in twenty minutes and she wants to move on, move on. The structure is here to help, not to constrain.

And one more: when something goes wrong — when the AI output is a mess, when she can’t articulate the design doc, when the wrong turn takes an hour to navigate — that’s usually the most valuable session of the series. Write it down. The wrong turns are where the real learning happens, and they make the best reading.