A problem worth solving
Most holiday programmes hand children a kit and a set of instructions. Follow the steps, get the result everyone else got, take it home.
We wanted to try the opposite. So the City Problem Solvers workshop opened with a question rather than a kit:
"What could make my city a little better?"
The answers were not abstract. Flooding after heavy rain. Traffic that does not move. Rubbish that blocks the drains. These are things children here actually see on the way to school — which is exactly why they were worth three days of work.
Day one: thinking like an engineer
The first morning had no robots in it at all.
It started with a blindfolded cup-stacking game. That sounds like an ice-breaker, and it is, but it is also the first real lesson: you cannot see the problem directly, so you have to work from feedback, adjust, and try again. That is debugging, before anyone has written a line of code.
Then the kits came out. First sketches on paper, first builds on the table, and the first cautious test drive — a robot following a black line across a practice mat, correcting itself at every corner.
Nothing about that first drive was polished. That is the point. The children saw immediately that a machine does exactly what you tell it, including the parts you got wrong.
Day two: what can AI actually help with?
Day two started with a question we think matters more than any tool: what is AI actually good for?
Not "AI is magic," and not "AI will do your homework." The session worked through real examples — some where AI genuinely helps, some where it does not — including a round of Future City Charades to get everyone arguing about which problems a machine could sensibly take on.
Only then did the children start designing. Each one used AI to help sketch out their own smart city: what the problem was, what their fix would do, and how it would work. They directed the tool rather than the other way round, which is the whole distinction we care about.
Day three: the robots take the city
On the last day the printed city rolled out down the length of the table — roads, parks, roundabouts, a river.
The code went up on the big screen, block by block, and one at a time the robots drove the streets their inventors had planned. Some worked first time. Most did not. The fixing was the interesting part: watch what the robot actually did, work out which instruction was wrong, change it, run it again.
By the end, every child had a robot driving a route they had programmed themselves, solving a problem they had chosen themselves.
What they walked out with
Each inventor wrote up their own project as a blog — the problem, the design, how it works, why it helps. In their own words, with their own artwork.
One built a city where robot drain-cleaners keep the water flowing so the streets do not flood. Another designed a snowy city that spots floods before they strike. A third took on traffic with flying cars and a fleet of smart drones.
You can read all three in the full workshop recap.
Why we build workshops this way
Three days is not long enough to teach a programming language. It is long enough to teach something more durable:
- Problems come before tools. The robot is not the point; the flooded street is the point.
- AI is something you direct. Children who have questioned where AI helps are far harder to impress with a confident wrong answer.
- Things break, and that is the lesson. Every robot misbehaved before it behaved. Fixing it is where the learning sits.
- Finishing matters. Writing it up turns a fun three days into something a child can show, explain, and be proud of.
That last one surprises parents most. The blogs are not a nice extra — being able to explain your own work is the skill that outlasts the kit.
Coming to the next one
Workshops run during the school holidays, with the same small groups as our regular classes — a maximum of 8, so every child gets real attention.
No experience is needed. The children who did this had never programmed a robot before the first morning.
