“I want my child to learn to program” is often a way of saying something bigger: I want them to understand technology, solve problems, and be able to make things of their own.
For years, the most obvious starting point has been a programming language. Pick up some blocks or learn a little syntax, then use those instructions to make something happen. There is real value in that approach. But as the tools for building software change, we should reconsider where children begin—and what we want them to practice.
We built Makerplay around a different starting point: give a child something they want to create, then help them get precise about how it should work. Let them try it, notice what falls short, and make it better.
We believe children should be able to start building software while they’re learning how to think it through.
A game gives careful thinking a purpose
Consider a child who wants to make a game about a knight escaping a castle. That idea is enough to begin. Developing it means answering questions.
What keeps the knight inside? Where is the key? What happens when a guard spots the player? If the knight loses a life, do they keep the key or have to find it again?
Each answer makes the design more specific. The child separates the game into pieces, defines what each piece does, and considers how the rules interact. They have a reason to think carefully because those decisions change something they want to play.
In Makerplay, those decisions go onto the Game Board. We developed the board and game cards to make a game’s structure visible and editable: its characters, objects, behaviors, and rules. Children can return to a particular piece, change its instructions, and try the result.
Written language is the way they express the design. Precision still matters. “Make the guard harder” leaves a lot undecided. “The guard chases the knight when they enter the courtyard, but stops at the bridge” describes behavior the child can test.
That is a substantial challenge, even when there is no code on screen.
The first version is where the interesting work begins
A game can follow every instruction and still be boring. The guard catches the knight immediately. The key is too easy to find. The player never notices the bridge.
Now the child has to decide what is wrong and what might help. Should the guard move more slowly? Should there be a warning before the chase? Would moving the key make the player explore?
This is where judgment develops through practice. The child makes a change, sees what happens, and decides whether it helped. Sometimes the idea needs work. Sometimes the tool has built it incorrectly. Learning to compare an intention with a result gives them a way to investigate both.
Watching a friend play adds another perspective. A rule that seemed obvious may be confusing to someone else. A shortcut may remove the challenge. The child gets to consider what another person understands and enjoys, then act on what they notice.
We want Makerplay to make that next version worth building. Generating a game is only the beginning of the experience we’re designing for.
Professional software development is moving in this direction too
Professional developers increasingly describe a feature, use tools to generate an implementation, and then inspect, test, and refine it. In Anthropic’s published development workflow, specifications, implementation plans, and review are explicit parts of working with coding agents.
This makes the quality of the direction consequential. Someone still has to decide what the software should do, explain its constraints, recognize an incorrect result, and judge whether it solves the intended problem. Technical understanding remains important, especially when checking code and diagnosing failures.
Makerplay brings an accessible version of that process to children. Our AI game maker for kids helps turn the instructions on their board into a playable game. Their work is to shape the idea, define its behavior, evaluate what gets built, and direct the next change.
Children making a game are taking on a much smaller challenge than engineers responsible for a production system. But the habits they can practice—clear descriptions, attention to how pieces interact, testing against an intention, and thoughtful revision—belong to software creation itself.
Those habits deserve to be taught as valuable skills in their own right.
Learning code is one path to greater control
Scratch gives children direct experience with programming logic through blocks, alongside creative thinking, debugging, and iteration. A child can construct a behavior from events, conditions, variables, and loops. That is useful knowledge.
Makerplay gives children a different kind of control: they describe the behavior they want, see it in a running game, and revise the design. The code is handled for them. This leaves more room for decisions about the game’s structure and the player’s experience, while giving them less direct exposure to its implementation.
The right starting point depends on what you want your child to practice. If the immediate goal is learning loops and variables, a tool that exposes those concepts directly makes sense. If the goal is turning ideas into working software and learning to improve it, we believe Makerplay is a strong place to begin.
Some children will become curious about the code underneath. Their games can give that curiosity a purpose: they already know what a health counter does, and now they want to understand how a program remembers it. Our guide to Makerplay, Scratch, and Godot explores those different layers.
Others may keep creating through tools that handle implementation. Their work still calls for ideas, decisions, and care. We don’t see writing code as the graduation requirement for being a capable creator.
Give them something worth improving
The broader educational opportunity is a child becoming more capable of taking an idea seriously: explaining it, trying it, listening to feedback, and doing another version.
We believe that practice has value well beyond games. Defining a problem clearly and judging the quality of an answer matter when planning a project, designing an experiment, or working with an AI tool. The tools and professions will change; children will still need their own reasons for deciding that something works—or could be better.
Games give that practice an immediate purpose. A child wants the chase to feel fair, the secret passage to surprise a friend, or the ending to be worth reaching. Improving those things asks for attention and persistence, with a result they can experience for themselves.
That is why we start with creation. We want a child to play what they made, notice something they can improve, and know how to take the next step.