Because I’ve stopped being the one who installs things.

The cost of not being the one who types

My whole workflow is now asynchronous: I prompt an agent, walk away to homeschool my three-year-old, come back minutes to hours later, prompt again. It’s the only thing that fits a parent developer’s fragmented day.

But there’s a bill attached, and this post is it. When the agent is the one writing the code, the agent is also the one reaching for dependencies. It needs a functionality, it pulls a package. It needs another, it pulls that one too. Multiply across weeks of lighlty supervised work and the result is a machine whose dependency tree I had never personally reviewed — assembled, decision by decision, by something that wasn’t me, while I was making breakfast.

So when Shai-Hulud hit, I couldn’t answer the only question that mattered: am I running any of these packages? I had outsourced the choosing, and the choosing turned out to be exactly the thing security depends on.

The audit, and the decision that came out of it

The fix, fittingly, was also agentic — but with more supervision. I had my agents go project by project: inventory every dependency, cross-check against the lists of known-compromised packages, flag anything unpinned, and pin what remained to specific known-good versions. It was a few hours of work I would rather have spent elsewhere, and it came out clean, which I credit more to luck and stack choices than to virtue.

The lasting change was a decision the audit forced me to: where I can, I’ve moved off npm entirely. Not because npm is uniquely evil — it’s the biggest target because it’s the biggest registry — but because the agentic-plus-npm combination concentrates the exact risk I’m least able to absorb. The JavaScript ecosystem’s deep, transitive dependency trees mean one poisoned package cascades into thousands of projects, and an agent with permission to install will pull the whole tree without a second thought. Reducing my surface area there was the highest-leverage thing I could do, so I did it.

Why agents make supply-chain attacks worse, specifically

This is the part worth internalizing even if you never touch JavaScript, because it generalizes to every package ecosystem and every agent.

The old supply-chain threat assumed a human at the keyboard, typing install and occasionally pausing to think wait, is that the right package name? That pause was a security control. We just never called it one.

Agents removed the pause. Two new failure modes follow directly:

Slopsquatting. LLMs hallucinate package names — they confidently reference a library that sounds right but doesn’t exist. Attackers noticed, and now register the hallucinated names as real, malicious packages, waiting for the next model to suggest them and the next agent to install them. Researchers estimate around a fifth of AI-generated code samples reference packages that don’t exist; every one of those is a slot an attacker can pre-fill. A human might squint at an unfamiliar name. An agent on auto-approve types it and moves on.

Unsupervised installation at machine speed. The whole point of an agent is that it acts without you. Point it at a task with broad permissions and it will fetch, install, and execute dependencies faster than you could review a single one — and increasingly, the attacks themselves target the agent’s own extensions and skills, which run with the agent’s full permissions. The convenience and the vulnerability are the same property. You cannot keep one and refuse the other.

The uncomfortable synthesis: the more useful the agent, the less you know about what it did. And what you don’t know, you can’t secure.

The wall, and why it’s the real answer

You cannot vet every package an agent pulls — not while sleep-deprived, not in the one-minute windows between parenting and existing. Vetting doesn’t scale to agent speed. So the strategy can’t be inspect everything; it has to be contain everything, so that the stuff you didn’t inspect can’t hurt what matters.

I run agents in disposable containers, never on my bare machine. Whatever an agent pulls, it pulls into a box that holds the project and nothing else — no SSH keys, no other clients’ code, no home directory full of credentials for a worm to harvest. Compromise the box and you’ve compromised a box I can delete in seconds.

The riskiest work lives on separate hardware. My autonomous agents run on a small dedicated machine — a NUC — physically apart from the computer that holds anything I’d grieve. Some basic network egress controls sit around it, so a compromised dependency can’t quietly phone home with whatever it found. The place where unreviewed automation runs should not be the place where your life’s details are stored.

Plan mode is the cheap half of the defense. Before any of the container stuff, I read the agent’s proposed approach and approve it. That single synchronous minute is where I’d catch let’s add this unfamiliar dependency before it executes. It’s not sufficient — plenty happens after approval — but it’s the highest-value minute in the workflow, and skipping it is how people end up not knowing what’s on their machine. I would know.

The sustainable version of autonomous work

I’m not going back to typing every install myself; the fragmented-time math doesn’t allow it, and that’s the whole reason this works for a parent at all. So instead I assume the agent will, sooner or later, reach for something it shouldn’t — and I make sure that when it does, it’s reaching inside a box I can throw away, on a machine that isn’t the one my life runs on. Build fearlessly, just in a box.

Building alongside your kids, not just around them? 12 Weeks of Tech Projects for Toddlers covers the safe-setup principles in a version pitched at age 2+ — same instinct, smaller stakes. At buildwithyourkid.com.

The boot sequence

0600 — my alarm. In theory. In practice the wake interrupt sometimes comes from down the hall instead, ahead of schedule. No system eliminates this when you’re a parent.

The button. First adult up hits one button in Home Assistant, which runs the whole morning script: the lamp in my son’s room flips from red to green — green means it’s morning and he’s free to come out — and the playroom and living-room lights begin ramping from dark to gentle morning light over the next ten minutes.

The agent’s first text. Hermes, our family agent, texts me the morning’s workout — chosen off my recent activity and how well I actually slept. Bad night, lighter session. I didn’t have to decide anything; deciding at 6am is exactly the work I’m trying not to do.

The manual block. After the workout: I open the shutters, start the coffee, start breakfast. Meanwhile dad and the almost-4-year-old do his daily reading practice. This part is hands and people, on purpose.

The agent’s second text. Hermes tells me what breakfast is — pulled from the meal plan I premade — plus which fridge and pantry items need using up today before they turn. The 6am fridge-stare, eliminated. The food-waste guilt, mostly eliminated.

After breakfast. I text Hermes what I actually ate, which may or may not have resembled the plan, and it logs the macros to my tracking app. The plan proposes; the human disposes; the agent records the truth without judgment (usually).

0800 — full brightness. The lights go to 100% and the house is officially awake. So are we, if the coffee’s kicked in.

Why it’s a button and not a clock

The embarrassing version-one mistake: I scheduled everything by time of day. Lights at 6:00, ramp up by 6:10, the whole morning on cron.

Then the kid slept in.

A time-triggered morning marches on whether or not anyone is awake to want it — lights blazing into rooms nobody’s in, the house performing its routine for an audience of zero, and the one precious morning the three-year-old sleeps past six, the system is actively working to end it. I rolled it back. The morning now starts when a human says it starts: event-driven, not scheduled. The kid is an unreliable cron job, and the architecture has to respect that.

The red/green lamp is the same philosophy pointed at him. He can’t read a clock, but he can read a color. Green is a signal he checks, not an alarm that fires at him — which means that he makes the transition when he’s ready. A semaphore, technically. He just thinks it’s his lamp.

The kid runs a sequence too

Not everything that runs the morning is electronic. The most load-bearing automation is the one installed in the kid: the familiar routine of reading practice, then get dressed, then breakfast. He knows the order. The order never changes. What used to be a negotiation — the getting-dressed standoff every parent knows — mostly dissolved once dressing stopped being a decision and became simply the step after reading. Sequences beat standoffs. It’s routine cards, running in production.

The numbers, honestly

Before the system: maybe four hectic mornings a week. Now: about two. Not zero — this is real life, after all. The system didn’t make mornings serene, but it made them less hectic, by removing a layer of decisions (what workout, what breakfast, what’s expiring, is it morning yet) so the remaining chaos is at least the irreducible kind.

The part no system fixes

And then there are the nights he’s up three times, nobody has slept a real night’s sleep, and 6am arrives like a tax audit. On those mornings the lights ramp beautifully, the agent texts on schedule, the boot sequence executes flawlessly — and I pour kefir into the coffee instead of cream, or brew the decaf instead of regular with devastating consequences. The system has never once prevented this. It just exists, fully automated, watching me drink yogurt coffee.

At least home automation can hold the structure so the tired humans don’t have to. Unfortunately, it cannot make the humans less tired. The structure is worth it anyway — on the worst mornings most of all, because the worst mornings are exactly when nobody has the spare capacity to remember what comes next.

The evening system shuts the house down; this one boots it up. Between the two, the hours that used to run on willpower now run on one button, two texts, and a lamp. If the agent half is what you want to copy, the family-agent post covers how Hermes is set up. If the kid half is what you want to copy — the sequence that dissolved the getting-dressed standoff — that’s the routine-card playbook from 12 Weeks of Tech Projects for Toddlers, running at 6am instead of bedtime. It’s at buildwithyourkid.com.

There’s a failure mode in working with language models that every practitioner learns the hard way: you assume that more context produces better output, so you cram everything into the prompt — every document, every instruction, every edge case — and the model gets worse. It hedges, it loses the thread, it fixates on some irrelevant detail you pasted in for completeness. The fix is counterintuitive but reliable: take things out. A clean, curated context beats a maximal one. The bottleneck was never how much the model could hold. It was how much it had to ignore.

The number people fixate on is the context window — how much you can put in. The number that actually governs the output is something more like a context filter — how much the system has to suppress to find the signal. I’ve come to believe small children run on the same principle, and I have a week of evidence from my own living room that I did not enjoy gathering.

The maximal-context toddler

My three-year-old’s environment was, by any reasonable standard, well-provisioned. Toys in every category, accessible at all times — the maximal context window, lovingly assembled. The theory was abundance: more to choose from, more to engage with, more development.

After a rough stretch at home, I started to suspect the abundance itself was part of the problem. The output of all that available context was not richer play. It was noise — and an increasingly dysregulated kid. The environment held more than he could meaningfully attend to, and the result was the toddler equivalent of a model fixating on the wrong line of a bloated prompt: scattered, escalating, never settling into anything.

So we ran the experiment. We put all of it away. Every toy, boxed and out of sight. And — the harder cut — no videos.

What a filtered context produced

I expected boredom, protest, a hard adjustment. What actually happened in the days since still surprises me.

He read. He read the entire Green Eggs and Ham book, start to finish. He drew. He asked to do penmanship practice — asked. He played Khan Academy Kids games, which sit at the creation-ish, low-stimulation end of what a screen can be. The smashing-and-breaking register of play — the rough, destructive, escalating mode that fills the space when nothing else is winning — largely went quiet, because the quieter activities were finally the loudest thing in an otherwise empty room.

None of these activities are new to him. He always could have chosen them. They were simply being drowned out. When I cleared the context, the signal that had been there all along got through. Removing options didn’t deprive him of anything. It revealed what he’d actually do given a clean room to do it in.

Why less-on-the-table works for both

The mechanism is, I think, genuinely shared between the toddler and the model, and it isn’t a cute analogy, but the same constraint.

Attention is the scarce resource, not material. A language model has a finite budget for what it can actively reason over; pile in more and the budget gets spent on suppression instead of thinking. A three-year-old has a much smaller such budget and far less ability to self-suppress. Every visible toy is a small open tab demanding a fraction of an executive-function system that is, at three, barely online. Twenty open tabs on a brand-new processor is not abundance. It’s a denial-of-service attack with good intentions behind it.

Clear the table and the same system that looked scattered suddenly looks capable — because it was capable the whole time, just overcommitted. The constraint wasn’t the size of what he could hold. It was how much he had to filter out to act.

The honest caveats

A few, because a clean arc is a warning sign:

This is days old, not a doctrine. I’m reporting an early result, not a parenting philosophy with a follow-up book. Calm baselines have a way of eroding, and I fully expect to be re-running this reset on a schedule rather than declaring victory once.

The goal isn’t a barren room forever. It’s rotation — a small, curated set of materials at a time, refreshed deliberately, the way you’d assemble a tight prompt for a specific task rather than dumping your entire hard drive into the input. Curation, not deprivation.

And the screen is still the strongest thing in the room. Khan Academy Kids wins a free choice more often than the books do, because it’s engineered to. Filtering the context narrowed what the screen is here; it didn’t make the crayons more magnetic than a tablet. I’d be overselling this badly if I claimed otherwise.

The takeaway for the rest of us

If you work with these models, you already know the move: when the output degrades, your instinct to add more context is usually exactly backwards. Take things out. Curate. Trust that the signal is in there and your job is to stop burying it.

It turns out that’s also a parenting move. The next time the play in your house tips from engaged into chaotic, consider that the problem might not be too few options. It might be too many — a context window stuffed past the point where a small, still-booting mind can find the one thing it actually wants to do. Clear the table. See what gets through.

The structured, deliberately-curated version of all this — a small set of materials and one build per week, by design — is 12 Weeks of Tech Projects for Toddlers. It is, in a real sense, a context filter in book form. At buildwithyourkid.com.

Most home software starts in the wrong place. It wants to assign chores, track habits, and produce a dashboard. The house slowly acquires another surface to maintain, which is an impressive solution to the problem of already having too much to maintain.

The real bottleneck in a home is usually mental overhead.

Dinner. Library books. Tomorrow’s appointment. The cup the toddler can reach. The tape that used to be in the drawer before the cardboard elevator project. The shoes that only matter on Sunday morning.

If one parent carries all of that in live memory, the house only works until the parent gets tired.

The useful family agent probably starts smaller than most people imagine. Not with a weirdly anthropomorphic robot in the kitchen, but with a text reminder to put out church shoes on Saturday night.

That is not glamorous. Good.

Glamour is how you get a dashboard nobody opens.

The analog version already existed

Cheryl Mendelson’s Home Comforts is almost 900 pages of household state made visible.

It covers bedding, stains, food safety, fabric care, dust, china, fire, law, closets, and the unglamorous mechanics of keeping a home livable. OpenLibrary’s back-cover summary lists things like folding fitted sheets, reading care labels, keeping surfaces free of food pathogens, and making up a bed with hospital corners.

That is not lifestyle content.

It is a maintenance manual for the machine everyone lives inside.

A good household reference book does not do the laundry for you. It makes the why and how legible enough that someone else can learn it.

That is what most family tech misses. The goal is to stop making one parent the database, not to automate the parent out of the home.

A house is a context problem

Parents are constantly deciding what belongs in view:

• What matters today?

• What can wait?

• What does the child need to reach without asking?

• What needs to be remembered next time?

• What should not become a permanent rule?

This is why a household board is more interesting than a chore chart.

A chore chart says who has to do what.

A household board says what the house currently knows.

Dinner. Homeschool block. Library day. Grandparents visit. Packing list. Church shoes. The thing that always gets remembered ten minutes too late.

Once that state is visible, people can act without querying the parent who happens to be carrying the whole room in her head.

A useful family agent forgets on purpose

A family agent that remembers everything is not helpful. It is a surveillance scrapbook.

The household board only works because the parent edits it. Wednesday’s reminder is gone by Thursday. The Sunday-shoes rule is there until the kid outgrows the shoes. Most of what runs the house is a small set of facts that expire on a schedule the parent quietly knows.

The machine has to know the same things, with the same shelf life:

• Who added this, and when?

• Does it still apply next week?

• What would make it false?

• Should it be visible to everyone, or just the parent?

“He likes airplanes” is useful until it becomes stale.

“Pack church shoes on Saturday night” is useful until the routine changes.

“He melted down after a late snack” might be a pattern, or it might be Tuesday.

The machine should not convert ordinary childhood into a permanent profile.

Multi-agent only matters when the boundaries are real

This is where multi-agent systems get less silly.

Most agent demos split roles because org charts are easy to draw. Planner agent. Researcher agent. Writer agent. Manager agent. Congratulations, the bureaucracy has learned JavaScript.

The useful split is boundary design, not roleplay.

One agent to handle household memory. One to handle calendars. One for meal planning. One for homeschool notes. They do not all need the same tools, the same data, or the same retention rules.

The meal agent does not need private homeschool observations.

The homeschool agent does not need purchasing history.

The calendar agent should not rewrite your business website.

The boundary is the safety mechanism.

What I would actually build for home

Start with a wall-mounted daily view:

• Dinner

• Homeschool plan

• Appointments

• Library books

• Delivery windows

• Tomorrow after 5:30

• The one thing we forget every time

Then add memory, carefully.

Not “remember everything about the family.”

Remember recurring situational needs. Remember where the system got them. Let the parent edit them. Let the parent delete them. Surface the right ones at the right time.

A Saturday evening rule with useful context might look like this:

Source: parent added after two Sunday morning shoe searches.

Condition: Saturday after dinner.

Surface: wall display and parent phone.

Text: "Put church shoes by the door."

Delete: one tap when the reminder becomes routine.

That is the family AI I want.

Not another place to check.

Not a chatbot with a chore-chart costume.

A home surface that stops making the parent the only API.

The agent can hold the state. It cannot do the building. For the part where you and your kid actually make something together, I wrote a twelve-week project curriculum — hands-on activities for ages 2-6, designed to run in the margins of a normal week. No coding required.

My 3-year-old doesn’t know what AI is.

He knows that mom sometimes talks to her watch, scribbles in a notebook, and that things happen because of it — a game appears on his computer, groceries show up, a recipe prints itself. He thinks this is normal. He’s right.

The strange part is not that I use an AI agent. The strange part is that, for a while, the only way to talk to it looked exactly like not being present.

My phone is the command surface for half my life: messages, calendar, email, notes, photos, reminders, shopping lists, maps, drafts, everything. It is also the most attention-capturing object in the house. Every time I picked it up to send a one-line instruction that would save me an hour later, my son saw the same thing every child sees when a parent picks up a phone:

Mom chose the rectangle over him.

The task got done. Something else got lost.

So I started rebuilding the interface. Not because I wanted less technology, exactly. I wanted less visible extraction. The problem was not the agent. The problem was the surface.

The phone is the wrong interface for parenting hours.

What the agent does

I run Hermes, an AI agent framework that gives me a persistent assistant I can talk to over iMessage. In practice, it handles the boring connective tissue of family life: email summaries, meal planning, homeschool tracking, draft capture, reminders, research queues, and small logistics that otherwise accumulate in my head until they become fog.

The default interface, though, was texting. Which meant picking up my phone. Which meant unlocking the black hole.

One quick instruction became one notification. One notification became one glance at email. One glance became ten minutes of tiny unrelated decisions. Even when I resisted that slide, the visual signal had already been sent. My son could not tell the difference between “Mom is ordering groceries” and “Mom is doomscrolling instead of playing Lego.”

He saw the rectangle.

So I moved the commands somewhere else.

Fast capture: the Watch

For quick, disposable commands, I use my Apple Watch.

Raise wrist, dictate, lower wrist. Three seconds of talking to my arm, then I am back to the block tower, the train track, the argument about whether the tiny plastic wrench belongs in the car wash or the garage.

On the other end, Poke gets the iMessage and executes. That turns the Watch into a real command surface, not just a smaller keyboard.

This is perfect for the mental lint that otherwise sticks to me all day:

“Add printer paper to the shopping list.”

“Remind me after bedtime to order the replacement tracing paper.”

“Capture this: he said the red car game needs a mountain road, not a racetrack.”

None of those thoughts need to set off a scroll session. All of them need to not be lost.

The Watch is not a universal interface. Dictation mangles technical terms and unusual names. It is terrible for reviewing anything longer than a sentence. Nobody should edit a draft on a screen the size of a cracker.

But for the eighty percent of commands that are just load-bearing scraps, it is exactly right. My son sees a raised wrist and a sentence. Then he gets me back.

Slow capture: the notebook

For anything that needs to think before it becomes a command, I use paper.

I use an inq pen that digitizes handwriting from a dot-pattern notebook. I write by hand, it transcribes the page, and I can send the result into the Hermes pipeline later.

This is my favorite interface because it changes the social meaning of the act.

A parent with a phone looks absent, even when she is doing something useful. A parent with a notebook looks like a parent with a notebook. Kids read that difference long before they can explain it.

The notebook is where I put thoughts that need a little oxygen: post ideas, observations from homeschool, weird things my son says that might become an essay later, the outline of a project, a question I want the agent to research after bedtime.

A typical version looks like this:

He says something during play. Maybe he is debugging a game in toddler language: “No, the car has to jump from the mountain, not the road.” I do not open my phone. I write the sentence down. Later, the note gets routed to Hermes. The agent files it under the relevant project or turns it into a draft seed. At night, when I am actually in a work window, the thought is waiting for me.

The important part is not the transcription. The important part is that I did not have to hold the thought in my head, and I did not have to disappear into a screen to preserve it.

The thought was captured. The moment stayed intact.

A pocket notebook would do most of this. So would index cards, a kitchen whiteboard, or a paper planner. The smart pen is convenient, but the principle is older than every device in this stack: write it down somewhere that does not open into the internet.

No capture: scheduled work

The best interface is no interface at all.

A lot of what my agent does should not require a command from me in the first place. Hermes runs scheduled tasks: checking email at intervals, monitoring mentions, building overnight summaries, reminding me about recurring household things, preparing reports while I sleep.

This is the part people underestimate. Automation is not just about saving the minutes spent doing the task. It removes the decision point before the task.

I do not have to remember to check email. I do not have to decide whether now is the moment to scan for something important. It happens on schedule, and I get a summary when something matters. Cognitive load stops existing.

This is also where the system becomes least visible to my child, which is the point. The cleanest command surface is the one he never sees because it never asks me to stop playing in the first place.

The rule underneath the gear

You don’t need Hermes, an inq pen, or an Apple Watch. The principle is interface design, not gear.

Move recurring work off your hands. Whatever you check daily — email, calendar, the school portal, a delivery window — should come to you, not the other way around. Cron jobs, iOS Shortcuts, scheduled emails to yourself, a smart speaker routine. Anything that converts “I need to remember to check this” into “it’ll show up when it matters.” That’s the cron-jobs idea without the infrastructure.

Pick a not-phone surface for live capture. The Watch and the pen work because they don’t look like scrolling. A pocket notebook does the same thing. A whiteboard on the fridge does the same thing. The input device your child sees you use shouldn’t be the same shape as Instagram.

Batch the phone into windows. Morning, midday, after bedtime. Between those windows, the phone is in another room. This is the rule that makes the rest possible. Without it, every “quick check” turns into ten minutes of something else.

Design for what they see. Your kid can’t tell the difference between “mom is doing something important” and “mom is scrolling.” They see the rectangle. Pick the interface that sends the message you actually want them to receive.

What my son sees

Right now, my son sees a mom who writes in notebooks, talks to her watch sometimes, and gets things done without staring at a screen.

When he is older, I will show him the infrastructure. I will show him the agents, automations, message routing, draft queues, and all the strange machinery humming underneath ordinary family life.

For now, he sees the outcome: a parent whose attention returns quickly.

That’s the output I’m shipping.

If you want a structured starting point for the screen-free part of the day, I wrote a twelve-week project curriculum at buildwithyourkid.com — hands-on building activities for ages 2–6, field-tested on a real preschooler. No coding required, screens optional. The same principle applies there too: the interface matters. Start with the world your child can touch, then let the technology support the thinking instead of swallowing the room.

A 2026 BSM Media survey found that 66 percent of U.S. mothers had used AI tools to find product ideas or parenting tips. The number is not shocking. Mothers are tired. Searching the web is wading through sludge. A machine that can make the next decision easier will get used.

But a tool used in front of a child becomes part of the environment. Environments teach.

Your child learns from you

If a parent asks a machine every question, the child learns where answers come from.

If the machine answers instantly, the child learns how long not-knowing should last.

If the adult never checks the answer, the child learns confidence is evidence.

If a chatbot behaves like a perfect friend, the child learns a strange thing about people: that the best ones never need anything from you.

None of this requires a villain.

It only requires defaults.

Software people should be the least surprised by this. Defaults are decisions. The path of least resistance was designed by someone. If the product lives in your home, its defaults become part of your home.

Put AI behind the parent

UNICEF’s 2026 interview with Harvard researcher Ying Xu lands because it does not flatten the issue. AI can help children explore. It can also crowd out sleep, schoolwork, friendship, and productive struggle.

Productive struggle is the part adults are tempted to optimize away.

A child asks a question. The machine can answer. The well-meaning parent can make the friction disappear.

But the friction is often the lesson.

The child guessing first. The child trying the wrong category. The child sounding out the word, getting annoyed, looking at your face, and trying again.

That is not inefficiency. That is the work.

This is where AI tools for young kids need a colder design rule: help the adult, don’t hand the kid answers.

The broader AI tutoring debate keeps circling the same problem. AI is a great tool for spotting patterns, suggesting lessons and materials, or turning your kid’s current obsession into an educational game. It can even remind the parent that the blocker might be hunger, not phonics.

The parent is the better teacher.

Use a protocol, not vibes

In Early Childhood Matters, Daanish Masood describes building an AI model for bedtime stories with his four-year-old son. The model draws from texts that matter to his family, including Rumi and the Tao Te Ching.

The custom model is the flashy part. The protocol is the useful part.

He uses it with his son. He checks sources. He treats the machine as fallible. His son calls it “robot” and corrects it when it wanders off.

That is not outsourcing.

That is a parent using a tool in the child’s presence while keeping the relationship intact.

You can do the same without training anything.

Ask the child first.

Use the tool together.

Say out loud when the machine may be wrong.

Make the answer point back to a book, a block tower, a drawing, a walk, a real object.

The screen should open a door into the room, not replace the room.

Edit the syllabus

The invisible curriculum is the accumulation of small lessons your child absorbs from the environment around him.

How fast answers arrive.

Who gets trusted.

Whether adults verify claims.

Whether hard thinking gets preserved or paved over.

Whether technology serves the family, or the family quietly rearranges itself around the technology.

I want a child who knows what job a tool has, what job it does not have, and when the human is still responsible.

The machine will not put itself in its place. That is the parent’s job.

The cleanest override is a real activity in the room. I wrote a twelve-week project curriculum for ages 2-6 — hands-on building, no screens required, designed so the parent stays the teacher and the tool stays the tool. It is the syllabus for the part of the day you do not want the defaults to write.

I spent twelve years writing software before I left a director-level position and stayed home. I have seen what makes an engineer actually good at reasoning — and it is not the toy they had at age four. It is whether someone taught them to break a problem apart, handed them something that doesn’t work, and stayed in the room while they figured out why.

No toy does that. You do.

What the research is actually finding

In March 2026, Lancaster University and the Micro:bit Foundation launched the Micro:bit Innovation and Research Lab (MIRL), a formal effort to scale hands-on computing education with evidence behind it. The micro:bit program has already distributed 11 million devices across 85 countries, reaching over 70 million children. The reason they built a research lab instead of just shipping more units is telling: distributing devices is not the same as building thinkers.

The IDC 2025 study on Bit:sort — a physical sorting activity designed for fourth graders — found something that should reframe how you think about early computing education entirely. Kids demonstrated genuine algorithmic reasoning through physical play even when they could not verbalize it. They were thinking in algorithms before they had language for it. The reasoning came from doing, not from being told.

The TMAR study pushed this further. When students were asked to generate their own challenges rather than complete preset ones, they showed significantly stronger gains in abstraction, decomposition, and algorithmic reasoning — the three pillars of computational thinking. Student-generated problems outperformed instructor-assigned problems on every metric that matters.

The kids who made the problems got smarter than the kids who solved them.

Why this matters if your kid is under six

The STEM toy market has a widely acknowledged gap for ages two to three. Most products either aim at babies (sensory, no logic) or school-age children (screen-based, app-dependent, increasingly passive). The shift that researchers and educators are watching — away from app-dependent toys and toward open-ended, screen-free, reusable play — is a direct response to evidence that passive engagement does not build reasoning skills.

For a three-year-old, the foundational moves are not about a specific device. They are about learning to notice patterns, test a hypothesis, hit a dead end, and try again. That loop is the thing. The physical substrate — blocks, magnet tiles, a simple circuit, a game you build together — matters far less than whether the child is the one deciding what happens next.

Handing a child an AI toy that responds to them is not the same as handing them a problem that does not respond at all until they figure it out.

The build-together advantage

Here is what changes when you sit down and make something with your kid instead of setting them up with something that was made for them.

First, narrate your own thinking out loud. “Hmm, this isn’t doing what I expected — why might that be?” Your child learns that uncertainty is not a failure state. It is just the next step.

Second, the challenge is theirs to define. The TMAR research is clear that self-generated challenges produce better outcomes than preset ones. When your kid says “I want to make a game where the cars race and crash into each other,” it’s not just chaos. That is the child setting the parameters. Your job is to help them build toward it.

Third, you are not replaceable by an app. The relationship is the scaffold. Research on early learning consistently shows that co-regulation — an adult’s calm presence modulating a child’s frustration tolerance — is what allows children to stay with hard problems long enough to solve them. A toy cannot co-regulate. You can.

The AI toy will not sit with your kid while they hit a dead end for the seventh time and keep their voice level while asking what they want to try differently. Toys are built to respond in a believable way, not to teach. That is not a feature gap. It is a category error.

What this looks like in practice

If you want a structured starting point for building with a child under six, I wrote a twelve-week project curriculum — physical and digital projects designed for the pre-reader age range, built around the exact principles the research supports: child-directed challenges, hands-on iteration, parent presence as the scaffold. It is practical and week-by-week, not theoretical.

The projects do not require any prior programming knowledge. What they require is your time and your willingness to be genuinely curious alongside your kid.

You were already the advantage. You just needed the roadmap.

When the room is bright and loud, it’s playtime. When the toys are out, it’s building time. And when everything is still bright and loud at 7:45pm, it’s “I AM NOT TIRED” time — which is a lie, but a lie delivered with such conviction that it’s almost admirable.

The shift happened when I stopped treating bedtime as a negotiation and started treating it as a systems problem. The variable wasn’t my son’s willingness to sleep. The variable was every environmental signal telling him it was still daytime.

So I automated the environment. And it changed everything — not just bedtime, but how I think about the repetitive infrastructure of parenting.

The Bedtime Sequence

Here’s what happens automatically in our house every evening:

• 6:00pm — Lights shift from cool white to warm. Subtle enough that nobody notices.

• 6:30pm — Lights dim to 50%, go amber. This is the signal. The room itself says “we’re winding down.”

• 7:30pm — Down to 20%. Warm orange. The day is ending whether you’re ready or not.

• 8:00pm — Living room dark. Bedroom nightlight on.

The transition is gradual enough that there’s no hard cutoff to fight against. By 7:30 the vibe has shifted and the bedtime routine feels natural instead of imposed. No cajoling, no sticker chart negotiations, no “five more minutes” loop. The house is the authority, not me.

I automated the environment and spared myself from being the bedtime police. That’s systems thinking applied to a three-year-old, and it works better than any strategy I’ve tried.

The Stack (It’s Simpler Than You Think)

I’m running Home Assistant on a Raspberry Pi with Zigbee bulbs. That sounds more complicated than it is. The reality:

• Buy smart bulbs. Screw them into existing lamps.

• Plug in a Raspberry Pi.

• Set up automations: “at 7pm, make the living room warm.”

• Walk away.

The whole thing took an afternoon to set up and has run without intervention for months. You don’t need to be a software engineer to set this up (trust me, I am one) — the Home Assistant setup wizard does most of the work.

The point isn’t the technology. The point is that every evening, while other parents are in the trenches of bedtime negotiations, my house is handling it and I’m free to just enjoy winding down and reading to my kid.

Morning Autopilot

The gap between “awake” and “functional” is the most dangerous period of my day. My son wakes up at 100% energy. I wake up at... well, when you have young kids I think about 12% is as good as mornings get.

Let the house handle the it:

• 6:30am — Set up a smart plug that fires the coffee maker (prepped the night before).

• 7:00am — Lights start a 30-minute sunrise ramp. No jarring brightness.

• 7:30am — Full daylight (and I’ve had some coffee by now).

By the time he’s raring to go, the coffee is kicking in, the house is lit, and I’ve had five minutes to exist as a person before I become a parent. That five-minute buffer is the difference between patience and survival mode.

The Compound Effect

Every decision I automate is one I don’t spend mental energy on. And mental energy is the real scarce resource.

Being a parent to a toddler involves 400 micro-decisions per day. What to eat, what to wear, when to go outside, how to redirect a tantrum, which book to read, whether the snack is too close to dinner. Every one of those decisions draws from the same finite cognitive pool.

Automating the predictable stuff — lights, coffee, routines — doesn’t save hours. It saves decisions. And when you’re trying to build something meaningful in a 90-minute window after bedtime, you need every scrap of cognitive capacity you can get.

The house handles lights. I handle the architecture.

The Systems Thinking Connection

There’s a thing that happens when you start automating your home: your kid notices.

My son now understands, on some level, that the house “knows” when it’s bedtime. The atmosphere changes. Things happen on a schedule. He doesn’t know the word “automation,” but he’s experiencing it — the idea that systems can handle repetitive tasks so humans don’t have to.

That’s the seed of computational thinking right there. Not in a curriculum or an app. In his own house, running on a Raspberry Pi in the closet.

When he’s older and I explain what an algorithm is, he’ll already know: “Like how the house turns the lights warm at bedtime,” will make perfect sense.

Where to Start

If bedtime is a battle: automate the lights. The gradual dimming does more than any sleep consultant advice I’ve tried.

If mornings are chaos: smart plug on the coffee maker. One plug, one automation, life-changing.

Don’t overhaul your house. Pick the friction point that drains you most. Automate that one thing. Live with it for a week. When you realize the house just handled something you used to spend energy on, you’ll understand why I automated the next thing. And the next.

That’s how systems thinkers parent. We don’t grind through problems. We build infrastructure so the problems solve themselves.

If you're building alongside your kids, check out 12 Weeks of Tech Projects for Toddlers — a parent's guide to computational thinking at age 2+.

Not casually interested. Obsessed. He knows the pickup schedule for our neighborhood. He can identify the squeal of its brakes from half a block away.

Every garbage day morning, we stood outside and watched the garbage truck like other families watch fireworks.

So when I wanted to introduce him to computational thinking — to start building the foundation for tech projects together — I had a choice. I could follow a curriculum: “Week 1: Learn about colors. Week 2: Learn about shapes. Week 3: Learn about sequences.”

Or I could follow the garbage trucks.

I followed the garbage trucks. And it changed everything.

The Curriculum Trap

There’s a whole industry of “teach kids to code” products, and most of them share the same structure: a predefined sequence of lessons that march through concepts in a logical order. First you learn this, then you learn that, then you combine them.

It makes sense on paper. It’s how we organize knowledge in computer science courses. Prerequisites before advanced topics. Building blocks stacked in order.

The problem is that toddlers and young kids don’t care about your logical order. They care about what they care about. And what they care about changes by the hour, but at any given moment, it’s intense.

When my son cares about garbage trucks, he will sustain attention on garbage truck-related activities for an astonishing amount of time. Thirty minutes. Forty-five minutes. That’s an eternity in toddler time. He’s asking questions, making connections, retaining information.

When he doesn’t care about something? You get maybe thirty seconds before he’s upside down on the couch asking for a snack.

So why would I fight that? Why would I try to make him care about abstract shapes on a screen when he already cares — deeply, passionately — about garbage trucks?

Interest as an Engine

Here’s what interest-led learning looks like in practice:

The concept I want to teach: Sequencing (step-by-step instructions)

Curriculum approach: “Let’s learn about sequences! Here’s a cute robot. Drag the arrows to make it walk to the star.”

Interest-led approach: “What does the garbage truck do first when it gets to our house? Then what? Then what? Can we make a garbage truck game that does all those steps?”

Same concept. Wildly different engagement.

In the interest-led version, my son was practically vibrating with excitement. He described the garbage truck’s entire pickup sequence from memory — pulls up, extends the arm, grabs the can, lifts, dumps, lowers, releases, drives to the next house. That’s an eight-step algorithm, and he generated it himself because it was about something he cared about.

In a curriculum, someone else defines the problem. In interest-led, the kid defines the problem. Guess which one produces better learning?

But What About Coverage?

This is the question I always get from other developer parents, because we’re wired to think in terms of completeness. “If you just follow interests, won’t there be gaps? What about concepts they never naturally encounter?”

Here’s what I’ve found: if you’re creative about it, you can teach almost any foundational concept through almost any interest. The only prerequisite is knowing them well-enough yourself to spot the opportunities.

Garbage trucks can teach:

• Sequencing: The pickup routine

• Conditionals: “What if the can is too heavy? What if it’s recycling day?”

• Loops: “The truck does the same thing at every house on the street”

• Debugging: “What if the arm misses the can?”

• Pattern recognition: “Which streets does the truck go to on which days?”

• Decomposition: Breaking down the full route into individual stops

That’s basically an entire basic algorithmic thinking curriculum, delivered through a single interest.

And here’s the thing about gaps: they fill naturally. Because kids’ interests change. Garbage trucks this month, airplanes next month, space the month after. Each new obsession is a new vehicle (pun intended) for the same underlying concepts, reinforced in a different context.

That’s actually better than a curriculum, which teaches each concept once and moves on. Interest-led learning revisits core concepts over and over, in varied contexts, which is how durable learning actually works.

The Developer Analogy

Think about how you learn best as a developer.

Have you ever tried to learn a new framework by reading the docs from page one to page done? How’d that go? You probably retained about 15% and forgot the rest by the time you needed it.

Now think about a time you learned a framework because you needed it for a project you cared about. You had a problem, the framework solved it, and you learned exactly what you needed as you went. You probably retained way more, and the learning was faster and more enjoyable.

That’s interest-led learning. It’s how adults learn best, and it’s how kids learn best. The only difference is that adults can sometimes force themselves to grind through boring material. Kids can’t. And honestly, why should they?

How to Do It

If you want to try interest-led tech learning with your kid, here’s the practical approach:

1. Identify the current obsession. What does your kid talk about nonstop? What would they choose to do all day? That’s your vehicle.

2. Map concepts to the interest. Take the computational thinking concepts you want to introduce (sequencing, patterns, conditionals, decomposition, debugging) and brainstorm how they connect to the obsession. I promise they do.

3. Let the kid drive. Don’t say “let’s learn about patterns using trucks.” Say “hey, I noticed the garbage truck always goes to the same houses. Does it go in the same order? Why?” Let the concept emerge from the conversation.

4. Build something. This is where it gets really powerful. “Want to make a garbage truck game?” takes the interest and adds creation. Now your kid isn’t just learning concepts — they’re applying them to build something they actually want to exist.

5. Follow tangents. If you’re building a garbage truck game and your kid suddenly wants to add a dinosaur that rides on top, go with it. The tangent is just another interest expressing itself. The concepts still apply.

The Hard Part

I’ll be honest: interest-led is harder in some ways for the parent than curriculum-led. A curriculum tells you what to do each day. Interest-led requires you to improvise, to find the computational thinking in whatever your kid is currently obsessed with, to think on your feet.

But it’s also more fun. Because you’re responding to a real kid with real enthusiasm, not marching through someone else’s lesson plan. And the results speak for themselves: deeper engagement, better retention, and a kid who associates learning with their favorite things instead of with obligation.

And if the only thing they retain from your lessons is a love of learning, that’s more than enough.

Subscribe now

I used to be an engineering director with a calendar full of deep work blocks and a standing desk in an office where I’d be unbothered for hours. Now my office is the kitchen counter, my sprint window is the gap between bedtime and when I physically cannot stay awake, and my ever-present co-founder is three years old.

Here’s a little of what I’ve shipped in the last few months from that kitchen counter: a book, a newsletter with weekly posts, a product line on Gumroad, multiple open source tools, and a daily content operation across three platforms. Not because I’m grinding 12-hour days, but because I stopped being the one who does the work and started being the one who reviews it.

Here’s how I’ve set myself up to create the time to ship where none exists.

The reframe that changed everything

The biggest unlock wasn’t a tool. It was a mental model shift.

I used to think my job was: research, write, build, design, post, promote, respond. All of it. Every day. In my 90 minutes. No wonder nothing shipped.

Now my job is: communicate intent, review, and approve. That’s it. I went from creator to editor. From builder to architect. From the person pushing code to the person reviewing pull requests.

The work still gets done. It just doesn’t require me to be the one putting in the hours.

The async everything stack

Here’s my actual setup. None of this is theoretical — I run this daily.

OpenClaw + iMessage: The async command layer

I have an AI agent (OpenClaw) that I talk to over iMessage. I text from my phone. While my kid plays. While I’m at the park. While I’m making lunch.

I don’t sit at a computer to manage my pipelines. I text “schedule the new posts” from the playground and it happens. I text “show me the overnight report” and I get a summary of what got done while I slept. I text “draft an about page using these two files” and I review the output when I have five minutes.

The key insight: iMessage is low-friction. I don’t need to get to my laptop, open a terminal, or log into a dashboard. The tool lives where I already am — in the same app I use to text my husband and my mom. My phone is in my pocket. The cognitive overhead is near zero.

Cron jobs: The night shift

While I sleep, automated jobs run:

• Content research: My agent browses, researches new ideas, and outlines notes and posts. I wake up to a summary of what was explored and new markdown files waiting for my review.

• Research: A nightly scan of HN, dev Twitter, and niche blogs compiles a research digest on topics I’m tracking. It’s my own personal-interest-filled, high-signal newsletter. I read it over coffee.

None of these require me to be awake. I set the schedule once. They run. I review the output in the morning.

The morning routine isn’t “sit down and figure out what to do today.” It’s “review what’s already been done and approve what ships next.”

The content pipeline: from creator to reviewer

Here’s what a typical day looks like:

7am: I text “gm.” My agent sends me the overnight report — what drafts were written, what research was compiled, what tasks were completed.

Throughout the day (in 2-minute bursts): I review on my phone. “This is good, queue it.” “Turn this post into a tweet.” A rambly stream-of-consciousness moment about something that happened with my 3yo becomes a new article. My involvement goes from hours of writing to a few minutes of grammatically-imperfect notes.

After bedtime: This is my only real focus block. But because the research is done, the drafts exist, and the admin is handled, I can spend it on the ONE thing that actually needs my brain: writing the newsletter post, editing the book, or building something new. The 90 minutes isn’t diluted across twenty tasks. It’s concentrated on the one task I can’t delegate.

The principle: decouple work from presence

The operating principle behind all of this: your work and your schedule need to be decoupled in time.

The content gets drafted at 1am by an agent. I review it at 10am from my phone. It posts at 2pm automatically. A visitor reads it at 8pm and becomes a customer. At no point did I need to spend one-on-one time with that customer to make a sale.

This is what makes the parent-developer life viable. Not “hustle harder” or “wake up earlier.” Definitely not Pomodoro timers. Just: build systems where the work happens when you’re not there, and your job becomes directing the intent and reviewing the output.

What you actually need

The specific tools matter less than the pattern. But since people always ask:

• An AI agent you can talk to async (I use OpenClaw over iMessage, but the concept works with any tool that doesn’t require you to be at a desk)

• Scheduled automation for anything repetitive (cron jobs, Zapier, whatever — the point is it runs without you)

• A review queue, not a to-do list — your daily work is approving and editing, not creating from scratch

• One focus block that’s protected for the work only you can do

The 90 minutes isn’t the limitation. The 90 minutes is enough — if you’re not wasting it on things a system could handle.

The unfair advantage

Here’s what the solopreneur Twitter crowd misses about parent-developers: the constraint IS the advantage.

When you have 90 minutes, you don’t over-engineer. You don’t build features nobody asked for. You don’t spend three hours picking a font. You ship the thing that matters and you ship it now, because bedtime is a hard deadline and toddlers don’t have a pause button.

I’ve shipped more in the last few months with 90-minute windows than I did in some quarters with a full engineering team. Not because I’m faster. Because I’m forced to be focused. I can’t afford feature creep or busy work. No slack time means no wasted time.

Every parent-developer already has this skill. You’ve been project managing under uncertainty since the day your kid was born. You just need systems that let you use your scarce time on decisions instead of execution.

The tools exist. The hours don’t need to. You just need to stop being the one who does the work and start being the one who decides what ships.

This is the TOOLS pillar of Raising Pixels — the parent developer’s toolkit. I write about computational thinking for kids, hands-on building projects, and the workflows that make it all possible when your coworker is three.

Subscribe now

There’s no shortage of developmental milestone charts. Rolling over by 4 months. First words by 12 months. Riding a bike by 5. Pediatricians have these mapped to the month.

But computational thinking? The skill set that arguably matters more than any other in the 21st century? Just vague advice to “introduce coding” at some undefined future date, usually involving an 8-year-old, a $200 robot, or a lot of screen time.

When I went from engineering director to SAHM, I realized that computational thinking isn’t some vague future course you’ll have to remember to enroll your kid in. Toddlers do it every day when they play with blocks, decide which clothes to wear, or negotiate for “one more story.” So I wrote the guide to toddler CS milestones that I couldn’t find.

This isn’t academic theory (though the research backs it up — Marina Umaschi Bers at Boston College has been studying computational thinking in early childhood for over a decade, and Jeannette Wing’s foundational paper on computational thinking made the case that it’s a universal skill, not just a CS major thing). This is what I’ve watched happen with my own kid, mapped against what developmental science tells us to expect. If your child is doing some of these things and not others, that’s normal. Kids aren’t firmware updates. They don’t all install features on the same schedule.

But it’s useful to know what you’re looking at.

Age 1-2: The Hardware Installation

Think of this phase as your child’s operating system booting up. They’re not “doing” computational thinking yet in any way you’d recognize. They’re building the prerequisite hardware: cause and effect, object permanence, basic categorization.

What you’ll see:

• Cause and effect loops. Drop the spoon, it falls. Drop it again, it falls again. Drop it thirty-seven more times because apparently the experiment needs replication. This is your child discovering that actions have predictable, repeatable outcomes — the absolute foundation of algorithmic thinking.

• Basic sorting by single attribute. Putting all the red blocks in one spot. Pulling all the books off the shelf (organizing by... accessibility?). They can group by at least one feature: color, shape, size.

• Sequential imitation. Copying a two-step action: open the cabinet, pull out the pot. They can’t invent sequences yet, but they can replicate short ones. That’s the beginning of following instructions — which is the beginning of understanding what instructions are.

• Trial and error without strategy. They’ll try to fit the square block into the round hole repeatedly, then accidentally succeed with the right one. No hypothesis yet. Just brute force. (But honestly, I’ve seen senior engineers debug this way too.)

What you won’t see (and that’s fine):

Planning. Abstraction. Multi-step reasoning. The prefrontal cortex is barely online. Don’t worry about it.

What to do:

Narrate cause and effect. “You pushed the ball and it rolled!” Name categories out loud: “That’s a big one. That’s a small one.” Let them fail at shape sorters. Some frustration is a motivator for learning.

Age 2-3: First Programs

This is when it gets interesting. Language explodes, and with language comes the ability to describe sequences, not just imitate them. Your child starts writing their first programs — they just don’t know it.

What you’ll see:

• Verbal sequencing. “First shoes, then outside.” They can describe a 2-3 step plan before doing it. This is pseudocode. Actual, literal pseudocode, just spoken by someone who pronounces “spaghetti” as “pasketti.”

• Multi-attribute sorting. “Big red cars here, small red cars there.” Two sorting criteria at once. This is a compound query. SELECT * FROM toys WHERE color = 'red' ORDER BY size.

• If/then reasoning (basic). “If it’s raining, we need boots.” They start predicting outcomes based on conditions. It’s not consistent yet — they might also predict that putting on boots will make puddles appear — but the structure of conditional logic is emerging.

• Pattern completion. Red, blue, red, blue, red. They can extend a simple AB pattern. Some kids start inventing their own patterns: “car, truck, car, truck.” This is the absolute seed of algorithmic thinking — recognizing a rule and applying it.

• Debugging with intention. The block tower falls and instead of random retry, they adjust. Bigger block on the bottom this time. They’re forming hypotheses about why things failed, even if the hypothesis is wrong. The method matters more than the accuracy.

What you won’t see:

Nested logic (”if it’s raining AND cold, we need boots AND a coat”). Abstraction beyond the concrete. Long multi-step planning. They’re still very bound to the physical and the present.

What to do:

Ask “what happens next?” constantly. Let them narrate routines, steps, recipes. Play pattern games with anything — toys, food, sounds. When something breaks or fails, say “why did that happen? Let’s look!” before jumping to fix it.

Building with AI at 2-3

My son and I built his first browser-based games with Claude at this age. He described what he wanted, I translated it into a prompt, he played and learned that his ideas can become things. His first game (”Make a red car game! Make it jump!”) transformed his whole relationship with a screen from consumer to creator.

Age 3-4: The Abstraction Leap

Something shifts around 3. I watched it happen in real time with my son. Your child starts operating on representations of things, not just the things themselves. They can think about thinking. Not philosophically — they’re three — but functionally.

What you’ll see:

• Representation and symbols. A stick becomes a sword. A box becomes a car. A line of couch cushions becomes a train. They’re using physical objects as variables — stand-ins that represent something else entirely. This is abstraction. Not metaphorical abstraction. Literal, computer-science-definition abstraction: stripping away irrelevant details to work with a simplified model.

• Algorithm narration. Not just “first this, then that” — they start dictating complete procedures. My son will explain how to make his favorite snack in six steps, in order, and get annoyed if I deviate from the protocol. He’s spec-writing. He’s defining an API. He’s three.

• Conditional branching. “If you sit properly at the restaurant, we’ll get dessert. If you’re disruptive, we’ll leave.” They understand that different inputs produce different outputs. They may also start manipulating the conditions (”But I wasn’t THAT loud!”), which is honestly just penetration testing the parental permission system.

• Decomposition. “I want to build a BIG house.” Okay, what do we need? “A foundation. And walls. And a door. And a roof.” They can break a big goal into component parts. Not always correctly. But the instinct to decompose is there.

• ABC and ABB patterns. They move beyond simple alternation. Red, blue, green, red, blue, green. Or red, red, blue, red, red, blue. The pattern recognition engine is getting more sophisticated.

What you won’t see:

Recursive thinking. True loop comprehension (they do things repeatedly, but don’t conceptualize “repeat until”). Error handling beyond one level (”what if the BACKUP plan fails?”).

What to do:

Build things together. Anything. Block towers, art projects, simple games. The act of specifying what you want, breaking it into steps, and iterating when it goes wrong IS the computational thinking curriculum. Ask them to explain their creations to you. “How does it work?” is the most powerful question you can ask a 3-year-old.

Building with AI at 3-4

This is the age my son started describing more complex games he wanted to build and watching them appear on screen. The computational thinking isn’t in the code — it’s in the specification. “I want a game where you drive a train through a maze with the arrow keys and it should pick up fallen branches and bring them to the garbage dump.” That’s a feature spec. From a kid who puts his shoes on the wrong feet 40% of the time.

What’s Next

He’s 3. According to the developmental research (Bers, Wing, Frontiers in Education), ages 4-6 is where loops, nested conditionals, and genuine systems thinking emerge. Kids start creating rule systems, optimizing their own algorithms, and transferring abstract concepts between domains.

I’ll write about it when I see it. Subscribe and you’ll get the ages 4-6 edition the same week I live it.

The Point

None of this requires a screen, an app, a robot, or a subscription.

The entire curriculum is four things: narrate what’s happening, ask questions, let them fail, build things together.

The milestones aren’t checkboxes — your kid might be a pattern recognition wizard who couldn’t care less about sequencing. That’s fine. The value isn’t grading your child. It’s learning to recognize computational thinking when it’s already happening so you lean into it instead of past it.

It’s happening right now. With the blocks. With the spoon drops. With the twenty-minute negotiation about whether pants are required.

You just have to know what you’re looking at.

I wrote the book on this — literally. 12 Weeks of Tech Projects to Build With Your Kid is the hands-on curriculum that turns these milestones into weekly activities. 12 weeks of projects designed for ages 2-6. No coding required. No screen dependency. Just you and your kid, building things that teach them to think.

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!

— Diana

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.