2. Patterns - NariShakti 2. Patterns | NariShakti Humane ClubMade in Humane Club

2. Patterns

Patterns Cover

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:

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:

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