Kids and AI: A Dinosaur Game, a Seven-Year-Old, and Real Guardrails

This story came out of one of JD\u2019s Autohive Office Hours sessions this week. JD is the CEO of Autohive, and Office Hours is where the community gets into practical conversations about AI across work, learning, creativity, security, and whatever people are testing in the wild.

If you want to join the next one, you can find the community here: community.autohive.com/c/events.

JD won’t post photos of his kids online. He’s careful about that. So this story has no pictures of Henry, age seven, bent over a sheet of paper sketching a dinosaur strategy game from scratch. You’ll have to imagine it.

The game Henry designed has velociraptors, baby triceratops, five nests to capture, a meat collection loop, a tech tree, a mini-map, and AI-controlled enemies. At 100% coolness (coolness is a real in-game stat, and it increases over time), the velociraptor gets sunglasses. The rule about baby dinosaurs (dinosaurs can eat other dinosaurs’ children, but not their own) was added after Henry got genuinely worried the parents might eat their babies.

That rule came from a seven-year-old. The game runs in a browser. His friends want to name the dinosaurs after themselves.

The promise that started it

JD keeps a disciplined house around screens. Henry gets an hour or two of gaming on weekends when things have gone well. He often loses those rights.

When Henry was four, JD introduced him to Minecraft. He made a deal: once Henry could read, write, and type well enough to participate, they’d build a game together. That promise became a reason to practice. Henry learned to read and write with something concrete on the other side of it.

By seven, Henry was ready. But the plan had shifted. JD had been watching AI tools develop quickly enough that he realized he no longer needed to teach Henry to code first. The more useful thing to teach was how to work with AI.

How they built it, step by step

Step 1: Paper before screen

Before Henry touched a keyboard, JD handed him paper. Henry spent several evenings sketching the game. He drew rules, dinosaur types, and their properties, including coolness. The sketching sessions weren’t a warm-up exercise. They were the actual work. Getting the idea onto paper before touching any tool kept the scope from expanding out of control, gave Henry ownership of the concept, and created a reference document the AI could respond to. It also turned into a bonding activity that neither of them had planned for.

Step 2: Turn the sketches into mockups

Once the paper design was solid, JD and Henry used Autohive to generate image mockups from Henry’s drawings and descriptions. The visual step mattered more than JD expected. Henry could react to an image immediately in a way he couldn’t react to a paragraph of text. They generated concept art, picked the scene that best matched Henry’s vision, then asked the AI to annotate the image: health bars, the core game loop, visual layers, the collect-meat-level-up-defend-nest cycle.

The AI got some labels wrong, pointing at the wrong objects here and there. Henry learned, in real time, that AI output needs checking. That’s not a minor lesson.

Step 3: Set up the coding environment with voice mode

For the build, JD used a coding agent with voice mode. Before Henry took the wheel, JD gave the AI context: he explained that he was Henry’s dad, Henry was seven, and they were building a browser game Henry could share with his friends. He gave a light technical frame: a website, browser-based, likely hosted on AWS.

The AI adapted its language without being told twice. It talked to Henry in plain terms, no jargon.

Step 4: Henry explains the rules

Henry then read from his own notes and explained the game’s rules to the AI. This wasn’t a small moment. When a child speaks to an AI from something they wrote themselves, they’re not a passive recipient of a tool. They’re directing it.

Step 5: Generate the to-do list

At the end of the planning session, JD asked the AI to turn the conversation into a to-do list. It generated roughly 180 steps. They worked through them in small chunks.

Step 6: The build loop

The loop was simple: the AI builds a piece, they run it in the browser, Henry play-tests it, they talk about what should change, then they nudge the AI again. JD set up an agent for the coding work in Autohive. Running different models in the same thread (image generation, planning, coding) kept the workflow in one place rather than jumping between disconnected tools.

What Henry said about it

Henry thought the process was slow. JD knew the same project would have taken months before AI tools existed, but that context doesn’t land when you’re seven.

Henry’s own description of building it: “kind of easy.” The funnest parts were playing it and play-testing it. He liked asking for changes. He’s already planning version two.

When the demo was ready, they printed a screenshot so Henry could take it to school. His friends loved it. Top request: name the dinosaurs after them. That feature is coming in version two.

What the research says

JD’s instincts track with what researchers have been finding. A 2024 meta-analysis found game-based learning in young children shows positive effects on problem-solving, memory, attention, and computational thinking. An NIH study on children aged 9 to 10 found that those who played video games for three or more hours a day performed faster and more accurately on working memory and impulse-control tasks, though the researchers were careful not to claim firm causality.

The American Academy of Child and Adolescent Psychiatry notes that children can benefit from AI tools for creative play, language practice, age-appropriate explanation, and learning support when adults explore the tools with them. The warning is just as clear: unsupervised over-reliance produces a different outcome.

None of this means gaming or AI is automatically good. Both come with real risks. The variable is how they’re used, with whom, and with how much adult presence.

What parents and schools can take from this

JD’s most practical lesson: for young children, voice is the right interface. Henry talked to the AI. He didn’t type much. Kids are comfortable doing this because they haven’t spent twenty years conditioning themselves to associate computers with keyboards. Many adults find voice interaction awkward. Children don’t carry that same association.

The hard part of the project wasn’t the code. It was calibration. JD didn’t teach Henry if statements or system architecture. He taught project thinking: what is the scope, what does version one mean, what is a browser game, how do you play-test, how do you decide what stays. Those are skills a child can carry into any creative or professional domain.

Paper first is not optional. The sketching phase kept the project contained and gave Henry a document he owned. When he spoke to the AI, he was reading from his own notes. That’s a meaningful difference from asking a child to describe something from memory while staring at a blank screen.

For schools considering AI literacy, this project is a model worth studying. It combined drawing, writing, systems thinking, oral communication, and iteration. The AI was one tool in a workflow that started offline and stayed grounded in things Henry had created with his hands.

JD keeps returning to one observation: most children aren’t getting a practical, age-appropriate introduction to AI at all. They get either unrestricted access with no framing, or a blanket refusal. There’s a lot of ground between those two positions, and most of it is unexplored.

Guardrails matter

Screens are allowed in JD’s house, on strict terms. Henry plays for an hour or two on weekends when he’s earned it. He loses that time regularly. The project was purposeful screen use for a defined goal, not open-ended play.

The guardrails for the AI sessions worked the same way. JD was in the room throughout. He set the context for the AI at the start. He kept the conversation on track. The shared workspace history meant he could see everything that had been exchanged, with nothing hidden.

JD thinks gaming teaches kids to reason in systems: if I do this, this happens. He sees real value in that. He also knows games can be addictive and that limits are not negotiable. The goal was never more screen time. The goal was creativity, planning, drawing, talking through ideas, making trade-offs, and learning how to work with AI in a way that felt safe and guided.

The AACAP’s guidance on co-engagement is worth reading for any parent navigating this. Screen time thinking has shifted toward context and co-engagement rather than raw minute counts. The minutes matter less than what’s happening inside them.

Henry’s project took several weeks of evening sessions. It produced a working browser game, a printed screenshot on a classroom desk, and a seven-year-old who already knows what version two should have.

That’s a reasonable return on a promise made when he was four.