She said she already knew patterns. She was right. But knowing a pattern and explaining why it exists are two different things.
She’d barely closed the construction game before she asked what was next.
What was coming after sequencing? What would the next game be about? She’d gone from reluctant participant on day one to someone already thinking about the series as a series.
I told her: patterns.
She didn’t even pause. “I already know patterns,” she said. “We do them in math all the time.”
She was right. So instead of explaining what a pattern is, I started somewhere else entirely with what she hadn’t yet asked.
Spotting a pattern is easy. Explaining one is harder.
Sabi had been recognising patterns long before this session. In leaves on our walks: Gulmohar leaves pair evenly along the stem while Jacaranda leaves have one extra at the tip, making them 2n and 2n+1. In barcodes at the supermarket, where the width and spacing of black bars encode numbers into a visual pattern any scanner can read. In music, where a melody repeats with small variations and your brain recognises it as the same song even when the key changes. In the Olympiad problems she’d been working through since she was 6 years. The kind that ask: what comes next? What’s the rule?
What she hadn’t done was ask the next question: why does this pattern exist, what causes it, and when does it break?
Spotting a pattern is the entry point. Understanding its structure is the thing.
I asked her: what’s the difference between a pattern you can predict and a pattern you can explain?
She thought about it. “Predicting is just… seeing what comes next. Explaining is knowing why.”
That’s exactly it. And explaining is harder.
We didn’t start with abstract number sequences. I didn’t have to look far for an example she already knew. When her baby sister Vasuda was born earlier this year, I did what I always do — I tracked everything. Feeds, sleep, diapers, tummy time, across twelve weeks and more than 3,000 rows of data. Sabi had watched me do this. She’d seen the charts on my laptop at the kitchen table, asked questions about the colours, noticed the lines going up and down.
What I’d found in that data was this: on evenings when Vasuda had two back-to-back feeds between 8pm and 10:30pm, her first sleep stretch that night was consistently 90 minutes longer. Every time. The pattern was so reliable that once I saw it in the data, I could predict a good night before it happened.
I asked Sabi: had she noticed that pattern?
She thought about it. “I remember you saying she’d had a good evening. And then she slept well.”
“Right. So you noticed it too — you just hadn’t looked at why.”
“Because she’d tanked up?”
“Exactly.”
That conversation opened something. A pattern isn’t just something that repeats — it’s a signal hiding inside noise. The data doesn’t create the pattern. The pattern was always there. The data just makes it visible.
This matters for computational thinking because computers deal with both kinds of patterns — the perfectly regular ones, like a number sequence with a strict mathematical rule, and the messier ones, like a baby’s feeding behaviour, where the signal is real but the noise is loud. Learning to distinguish between them, and to ask why a pattern exists rather than just noticing that it does, is where the real thinking begins.
Pattern recognition, I told her, is how intelligence gets efficient. It’s why an experienced analyst can look at a chart and immediately know where to investigate when a beginner just sees lines. It’s why a chess grandmaster sees the board differently from a beginner. And it’s how computers learn to recognise faces, filter spam, and generate music.
“So we’re going to build a game around it,” I said.
She didn’t need much convincing.
How she chose what to build
Day two, she sat down with her notebook already open.
“I want to do number patterns,” she said. “Like the Olympiad questions.”
She’d been doing mathematical pattern problems in competitions for a 3 years now (triangular numbers, letter sequences, skip patterns) and she knew exactly what made them interesting: the moment when you think you’ve found the rule, and then the sequence throws something unexpected at you.
More importantly she already knew what made them hard. The sequences that looked simple but weren’t. The ones where the gap between numbers wasn’t constant but where you had to find the rule governing the gaps themselves.
She wanted to build something that would challenge other kids the same way.
I didn’t redirect this one. I just asked her to write it down before we touched anything.
The design doc and the robot she invented
She sat with her notebook for twenty minutes. What came back was more sophisticated than day one in every dimension.
Three levels — Easy, Medium, Hard — each with five questions she had written herself from her Olympiad preparation. A fifteen-minute timer per level. Multiple choice with four options. Shuffled questions on every new game.
And then, buried in the instructions at the bottom: two robots competing against the player. Progress bars for the robots and the user. If either robot finished first, the game was over. The player lost.
She’d invented an opponent. Nobody told her to. It wasn’t in any brief I’d given her.
Here is exactly what she wrote:
Find the Pattern
Mission: You have to find the correct pattern / number in order to set a high score. You have to set a high score by solving all of these questions correctly. If you make a mistake, the game ends.
There are three levels. Level 1 — Easy. Level 2 — Medium. Level 3 — Hard.
Level 1 — Easy
1. What are the next numbers in this pattern? 1, 3, 6, 10, 15, ___, ___
2. What are the next numbers in this pattern? 1, 3, 5, 7, 9, ___, ___
3. What is the pattern? 2, 4, 6, 8, 10…
4. Which letter comes next? A, C, E, G, ___, ___
5. Which letter comes next? V, X, ___
Level 2 — Medium
1. What is the pattern? 1, 2, 5, 16, 64…
2. Which numbers come next? 1, 4, 10, 20, ___, ___
3. Which letter comes next? A, E, H, L, ___
4. What is the pattern? A, D, G, J…
5. What are the next colours in this pattern? Red, Yellow, Green, Blue, Orange, ___, ___
Level 3 — Hard
1. Which number comes next in this pattern? 1, 2, 5, 16, 64…
2. What letter comes next in this pattern? A, G, N, ___
3. What pattern can you see in this triangle? (Pascal's triangle — picture to be inserted)
4. What letters come next? AB, FG, KL, PQ, ___, ___
5. What comes next? 1, 5, 15, 35, ___, ___
Rules: If player gives wrong answer, game ends.
Instructions:
- Make this as a single browser HTML.
- There should be white buttons and the background should be black.
- The questions should be in MCQ format. There should be 4 options to choose from.
- There is a timer for 15 minutes on each level.
- Do not add/ modify/ or change the questions
- Once the game is over, show a big button called “Play Again”
- Make sure to shuffle the questions at each level.
- The levels should be clearly visible
- Once the game is over, the user should not be able to click any option.
- This game should be built for a mobile phone screen however, it should be usable on a laptop too.
- If the user makes a mistake, the game gets over
Look at the Level 3 questions. Triangular numbers, Pascal’s triangle, sequences where the rule governs the gaps between gaps. She wrote these from years of competition preparation. She knew exactly how hard to make them because she’d been stumped by them herself.
And she added robots. Not a leaderboard, not a score comparison — actual opponents with progress bars moving in real time, racing her to the finish.
Design → Build → Ship
With the design doc done, she opened ChatGPT. She was deliberate this time. She typed everything out carefully: every rule, visual requirement and constraint.
Here is roughly what she typed:
Make a pattern quiz game as a single HTML file
That’s it. Then she pasted the full design doc because all instructions were mentioned in the document itself.
The first output was good. Better than day one’s first attempt — and the reason was visible in the prompt itself. On day one she’d written a paragraph of tangled instructions that took twelve attempts to untangle. This time the prompt was one sentence. She’d moved all the thinking into the design doc and kept the prompt clean. She’d realised, somewhere between day one and day two, that the prompt isn’t where the thinking happens. The design doc is. The prompt is just the instruction to start.
Then she wanted to add emojis to the questions. Small change, she thought. One prompt.
The AI changed the questions.
Not the emojis, the questions themselves. It rewrote her carefully constructed Olympiad sequences, replacing them with simpler versions that bore no resemblance to what she’d written. The confetti also broke. Two things went wrong when she’d only asked to change one.
She was frustrated. Then she was curious.
She pulled the prompt apart. Separated the visual instructions from the content instructions. Specified explicitly: “Do not touch the questions. Only add emoji decorations around them.”
It worked.
This is what she told me afterwards: when you ask a computer to do something, you can’t jumble your words. There has to be a clear set of instructions for the computer and a clear set of rules for the user. If they’re mixed up, the computer gets confused. She’d figured this out herself, through the frustration of watching an AI misinterpret her own unclear thinking. She’ll carry this lesson into every build from here.

What this is actually building
The moment that stayed with me wasn’t the game.
It was what the emoji incident taught her.
She didn’t ask me what had happened. She pulled the prompt apart herself, separated the visual instructions from the content instructions, and added one line that hadn’t existed before: “Keep emojis only in the celebration screen, not inside the questions.”
That line came entirely from understanding, in that moment, exactly what had gone wrong and why. She didn’t just fix the problem. She wrote the rule that would prevent it happening again. The frustration was the lesson. The tool taught her something I couldn’t have taught directly.
She didn’t ask me what had happened. She pulled the prompt apart herself, separated the two, and added one line that hadn’t existed before: “Keep emojis only in the celebration screen, not inside the questions.”
That line came entirely from understanding, in that moment, exactly what had gone wrong and why. She didn’t just fix the problem. She wrote the rule that would prevent it happening again. The frustration was the lesson. The tool taught her something I couldn’t have taught directly.
The robots tell the same story from a different angle. Nobody suggested opponents with progress bars. She added them because she knew, from years of playing games, that losing to something feels different from running out of time. That’s empathy in design and it came from the same place as the separated instructions. Her own experience, turned into a deliberate decision.
Patterns is where she started surprising me. ⚡️
What’s next
The number puzzle game is sitting on her laptop, complete through all three levels. She made her friend play it over the weekend and watched carefully.
Two bugs surfaced immediately.
- The first: even when a wrong answer triggered “Game Over” on screen, the player could keep clicking options until they stumbled onto the right one. The game over screen was showing — but the game wasn’t actually over.
- The second: even when a robot crossed the finish line first, the game didn’t stop. The player could keep going, finish all the questions, and effectively pretend the loss hadn’t happened.
She hadn’t caught either of these herself. They only appeared when someone else played — someone who hadn’t designed the game and didn’t feel bound by how it was supposed to work.
She wants to fix both.
That’s a lesson we’ll come back to properly in week seven, when we get to debugging. But she’s already discovered the most important thing about bugs: they hide in the gap between how you intended something to work and how someone else actually uses it. You can’t find that gap by yourself. You need someone who doesn’t know the rules.
The Sherlock Holmes game is still in the backlog. Every session she asks and every session I say: not yet, one more tool first.
Next up is categorisation — how you group things changes what you can find, and what stays invisible. And the afternoon she spent reorganising her entire bookshelf by a system nobody else could understand, which turned out to be exactly the right place to start.
New here? Start with the series introduction. Parent’s Guide: Computational Thinking for Pre-Teens