There’s a genre of founder content that doesn’t apply to us. The one where someone quits their job, gets a MacBook, and ships a SaaS from a coffee shop in Lisbon. The 4-hour workweek, remixed for the AI era. Build fast, ship faster, iterate fastest.

We have a different constraint set. My co-founder is three, doesn’t nap anymore, and just learned that the letter combination S-T-O-P spells a word he can yell at maximum volume. My office is the kitchen counter (while my toddler snacks). My sprint window is the gap between bedtime and when I physically cannot stay awake.

Here’s the thing nobody tells you: those constraints aren’t a disadvantage. They’re a filter. They force you to build the right way.

The time budget (it’s enough)

A stay-at-home parent with one child, no naps, and no regular childcare has approximately this much daily availability for focused work:

• Before kid wakes up: 0–90 minutes (depends on your alarm discipline and their sleep schedule)

• During independent play: 15–45 minutes (fragmented, interruptible)

• After bedtime: 90–180 minutes (your only reliable block)

Total: 2–5 hours per day. But “hours” is misleading. Context-switching between parenting and deep work has a cognitive cost that research consistently pegs at 23 minutes to regain focus (Gloria Mark, UCI). So your 25-minute play break isn’t 25 productive minutes. It’s ramp-up time plus the shallow work you can likely get done in the remaining 2 minutes.

Your real number: 90–180 minutes of quality focus time per day. Some days less. Some days zero. Sick days, bad sleep nights, developmental leaps — these all eat into a budget that was already lean.

Here’s why that’s still enough: 90 minutes a day, compounded over a year, is 540 hours. A typical solo founder without children has 6–10 focused hours daily — but they also spend a lot of those hours on the wrong things. You can’t afford that luxury, which means every hour you spend is deliberate. Constraints create clarity.

540 hours is enough to write a book. Build a product line. Launch a newsletter. Establish a real revenue stream. That’s not just theory — I’ve done all of those in the last six months alone.

The childcare question

The obvious lever: hire childcare, buy more time. The honest challenge: childcare costs money you might not have yet.

Average US childcare in 2026: $24,243/year in DC, $12,000–$18,000 in most metros. Part-time (3 mornings a week) runs $500–$800/month. The Care.com 2026 Cost of Care Report found parents spend 20% of household income on childcare — nearly triple what HHS considers affordable.

The math: to justify $600/month from business revenue, you’d need roughly $9,000 in gross sales per year on Gumroad (after fees and processing). On a $29 product, that’s about 26 units per month.

Most digital products don’t hit that number in year one. So what do you do?

You bootstrap through the gap. You build the first product in those 90-minute windows. You ship it before the childcare math makes sense. And then, if you want to, you use early revenue to buy back time incrementally — a mother’s helper two mornings a week, a swap with another parent, a few hours of drop-in care. The gap is real, but it’s temporary. The product you build during the gap is what closes it.

Why “hustle harder” is the wrong advice

The “build while your kids sleep” advice works for a sprint — ship something in two weeks of late nights. Late nights don’t work as a lifestyle. Chronic sleep deprivation degrades decision-making to a measurable degree — 17–19 hours without sleep equals a BAC of 0.05% (Williamson & Feyer, 2000). Impaired founders ship products with bugs, copy with typos, and pricing mistakes they don’t catch.

The smarter move: protect your 90-minute window like it’s sacred. Don’t expand your hours. Expand what you accomplish in them with clear goals and strict scope. The constraint isn’t your enemy — the temptation to fight it is.

The business model that fits

If your daily focus window is 2 hours, you need a model that matches. Some models fight your schedule:

• Client services (freelance, consulting): Requires synchronous availability and responsive communication. Incompatible with all-day childrearing and unpredictable days.

• SaaS with support obligations: Uptime, bug reports, feature requests — all on someone else’s timeline.

• Content that requires daily posting: Unless you’re disciplined with batching in advance, the algorithm rewards consistency your schedule can’t guarantee.

Some models work with it:

• Digital products with zero marginal cost: Ebooks, templates, courses, prompt packs. Build once, sell forever. No inventory, no fulfillment, no schedule.

• Async content: Newsletters on a weekly cadence you control. Not daily — weekly.

• Tools with minimal support: Open-source with community maintenance. Paid add-ons on platforms that handle distribution.

The operating principle: your work and your revenue need to be decoupled in time. You do the work at 10pm. Someone buys at 3pm the next day while you’re at the playground. If the business requires you to be present when the customer is, pick a different model.

The identity evolution

This is the part that has nothing to do with math and everything to do with whether you keep going.

You used to be an engineer. Or a designer. Or a PM. You had a title, a team, a salary. People knew what you did.

Now you’re someone who makes peanut butter sandwiches with the crusts cut off and occasionally opens a laptop after 8pm. The temptation is to prove you still have it — over-engineer a SaaS, build something complex, show the market you haven’t gone soft.

The ego project is the most expensive mistake a parent founder can make, because it consumes your scarcest resource — focus time — on something the market didn’t ask for.

The businesses that work for parents are usually satisfyingly simple. An ebook, not a platform. A template, not a framework. A curated resource, not a custom tool. Simple ships faster. Simple needs less maintenance. Simple survives the weeks when your kid has a stomach bug and you haven’t opened your laptop in five days.

And here’s what the identity crisis misses: you didn’t lose your skills. You gained a constraint that makes you a sharper builder. The person who can ship a product in 90-minute increments between bedtime and exhaustion is a more disciplined operator than someone with unlimited runway and no urgency.

The unfair advantages

The constraints are real. They’re also an edge.

You have no exit pressure. No investors, no runway, no board meetings. If your product makes $500/month and that covers groceries, it’s working. You can iterate for years at a pace that would get a VC-backed founder fired. Time horizon is your moat.

You’re battle-tested. Project management with a toddler is project management under uncertainty — no sprint planning, no tickets, and a stakeholder who changes requirements every 30 seconds. If you can ship under those conditions, you can ship under any conditions.

Your story resonates. The market is full of polished founders with perfect launches. A parent who built something real in the margins of a chaotic life? That’s a story people root for, share, and buy from.

The bottom line

Building a business as a stay-at-home parent is slower than the inspiration posts suggest. The math is real. The time is limited.

But 540 hours a year, spent deliberately, compounds into something significant. Not a startup. Not a unicorn. A business that works on your terms, at your pace, that doesn’t require you to choose between building something and being present for the person you’re building it for.

Subscribe now

The other day, he stopped eating them and started lining them up instead. Yellow ones here. Orange ones there. Red. Then the weird reddish-brown ones that look like they can’t decide what they are. He made a rainbow across the counter, completely unprompted.

A few days later, we sat down and built a sorting game on the computer. Emoji animals and emoji vehicles appear on screen, and you drag them to either a garage or a grassy field. He got it instantly — he’d already done the hard cognitive work of sorting with tomatoes, and many other things before that. The screen version was just a new surface for something he already understood.

Physical first, digital second; that way, they’ve something to relate the latter to.

Why Physical Matters

Young kids learn through their bodies first.

Piaget’s stages of cognitive development place children under seven in the preoperational stage, where thinking is tied to concrete, tangible experience. Abstract reasoning — the kind screens demand — doesn’t fully develop until much later. Children at this age think by doing. They need to touch, move, sort, stack, and break things to build mental models.

Montessori figured this out over a century ago: concrete before abstract. Let children manipulate real objects until the concept lives in their hands, then introduce the symbolic version. Research in embodied cognition backs this up — physical manipulation creates sensorimotor traces that anchor learning in ways that flat visual input alone doesn’t.

When my son sorted tomatoes by color, he was making decisions. This one’s orange, not red. This one’s in between — where does it go? That’s where the cognitive exercise is occurring. The sorting game on the computer just gave him a new context to exercise the same skill.

Screens are visual and auditory only. That’s fine for adults who have decades of physical experience to draw on. But for a three-year-old still building those mental models, starting on a screen is like reading the manual before seeing the tool. You’ve got a thin concept of it without real texture or heft.

I’m not anti-screen. My son learned to read with an iPad app, and we build browser games together for fun. But I’ve noticed a clear pattern: when we do a physical version of a concept first, the digital version lands faster, sticks better, and is way more fun for both of us.

The Pattern

1. Physical exploration. Hands-on, no screens. The concept shows up through play.

2. Connection. Talk about what just happened. “You sorted the tomatoes by color — what other ways could we sort them?”

3. Digital creation. Build something on the computer that uses the same concept. “Want to make a sorting game?”

4. Play. Actually play with what you built. The kid sees their physical understanding reflected on screen.

The bridge between steps 2 and 3 is where the magic happens. When my son sits down at the computer after sorting tomatoes, he’s not encountering “sorting” for the first time. He’s recognizing it. “Oh, this is like the tomatoes!” The concept transfers.

Real Examples

Here’s how this plays out with different computational thinking concepts:

Sequencing

Physical: Steps for washing the car. First you rinse it. Then soap. Then scrub. Then rinse again. Order matters — soap without water does nothing.

Digital: We made a car wash game where tools appear on screen (water, soap, sponge) and you click them in the right order to wash the car. He already knew the sequence from doing it real life. The game just let him practice it on repeat without the running water.

Patterns

Physical: I point these out to him everywhere. Stripes on a crosswalk. Alternating fence posts. The rhythm of windshield wipers. Once you start noticing patterns, a three-year-old will not let you stop.

Digital: We made a pattern prediction game using images of his favorite airplanes. A sequence appears — Airbus Beluga, Super Guppy, Airbus Beluga, Super Guppy — and he picks what comes next. He was already pattern-hunting in the wild, the airplane game just made it even more interesting.

Loops

Physical: Cleaning up his toys. Pick up a block, put it in the bin. Pick up a block, put it in the bin. Same action, repeated until done. That’s a loop.

Digital: A maze game where you move a character forward by repeatedly pressing the arrow key. The loop concept already had a physical anchor from cleanup time – continue until complete.

Cause and Effect

Physical: Matchbox cars on a ramp. Place the car at the top, let go, it rolls down. Line up wood blocks like dominoes and knock them over. Every action has a visible, immediate consequence.

Digital: This is every game we’ve ever made. Click a button, something happens. Change a number, something changes. But the ramps and the blocks came first, and that’s why cause-and-effect on screen already makes sense to him.

What the Research Actually Says

Most developer parents skip straight to the screen — we live there, we can explain sorting abstractly, why bother with tomatoes? Because we’re not three. We have decades of physical experience backing every abstract concept we encounter. A toddler doesn’t have that yet. And the research explains why it matters.

Piaget’s concrete operational framework established that children under seven learn through direct manipulation of their environment — they literally cannot reason abstractly yet. Their thinking is bound to what they can see and touch.

Research on embodied cognition in children shows that physical manipulation creates sensorimotor memory traces that persist and transfer to new contexts. When a child sorts objects with their hands, they’re not just learning “sorting” — they’re building neural pathways that activate again when they encounter sorting in a different form.

A 2017 study on embodied math learning found that physical manipulation of objects before abstract representation improved both understanding and transfer — but only when the physical activity was directly connected to the concept. Random hands-on play didn’t help. Intentional physical exploration of the same idea they’d later encounter digitally did.

This is why the pattern matters. It’s not “play outside then do screen time.” It’s “explore this specific concept physically, then build this specific concept digitally.” The connection between the two is everything.

The Permission to Be Low-Tech

There’s a weird pressure in the developer parent community to start kids on technology as early as possible. As if your professional identity depends on your toddler being tech-forward.

Your three-year-old sorting cherry tomatoes on a cutting board isn’t falling behind, they’re building the cognitive scaffolding that will make every future digital experience meaningful instead of superficial.

No need to rush past the physical parts. The screens will be there later, but the tomatoes won’t keep.

This essay is part of the thinking behind 12 Weeks of Tech Projects to Build With Your Kid — a hands-on curriculum for ages 2-6 that pairs physical activities with AI-assisted game building. No screens required for most of it.

He stacked two triangular prisms together and ran a matchbox car down the slope. A ramp.

Then he added a flat block at the top. Now the car could drive up the ramp onto a platform. The ramp wasn’t a ramp anymore — it was a driveway.

Then he added a gantry over the platform. Declared the whole thing a race course. Started lining up cars at the top.

He didn’t sit down and think “I’m going to build a race course.” He built a ramp, and the ramp told him what it wanted to be next.

The Bricoleur

In 1962, anthropologist Claude Lévi-Strauss described two fundamentally different ways humans create things. The engineer starts with a plan — a blueprint, a specification, a clear picture of the end goal — and then acquires the exact materials needed to execute it. The bricoleur starts with whatever’s at hand and builds by rearranging, adapting, and responding to what emerges.

Lévi-Strauss wasn’t ranking them. He was arguing they’re equally sophisticated ways of thinking. But if you’ve spent any time in schools or workplaces, you know which one gets all the respect.

Almost thirty years later, MIT researchers Sherry Turkle and Seymour Papert observed the same split in how children learn to program. Some kids planned their program top-down: outline the structure, define the functions, then fill in the details. Others — the bricoleurs — came up with a set of instructions, ran it, reacted to what happened, adjusted, ran it again. They were in conversation with the material.

The planners’ result wasn’t better. It was just more legible to teachers who’d been trained to value planning. Turkle and Papert called this bias a failure of “epistemological pluralism” — a fancy way of saying we only recognize one style of thinking as real thinking.

My three-year-old doesn’t know any of this. He just builds the way that feels natural, which happens to be the way Lévi-Strauss described, Turkle and Papert validated, and every maker space on earth now tries to teach back to adults.

What the Blocks Are Saying

Here’s the thing about the race course: each step made sense only in context of the step before it.

The platform made sense because the ramp existed. The gantry made sense because the platform existed. If you’d asked my son at the beginning “what are you building?” he would have said “a ramp” — because that’s all it was. The race course didn’t exist yet. It couldn’t exist yet. It emerged from the building.

This is what Papert meant when he described learning as a conversation between the builder and the thing being built. The blocks aren’t passive raw materials. They’re participants. Every time my son placed one, the structure changed — and the changed structure suggested new possibilities. The ramp became an entryway the moment the platform appeared beside it. The context shifted.

Mitchel Resnick, Papert’s student at MIT and the creator of Scratch, later formalized this as the Creative Learning Spiral: imagine, create, play, share, reflect, imagine again. It’s the cycle that drives kindergarten — and, he argues in Lifelong Kindergarten, it’s how the most creative work happens at every age. We just stop calling it learning and start calling it “iterative design” or “rapid prototyping” somewhere around middle school.

What We Train Out of Them

Every formal education system I’ve encountered — and I went through a lot of them to earn my Masters — eventually teaches children to plan before they build. Outline before you write. Spec before you code. Know what you’re making before you start making it.

This is useful. I’m not arguing against blueprints. If you’re building a bridge, please have a blueprint.

But there’s a cost to making planning the only acceptable mode. When “what are you building?” always requires a confident answer before you’re allowed to pick up the materials, you lose something. You lose the willingness to start without knowing where you’ll end up. You lose the ability to let the work talk back to you. You lose the ramp that becomes a race course.

Turkle and Papert saw this concretely: children who naturally built in the bricoleur style were marked down, redirected, told to “plan it out first.” Not because their programs didn’t work — they worked fine — but because the process looked wrong to adults who’d been trained in the engineering style.

Papert spent his career pushing back on this. His argument wasn’t that planning is bad. It was that we systematically undervalue building-as-thinking. When a kid stacks blocks and discovers something he didn’t intend, that’s not a failure of planning. That’s cognition. That’s how humans have made things for most of our history. The blueprint is the newcomer.

The Feedback Loop

What makes my son’s block play look like play and a designer’s prototype sprint look like work? (A paycheck?)

Build something small. Look at what you built. Respond to what you see. Build the next thing. The feedback loop is the same whether you’re three years old with wooden blocks or thirty years old with a Figma prototype.

The race course emerged from forty-five seconds of iterative building. Ramp → platform → gantry → “it’s a race course!” Each cycle took maybe ten seconds. No hesitation. No “is this good enough to show someone?” Just build, observe, respond.

This is the loop I try to protect. Not because I want to raise a kid who never plans — he’ll learn that skill, and it’s a good one. But because the instinct to start building and let the thing tell you what it wants to be is rare and valuable and very, very easy to train out of someone.

Try This

Next time your kid is building something — blocks, LEGO, a pillow fort, a drawing — resist the urge to ask “what are you making?” at the beginning.

Just watch.

Watch how each piece responds to the last. Watch the project change identity midstream. Watch a tower become a bridge become a house become a rocket ship. That’s not indecision. That’s a conversation between a builder and a material, playing out in real time.

That’s the feedback loop that drives all creative work. Your kid just hasn’t learned to be self-conscious about it yet.

Protect that.

This essay is part of the thinking behind 12 Weeks of Tech Projects to Build With Your Kid — a curriculum designed around exploration-first learning for ages 2-6.

References

• Lévi-Strauss, C. (1962). The Savage Mind. University of Chicago Press.

• Turkle, S. & Papert, S. (1990). “Epistemological Pluralism: Styles and Voices within the Computer Culture.” Signs, 16(1), 128-157.

• Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. Basic Books.

• Resnick, M. (2017). Lifelong Kindergarten: Cultivating Creativity through Projects, Passion, Peers, and Play. MIT Press.

What we didn’t know: Cocomelon switches scenes every one to two seconds. That’s not an accident. It’s engineered — focus-grouped, A/B-tested, optimized for one metric: watch time. The rapid cuts trigger an orienting response — the involuntary reflex your brain has to novel visual stimuli. Every cut is a tiny dopamine hit. Your toddler isn’t watching. They’re being held.

The first time we said “no more Cocomelon,” our son had a meltdown. Not a tantrum — a withdrawal. Screaming, inconsolable. That convinced us.

We went cold turkey. And here’s the thing: he’s fine. He’s on screens plenty now — building games, typing in his tiny-terminal, using apps we chose deliberately. When we say “okay, time to go outside,” he goes. No meltdown. No negotiation. The difference isn’t less screen time. It’s different screen time.

That experience is what led me to the only framework I’ve found that actually helps.

The Spectrum

Every interaction your kid has with technology falls somewhere on a line. On one end: pure consumption. On the other: pure creation.

Consumer end → Watching YouTube, streaming shows, scrolling. The screen asks nothing of your child except their eyeballs and attention.

Creator end → Designing a game, directing what gets built, making decisions, giving feedback, iterating. The screen doesn’t work without your child’s input.

Most things fall somewhere in between. Minecraft creative mode is further right than watching Minecraft YouTube. Drawing on an iPad is further right than scrolling through a feed. Same device, wildly different cognitive engagement.

The framework is simple: instead of “less screen time,” aim to shift right on the spectrum. That you can actually do something with.

The Research Backs This Up

This isn’t just a nice mental model. The science increasingly distinguishes between passive and active screen engagement — and finds they have very different effects on developing brains.

Michaeleen Doucleff’s Dopamine Kids (2026) makes the neuroscience explicit: dopamine doesn’t give pleasure — it makes you want. Screens optimized for engagement create wanting loops, not satisfaction. Your kid isn’t enjoying the content. They’re trapped in a craving cycle. Doucleff’s diagnosis is exactly right. But here’s where I diverge: the prescription isn’t “fewer screens.” It’s “different screens.” A terminal where your kid types commands and a feed that auto-plays the next video trigger completely different dopamine profiles — even though both involve a glowing rectangle.

Lillard & Peterson (2011) randomly assigned 4-year-olds to watch either a fast-paced cartoon (SpongeBob), an educational show, or draw with crayons for nine minutes. The fast-paced group performed significantly worse on executive function tests immediately afterward — self-regulation, working memory, the cognitive skills that let kids focus and make decisions. Nine minutes.

Cocomelon is faster-paced than SpongeBob.

Radesky & Christakis (2016) at the University of Michigan and Seattle Children’s Research Institute reviewed the evidence on screen time and early childhood development. Their key finding: it’s not the screen itself that matters, it’s the nature of the interaction. Passive viewing correlates with attention problems and language delays. Interactive, co-viewed media doesn’t show the same pattern — and in some cases shows benefits.

A 2021 Frontiers in Education study on passive vs. active screen time and phonological memory in young children found significant differences: passive screen time was associated with lower cognitive performance, while active screen time showed no such effect. Same screens. Different engagement. Different outcomes.

The Australian Government’s original screen time guidelines (2011) recommended zero screen time under 2, based on the assumption that all screen activities are “physically and cognitively sedentary.” Subsequent research has challenged this — showing that interactive media can support cognitive development in ways passive viewing doesn’t. The blanket timer approach conflates two fundamentally different experiences.

This is why “is Cocomelon bad?” and “is Minecraft bad?” are the wrong questions. The right question is: what is my kid doing? Are they making decisions, or just receiving stimulation?

The Cocomelon Test

Here’s a quick diagnostic I use now when evaluating any screen activity:

Can my kid walk away from it easily?

This sounds simple but it’s surprisingly revealing. When my son was watching Cocomelon, turning it off triggered a crisis. That’s the hallmark of a passive dopamine loop — the content does the work of engagement, and removing it feels like withdrawal.

When he’s building a game with me, or playing in his terminal, or drawing on the iPad — and I say “okay, time for dinner” — he might grumble, but he transitions. Because he was driving the experience. He was the active agent. Stopping doesn’t feel like something being taken away. It feels like pausing something he can come back to.

If your kid loses it every time you turn off a specific app or show, that’s a signal. Not that screens are bad, but that this particular screen experience is in the passive consumption zone.

Why “Set a Timer” Doesn’t Work

Most screen time advice boils down to: pick a number of minutes, set a timer, feel responsible. The AAP says one hour for ages 2-5. The WHO says less.

The problem is that timers treat all screen time as equal. Thirty minutes of building a game and thirty minutes of watching someone else play a game register the same on the clock, but they are fundamentally different experiences for your kid’s brain. One is creative work that happens to involve a screen. The other is television with a touchscreen.

When you feel guilty about your kid’s screen time, check the spectrum position before checking the clock. If they’re actively creating — making choices, giving instructions, iterating on ideas — the guilt is probably misplaced. If they’re slack-jawed and glazed, that’s your signal to redirect, not just restrict.

Shift Right

Here’s how this works in daily life:

Audit activities, not minutes. List every tech thing your kid did this week. Place each one on the spectrum. Look at the ratio. Most unsupervised screen time lands on the consumer end. That’s a design insight.

Choose tools that require input. Apps and activities that don’t work without your kid’s participation naturally land further right. A drawing app is better than a video player. Building a game together is better than both.

Be the co-pilot, not the bouncer. The guilt-driven approach is restriction: set limits, enforce them. The design-driven approach is redirection: what if screen time was something you did together, where your kid steered?

Name what’s happening. Kids can learn the difference. “Right now you’re watching. Want to make something instead?” Over time, they start to prefer creation — because it’s genuinely more rewarding than consumption when you give them the option.

What Changed for Us

After we cut Cocomelon, we didn’t go anti-screen. We went pro-creation. My son practiced his phonics with YouTube videos, his critical thinking skills with GCompris games. He now builds browser games with me. He draws on the iPad and explains what he’s doing.

Is it screen time? Yes. Does it look anything like that fourteen-month-old, glued in place, watching highly-saturated flashing picture nonsense for the fortieth consecutive minute? Not even close.

The device is neutral. A screen showing Cocomelon and a screen showing your kid’s own game are the same hardware doing completely different things to their brain. One is engineered to hold attention. The other develops it.

You don’t need less screen time. You need better screen time. And now you have a framework to tell the difference.

If you want structured activities that live on the creator end of the spectrum, that’s exactly what I built: 12 Weeks of Tech Projects to Build With Your Kid — 60 activities for ages 2-6, mostly unplugged, designed around exploration-first learning.

References

• Lillard, A.S. & Peterson, J. (2011). “The immediate impact of different types of television on young children’s executive function.” Pediatrics, 128(4), 644-649.

• Radesky, J.S. & Christakis, D.A. (2016). “Increased Screen Time: Implications for Early Childhood Development and Behavior.” Pediatric Clinics of North America, 63(5), 827-839.

• Kostyrka-Allchorne, K., Cooper, N.R. & Simpson, A. (2021). “Short- and Long-Term Effects of Passive and Active Screen Time on Young Children’s Phonological Memory.” Frontiers in Education, 6, 600687.

• Sweetser, P., Johnson, D., Ozdowska, A. & Wyeth, P. (2012). “Active versus Passive Screen Time for Young Children.” Australasian Journal of Early Childhood, 37(4), 94-98.

I’ve been a developer for over a decade — web apps, APIs, infrastructure — but game dev always felt like a different discipline. Engines, physics libraries, sprite sheets. Then my three-year-old said “make me a game where a red car goes fast” and I opened Claude instead of Unity.

We made it. It was playable. He loved it. We’ve built dozens since.

Here’s everything I’ve learned about the process.

What You Actually Need

An AI chatbot. Claude, ChatGPT, Gemini — any of the major ones. The technique is the same across all of them.

A web browser. That’s it. We build simple HTML/CSS/JavaScript games that run in a browser tab. Completely sufficient for young kids. No installs. No build tools. No dependencies.

A kid with opinions. (This is the easy part.)

You do NOT need game development experience, knowledge of any game framework, art skills, sound design skills, or a CS degree (though it helps for debugging).

The Basic Flow

Here’s how a typical session goes in our house:

Step 1: The kid has an idea. “I want a game where a delivery truck drives through a maze.”

Step 2: You help translate it into a prompt. “Create a simple HTML game where the player drives a delivery truck through a maze using arrow keys. There are houses along the route — when the truck reaches a house, it delivers a package and the house lights up. Add a counter for deliveries completed. Keep it simple and colorful, suitable for a 3-year-old.”

Step 3: The AI generates code. You get back a complete HTML file with embedded CSS and JavaScript. Save it as .html, open it in your browser.

Step 4: The kid reacts. “Make the truck yellow.” “Add more houses.” “I want a warehouse where you pick up the packages first.”

Step 5: You iterate. Feed the feedback back to the AI. “Change the truck color to yellow. Add a warehouse at the start where the truck loads packages before delivering. Add more houses to the route.”

Step 6: Repeat steps 4-5 until the kid is satisfied or hungry.

That’s the entire game development cycle. Your kid’s imagination, an AI that writes code faster than you can explain what you want, and a browser.

Prompting Tips (The Practical Stuff)

After building a lot of these, here’s what works:

Start way simpler than you think.

Your first prompt should describe a game that a first-year CS student could build. One mechanic. One interaction. One thing on screen. You can always add complexity later, but starting complex usually produces buggy, tangled code that’s hard to iterate on.

Good first prompt: “Make an HTML game where a red circle follows the mouse cursor and collects yellow stars that appear randomly.”

Too ambitious first prompt: “Make a 2D platformer with multiple levels, power-ups, enemies with AI pathing, and a save system.”

Specify the audience.

Always mention that this is for a young child. It changes the AI’s output in useful ways: bigger click targets, brighter colors, simpler controls, more forgiving collision detection.

Ask for everything in one file.

“Put all HTML, CSS, and JavaScript in a single HTML file.” This makes it trivial to save and run. No build step, no dependencies, no module imports that break.

Request mobile/touch support.

“Make it work with both mouse/keyboard and touch.” Toddlers are surprisingly good with touchscreens, and this means the game works on your phone or tablet too.

When things break (and they will):

Copy the error from the browser console and paste it directly to the AI. “When I click the truck, I get this error in the console: [error]. Fix it.” Or if there’s no error, describe it: “When I press the down arrow, the page moves instead of the truck.” AI is excellent at debugging its own code.

What Your Kid Actually Learns

Here’s the part that surprised me: building games this way is sneakily educational, even though it feels like pure play.

Decision-making. Every feature request is a design decision. “Should the truck be fast or slow?” “What happens when you crash?” Your kid is learning to think about cause and effect in a system.

Iteration. The game is never right on the first try. Your kid learns that making things is a process of attempt → evaluate → adjust. That’s the most important meta-skill in all of technology.

Systems thinking. “When I added the dinosaur, the truck stopped working.” Things are connected. Changes have consequences. Welcome to software.

Creative expression. Your kid’s game is their game. Not a game they downloaded. Not a game someone else designed. It has their ideas, their aesthetics, their dinosaur-on-a-garbage-truck vision. That ownership compounds interest.

Common Pitfalls

Don’t optimize too early. Your kid doesn’t care about code quality. They care about whether the dinosaur is big enough. Ship the feature, clean up later (or don’t — these are throwaway games).

Don’t take over. It’s tempting to start adding your own ideas. “What if we add a leaderboard? What about particle effects?” Let your kid drive. Your job is to translate their ideas into prompts, not to impose your own.

Don’t expect polish. AI-generated games look like AI-generated games. They’re functional and fun, but they won’t win any design awards. That’s fine. Your kid genuinely does not care that the truck is a rectangle with two circles for wheels.

Don’t make it a lesson. The moment you say “this is teaching you about algorithms,” the magic dies. Just build. The learning happens in the background.

One More Thing

The games we build might be objectively terrible. The collision detection is approximate. The graphics are basic shapes. The physics are suggestions at best. My son’s current favorite is a car wash game – you literally wash a car. Click on water, click the car. Click on soap, click the car. Some elements overlap others and there’s a bug when you click on the sponge too early – but it’s fine. It works well enough and he’s played it about a hundred times already.

He made it. That’s why.

You don’t need game dev experience to give your kid that feeling. You need an AI, a browser, and the willingness to build a really, really bad game about garbage trucks.

It just might be the best thing you ship all year.

I know that sounds ridiculous. Your kid can’t read. They put stickers on the dog. They had a meltdown yesterday because their banana broke in half. Computer science?

Yeah. Computer science.

Not the “writing Python” kind. The thinking kind. The patterns and problem-solving strategies that underpin all of computing — and, conveniently, also underpin being a functional human. You practice them with your kid every single day. You just don’t call them that.

1. Sorting Laundry → Pattern Recognition & Classification

“Can you put all the socks in this pile?”

Congratulations, you just taught categorization. Your toddler looked at a heap of mixed objects, identified a shared attribute (sock-ness), and grouped items accordingly. That’s pattern recognition and classification — foundational concepts in computer science.

My son’s current favorite version of this: sorting cars by color. Red cars here, blue cars there. Sometimes he invents his own categories. “These are the fast ones.” By what criteria? “They look fast.” Hard to argue with that methodology.

The computational thinking is in the sorting itself — the act of looking at a set of things, defining a rule, and applying it consistently. That’s what databases do. That’s what machine learning does at scale. Your kid is doing it with socks.

Level up: Let your kid invent the categories. “How should we sort these?” gives them practice defining the classification rules, not just applying yours. That’s a step closer to algorithm design.

2. Following a Recipe → Sequencing & Algorithms

“First we put in the flour. Then the eggs. Then we stir.”

That’s an algorithm. A set of sequential instructions that produce a specific output. Your toddler is learning that order matters — that putting eggs in before flour produces a different result than the reverse. (A messier result, usually, in our kitchen.)

Every time you walk your kid through a sequence — getting dressed (underwear before pants, the eternal lesson), brushing teeth, making a sandwich — you’re teaching them sequential thinking. Step 1, then step 2, then step 3.

My son narrates sequences back to me. “First we put on shoes. Then we go outside. Then we walk to the park.” He’s writing pseudocode and he can barely spell his own name.

Level up: Introduce conditionals. “If it’s raining, we need boots. If it’s sunny, we need sandals.” Now you’re teaching if/else logic with weather and shoes.

3. “Try Again” → Debugging & Iteration

Your toddler is building a block tower. It falls. “Try again!” you say.

But here’s the thing — you don’t just say “try again.” You say “why did it fall?” Maybe the base was too small. Maybe he put the big block on top of the small block. Maybe he bumped the table.

That’s debugging. Identify the failure → hypothesize the cause → try a fix → test.

This is honestly the computational thinking concept that toddlers practice most, because toddlers fail at things constantly. Every single day is a gauntlet of attempts, failures, adjustments, and retries. Pouring water, climbing, puzzles, zippers — it’s all debugging.

The parent’s role here is critical: resist the urge to just fix it for them. (It’s very hard, I know.) I see the tower wobbling before he puts the last block on, and yet, I sit still and watch it fall. Then I ask: “What happened? What could you do differently?” Sometimes he has an idea. Sometimes he says “I don’t know” and I offer one suggestion. Sometimes he just knocks everything down and walks away, which is also a valid approach to debugging in my professional experience.

Level up: When something goes wrong, externalize the process. “Let’s figure out what happened. Let’s try something different. Did that work better?” You’re teaching the debug loop explicitly.

4. “What If?” → Abstraction & Hypothetical Thinking

“What if the car could fly?”

“What if we built a really, really big tower?”

“What if we had dessert before dinner?”

Every toddler lives in a constant state of “what if.” And “what if” is the engine of computational thinking — it’s abstraction. Taking a concrete situation and imagining variations on it. Changing one variable and reasoning about the consequences.

When my son says “what if the car goes REALLY fast?” he’s doing something that programmers do all day: taking a system, modifying a parameter, and predicting (or testing) the outcome. He just thinks it’s fun.

This is also the root of simulation and modeling. “What if” is how engineers think about systems before building them. Your toddler is running mental simulations every time they imagine an alternative scenario.

Level up: Play the “what if” game actively. “What if we didn’t have spoons? How would we eat soup?” Let them reason through the implications. You’re building their ability to think about systems abstractly.

5. Giving Directions → Decomposition & Clear Instructions

“Tell me how to get to your room.”

If you’ve ever asked a toddler for directions, you know the results are... imprecise. “You go... that way... and then you go... up... and then it’s there!”

But the attempt is what matters. They’re trying to break down a complex task (navigating a house) into discrete steps (go this way, go up, arrive). That’s decomposition — taking a big problem and splitting it into smaller, manageable pieces.

And when their directions don’t work (”that way” while pointing vaguely at the ceiling), they learn something crucial: instructions need to be specific. The person following them (or the computer executing them) can’t read your mind. You have to be explicit.

My son recently tried to tell me how to draw a truck he’d seen. “Draw the wheels. And the front thing. And the other thing.” When my drawing didn’t match his vision, he got frustrated. “No, the SQUARE thing.” He was learning, in real time, that vague instructions produce vague results. That’s literally the core lesson of programming. (We got there eventually — it was a Jeep Renegade.)

Level up: Play “robot game.” Your kid gives you instructions and you follow them exactly as stated, even when they’re clearly wrong. “Walk forward” — you walk into a wall. They learn fast that instructions need to be precise. (This game is also hilarious.)

Why This Matters

I’m not writing this so you can brag at playgroup that your toddler understands algorithms. (Although you can. I won’t stop you.)

I’m writing this because if you’re a developer who wants to eventually share your world with your kid — teach them about technology, build things together, help them think computationally — you’re not starting from zero.

You’re already doing it.

Every sorted sock pile, every recipe followed, every block tower rebuilt, every “what if” entertained, every set of wobbly directions given — those are the building blocks of computational thinking. When your kid is eventually ready for more structured tech experiences, they’ll already have the cognitive scaffolding in place.

You’re giving them a computer science education every day, in the most natural way possible: through play.

Just maybe throw in a few more “what ifs” at dinner. You know, for the algorithm development.

He couldn’t read. He couldn’t type. But he could sit next to me and say: “Make a red car game! Make it jump!”

So I typed his words into an AI coding tool. A red car appeared. He pressed space bar. It jumped.

His face did the thing — that wide-open, full-body joy that kids have before the world teaches them to play it cool. Then he said: “Make it go faster. Can we make it a digger?”

He was designing. He was iterating. He was two.

I’m a software engineer. 12 years building software, master’s in CS. And the most useful thing I’ve ever taught my kid about technology didn’t involve a screen — it was a sequence. First this, then that, then done.

That’s computational thinking. Not coding. Thinking.

Here’s what nobody tells dev parents: there’s no reason to wait. The neural pathways for sequential reasoning, pattern recognition, conditional logic — those are forming right now, between ages 2 and 6. Your kid is already doing computational thinking when they sort toys by color or figure out that pushing a button makes a sound. They just don’t have anyone connecting the dots.

So I wrote the curriculum I couldn’t find

I wanted hands-on activities. AI-assisted game building where the kid directs and the parent types. Actual CS concepts. A structure a tired parent could follow without prep.

It didn’t exist. So I built it.

12 Weeks of Tech Projects to Build With Your Kid — computational thinking for ages 2-6.

Each week covers one concept (sequences → patterns → loops → conditionals → debugging → all the way to integration). The rhythm:

• Mon-Tue: Hands-on activities. No screens. Sorting games, pattern hunts, chain reactions with dominos.

• Wed: Build a browser game with AI. Kid describes, you type.

• Thu: Remix day. Kid changes the game — new colors, new rules, harder levels.

• Fri: Kid “teaches” the concept to a stuffed animal. If they can explain it, they own it.

The format has been tried and tested on my actual 3-year-old. The kid who earned the nickname “Mr Wiggles” at a year old and would rather hurl paper airplanes/play excavators/race cars than sit still for literally anything. If it survived his attention span, it made the cut.

The magic is AI-assisted game building. AI removes the bottleneck. Your kid describes a game in plain language, watches it appear, then iterates. The feedback loop is instant. They’re the product manager, the designer, and the QA team.

You’re just the typist.

This isn’t about raising the next Zuckerberg. It’s about giving your kid the same thinking framework you use every day — while their brain is literally built to absorb it.

The book: 12 Weeks of Tech Projects to Build With Your Kid — $29 on Gumroad. PDF you can mark up and reprint.

I also made companion products because I’m like this:

• 41-Prompt AI Pack ($17) — Copy-paste prompts for ChatGPT/Claude, each with a [CHILD’S INTEREST] placeholder. Three per concept: a story prompt, a hands-on activity prompt, and a browser game prompt. Swap in “monster trucks” or “butterflies” and go.

• Screen Time Conversation Cards ($0+) — 10 screen-free discussion prompts you can use anywhere. Car, bath, dinner. No materials needed.

• Unplugged Expansion Pack ($12) — 12 additional screen-free activities (one per concept), all household items.

• “What Are They Learning?” Cheat Sheet ($5) — Quick reference for each concept.

• Complete Toolkit Bundle ($39) — Everything above plus bonus activity cards. Save $24.

Browse everything at shop.raisingpixels.dev

No coding required. No CS degree required. (I have one, but I promise you don’t need it.)

Screen time they made > screen time they watched.

If you know a parent who’d lean in at “computational thinking for toddlers” — send them this!

— Mei

Parent developers lose an average of 10-15 minutes per coding session just remembering what they were working on. Over a week of fragmented sessions, that’s 1-2 hours of productive coding time lost to context recovery alone. Two free tools—tmux (a terminal multiplexer) and AI-powered context scripts—reduce that ramp-up time to under 2 minutes, turning even a 20-minute window into real progress.

The problem isn’t speed. Aliases save keystrokes. Shortcuts save clicks. But neither can tell you why there’s a half-finished function called addMissingContext() or what that TODO comment about “ask someone smarter than me tomorrow” was supposed to refer to. Parent developers don’t need faster typing—they need context recovery systems that bridge the gap between sessions separated by days of sick kids, work deadlines, and birthday parties that somehow require three trips to Target.

After testing dozens of productivity tools and workflows, these are the only two that consistently move the needle for coding in fragmented time.

tmux: Your Session Survives Everything (Including Your Kid on the Trackpad)

tmux keeps your terminal sessions alive even when you close your laptop, restart, or accidentally kill Terminal because your kid was “helping” with the trackpad. It’s a terminal multiplexer that creates persistent “workspaces” that survive disconnections, crashes, and the chaos of parent life.

Without tmux, every coding session starts with: open terminal, navigate to project, start the dev server, open the right files, remember which browser tab had localhost:3000. That’s 5-7 minutes gone. With tmux, you type one alias and you’re back exactly where you left off—even if it’s been a week.

The Setup

Here’s a tmux config optimized for parent developers:

# ~/.tmux.conf

set -g prefix C-a # Easier to reach than default C-b

unbind C-b

bind C-a send-prefix

# Mouse support (essential when you’re tired)

set -g mouse on

# Show which project you’re in

set -g status-left “#[fg=green][#S] “

And these three aliases that make tmux feel natural:

alias twork=”tmux attach -t work”

alias tblog=”tmux attach -t blog”

alias tfam=”tmux attach -t family-projects”

Quick setup: I’ve created a complete tmux setup script that installs tmux, adds the configuration, and sets up all the aliases automatically.

One Command, Right Back Where You Left Off

Every project gets its own tmux session. When I start working on my blog, I type tblog and I’m back in my development environment exactly where I left off, even if it’s been a week.

The first time you create a session for a project:

# Navigate to your project and create a named session

cd ~/blog

tmux new-session -d -s blog

hugo server -D # Start your dev server

# Open another terminal window/tab and attach

tmux attach -t blog

Real-world example: Last Tuesday, my laptop died mid-deploy (I ignored the battery warning because I was “almost done”). After restarting, I typed tblog and my terminal environment was exactly as I’d left it. The deploy had even completed successfully in the background. That’s not just time saved—it’s confidence that you can pick up any project instantly.

Setting Up Your Sessions

# Create sessions for your main projects

tmux new-session -d -s work

tmux new-session -d -s blog

tmux new-session -d -s family-projects

# Then use the aliases to jump between them

tblog # Attach to blog session

twork # Attach to work session

tfam # Attach to family projects session

Each session maintains its own windows, working directories, and running processes.

AI Context Recovery: A 30-Second Briefing Instead of 15 Minutes of Staring

AI-powered context recovery uses your git history, file changes, and TODOs to reconstruct what you were working on—replacing the 10-15 minutes of “staring at your own code trying to remember” with a 30-second briefing. This is the second tool that transforms fragmented coding from frustrating to productive.

The Context Recovery Script

One script gathers all the breadcrumbs from your recent work:

#!/bin/bash

~/scripts/context.sh

echo “🔍 What was I working on?”
echo “”

echo “📝 Recent commits:”
git --no-pager log --oneline -5
echo “”

echo “📂 Files I changed recently:”
git --no-pager diff --name-only HEAD~3..HEAD
echo “”

echo “🚧 Current status:”
git --no-pager status --porcelain
echo “”

echo “💭 TODOs in recent files:”
git --no-pager diff --name-only HEAD~3..HEAD | xargs grep -l “TODO|FIXME|NOTE” 2>/dev/null | head -3 | xargs grep “TODO|FIXME|NOTE” 2>/dev/null
echo “”

echo “💡 Copy this info and ask your AI: ‘What was I working on and what should I do next?’”

Run context and paste the output into Claude (or your preferred AI) with: “Based on this git activity, what was I likely working on? What should I focus on next?”

Your Tiredness-Proof Memory

The AI sees patterns in your commit messages, file changes, and TODOs that you miss when you’re tired or distracted. It’s like having a coworker who watched your last session and can give you a 30-second briefing.

30 Seconds Now, 15 Minutes Saved Later

alias snapshot=”echo $(date): >> .project-notes.md && code .project-notes.md”

Before stepping away, run snapshot and jot down what you were doing, what you figured out, and what’s next. Takes 30 seconds, saves 15 minutes later.

The 2-Minute On-Ramp

The real power emerges when tmux and AI context recovery work together:

1. tblog — Instantly restore your development environment

2. context — Get AI summary of recent work

3. tail .project-notes.md — Read your last manual note

4. Start coding — Usually within 2 minutes of sitting down

Compare that to the old workflow: navigate to directory, remember what servers to start, open files you think you were working on, stare at code trying to remember, give up and start something easier, maybe start coding 10 minutes later.

The Real Win: You Stop Avoiding Hard Projects

The compound effect of reduced context-switching overhead transforms what kinds of projects parent developers can maintain. The productivity gain isn’t just minutes saved—it’s the elimination of the mental barrier that makes you avoid complex work.

Before: “I only have 20 minutes, that’s not enough time to make real progress on the authentication refactor.”

After: “I have 20 minutes, let me see what I was doing on the auth stuff.”

When you’re not afraid of ramp-up time, you work on bigger, more ambitious projects. Side projects actually get finished instead of being abandoned when life gets busy.

Start Here

Start with tmux sessions. Install tmux, create a session for your main project, and force yourself to use it for a week. The productivity gain is immediate.

Add AI context recovery later. Once tmux is a habit, add the context script. The combination is where the real transformation happens.

Don’t try to implement everything at once—that’s how productivity tools get abandoned.

These two tools handle the infrastructure of fragmented development. Combined with the right mindset and workflow aliases, you have a complete system for productive parent developer work. Your coding time might be fragmented, but your progress doesn’t have to be.

"Fix"? Fix what?!

By the time you remember what you were doing, you have maybe eight minutes before exhaustion wins. You manage to write three lines of code, realize you broke something, and hear crying from the nursery.

Sound familiar?

Why Standard Productivity Advice Fails Parents

Most developer productivity advice assumes you have uninterrupted blocks of time. "Just use the Pomodoro Technique!" they say. "Time-box your deep work!"

Right. Let me just explain to my toddler that Mommy is in a focused work session and cannot be interrupted for the next 25 minutes. I’m sure he'll understand.

The reality is that parent developers need completely different strategies. We don’t need advice on how to focus for hours—we need to know how to make meaningful progress before the kiddo has finished testing all the crayons in this box and needs a new box. (We've discussed the fact that all the colors are the same between the two boxes, and while I'm pretty sure he understands, he still insists on testing both sets.)

The Mindset Shift: From Blocks to Fragments

Traditional developer thinking: "I need at least 2-3 hours to get into flow state and accomplish anything meaningful."

Parent developer reality: "I can write a function while my kid watches one seven-minute Helper Cars episode, debug during 40-minute naptime, and deploy after bedtime."

Small, frequent progress beats waiting for perfect conditions.

I’ve shipped entire new projects in 15-minute increments. Not because it’s ideal… because it’s what you've got when you’re moonlighting at coding as a full-time parent.

Strategies That Actually Work

1. Leave Breadcrumbs for Future You

Never close your laptop without leaving yourself a note about what you were doing and what comes next. Your future self (whether that’s in 20 minutes or 3 days) will thank you.

What I do:

• Always commit with descriptive messages, even for work-in-progress

• Leave TODO comments with specific next steps

• Keep a simple text file open with "where I left off" notes

Example workflow:

// TODO: Next - add validation for email field in UserForm.tsx
// Problem: handleSubmit isn't calling the API correctly
// Test with: npm test -- UserForm

2. Optimize for Quick Restarts

The biggest productivity killer isn’t the interruption itself—it’s the time it takes to get back into context. Design your workflow for fast context switching.

Environment shifts that help:

• Keep your development server running (even when stepping away)

• Use terminal tabs/windows that stay open with the right directories

• Have your browser tabs pre-loaded with the right localhost ports

• Keep your code editor open with the relevant files

Basically do the opposite of what I'm always telling my toddler: don't clean up after yourself.

3. Embrace "Good Enough" Commits

Perfect is the enemy of shipped when you’re a parent developer. I’ve learned to commit early and often, even if the code isn’t perfect.

My philosophy: working software that ships is infinitely better than perfect code that never gets finished.

Some of my largest projects were built in tiny commits with messages like:

• "Basic login working, needs cleanup"

• "Ugly but functional user dashboard"

• "Fixed the bug, will refactor later"

4. Batch Similar Tasks

When you only have small windows of time, context switching between different types of work is expensive. Try to batch similar activities:

• Writing day: Focus on documentation, comments, planning

• Coding day: Pure implementation, bug fixes

• Testing day: QA, debugging, deployment

This isn’t always possible, but when you can batch, it helps maintain momentum.

5. Build for Resumability

Design your projects so they’re easy to pick up after days or weeks away:

• Clear documentation: Write README files like you’re explaining to a stranger

• Consistent structure: Use the same patterns or frameworks across projects

• Good logging: When things break, you need to quickly understand why

• Automated tests: Confidence that you didn’t break anything while away

6. Let AI Handle Context Switching

This is where 2026 parent developers have a massive advantage. AI coding assistants excel at the exact problems we face: understanding unfamiliar code quickly, filling in context, and maintaining momentum in short bursts.

The parent developer AI workflow:

1. Open project after days away

2. Ask AI: "What is this codebase and what was the last significant change?"

3. Get oriented in 30 seconds instead of 10 minutes

4. Make meaningful progress in your remaining time

AI strategies that work:

• Quick context recovery: When you can’t remember what you were doing, ask your AI assistant to analyze recent commits or current files

• Boilerplate generation: Don’t spend precious minutes on repetitive code. AI handles forms, API calls, test stubs instantly

• Smart documentation: AI can generate comments, README updates, or todo lists from existing code

The Two-Minute Rule for Developers

Borrowed from productivity expert David Allen but adapted for coding: If a coding task takes less than two minutes, do it immediately.

This includes:

• Fixing obvious typos

• Adding missing semicolons

• Updating a quick comment

• Installing a package you know you need

• Pushing your latest commits

These micro-improvements add up and prevent the "death by a thousand small tasks" problem.

Managing the Emotional Side

Let’s be honest: coding with constant interruptions can be frustrating. You’re in the middle of solving a complex problem when your kid wakes up early. Again.

Here are some mental frameworks I find helpful.

Remember Your Why

You’re modeling curiosity, problem-solving, and creation for your kids. When my son and I build games together, he knows we're making something, not just consuming content.

Celebrate Small Wins

Finished a function? That’s a win. Fixed a bug? Victory. Deployed a feature? You’re basically a superhero.

When your coding sessions are measured in minutes, not hours, you need to recalibrate what counts as progress.

Accept the Rhythm

Some days you’ll get 30 minutes of coding done. Other days you’ll get three minutes. Both are valid. Parenting has seasons, and so does your coding productivity.

Tools That Actually Help

While I’ll cover specific technical tools in upcoming posts, here are the categories that matter most for parent developers:

Auto-save everything: Configure your tools to save constantly. You never know when you’ll need to close the laptop quickly.

Cloud sync apps: Work seamlessly across devices. Sometimes you’ll code on your laptop, sometimes on a desktop, sometimes (let’s be honest) on your phone.

AI coding assistants: Your secret weapon for context switching and momentum. Whether it's Cline, GitHub Copilot, Codex, or Claude, these tools excel at helping you pick up where you left off.

The Parent Developer Advantage

It might seem like a constant struggle to be productive, but don't discount the skills you’re building every day! These are sustainable habits that will serve you for decades.

You’re gaining these superpowers:

• Extreme efficiency: You learn to cut through the noise and focus on what matters

• Better prioritization: When time is scarce, you get ruthless about important vs. urgent

• Stress testing: If your code works through multiple snack time interruptions and restarts, it’ll work anywhere

The Truth About Parent Developer Productivity

Working within constraints forces clarity and intentionality.

Yes, it’s challenging. Yes, it’s different from how you coded before kids. But it’s not lesser. It's just adapted to the most important job you’ll ever have: building your family legacy.

Your kids won’t remember that you shipped a month later than planned. But they will remember that you showed them what it looks like to be curious, to build things, and to never stop learning.

Before I buy anything, I ask: Does this build a transferable mental model? Can they use this concept tomorrow in a different context?

Here’s what I’d get my 3yo for Christmas if he didn’t already have it and love it:

Fraction puzzle. He learned 1, 1/2, 1/3, 1/4 in ten minutes. Now when I say “after you eat half your meatball, you can have more strawberries” he understands what half is.

Cylinder puzzle. He spent a full half hour on this, mixing up the pieces and redoing the puzzle over and over. Improves spatial awareness, trains differentiation and pattern recognition.

DIY wood toys. I must have gotten him half a dozen of these sets already. We build them together. He’s learned to follow the instructions, work backwards from images of the finished piece, and even enjoys improvising his own creations with the parts.

Buddha board. No mess painting, image fades as it dries. Fine motor control and prepares him for writing. Also, “Mama what does this look like? A duck! Look I drew some water for the duck to swim in!”

Snap Circuits. Very fun and safe to play with, and he now understands the basic components of a circuit and why we don’t stick forks in outlets.

Tangram puzzle. Useful for showing how one shape can contribute to many final products when used differently. He’ll rotate a triangle piece and say “look, now it’s a mountain! Now it’s a hat!” Same shape, different context—exactly how I want him to think about code later.

Ultimate Spotlight books series. Fun interactive books with movable pieces and pop up pages. They have so many topics! We’ve especially loved the vehicle and construction ones.

Eyewitness books. So many books for kids don’t use real pictures, so this series is our go-to for learning with real photos.

Movable alphabet, fridge edition. Keeps little hands busy while I make coffee. I recommend getting two or three sets so you can spell most words. We started our son with phonics before he was two and he can reliably spell short words like “car,” or “truck” on the fridge.

Stainless steel camping plates. Just big enough for a big sandwich. Light and strong. He likes to help put them away when we unload the dishwasher and brings his dirty plate to the sink. No fear of breaking them.

The pattern: Each one teaches a concept that compounds. Fractions show up in cooking, time, money. Circuits explain why the lights work. The plates build executive function through real responsibility.

Every toy should answer: what system am I teaching? If you can’t answer that, it’s just noise.

What toys are you buying that build mental models your kids will use for decades?

Have other gems to add to this list? Comment and let me know!

These Amazon affiliate links let me earn a small commission if you purchase through them at no extra cost to you. I only recommend things my kid actually uses daily! Thank you for supporting my work!

This would not be the ideal time to look up the exact git command syntax.

It’s a good thing you’ve set up an alias for this precise situation:

quickfix runs git pull --rebase && git add . && git commit -m 'Quick fix' && git push in one command. Three seconds, and your work is shipped.

When your cognitive load is already maxed out on keeping tiny humans alive, every saved keystroke matters.

Why Aliases Matter More for Parent Developers

Typically, developers optimize for readability and best practices. Parent developers benefit from optimizing for speed and resumability. When your coding windows are measured in minutes and you have precious few more of those than functioning brain cells, every saved keystroke compounds.

The math is simple:

• Average parent coding session: 15 minutes

• Time spent on repetitive commands: 2-3 minutes

• Time saved with good aliases: 2-3 minutes

• Daily productivity increase: 15-20%

But here’s the real impact:

• 5 coding sessions × 3 minutes saved = 15 minutes weekly

• Over a month: 1 extra hour of deep work

• Over a year: 12+ hours = almost two full workdays of found time

More importantly, aliases reduce cognitive load. When you’re tired and distracted, muscle memory beats trying to remember command syntax. They also create rage-quit-proof workflows—when you’re interrupted mid-thought, one command saves your work before you sprint to handle whatever’s happening.

The Parent Developer Aliases for Every Situation

Before we dive in, here’s a quick power-user tip:

# Function alias for dynamic commit messages
alias gc='function _gc(){ git commit -m "$*"; }; _gc'

# Now you can type: gc Fixed the API timeout issue
# Instead of: git commit -m "Fixed the API timeout issue"

Now, the essentials—organized by the scenarios that actually happen in parent developer life. Copy these straight into your .zshrc or .bashrc.

1. Emergency Git Workflows

These are for when things break and you need to act fast:

# The golden trio - save your work instantly
alias save="git add . && git commit -m 'WIP: interrupted by life' && git push"
alias quickfix="git pull --rebase && git add . && git commit -m 'Quick fix' && git push"
alias backup="git add . && git commit -m 'Backup before trying something' && git push"

# When you return and can't remember what you were doing
alias last="git log --oneline -5"
alias status="git status && echo '---' && git log --oneline -3"
alias changes="git diff HEAD~1"

# Quick branch management
alias main="git checkout main && git pull"
alias newbranch="git checkout -b"
alias deletebranch="git branch -d"

# When you need to abandon ship quickly
alias abort="git reset --hard HEAD && git clean -fd"
alias unstage="git reset HEAD ."

Real scenario: API was returning 500s just as I heard “MAMA MAMA MAAA” from the monitor. Used backup to save current state, changed req.body.userId to req.body.user_id (why do we never standardize these?), hit quickfix, then to mom duties. When I came back some hours later, last showed me exactly where I’d left off.

2. Quick Project Switching

Parent developers juggle multiple projects in fragments:

# Navigate to common project directories
alias work="cd ~/work && ls"
alias personal="cd ~/personal-projects && ls"
alias blog="cd ~/blog && code . && hugo server -D"

# Quick environment setup
alias devup="docker-compose up -d && npm run dev"
alias devdown="docker-compose down && pkill -f 'node'"
alias fresh="rm -rf node_modules && npm install && npm run dev"

# Open common project combinations
alias workday="code ~/work/current-project && cd ~/work/current-project"
alias blogpost="cd ~/blog && hugo new content/posts/$(date +%Y-%m-%d)- && code ."

Parent-specific benefit: No time wasted navigating directories or remembering startup commands. blog opens your editor and starts the dev server in one command—crucial when you have exactly 12 minutes during snack time.

3. Development Environment Shortcuts

When you have 15 minutes to code, environment setup can’t take 5 of them:

# Server management
alias serve="python -m http.server 8000"
alias nodeserve="npx serve -s build -l 3000"
alias hugoserve="hugo server -D --bind 0.0.0.0 --port 1313"

# Testing shortcuts
alias test="npm test"
alias testwatch="npm test -- --watch"
alias testcoverage="npm test -- --coverage"

# Package management
alias ni="npm install"
alias nid="npm install --save-dev"
alias nrun="npm run"

# Quick file operations
alias ll="ls -la"
alias ..="cd .."
alias ...="cd ../.."

# Process management
alias ports="lsof -i -P -n | grep LISTEN"
alias killnode="pkill -f node"
alias killport="function _killport(){ lsof -ti:$1 | xargs kill -9; }; _killport"

4. Mobile & Remote Coding

For when you’re coding on iPad via SSH during Daniel Tiger:

# Ultra-short for thumb typing
alias m="git add . && git commit -m"  # usage: m "quick fix"
alias p="git push"
alias pl="git pull"
alias s="git status -s"
alias d="git diff"

# Codespaces/remote dev
alias remote="gh cs ssh"
alias cslist="gh cs list"
alias cscode="gh cs code"

# Quick file edits on mobile
alias v="vim"
alias n="nano"

These work great in GitHub Codespaces, Termius, or any SSH session.

5. Content Creation Workflows

For building in public while building humans:

# Blog post management
alias newpost="hugo new content/posts/$(date +%Y-%m-%d)-"
alias preview="hugo server -D --bind 0.0.0.0"
alias publish="git add . && git commit -m 'New post' && git push"

# Quick content ideas capture
alias idea="echo '$(date +%Y-%m-%d): ' >> ~/content-ideas.md && code ~/content-ideas.md"

Installation Guide for Busy Parents

Step 1: Back Up Your Current Setup

# Always backup first - parent developers can't afford to break their environment
cp ~/.bashrc ~/.bashrc.backup
cp ~/.zshrc ~/.zshrc.backup 2>/dev/null || echo "No zsh config found"

Step 2: Add Aliases Gradually

Start with just these three life-savers:

1. save - for instant work preservation

2. quickfix - for emergency deploys

3. last - for context recovery

Master these, then add more.

Step 3: Test in Low-Stakes Moments

Try them during a calm coding session before relying on them during naptime production emergencies.

Advanced Parent Developer Power Moves

Once comfortable with basics, these compound your efficiency:

# One-command pull request workflow
alias pr="git push && gh pr create --fill"

# Branch cleanup
alias cleanup-branches="git branch --merged | grep -v main | xargs -n 1 git branch -d"

# Update all your projects at once
alias update-all="find ~/projects -name '.git' -type d -execdir git pull \;"

Making Aliases Stick

Use Muscle Memory

The best aliases feel natural. save works because it’s obvious. qf for quickfix might be faster, but you’ll forget it exists.

Document Your Aliases

# List all your custom aliases
alias

Keep this output in your notes app for quick reference.

Troubleshooting

“Command not found” After Adding Aliases

# Reload your config without restarting terminal

source ~/.zshrc  # or ~/.bashrc

Git Aliases Conflicting

# Check existing git aliases

git config --list | grep alias

# Remove conflicts

git config --global --unset alias.save

The Compound Effect

These aliases don’t just save seconds—they reduce context-switching overhead. When you can execute complex workflows without thinking, you preserve mental energy for actual problem-solving.

After a month with these aliases, my typical 15-minute session:

• 30 seconds: Environment setup (was 3 minutes)

• 14 minutes: Actual coding and problem-solving

• 30 seconds: Save and cleanup

That’s 20% more coding time, which over a year adds up to two full weeks of additional productivity.

Your Next Step

Your time is fragmented. Your attention is split. Your coffee is cold. But your commands? Those can be lightning fast.

Start with three aliases today. Just three. By next week, you’ll wonder how you ever git add . && git commit -m 'message' && git push’d like a caveman.

Now if you’ll excuse me, someone just discovered they can flush toy cars down the toilet. Time to save and run.

Download: Want all these aliases in one file? Get the ready-to-install parent developer aliases collection that you can source directly into your shell configuration.

Next in the series: CLI tools designed for 15-minute coding windows—including AI-assisted context recovery and emergency deployment strategies.​​​​​​​​​​​​​​​​

“Build a tower,” he says.

My toddler is more interested in stacking them than lining them up, so I switch axis. “Big block, small block, big block…”

“I’m going to knock it over!” he announces.

“Okay, but first tell me if a big block or small block comes next.”

“Small block,” he says, and uses a small block to knock over the tower.

It’s progress.

Tricking Toddlers into Learning Programming Fundamentals

1. The Sock Sorting Algorithm

Post-laundry, dump all the socks on the floor. "Find all the truck socks!" He groups them. "Now find their friends!" He matches pairs.

We just taught classification and matching—core programming concepts—disguised as helping with chores.

2. Red Light, Green Light 2.0

Classic game, programmer twist. Green = walk, Red = stop. Then we add: "When I clap AND say green, you clap and walk!”

Congratulations, you just taught conditional logic. Next: "Two claps means go backwards!" Now we're teaching parameters.

3. The Toy Car Parking Lot

Line up cars by size. Now by color. Now red cars in front, everything else behind. He's learning sorting algorithms without knowing what an algorithm is.

Add a rule: "Emergency vehicles always go first!" That's priority queuing.

4. Snack Patterns

Goldfish, pretzel, goldfish, pretzel. "Can you continue the pattern?" Once he masters it: "What if we add a raisin?" Now it's goldfish, pretzel, raisin, goldfish, pretzel, raisin.

We just taught sequence expansion (although the raisins rarely last past a couple iterations).

Why This Actually Matters

These aren't cute games that vaguely relate to programming. They're teaching the exact thinking patterns he'll use whether he's prompting AI or (unlikely) writing actual code:

• Pattern recognition: The basis of all debugging

• Sequential thinking: How programs execute

• Conditional logic: If this, then that

• Classification: Grouping similar things

• Algorithm design: Steps to solve a problem

Your Turn

Talk out loud about any pattern you see. Cars parked on the street. Tree, bush, tree, bush along the sidewalk.

Give your kid the opportunity to match: “Can you put this fork in the drawer with the other forks?”

Tonight at dinner, make a pattern with food and ask your kid to describe it. The yummier, the better!

Subscribe now

What pattern games do you play? Reply and tell me—I'm always looking for new ways to sneak programming logic into playtime.

“If I eat meatball, then I can have more blueberries?”

Conditional statements come naturally at mealtimes. He doesn’t know it yet, but he’s programming me.

The Daily Algorithms

Every toddler negotiation follows programming logic:

The Basic If-Then

“If I put on my shoes, then we go outside?”

Classic conditional. Input (shoes) leads to output (park). He’s learning cause and effect aren’t just natural laws—they’re negotiable parameters.

The AND Operator

“If I brush teeth AND pick up toys, then two stories?”

Multiple conditions! He’s combining requirements.

“If I lay down AND be quiet AND close my eyes, then another story?”

That’s a three-condition function.

The OR Logic

“I wear the dinosaur shirt OR the truck shirt?”

He’s presenting options, understanding that either input produces the desired output (getting dressed). Then he levels up: “If dinosaur shirt, then green pants. If truck shirt, then blue pants.”

Different inputs, different outputs. That’s programming.

The Edge Cases

My favorite is when he finds the bugs in our parent logic:

Me: “If you don’t eat your fish, then you can’t have more crackers.”

Him: doesn’t eat fish

Him: “I don’t want more crackers. I want melon.”

He found the loophole. Our conditional didn’t account for his ability to reject the entire premise. That’s debugging.

Or this one:

Me: “If you eat your fish, then you can have melon.”

Him: takes one bite of fish

Him: “May I have melon now, please.”

One bite of fish for a bowl of melon? That’s optimization.

Why This Matters

These aren’t cute moments that vaguely relate to programming. This IS programming. He’s learning:

• Conditional logic: If X then Y

• Boolean operators: AND, OR, NOT

• Variables: Different inputs produce different outputs

• Edge cases: What happens when assumptions break

• Debugging: Finding flaws in logic

• Optimization: Maximum reward for minimum effort

Every negotiation is a program he’s writing in real-time.

The Magic Question

When he negotiates, I’ve started asking: “What’s your if-then?”

“If I drink water, then we go outside.”

“If I get dressed, then we play GCompris.”

“If I lay down, then Mama sings Twinkle Twinkle Little Star.”

He’s getting explicit about his logic. He’s learning that clear conditions lead to predictable outcomes.

Your Turn

Tomorrow, when your toddler starts negotiating, listen for the logic:

• What conditions are they setting?

• What operators are they using?

• Where are the edge cases?

Talk through each point (in toddler terms) and make them explicit. Then try this: “Okay, if we do that, then what do you want to happen?”

Watch them think. Watch them structure their argument. Watch them debug their own logic when it doesn’t work.

They’re not just negotiating. They’re programming.

When we teach them to think in if-thens, we're teaching them to think clearly about cause and effect, actions and consequences, effort and reward. That's not just coding. That's life.

Subscribe now

This morning: "If I hug, then Mama is happy.” Yes, buddy. That program runs perfectly every time. What's your favorite toddler if-then that just melts you?

We skipped the "kid-friendly" stuff and went straight to real tools. Turns out, toddlers are vastly underestimated! They don't need training wheels, just guidance and motivation.

The Entire Setup (Yes, Really)

Step 1: Install VS Code (3 minutes)

Download Visual Studio Code. That's it. The same editor I used at work now serves as my toddler's creation platform. Don't overthink it—kids don't care about themes or extensions.

Step 2: Add Cline Extension (2 minutes)

Search "Cline" in VS Code extensions. Click install. This is the AI assistant that turns natural language into code. No configuration needed beyond adding your API key.

Step 3: Make It Toddler-Friendly (5 minutes)

• Bump the font size to 20 (Command+Plus a few times)

• Hide the sidebar (they don't need it)

• Full-screen the window (fewer distractions)

• Create a folder with their name on the desktop and open it in VS Code

Done. Your toddler can now build software.

The Secret: It's Not About the Tools

Here's what I didn't do:

• Install a "kid-friendly" IDE

• Set up Scratch or Blockly

• Create special shortcuts

• Baby-proof anything

Why? Because the complexity isn't in the tools—it's in the syntax. Remove the syntax (thanks, AI), and suddenly VS Code is as simple as any toy. (Well, you might have to help them type.)

The First Session

Open VS Code. Open Cline. Say: "Tell the computer what you want to make."

That's your entire onboarding.

My son's latest request: "Make a green car website for kids."

I typed exactly that. A few minutes later, it existed. No configuration. No setup. No "let's learn about variables first."

What About Safety?

Fair question. Here's my approach:

• I'm always present (it's a together activity)

• The API has spending limits

• We use a separate user account on the computer

• Generated games run locally in the browser

If you wanted to be extra, extra cautious, you could use a devcontainer to isolate Cline's coding environment. (For these details, see my post on API keys and safety) But honestly? The biggest safety feature is that he can't type yet. I'm the gateway, which means natural moderation.

Skip the Kids' Stuff

Scratch teaches drag-and-drop coding. ScratchJr simplifies it further with picture blocks. But they’re still teaching syntax, just with pretty colors. We're teaching creation with real tools that will matter in industry for the next generation.

Your toddler doesn't need a special "learning environment." They need:

1. A way to express ideas (their voice)

2. Something to turn ideas into reality (AI)

3. A place to see it happen (VS Code)

That's it. Ten minutes to set up. A childhood full of creation ahead.

Tonight's Homework

Stop researching "best coding apps for kids." Instead, install VS Code and Cline. Tomorrow, ask your kid what they want to make.

Then make it.

You'll be amazed at what happens when you stop teaching them to code and start helping them build.

Subscribe now

Stuck on setup? Reply and I'll help you out! Let’s get your kids building together.

Yes. And it’s safer than giving them YouTube. Here’s how to do it right.

First: What’s an API Key?

Think of it as a password that lets the AI work. You need one, it costs a little money when used, and you absolutely don’t want it public. That’s it. That’s all you need to know.

The Basic Safety Setup

1. Set spending limits (2 minutes)

Every AI service lets you set monthly limits. I set mine to $10. My toddler would need to build upwards of 500 games to hit that. When the limit’s reached, it just stops working. No surprise bills.

2. Use a password manager (already done, right?)

Your API key goes in your password manager, not a sticky note. I use 1Password, but Bitwarden’s free and excellent. Copy-paste when needed.

3. Separate user account (5 minutes)

Create a “Family Coding” user on your computer. It only has VS Code and a browser. No email, no shopping sites, no saved passwords. This is your coding sandbox.

The Advanced Move: Devcontainers

Want bulletproof safety? Devcontainers isolate the AI’s environment completely. It’s like giving the AI its own computer inside your computer. It can’t touch your files, can’t see your system, can’t do anything outside its box.

Here’s a simple setup. Create a folder called .devcontainer and a file inside it called devcontainer.json.

.devcontainer/devcontainer.json:

{
  "name": "Toddler Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:1-20",
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "anthropic.claude-code"
      ],
      "settings": {
        "editor.fontSize": 20,
        "editor.wordWrap": "on",
        "files.autoSave": "afterDelay",
        "files.autoSaveDelay": 1000,
        "terminal.integrated.fontSize": 16,
      }
    }
  },
  "postCreateCommand": "npm install -g @anthropic-ai/claude-code",
  "remoteUser": "node"
}

Save this, restart VS Code, and it’ll ask if you want to open in a container. Say yes. Now the AI can only work in this sealed environment.

What Can Actually Go Wrong?

Let’s be realistic about risks:

Could the AI write weird code?

Theoretically, yes. Practically, your toddler’s asking for truck games, not bitcoin miners. And you’re watching everything happen.

Could they rack up huge bills?

Not with spending limits. $10 max means $10 max.

Could they accidentally delete files?

Not anything unrecoverable if you're using a devcontainer.

The Reality Check

I’ve been doing this for months. The worst thing that’s happened? My son asked the AI to “make everything green” and it did. Everything. The horror.

Your toddler is safer building games with AI than:

• Watching YouTube (no algorithm suggesting weird videos)

• Playing mobile games (no ads or in-app purchases)

• Using kid apps (no data collection)

The One Rule That Matters

You’re always there.

This isn’t your typical screen time. You’re sitting together, typing their words, watching the magic happen. You’re the filter, the guide, and the emergency stop button.

That’s better than any technical safety measure.

Your Action Items

1. Get an API key (Claude or OpenAI)

2. Set a $10 monthly limit

3. Put the key in your password manager

4. Create that devcontainer file (optional but recommended)

5. Start building!

We’re living in a moment where a 2-year-old’s imagination can become reality in minutes. Safely. Easily. Together.

When my son says “Make a race car game!” and we actually make it, I watch his understanding of what’s possible expand. He’s learning that computers aren’t mysterious boxes—they’re creative partners. He’s discovering that his ideas have value. That he can build, not just consume.

And it’s all happening safely, with you right there, guiding the adventure.

That’s not just safe. It’s magical.

Subscribe now

Security questions? Reply and ask. I’ve probably overthought it already so you don’t have to!

So when we told him that he could make his own game, with any kind of vehicle he wanted, it was an unsurprising jump to:

“Make a red car game!”

I explained it like this:

“You type what you want here, and the computer helper will try to make it for you.”

His eyes lit up. “Make a red car game! Tell the computer to make a red car game RIGHT NOW.”

Why I’m Not Teaching My Kid to Code

I’ve been in software development for a decade. I’ve written more functions, loops, and algorithms than I could possibly count. And yet I’m convinced that teaching my toddler how to write a proper if…then would be a complete waste of time (and not because he wouldn’t get it—he’s already an expert at “If you finish your meatball, then you can have more blueberries.”).

The point is that he’s not going to grow up in the world I learned to code in. That world is gone. Learning Python will be akin to learning plumbing. Does it make you more knowledgable and self-sufficient to know how the water gets to the faucet and how to fix a broken pipe? Yes. But 99% of the time your focus is on what you’re doing with the water.

LLMs (Large Language Models—or, colloquially, “AI”) are already impressive. By the time my son is working-age, they’ll be unrecognizable. Well, more accurately, they’ll be infinitely recognizable—invisibly embedded into every bit of technology we use, from our wristwatches to our televisions. (For future readers: wristwatches are devices we used to wear on our wrists to tell the time, and televisions are… oh, nevermind.)

If you want your kids to thrive with tomorrow’s technology, please don’t teach them how to code.

Teach them how to build.

Subscribe now

My Toddler, the Prompt Engineer

My son knows his letters but we’re still working on keyboard skills, so we helped him type it in.

make a browser based red car game

Visual Studio Code lit up, green lines filling the screen, things happening. He watched excitedly. “Can we play it now? Is the computer done yet?”

Eight minutes later, we opened the browser window and there it was: a little red car, trundling down the road on a sunny day, jumping over traffic cones and obstacles at the press of the space bar. Then,

“Can we make it a digger? Make a firetruck game. Make an AMBULANCE game!”

(He’s two, after all.)

My little prompt engineer has been busy: you can see all the games we’ve made so far at madladstudios.com.

Forget Syntax. This is What Actually Matters.

My son thinks we made a little red car game that day, but what we achieved was much bigger than that.

He used to think computers were things that showed him other people's stuff. YouTube videos of excavators. Educational games someone else designed. Now, the computer is his collaborator. When he has an idea, he knows he can build it. The computer changed from a tool for consumption to a tool for creation.

But more importantly, he's learning foundational skills for the type of programming that will be most relevant in his lifetime: natural language programming.

I watched him figure out that specificity matters. "Make a fire truck game," left a lot up to the model to assume, but, "make a fire truck game where it sprays water and puts out fires," got him just the game he wanted. When the red car's short jumps landed it on top of obstacles more often than over them, "make it easier for kids," got him bigger, loftier jumps that kept the game frustration-free.

He's discovering that creation can be a conversation. You say what you want, you see what you get, you refine, you try again. It's the same iterative process I use as a developer, minus all the unnatural syntax that gets in the way.

The tools have fundamentally changed. When any child who can describe an idea can also build it, we need to rethink what we're teaching them.

Some parents want to teach their kids Python. We're teaching ours to think in systems and communicate clearly. To break down big ideas into smaller pieces. To iterate based on results. To imagine boldly and describe precisely. To build with timeless skills in tomorrow's world.

Your Toddler Can Ship Software Today

Want to try this with your own kids?

You'll need a computer, an AI assistant like the Cline extension in VS Code, and a kid with ideas. The setup takes minutes—after that, you're limited only by naptime and snack breaks. (If you want specifics, comment and I'll help you out!)

Start with what your kid already loves. Let them describe it in their own words. Type exactly what they say—toddler grammar and all. Watch what happens. The moment they realize their ideas can become real things is when everything changes.

My son still asks for the red car game. But now he also asks, "What should we make today?"

I can't think of a better question to teach a kid to ask.

Subscribe now

Have you tried building with AI and your kids? What did you discover? Reply and let me know—my toddler and I read every response (though he's mostly interested in whether you made any vehicle games).