Sooner or later most developers face a small human asking what you do all day — and the tempting mistake of answering with a lecture about variables. Teaching children to code is a genuinely lovely project, but the developer instinct to start from fundamentals is precisely backwards for kids. Children do not fall in love with syntax. They fall in love with making something happen — a cat that dances, a game where the dragon chases their sister's name across the screen.
The good news from classrooms and kitchen tables alike: the sequence that works is well mapped, the tools are free, and the total parental skill required is mostly restraint.
Stages, not ages
Before reading fluency, screenless logic games and 'command the robot parent around the kitchen' teach sequencing — the real prerequisite. From roughly six or seven, block-based environments like Scratch are the serious choice, and calling them toys misses the point entirely: blocks remove typing and syntax errors, the two things that end sessions in tears, while preserving every concept that matters — loops, conditionals, events, variables, even concurrency when two sprites run at once. A child deep in Scratch is doing real computational thinking with the friction removed.
The jump to text — usually Python, usually somewhere between ten and thirteen, when the child personally feels blocks are limiting — is best framed as a power-up, not a graduation. Same ideas, new costume: the loop they have used for years simply gains a keyboard spelling. Kids who move because they want features handle the shift easily; kids pushed early meet typos and cryptic errors before the motivation exists to push through them, and conclude coding is not for them. The child's boredom with blocks is the signal; the parent's impatience is not.
The two great backfires
Backfire one is turning it into school: mandated sessions, exercises with right answers, correcting their messy code over their shoulder. The unicorn game with spaghetti logic that the child proudly demos beats the tidy exercise they abandoned — by exactly the margin that motivation beats curriculum. Let the project be theirs: games, animations, pranks, a quiz about their friends. Your role is asking 'what should it do next?' and being impressed at the demo, not auditing the blocks.
Backfire two is rescuing too fast. The instinct to grab the mouse when the sprite goes the wrong way steals the exact experience being taught — the loop of it's broken, I wonder why, let me poke it, ha, got it. Debugging tolerance, not syntax, is the actual skill of childhood coding, and it only grows in children who get to be confused safely. Sit on your hands; ask what they've tried; celebrate the fix as theirs.
The AI-era question
Today's kids will never code without AI assistants existing — so the honest question is not whether they'll use one, but what they should get from coding anyway. The answer is unchanged, and arguably stronger: the point was never producing lines of code, it was learning to decompose a fuzzy wish into precise steps, predict what a system will do, and investigate calmly when it does something else. Those skills are exactly what directing an AI requires, too. A child who can read a program and ask 'why did it do that?' will thrive; a child who can only paste and pray will not — with or without a career in software.
Practically: early years need no AI at all — Scratch's whole design is that discovery is the game. For a text-language teenager, an assistant used as explainer ('what does this error mean?') is a patient tutor; used as vending machine ('write me the game'), it skips the loop where learning lives. The house rule that seems to work: AI may explain anything, but the fingers on the keyboard are yours. Which is, come to think of it, decent advice at any age.