The pitch
VybeKids is a voice powered coding playground for kids aged 6 to 14. You talk to it in plain English, it writes the code, and you watch your idea show up on the screen. Mac, Windows, and iPhone. Free to download.
Underneath it is a serious tool. It's a desktop app called VybeCoding that wraps Claude Code, Codex, and other AI coding agents in a terminal that's genuinely friendly to a beginner. VybeKids is the same engine in a kid shaped wrapper: bigger buttons, brighter colours, a parental PIN, an auto approve flow so a nine year old doesn't have to read a permissions prompt, and a stack of starter quests that turn an empty folder into a finished game.
Why I built it
My kids kept watching me work and asking what I was doing. The honest answer was that I was typing into a black rectangle and arguing with a robot. That's not a great pitch for a child. The interesting bit, the part where you ask for a thing and the thing appears, was buried under three layers of CLI ceremony.
So I built the layer that removes the ceremony. Voice in, code out, app on the screen. The robot still does the arguing. The child gets to be the director.
What it actually is, under the hood
The desktop app is Tauri. Rust on the back, TypeScript and React on the front, xterm.js for the terminal surface. A small Rust daemon called vybe-mux owns the PTY so sessions survive an app restart, which matters more than you'd think when a six year old closes a window mid build.
The mobile companion is a native iOS app (SwiftUI, Citadel for SSH) and a Kotlin Android app (Compose, SSHJ). They discover the desktop on the local network with Bonjour, then talk to a small axum HTTP server the desktop exposes. Phone snaps a photo, photo lands in the project folder, the agent picks it up, the agent uses it. That loop is the thing kids love most.
The marketing site at vybekids.com is a separate Next.js app with its own loud chunky design system. Tailwind, custom shadow tokens, hand picked colours called things like flamingo, sunshine, mint, and grape. The brand had to read as a toy, not as a developer tool, even though a developer tool is exactly what's running underneath.
The interesting problems
Three things ate most of the build time.
One. Auto approve. AI coding agents pause and ask permission constantly. An adult can read "Do you want to proceed?" and pick option two. A child cannot, will not, and shouldn't have to. I built a two signal detector in the renderer that watches for a permission prompt phrase plus numbered options before pressing Enter, with a startup grace period and a cooldown so it never fires on accidental text. Platform split on the key sequence because macOS and Windows TUIs behave differently. It lives in the frontend on purpose, because an earlier version that lived in the PTY reader thread stalled byte delivery and made Codex draw garbage on resize. Diagnosing that took a week. Moving the logic up one process boundary fixed it in an afternoon.
Two. Safety. Kids will type anything. They'll also let the agent type anything. The app must never, under any circumstance, delete a project folder. That sounds obvious until you notice that a normal AI agent will happily run rm -rf if you ask it nicely. So there's a hard rule in the codebase: no filesystem delete operations on user project directories, anywhere, ever. Any clear or delete control in the UI only touches session metadata. Labels say "Clear Sessions" not "Clear All" because a nine year old reads labels literally.
Three. The mobile to desktop contract. iOS, Android, and the desktop all share a JSON wire format, and renaming a single field on the desktop silently breaks decoding on the phone. Caught a few of those the hard way. The fix was boring and worth every minute: every response shape is now a named Rust struct with serialize derived, and a suite of contract tests pin the JSON literal. Rename a field, the desktop compiles fine, the test fails, the test message tells you to update the iOS and Android decoders in the same PR. The whole class of bug is gone.
What I learned
A friendly product is mostly the removal of small frictions, repeated a hundred times, in places nobody will ever notice. The voice button has to warm the mic before the user presses record, because a half second cold start feels like the app is broken. The terminal has to scroll smoothly while the model is streaming, because a stutter makes a child think it crashed. The wizard has to ask for a project name once, not three times. None of this is technically hard. All of it is the actual work.
The other lesson is that constraints help. Once I committed to "no dashes in any visible copy" as a brand rule, the writing got cleaner. Once I committed to "the desktop never deletes a user file", the architecture got simpler. Once I committed to "the daemon never runs renderer work, the renderer never runs PTY work", a whole category of timing bug evaporated. Picking a rule and holding it is cheaper than reasoning about every edge case from scratch.
Where it's going
Next is a quest library: short, structured projects with a clear win at the end. Build a pet that follows your mouse. Build a chat bot that knows your favourite jokes. Build a website for your hamster. Each quest is a folder of starter assets, a system prompt that biases the agent toward the right tools, and a finish line the kid can show a grown up.
After that, multi device sessions. Start a project on the iPad in the kitchen, finish it on the desktop in the bedroom, your friend joins from their phone. The session multiplexer was built for exactly this. The UI just hasn't caught up yet.
Try it
vybekids.com has the downloads. Mac, Windows, iPhone. It's free. If your kid breaks it in an interesting way I want to hear about it.