Inspiration
I did not want to introduce children to AI through a lecture about what the technology is. I wanted them to experience what it means to create with it, and to notice who they become when a powerful tool is available to them.
There is an easy way for AI to weaken agency: the learner gives away the original idea, accepts the first output, and becomes a spectator. I wanted the opposite. Children should bring the impulse, make decisions, test the result, encounter bugs, change direction, and decide what is worth sharing.
That became Adventures in AI, a TechLabs course for learners aged 10 to 16, and TechLabs Studio, the platform that holds the course experience together.
What it does
TechLabs Studio is a bounded creation and sharing environment for young learners working with personal AI Buddies.
Each child enters through a fictional course identity rather than a personal email account. Learners shape how their AI Buddy should support them, then use conversation to turn an idea into a working browser-based creation. They test it, improve it, publish it intentionally, and share it with the course community. Other learners can open the creation, play it, and respond inside the course environment.
The platform connects several parts that usually live separately:
- fictional learner identities and code-based access;
- personal AI Buddy workflows;
- a course Studio with bounded chat and sharing;
- separate hosting for learner-created games;
- a catalogue where the group can find and play published work;
- a separate multiplayer path for creations that need it.
The separation matters. A learner device or AI Buddy should not need broad infrastructure credentials just to publish a game. Learner-created code should not run inside the Studio itself. Sharing should happen because the learner chose to share, not because every draft is public by default.
How we built it
The platform runs on Cloudflare. The Studio, game-serving origin, and multiplayer service are separated so each part has a narrower role and authority. The implementation uses TypeScript and Bun, Cloudflare Workers, D1 and R2-backed services, Durable Objects and WebSockets where required, Python components for bounded publishing workflows, and Playwright/browser tests for the learner journey.
The architecture was shaped around the real classroom path:
- A learner enters with a fictional Member Code.
- The learner connects a personal AI Buddy to TechLabs Studio through a scoped flow.
- The learner develops and tests a creation with the Buddy.
- Publishing produces a playable link without exposing infrastructure credentials.
- The learner shares the creation with the course group.
- Other learners open, play, and discuss it.
GPT-5.6, running through Hermes Agent, was the primary model I worked with for architecture, implementation, debugging, and test orchestration. Hermes provided the agent workflow, project context, and tool execution needed to work across the platform rather than treating each code change as an isolated prompt.
Codex in the ChatGPT app supported final validation and the deployment workflow across the classroom devices. I made the product, educational, safety, architecture, and deployment decisions, reviewed the generated work, and chose what entered the live course. TechLabs owns the project; I am its sole creator and developer.
Challenges we ran into
The hardest part was not generating a game. It was building a coherent system around AI-assisted creation for a real group of children.
Preserving the child’s creative role
An AI coding tool can produce something impressive very quickly. That speed can also erase the learner’s authorship if the system races ahead of the child’s idea. The Buddy and the course therefore frame AI as a collaborator that responds to the learner’s direction. The child remains responsible for the concept, the choices, the tests, and the decision to publish.
Giving useful capability without broad authority
The Buddy needs enough capability to help produce and publish a working creation, but it should not hold general deployment credentials. We separated identity, Studio access, game serving, and multiplayer responsibilities, then used scoped flows between them.
Running learner-created software safely
Children make unpredictable things. That is the point. It also means their generated games should not execute inside the same origin and authority boundary as the learner Studio. Separating game execution from the Studio reduced that risk and made the publishing path easier to reason about.
Making the classroom path work under real conditions
A system can pass a local test and still fail in a room full of learners using different devices. Student login, Buddy connection, long model responses, publishing, game links, and multiplayer all had to survive the actual course environment. Under deadline pressure, I repeatedly chose the smallest complete learner journey over unfinished administrative breadth.
Accomplishments that we're proud of
TechLabs Studio was used in a real Adventures in AI course, not only demonstrated as a concept. Learners created personal AI Buddies, built and debugged games, published playable links, explored one another’s work, and presented what they had made.
The result we care about is visible in their behavior. They were not watching an AI demonstration. They were making decisions, explaining their ideas, noticing limitations, and developing judgment about how to work with the technology.
What we learned
The children gave us the clearest evidence of what the course teaches.
One learner explained that a shorter, focused prompt was easier for the AI to understand, while a long and complicated prompt could introduce bugs and glitches. That is more important than producing a game in one minute. The learner was observing the system, forming a hypothesis, adjusting the instruction, and judging the result.
We also saw that bugs did not end the creative process. A moving character that could not be stopped became the next problem to investigate. A platforming test became a playable game. Another learner designed a 3D hotel simulation with rooms, check-ins, a budget, revenue, a restaurant, and a bar. The variety came from the children, not from a fixed lesson template.
Community changed the process too. When learners reached a dead end, they looked at what others were making, offered ideas, played one another’s games, and returned to their own work with new possibilities.
The technical lesson was equally clear: boundaries can create freedom. Fictional identities, scoped authority, explicit publishing, and separated game execution gave learners room to experiment without requiring unrestricted access.
What's next for TechLabs Studio: Adventures in AI
The next step is to deepen the course without turning it into a ranking system. We want better instructor feedback and curation, clearer learner progression, stronger review of Buddy behavior, and easier reuse across weekly courses and school settings.
We will continue testing the system with real learners while keeping identities fictional, authority narrow, and sharing intentional.
AI should not replace the child’s creative impulse. It should help the child bring that impulse into form.
Built With
- browser
- bun
- chatgpt
- cloudflare
- codex
- edtech
- gpt-5.6
- hermes
- openai
- playwright
- python
- r2
- typescript
- websockets
- workers
- wrangler
Log in or sign up for Devpost to join the conversation.