Teaching My Kids to Build With AI at Dusit Thani hotel buffet

So today I headed to the Dusit Thani for their hotel buffet. It’s quite an iconic building as you drive into downtown Abu Dhabi - one of those places I’ve always clocked and thought, “I need to go and try that.” Today was the day, and it was great. I think I arrived just as the bus tours staying there decided to descend on breakfast all at once, because I got put into the overflow space. But by 9:10 everyone had cleared out and there were about five people left. Unfortunate timing, but the food was good. Loads of extra chilli in my omelette, which is always a win.

But this week’s breakfast was different. Because I’m seeing how fast this stuff is changing - AI tooling, what’s possible, the speed at which you can go from idea to something real - and it’s great to talk about that in a business context, but I’m starting to realise something bigger. We don’t just need to teach the next generation about AI, or work alongside them with it. We need to watch how they’re going to use it. Because this generation has been raised with it. They don’t have any bias against using it. They don’t have the hesitation or the “should I really be using this?” guilt that a lot of us carry. They just expect it to work. They expect to be able to talk to a machine and have something happen. And that changes everything about how we should be thinking about what comes next.

So I set them up with the same AI development tooling I use in my actual job. Not a dumbed-down version. Not a kids’ app with guardrails and cartoon mascots. The real thing. The same tools that people are using right now in the market to build real products and real businesses.

Not ‘Simple’ Tools - Proper Builds

I know my kids’ friends already use a lot of these online tools - things like Base44 and various wrapper tools that sit on top of AI services. And they’re fine for what they are. If you want to build a funny website or knock something together quickly, they do the job. But I feel like that stuff is going to hit a point of restriction pretty fast. The abilities and expectations of even kids now are going to start expanding dramatically, and they’re going to outpace these types of tools very quickly. You hit a ceiling, you’re stuck, and you can’t do anything the platform didn’t anticipate you wanting to do.

So I’m talking about the full stack - Visual Studio Code, Claude, proper code environments, the lot. The same setup I sit down with when I’m building things professionally. Because when you give someone the proper tooling - even a kid - the ceiling disappears. The only limit becomes what you can imagine and describe clearly enough for the AI to help you build.

This was the first time I’d installed proper dev tools on a fresh machine for a non-developer. VS Code, Claude, authentication, spend controls, the lot. I’ll be honest - it was a lot more faff than I expected. Significantly more. Especially over hotel wifi. Downloads, installations, extensions, tokens, environment configs - it ate a good chunk of our first session just getting everything connected and running. I might do a video in the future about how to get all of this set up for non-developers, because the barrier to entry isn’t intelligence or creativity - it’s configuration. But once you’re past it, the playing field opens up in ways most people don’t realise.

Starting With Passion, Not Technology

Here’s the approach I walked them through, and it’s one I’d recommend to anyone - adult or child - who wants to build something meaningful with AI.

Don’t start with the technology. Start with what you care about. Start with passion. What are you genuinely interested in? What gets you fired up? What do you spend your free time thinking about or doing?

Just assume AI can do it by default.

From passion, move to personal problem. Within that thing you care about, what annoys you? What’s missing? What do you wish existed but doesn’t? That intersection - passion plus personal frustration - is where the best ideas live. Not in some theoretical market gap analysis. In your own lived experience.

Once they’d each landed on an area they cared about, we took the next step: ask the AI to generate 20 ideas in that space. Twenty business or product ideas around their personal problem.

Now, here’s the thing you need to understand about this step. The first batch of ideas from any AI are going to be generic. They’re going to be obvious. Some of them will be things that already exist. That’s absolutely fine. That’s expected. The point isn’t to take idea number seven and run with it. The point is to spark thinking. To see the landscape of what’s possible. To read through twenty ideas and go, “that one’s rubbish, and that one already exists, but actually... that one made me think of something else entirely.” The AI’s ideas are kindling, not the fire.

Testing Complexity - And Learning to Iterate

Then we took their first real idea - the one that felt exciting to them - and asked the AI about the complexity. What would it actually take to build this? What systems would need to connect? What data would you need? How many moving parts are we talking about?

And this is where the process got really interesting. I had them tell the AI about themselves - their age, their capability, their tech experience. Not because the AI needs to know for technical reasons, but because it changes how the AI communicates. It adjusts the complexity of its explanations. It suggests simpler approaches. It frames things in terms they can actually relate to and act on.

The first idea is almost always too complex. That’s not a failure - that’s the process working. Too many integrations. Too many external services. Too many things that need to happen before you can even see something on screen. So you iterate. You go back to the AI and say, “that’s too complex for where I am right now - what’s a simpler version of this? What could I build this week rather than this year?”

Keep generating. Keep refining. Keep pushing back and forth with the AI. “Is this simpler? Could I actually build this? What if we removed that feature and just focused on this core thing?” You do this until you land on something that feels right. Something that’s ambitious enough to be genuinely interesting - not a toy, not a tutorial exercise - but not so complex that you’ll abandon it by lunchtime because you can’t figure out how to connect to a payment gateway.

This iterative narrowing is a skill in itself. Most adults don’t do it well. They either aim too high and never ship, or aim too low and build something they’re not excited about. Finding that sweet spot - the idea that’s just challenging enough - is something worth practising regardless of your age.

Where Having a Guide Matters

This is where me being there made a real difference. Not because I was writing code for them - I wasn’t touching their keyboards. But because I understand integration complexity. I’ve spent years plugging systems together, wrestling with APIs, figuring out what’s realistic for a first build and what’s going to send you down a rabbit hole you won’t come back from.

When one of them landed on an idea that would have needed three external services, a database, and real-time data feeds, I could step in and say, “I love the ambition - genuinely. But let’s think about version one. What’s the smallest thing you could build that still proves the concept? What could we fake for now and make real later?”

That kind of guidance isn’t about limiting them. It’s about understanding the difference between “can’t be done” and “can’t be done yet.” It’s knowing that local storage can stand in for a database in a prototype. That a hardcoded list of sample data can stand in for an API call. That you can build something that looks and feels real without every piece of infrastructure being production-ready behind the scenes.

I know what it takes to plug a front end into a back end, to get authentication working, to handle edge cases in data. That experience meant I could steer them away from ideas that would have burned all our time on infrastructure and towards ideas where the AI could do the heavy lifting and they could focus on the thing that mattered: the experience they were trying to create.

They both found an idea they were excited about. That matters more than the idea itself. Because excitement is the fuel that gets you through the frustrating bits. And there are always frustrating bits.

Build the Prototype

Next step: build. And here’s where the process gets genuinely powerful.

I had them describe the problem clearly - in plain English, in their own words - to the AI. Not in technical language. Not trying to sound like a developer. Just: “here’s my problem, here’s what I want to build, here’s what I want it to do.” Clarity over jargon, every time.

Then - and this is a step most people skip, and it’s arguably the most important one in the entire process - I had them ask the AI to repeat back its understanding. “Before you build anything, tell me what you think I’m asking for.” Because if the AI has misunderstood what you’re trying to build, everything that follows is going to be wrong. You’ll get working code that solves the wrong problem. Validate alignment before a single line of code gets written. This applies whether you’re a kid at a breakfast table or a senior developer in a sprint planning meeting.

Once we were confident the AI understood the problem, we built the prototype. Right there at the breakfast table, on their laptops, with hotel wifi. The AI generated the code. They ran it. It didn’t work perfectly the first time - it never does. So they iterated. “The button’s in the wrong place.” “This page doesn’t link to that page.” “I want it to show the data differently.” Back and forth with the AI, adjusting the UI, tweaking the logic, refining the experience.

Where things needed a database, we used local storage instead - good enough for a prototype, easy to swap out later. Where things needed real external data, we faked the API responses - hardcoded some sample data that looked real enough to test the experience against. The point isn’t perfection. The point is momentum. Get something working. See it on screen. Click through it. Feel the dopamine hit of “I made this thing and it actually works.”

That feeling is rocket fuel for a kid. Honestly, it’s rocket fuel for anyone. There’s something fundamentally different about reading about AI versus sitting in front of something you built with AI twenty minutes ago. It stops being abstract. It becomes real. It becomes yours.

Thinking About Scale

One of them had built something around cycling. The prototype had 30 bikes in its sample data. It worked beautifully with 30 bikes. So I asked: “Right now you’ve got 30 bikes. What happens when it’s 1,000? What happens when it’s 10,000? Does your approach still work? Does the page still load fast? Can you still find what you’re looking for?”

That question opened up a whole new world. We started exploring Google search APIs - could you pull in real bike data from the web? We experimented with LLMs - could the AI help categorise and describe bikes automatically? Each of these is a rabbit hole in its own right, but the point wasn’t to master any of them. The point was to understand that they exist. To know that when you’re ready to go from 30 to 10,000, there are tools and services that can help you get there.

Understanding the difference between a demo and a product. Between sample data and real data. Between something that works on your laptop and something that works for a thousand users. These aren’t abstract concepts when you’re staring at something you built twenty minutes ago and asking, “how do I make this real?” They become tangible, practical, exciting questions rather than theoretical ones.

End of Session One

By the time breakfast was over and we hit the Claude Code AI limit - by the time the buffet staff had genuinely started clearing up around us - they each had three things:

1. A problem they genuinely cared about solving.

2. A working prototype they’d built themselves, running on their laptops.

3. A list of more complex next-step requirements for taking it from prototype to product.

Not bad for a buffet breakfast.

The Four-Breakfast Plan

Here’s where it gets ambitious. I’ve mapped out a plan across four breakfast sessions:

Session one (done): Ideation, setup, and prototype. Start with passion, narrow to a problem, build something that works. Get from zero to “I can see it on my screen and click through it.”

Session two: Integration. This is where it gets real. Connect actual APIs. Replace the fake data with real data sources. Start dealing with the messy, frustrating, educational reality of systems talking to each other. Authentication. Rate limits. Data formats that don’t quite match what you expected. This is where you learn what software development actually feels like.

Session three: Deployment or mobile app wrapping. Get it off localhost and into the world. Put it on a real URL that someone else can visit. Or wrap it as a mobile app they can install on their phone. Make it something they can pull out and show a friend. “Look what I built” hits different when it’s on your actual phone rather than running in a browser on your laptop.

Session four: Testing, feedback, and marketing. How do you know it works properly? What happens when someone uses it in a way you didn’t expect? Who’s going to use this? How do you find them? How do you tell them about it? This is where building a thing becomes building a business - even if it’s a tiny one.

The goal: take an idea from zero to a deployed, usable application within four breakfast mornings. Not four sprints. Not four weeks of evening work.

Four breakfasts.

Why This Matters

I spend a lot of time in this newsletter talking about how AI is reshaping business strategy, product development, and competitive advantage. I write about enterprise transformation and market dynamics and strategic positioning. But here’s what struck me sitting at that breakfast table, watching my kids argue with an AI about button placement: none of that matters as much as this.

The generation coming up behind us doesn’t need to be taught about AI as a concept. They don’t need lectures about how it’s going to change the world. They need to be handed the tools and shown how to build with them. The same tools the rest of us are using to build real things in the real world.

Because the gap between “I have an idea” and “I have a working product” has never been smaller. It’s never been more accessible. And the kids who learn that now - who internalise that building is something they can just do, over breakfast, with a laptop and the right tooling - they’re going to operate at a completely different level to the ones who are still being taught to write essays about what AI might do someday.

We’re not preparing them for a world where AI exists. We’re preparing them for a world where the ability to build with AI is as fundamental as literacy. Where “I had an idea” is immediately followed by “so I built it” rather than “but I don’t know how to code.”

Four breakfasts. That’s all it takes to go from “what if” to “here it is.”