From Playing with AI to Building with It
My son had seen me using ChatGPT and some of the experiments on my website. One day, he said he had an idea for a game. “Maybe we could use ChatGPT to make it.”
He already knew ChatGPT. We’d used it to invent and play games together, and he was comfortable challenging its rules, finding loopholes, and changing the direction of the game. But this time he wanted to build something he could play outside the conversation: a game about choosing healthy and unhealthy foods.
I didn’t know all the rules he had in mind, but I thought it would be interesting to try.
I wanted him to explore his idea and get to something playable before the process became frustrating. As an engineer, I was already thinking about how to make that possible.
Getting started
For this session, I used Astra 6 (High). My initial prompt was:
“We are going to design a game locally probably in html, my son is going to help design the rules, you will divide the story/idea/concept from the mechanics/code, so we can iterate on both separately, if you need to create files locally do it.”
I wasn’t sure how difficult the implementation would be, but I wanted something we could run and change quickly.
I’d seen impressive examples of AI generating more elaborate games and videos. But those can take considerable time to produce and iterate on. I didn’t want him to describe an idea and then spend a long time waiting to see whether it worked.
I also asked the agent to keep the story and rules separate from the game mechanics. We barely knew what the game would be, so I expected things to change.
We were mostly talking, not typing.
My son described what he wanted: players taking turns, choosing foods, different difficulty levels, and surprise snacks. The description wasn’t always precise, but I was impressed by how well the agent understood what he meant.
It asked questions, made suggestions, and kept track of the decisions.
Every so often, I asked it to summarize what it understood and identify what was still missing.
“Summarize or describe the game, the actions, the goal, and also what is missing, what decisions, what key decisions are missing from our side.”
I wasn’t worried about whether the model could produce functional software. I was more concerned about the decisions it might make when the rules were incomplete.
Some assumptions could significantly change the game. For example, what happens when a player makes a mistake? Does the player lose a turn, lose points, or get eliminated?
I wanted my son to make those decisions.
Keeping the first version small
I mostly tried to let him describe the rules himself. When he had an idea, I wanted him to explain it to the agent, even if his first description wasn’t perfectly clear.
But I also stepped in occasionally to simplify things.
At one point, he proposed allowing players to send messages to trick each other. I suggested leaving that out of the first version.
He also wanted difficulty to change depending on the player’s age. I suggested using broader categories: baby, child, and adult.
He accepted both suggestions and explained the changes to the agent.
These were familiar engineering decisions: limiting scope, separating components, and deciding what could wait until later.
But the objective was different from a typical software project.
I wasn’t trying to produce the most complete game or optimize the implementation. I wanted us to get to something playable while he was still interested in developing it.
There was also a balance I was trying to maintain. I could have specified the rules myself and asked the agent to implement them. That probably would have been easier.
But then it wouldn’t have been the same activity.
My son was supposed to be designing the game. My role was to help him make progress without taking over the decisions.
From conversation to something playable
Once we had enough of the rules, we started discussing how the game should look.
He wanted a restaurant, pixel art like Minecraft, and cartoon characters. We looked at a visual preview, and he asked for changes.
Then we asked the agent to build the first playable version.
He started playing and immediately began noticing things that weren’t quite what he intended. At one point, a player could take over another player’s turn after losing. He considered that cheating.
Some of these problems probably came from rules he hadn’t fully specified earlier.
What interested me was how naturally he responded. He didn’t need to understand the implementation or explain which part of the code was wrong. He could describe what had happened, explain why it wasn’t right, and ask the agent to change it.
We made a couple of corrections and played again.
This was different from the games we had previously played with ChatGPT.
In a conversational game, changing a rule can be as simple as saying that something should happen differently. The model can adapt the story in the next response.
Now the rules existed in software. The game behaved in a particular way, regardless of whether that was what he originally intended.
He could still challenge the agent, but now he had something concrete to evaluate.
And I think having something playable helped him express parts of his idea that hadn’t been clear during the conversation.
What the shorter feedback loop changed
I’ve been thinking about my role in that process.
My son came up with the game, described the rules, chose the visual elements, and decided whether the result matched what he wanted.
The agent was remarkably capable of interpreting his descriptions and turning them into something functional.
I was mostly shaping the process: keeping the scope manageable, asking which decisions were missing, separating things we might want to change, and choosing when we had enough to try a version.
I recognized many of those decisions from software projects: how much to define before building, which assumptions matter, and when it makes more sense to try something than keep discussing it.
But I also wanted him to remain the person directing the game. I didn’t want the model to fill every gap with an assumption and have him simply accept the result.
At the same time, I didn’t want to turn the afternoon into a requirements exercise.
AI made the implementation fast enough that we could move between discussing, building, playing, and correcting the game.
That mattered more to me than the speed of generating code.
If producing the first version had taken several days, I might have ended up doing most of the implementation while my son waited. Instead, he could participate throughout the process.
He didn’t need to describe the entire game perfectly at the beginning. He could describe enough to start, see what the agent produced, and then make more precise decisions.
The first playable version wasn’t just the result of our earlier conversation. It gave us another way to continue that conversation.
I don’t know how much of this would have happened differently if he had worked with the agent alone. And I don’t think this experience tells us how children should learn programming or use AI.
It was simply an afternoon spent making a game together.
The conversation
From an idea to a game we could play
My son brought the ideas, examples, and corrections. The agent recorded the rules, asked questions, produced visual mockups, and built a local prototype. The game took shape through those exchanges.
Selected moments from our 25-exchange conversation. The numbers refer to the original turns in the chat.
- Turn1
Set up the collaboration
My son would help design the game, while the agent turned the ideas into code. Rules and visuals would stay separately editable.
- Turn2
“I want a food game.”
He established the central theme.
- Turn3
Give the idea its first structure
Three players, daily food allowances, and difficulty modes defined the basic game.
- Turn5
Add stakes and a goal
Points, surprise snacks, elimination, and a chosen game length gave players a way to win.
- Turn14
Classify, then Eat or Skip
The agent offered three alternatives. My son chose to classify the food first, then decide whether to Eat or Skip.
- Turn15
Make the mistake limits precise
Mistakes would accumulate within a day and reset the next day.
- Turn18
Choose the restaurant setting
Pixel art and numbered cartoon characters gave the game its visual direction.
- Turn19
See the idea for the first time
One food, with buttons beneath it: the first mockup made the design visible.
- Turn21
Build the first playable version
The mockup helped establish the visual direction. The first playable version used simple artwork so we could test the rules.
Play the food game → - Turn23
Revise after playing
Playing exposed rules that needed changing. My son clarified that identifying an unhealthy snack should not eliminate a player and requested CPU opponents so losing players couldn’t simply take over another slot.
Agent’s summary of the session
The agent summarized our chat as follows:
Turn count: 25 completed exchanges.
We developed:
- Food classification with Healthy/Unhealthy buttons, followed by Eat/Skip.
- Three difficulty levels, daily mistake limits, points, meals, and surprise snacks.
- Baby, Child, and Adult categories; up to three Human or CPU players.
- A restaurant design with numbered characters and a compact day/round/turn sign.
- Separate files for design, food content, mechanics, and styling.
| Area | Files | Count |
|---|---|---|
| Game logic | mechanics.js, cpu.js, config.js | 3 |
| Food content | content.js | 1 |
| Interface and styling | index.html, app.js, styles.css | 3 |
| Design documents | concept.md, rules.md, decisions.md | 3 |
| Tests | mechanics.test.cjs | 1 |
| Instructions | README.md | 1 |