DEV Community: Diana Park

The Package You Didn't Choose

Diana Park — Sat, 27 Jun 2026 13:00:00 +0000

Recent news has been full of npm supply-chain attacks, like the self-replicating worm researchers named Shai-Hulud, which compromised hundreds of packages, stole credentials and tokens off developer machines, and republished itself into other packages automatically. I read the coverage the way you read about a storm in another state. Then I tried to check whether I was exposed, and ran into a problem that was entirely my own doing: I didn't actually know what was installed on my machine.

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 lightly 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 Morning Runs Itself Too

Diana Park — Sat, 20 Jun 2026 12:40:26 +0000

The evening post was about shutdown: a system that winds the house down after 8pm so the adults can stop being routers. This is the other end. Mornings are the opposite problem entirely -- a cold start. Everything boots at once around here: a kid and two adults on variable amounts of sleep, breakfast, lights, and a day's kickoff with a hard 8am deadline. Here's the boot sequence that runs our 6-8am -- what's automated, what's deliberately not, and the one failure I had to roll back.

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. The 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, and 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, and 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's awake to want it -- lights blazing into empty rooms, the house performing its routine for an audience of zero. The one precious morning the three-year-old sleeps past six, the system is actively working to end it. So 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 -- so 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. 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. 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 chaos that remains is at least the irreducible kind.

The part no system fixes

And then there are the nights he's up three times, nobody's 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 the regular with devastating consequences. The system has never once prevented this. It just exists, fully automated, watching me drink yogurt coffee.

Home automation can at least hold the structure so the tired humans don't have to. What it can't do is 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 them, 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 -- 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.

Context Filter, Not Context Window

Diana Park — Sat, 13 Jun 2026 12:53:25 +0000

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 didn't 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. All that available context didn't add up to richer play; it added up to 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 so much as the same constraint showing up twice.

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 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 isn't abundance so much as 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 was never the size of what he could hold; it was how much he had to filter out before he could 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 was never a barren room forever. What works is rotation -- a small, curated set of materials at a time, refreshed deliberately, the way you'd assemble a tight prompt for a specific task instead of 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.

The Useful Family Agent Is Not a Chore Chart

Diana Park — Sat, 06 Jun 2026 12:50:53 +0000

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 that parent gets tired.

The useful family agent probably starts smaller than most people imagine. Not a weirdly anthropomorphic robot in the kitchen -- a text reminder to put out the church shoes on Saturday night. That's not glamorous, which is exactly the point. Glamour is how you end up with 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 a bed with hospital corners.

That's not lifestyle content. It's a maintenance manual for the machine everyone lives inside.

A good household reference book doesn't do the laundry for you. It makes the why and the how legible enough that someone else can learn them. That's the part 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 visiting. Packing list. Church shoes. The thing that always gets remembered ten minutes too late.

Once that state is visible, people can act on it 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 isn't helpful. It's a surveillance scrapbook.

The household board works precisely because the parent edits it. Wednesday's reminder is gone by Thursday. The Sunday-shoes rule stays until the kid outgrows the shoes. Most of what runs a 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 to the parent?

"He likes airplanes" is useful until it goes 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 shouldn't 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 for calendars, one for meal planning, one for homeschool notes -- and they don't all need the same tools, the same data, or the same retention rules. The meal agent doesn't need private homeschool observations. The homeschool agent doesn't need purchasing history. The calendar agent has no business rewriting 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, and 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, once the reminder becomes routine.

That's the family AI I want. Not another place to check. Not a chatbot in a chore-chart costume. A home surface that stops making the parent the only API.

The agent can hold the state. It can't 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.

How I Run an AI Agent Without Touching My Phone

Diana Park — Sat, 30 May 2026 12:41:28 +0000

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 isn't that I use an AI agent to handle mundane tasks so that I can have more quality time with my son. 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, all of it. It's 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 agent was never the problem. The surface was.

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 the small logistics that otherwise pile up in my head until they turn into fog. (What that household memory should and shouldn't hold is a question of its own.)

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 gone out. My son couldn't 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 task, lower wrist. Three seconds of talking to my arm, then I'm back to the block tower, the train track, the argument about whether the Lego police car ran into the Matchbox FedEx van or if it was the other way around.

On the other end of the iMessage, Poke handles the task or adds it to my Todoist for me to tackle later. That turns the Watch into a real command surface, not just a smaller keyboard.

It's perfect for the mental lint that otherwise sticks to me all day:

"Add printer paper to the shopping list."

"Remind me after bedtime to make new letter tracing sheets."

"Note that he said the red car game needs a mountain road, not a racetrack."

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

The Watch isn't a universal interface. Dictation mangles technical terms and unusual names. It's terrible for reviewing anything longer than a sentence. Nobody should edit a draft on a screen the size of a cracker (I tried).

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

Slow capture: the notebook

For anything that needs to percolate before it becomes a prompt, I use paper.

I use an inq pen that digitizes handwriting from a dot-pattern paper 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's 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 goes like this. He says something during play -- maybe he's debugging a game in toddler language: "No, the car has to jump from the mountain, not the road." I don't open my phone. I write the sentence down. Later, the note gets routed to Hermes, which files it under the right project or turns it into a draft seed. At night, when I'm actually in a work window, the thought is waiting for me.

The transcription isn't really the point. The point is that I didn't have to hold the thought in my head, and I didn't have to disappear into a screen to save it.

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 doesn't open doors to the internet.

No capture: scheduled work

The best interface is no interface at all.

A lot of what my agent does shouldn't 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 isn't just about saving the minutes spent doing a task. It removes the decision point before the task.

I don't have to remember to check email. I don't 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. The cognitive load stops existing.

This is also where the system becomes least visible to my child, which is the whole point. The cleanest command surface is the one he never sees, because it never requires 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 turns "I need to remember to check this" into "it'll show up when it matters."

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 job. A whiteboard on the fridge does the same job. 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's older, I'll show him the infrastructure -- the agents, the automations, the message routing, the draft queues, all the strange machinery humming underneath ordinary family life.

For now, he sees the outcome: a parent whose attention comes back quickly. That's the part worth 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.

Do Not Let The Defaults Raise Your Kid

Diana Park — Sat, 23 May 2026 12:35:59 +0000

Parents ask whether AI is good or bad for kids. I think the more useful question is what AI is teaching before anyone thinks to call it teaching.

A 2026 BSM Media survey found that 66 percent of U.S. mothers had used AI tools to find product ideas or parenting tips. That number isn't shocking. Mothers are tired, searching the web has become an exercise in wading through sludge, and a machine that makes the next decision a little easier is going to get used.

But a tool you use in front of a child becomes part of the environment, and environments teach.

Your child learns from you

Watch what gets absorbed. 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 is supposed to last. If the adult never checks the answer, the child learns that confidence is the same thing as being right. And if a chatbot behaves like a perfect friend -- always available, never needing anything back -- the child picks up a strange idea about people: that the best ones make no demands on you at all.

None of this requires a villain. It only requires defaults.

Software people, of all people, shouldn't be surprised by this. Defaults are decisions. The path of least resistance was designed by someone, and if the product lives in your home, its defaults quietly become part of your home.

Put AI behind the parent

UNICEF's 2026 interview with Harvard researcher Ying Xu holds up because it refuses to 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 most tempted to optimize away. A child asks a question, the machine can answer it, and the well-meaning parent can make the friction vanish in a second. But the friction is usually where the lesson lives -- the child guessing first, trying the wrong category, sounding out the word, getting annoyed, glancing at your face, and trying again. None of that is wasted motion; it's the lesson itself.

This is where AI tools for young kids need a colder design rule: help the adult, don't hand the kid the answer. The broader AI tutoring debate keeps circling the same point. AI is great at spotting patterns, suggesting lessons and materials, or turning your kid's current obsession into an educational game. It can even nudge the parent to consider that the blocker might be hunger rather than phonics. What it shouldn't be is the thing standing between the child and the struggle. The parent is still 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, drawing on texts that matter to his family -- Rumi, 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 the sources. He treats the machine as fallible, and his son, who calls it "robot," corrects it when it wanders off. That isn't outsourcing the relationship -- it's a parent using a tool in the child's presence while keeping the relationship whole.

You can do the same without training anything. Ask the child first. Use the tool together. Say out loud when the machine might be wrong. And make the answer point back to something real -- a book, a block tower, a drawing, a walk, an object you can hold. The screen should open a door into the room, not stand in for the room.

Edit the syllabus

There's an invisible curriculum running in every home -- the slow accumulation of small lessons a child absorbs from the world around them. How fast answers arrive. Who gets trusted. Whether adults bother to verify a claim. Whether hard thinking gets preserved or quietly paved over. Whether the technology serves the family, or the family slowly rearranges itself around the technology.

I want a kid who knows what job a tool has, what job it doesn't, and when the human is still the one responsible. The machine won't put itself in its place. That part 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's the syllabus for the part of the day you don't want the defaults to write.

The AI Toy Won't Teach Your Kid to Think

Diana Park — Sat, 16 May 2026 12:39:27 +0000

There's a $4.67 billion industry that would like you to believe the right toy will give your kid a head start in tech. The packaging says "coding." The app says "STEM." The price tag says this one is worth it.

I spent twelve years writing software before I left a director-level job and stayed home. I've seen what actually makes an engineer good at reasoning, and it has nothing to do with the toy they had at four. It comes down to whether someone taught them to break a problem apart, handed them something that didn't work, and stuck around 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 put 11 million devices into 85 countries, reaching over 70 million children. The telling part is that they built a research lab instead of just shipping more units -- because handing out devices and building thinkers turn out to be two different things.

The IDC 2025 study on Bit:sort -- a physical sorting activity for fourth graders -- found something that should reframe how you think about early computing entirely. Kids demonstrated genuine algorithmic reasoning through physical play even when they couldn't put it into words. They were thinking in algorithms before they had the language for it, and the reasoning grew out of doing rather than being told.

The TMAR study pushed further. When students were asked to invent their own challenges instead of completing preset ones, they showed significantly stronger gains in abstraction, decomposition, and algorithmic reasoning -- the three pillars of computational thinking. Student-generated problems beat instructor-assigned ones on every metric that mattered.

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 well-known gap for ages two to three. Most products aim either at babies (sensory, no logic) or at school-age kids (screen-based, app-dependent, increasingly passive). The shift researchers and educators are now watching -- away from app-dependent toys and toward open-ended, screen-free, reusable play -- is a direct response to evidence that passive engagement doesn't build reasoning.

For a three-year-old, the foundational moves have nothing to do with a particular device. They're about learning to notice patterns, test a hypothesis, hit a dead end, and try again. That loop is the whole 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.

An AI toy that responds to your child is a very different thing from a problem that doesn't respond at all until they figure it out. Only one of those leaves the thinking to the kid.

The build-together advantage

Here's 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, you narrate your own thinking out loud. "Hmm, this isn't doing what I expected -- why might that be?" Your child learns that uncertainty isn't a failure state, just the next step in the work.

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

Third, you can't be replaced by an app, because the relationship is the scaffold. Research on early learning consistently shows that co-regulation -- a calm adult presence modulating a child's frustration -- is what lets children stay with hard problems long enough to solve them. A toy can't co-regulate. You can.

An AI toy won't sit with your kid through the seventh dead end and keep its voice level while asking what they want to try differently. Toys are built to respond in a believable way, not to teach. The gap there isn't a missing feature you can patch in a software update -- it's the difference between a convincing performance and an actual teacher.

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 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's practical and week-by-week, not theoretical.

The projects don't require any prior programming knowledge. What they require is your time and your willingness to be genuinely curious right alongside your kid.

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

The House Runs Itself After 8pm

Diana Park — Sat, 09 May 2026 12:43:51 +0000

My son doesn't read clocks. He reads environment.

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.

Things shifted when I stopped treating bedtime as a negotiation and started treating it as a systems problem. The variable was never my son's willingness to sleep. It was every environmental signal still telling him it was daytime.

So I automated the environment. And it changed more than bedtime -- it changed how I think about the whole 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. In reality:

Buy smart bulbs. Screw them into your existing lamps.
Plug in a Raspberry Pi.
Set up the 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 for this (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 deep in the trenches of bedtime negotiations, my house is handling it, and I'm free to just wind down and read to my kid.

Morning Autopilot

The gap between "awake" and "functional" is the most dangerous stretch of my day. My son wakes up at 100% energy. I wake up at... well, with young kids I think 12% is about as good as mornings get.

So I let the house handle it:

6:30am -- A smart plug fires up 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's 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 whole difference between patience and survival mode. (The full morning version of this, agent texts and all, is its own post.)

The Compound Effect

Every decision I automate is one I don't have to spend mental energy on, and mental energy is the real scarce resource.

Parenting a toddler is something like 400 micro-decisions a 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 them draws from the same finite pool.

Automating the predictable stuff -- lights, coffee, routines -- doesn't save hours so much as 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

Something 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 have the word "automation," but he's living inside 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 have a hook for it: "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 has done more for us than any sleep-consultant advice I've tried.

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

Don't overhaul your house. Pick the friction point that drains you most, automate that one thing, and live with it for a week. The first time you notice 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+.

Why “Interest-Led” Beats “Curriculum-Led” for Teaching Kids Tech

Diana Park — Sat, 02 May 2026 13:22:51 +0000

My son is obsessed with garbage trucks.

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

Every garbage day, we stood out on the sidewalk and watched the truck the way other families watch fireworks.

So when I wanted to introduce him to computational thinking -- to start laying the foundation for building things together -- I had a choice. I could follow a curriculum: "Week 1: colors. Week 2: shapes. Week 3: sequences." Or I could follow the garbage trucks.

I followed the garbage trucks, and I haven't looked back.

The Curriculum Trap

There's a whole industry of "teach your kid to code" products, and most of them are built the same way: a fixed sequence of lessons marching through concepts in a tidy order. First you learn this, then that, then you combine them.

On paper it makes sense. It's how we organize a computer science degree -- prerequisites first, advanced topics later, building blocks stacked in order.

The trouble is that toddlers do not care about your tidy order. They care about what they care about, and what they care about changes by the hour. But in any given hour, the interest is intense.

When my son cares about garbage trucks, he'll stay locked onto garbage-truck activities for an astonishing stretch of time. Thirty minutes. Forty-five. That's a geological age in toddler time. He's asking questions, making connections, holding onto information.

When he doesn't care about something, I get maybe thirty seconds before he's upside down on the couch asking for a snack.

So why fight it? Why work so hard to make him care about abstract shapes on a screen when he already cares -- deeply, fiercely, with his whole body -- about garbage trucks?

Interest as an Engine

Here's what it looks like in practice.

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

The curriculum version: "Let's learn about sequences! Here's a cute robot. Drag the arrows to make it walk to the star."

The interest-led version: "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. The difference in engagement is night and day.

In the interest-led version, my son was practically vibrating. He rattled off the truck's entire pickup routine 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 every step of it himself, because it was about something he loved.

A curriculum hands the kid a problem someone else defined. Interest-led learning lets the kid define the problem. The second one wins, and it isn't close.

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 happen to bump into?"

What I've found is that with a little creativity, you can teach almost any foundational concept through almost any interest. The one prerequisite is knowing the concepts well enough yourself to spot the opening when it comes.

Garbage trucks alone 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 visit on which days?"
Decomposition: breaking the full route down into individual stops

That's a whole introductory algorithmic-thinking curriculum, delivered through one obsession.

And the gaps? They fill in on their own, because kids' interests move. Garbage trucks this month, airplanes next, space the month after. Each new obsession is a fresh vehicle (pun fully intended) for the same underlying concepts, met again in a different context.

That turns out to beat a curriculum, which teaches each concept once and moves on. Interest-led learning circles back to the core ideas over and over, in varied settings -- which is how durable learning actually forms.

The Developer Analogy

Think about how you learn best as a developer.

Ever tried to learn a new framework by reading the docs cover to cover? How did that go? You probably retained about 15% and forgot most of it before you needed it.

Now think about a framework you learned because a project you cared about required it. You had a problem, the framework solved it, and you picked up exactly what you needed as you went. You retained far more, and the whole thing was faster and more enjoyable.

That's interest-led learning, and it's how adults learn best too. The only real difference is that an adult can occasionally force themselves to grind through boring material. A kid 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 version.

1. Find the current obsession. What does your kid talk about nonstop? What would they do all day if you let them? That's your vehicle.

2. Map concepts onto the interest. Take the computational thinking concepts you want to introduce -- sequencing, patterns, conditionals, decomposition, debugging -- and work out how each one connects to the obsession. I promise it does.

3. Let the kid drive. Don't announce "let's learn about patterns using trucks." Say "hey, the garbage truck always goes to the same houses. Does it go in the same order? Why?" Let the concept surface out of the conversation.

4. Build something. This is where it gets powerful. "Want to make a garbage truck game?" takes the interest and adds creation. Now your kid isn't just meeting concepts -- they're using 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 a dinosaur riding on top, go with it. The tangent is just another interest surfacing, and the concepts still apply.

The Hard Part

I'll be honest: interest-led is harder on the parent than curriculum-led, in some ways. A curriculum tells you what to do each day. Interest-led asks you to improvise -- to find the computational thinking inside whatever your kid happens to be obsessed with this week, and to do it on your feet.

It's also a lot more fun, because you're responding to a real kid with real enthusiasm instead of marching through somebody else's lesson plan. And the payoff is hard to argue with: deeper engagement, better retention, and a kid who connects learning with their favorite things rather than with obligation.

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

Subscribe now

How I Ship Products in 90-Minute Windows

Diana Park — Sat, 25 Apr 2026 13:25:48 +0000

I have 90 minutes of real focus time per day. Some days less. Some days zero.

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

Here's a sample of what I've shipped from that kitchen counter in the last few months: a book, a newsletter with weekly posts, a product line on Gumroad, several open-source tools, and a daily content operation across three platforms. Not from grinding twelve-hour days -- I just stopped being the person who does the work and became the person who reviews it.

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

The reframe

The biggest unlock wasn't a tool. It was a shift in how I think about my own job.

I used to believe 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 to communicate intent, review, and approve. That's it. I went from doing the work to directing it -- from the person pushing the code to the person reviewing the pull request. The work still gets done. It just no longer depends on me being the one putting in the hours.

The async everything stack

Here's my actual setup. None of it is theoretical -- I run this every day.

OpenClaw + iMessage: the async command layer

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

I don't sit down 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 get a summary of what got done while I slept. I text "draft an about page using these two files" and review the output when I have five minutes.

The thing that makes this work is the lack of friction. I don't have to get to my laptop, open a terminal, or log into a dashboard. The tool lives where I already am -- the same app I use to text my husband and my mom. My phone's in my pocket, and the cognitive overhead is close to zero.

Cron jobs: the night shift

While I sleep, scheduled jobs run:

Content research: my agent browses, researches new ideas, and outlines notes and posts. I wake up to a summary of what it explored and a set of new markdown files waiting for review.
Research digest: a nightly scan of HN, dev Twitter, and a few niche blogs compiles a digest on topics I'm tracking. It's my own high-signal, personal-interest newsletter, and I read it over coffee.

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

So the morning doesn't start with "sit down and figure out what to do today." It starts with reviewing what's already done and approving what ships next.

The content pipeline: from creator to reviewer

Here's a typical day.

7am: I text "gm." My agent sends the overnight report -- what drafts got written, what research got compiled, what tasks finished.

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 thought about something my 3yo did becomes a new article. My involvement drops from hours of writing to a few minutes of grammatically-imperfect notes.

After bedtime: my one real focus block. Because the research is done, the drafts exist, and the admin is handled, I can spend it on the one thing that genuinely needs my brain -- writing the newsletter, editing the book, building something new. The 90 minutes isn't spread thin across twenty tasks. It's concentrated on the one I can't delegate.

The principle: decouple work from presence

The operating principle underneath 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 have to be present, one-on-one, to make that sale.

This is what makes the parent-developer life actually work. It has nothing to do with hustling harder or waking up earlier, and definitely nothing to do with Pomodoro timers. You build systems where the work happens when you're not there, and your job becomes directing the intent and reviewing the output. (The screen-free, no-phone version of running an agent like this is its own post.)

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 idea works with anything that doesn't require you to be at a desk)
Scheduled automation for anything repetitive (cron jobs, Zapier, whatever -- the point is that 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 protected for the work only you can do

The 90 minutes was never the real limitation. Ninety minutes is plenty, as long as you're not burning 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 come with a pause button.

I've shipped more in the last few months of 90-minute windows than I did in some quarters with a full engineering team. The difference isn't raw speed -- it's that I'm forced into focus. I can't afford feature creep or busywork. No slack time means no wasted time. (For the dollars-and-hours version of that claim, I did the actual math here.)

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 spend your scarce time on decisions instead of execution.

The tools exist. The hours don't need to. You just have 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

Computational Thinking Milestones: What to Expect from Ages 1 to 4

Diana Park — Sat, 18 Apr 2026 13:25:07 +0000

There's no shortage of developmental milestone charts. Rolling over by four months. First words by twelve. Riding a bike by five. Pediatricians have these mapped down to the month.

Computational thinking, though -- arguably the skill set that matters most in the 21st century -- gets nothing but a vague nudge to "introduce coding" at some undefined later date, usually involving an eight-year-old, a $200 robot, and a lot of screen time.

When I went from engineering director to stay-at-home mom, it struck me that computational thinking isn't some future course I'd need to remember to enroll my kid in. Toddlers do it every single day -- when they play with blocks, pick out their clothes, or negotiate for "one more story." So I wrote the guide to toddler CS milestones I went looking for and couldn't find.

This isn't armchair theory, though the research backs it up: Marina Umaschi Bers at Boston College has studied computational thinking in early childhood for over a decade, and Jeannette Wing's foundational paper made the case that it's a universal skill rather than a CS-major thing. Mostly, though, this is what I've watched happen with my own kid, lined up against what developmental science says to expect. If your child does some of these and not others, that's normal. Kids aren't firmware. They don't all install features on the same schedule.

It is, however, useful to know what you're looking at.

Age 1-2: The Hardware Installation

Think of this stretch as your child's operating system booting up. They're not "doing" computational thinking in any form you'd recognize yet. They're laying down 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 clearly the experiment demands replication. This is your child discovering that actions have predictable, repeatable outcomes -- bedrock for everything algorithmic that comes later.
Basic sorting by a single attribute. All the red blocks in one spot. Every book pulled off the shelf (sorted by... reachability?). 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 copy short ones -- the start of following instructions, which is the start of grasping what an instruction even is.
Trial and error, no strategy. They'll jam the square block at the round hole over and over, then succeed by accident with the right one. No hypothesis. Just brute force. (Though, in fairness, I've watched senior engineers debug exactly this way.)

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

Planning. Abstraction. Multi-step reasoning. The prefrontal cortex is barely plugged in. Let it be.

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 lose at the shape sorter -- a little frustration is a fine motivator.

Age 2-3: First Programs

This is where it gets fun. Language explodes, and with language comes the power to describe a sequence instead of just imitating it. Your child starts writing their first programs without the faintest idea that's what they're doing.

What you'll see:

Verbal sequencing. "First shoes, then outside." A two- or three-step plan, narrated before doing it. This is pseudocode -- actual, literal pseudocode, just delivered by someone who pronounces "spaghetti" as "pasketti."
Multi-attribute sorting. "Big red cars here, small red cars there." Two sorting criteria at once, which is a compound query: SELECT * FROM toys WHERE color = 'red' ORDER BY size.
Basic if/then reasoning. "If it's raining, we need boots." They begin predicting outcomes from conditions. It isn't reliable yet -- they might also predict that putting boots on summons puddles -- but the shape of conditional logic is there.
Pattern completion. Red, blue, red, blue, red. They can extend a simple AB pattern, and some start inventing their own: "car, truck, car, truck." This is the seed of algorithmic thinking -- spotting a rule and applying it.
Debugging with intention. The tower falls, and instead of a random retry they adjust: bigger block on the bottom this time. The hypothesis about why it fell might be wrong, but they're forming one, and the method matters more than the accuracy.

What you won't see:

Nested logic ("if it's raining AND cold, boots AND a coat"). Abstraction past the concrete. Long multi-step plans. They're still firmly tied 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 to hand -- toys, food, sounds. When something breaks, say "why did that happen? Let's look!" before you swoop in to fix it.

Building with AI at 2-3

My son and I built his first browser games with Claude right around here. He described what he wanted, I turned it into a prompt, and he played -- and learned that his ideas can become things. His first one ("Make a red car game! Make it jump!") quietly changed his whole relationship with a screen, from something he watched into something he made.

Age 3-4: The Abstraction Leap

Something shifts around three. I watched it happen in real time. Your child starts operating on representations of things rather than 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 for something else entirely. This is abstraction in the strict computer-science sense: stripping away the details that don't matter so you can work with a simpler model.
Algorithm narration. Not just "first this, then that" -- they start dictating whole procedures. My son will explain how to make his favorite snack in six ordered steps and get genuinely annoyed if I deviate from the protocol. He's writing a spec. He's defining an API. He is, I'll remind you, three.
Conditional branching. "If you sit nicely at the restaurant, we'll get dessert. If you're disruptive, we leave." Different inputs, different outputs -- and they'll start manipulating the conditions ("But I wasn't THAT loud!"), which is really 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 parts. Not always the right parts. But the instinct to decompose has arrived.
ABC and ABB patterns. Beyond simple alternation now. Red, blue, green, red, blue, green. Or red, red, blue, red, red, blue. The pattern engine is getting more capable.

What you won't see:

Recursive thinking. True loop comprehension -- they'll do things repeatedly without conceptualizing "repeat until." Error handling beyond one level ("but what if the BACKUP plan fails?").

What to do:

Build things together. Anything. Block towers, art projects, simple games. Specifying what you want, breaking it into steps, and adjusting when it goes sideways is the computational thinking curriculum. Ask them to explain what they made. "How does it work?" might be the single most powerful question you can ask a three-year-old.

Building with AI at 3-4

This is the age my son started describing more elaborate games and watching them appear on screen. The computational thinking is all in the specification. Listen to this one: "I want a game where you drive a train through a maze with the arrow keys and it picks up fallen branches and brings them to the garbage dump." That's a feature spec, from a kid who still puts his shoes on the wrong feet about 40% of the time.

What's Next

He's three. The developmental research (Bers, Wing, Frontiers in Education) puts loops, nested conditionals, and real systems thinking in the four-to-six range. That's where kids start building rule systems, optimizing their own little algorithms, and carrying abstract ideas from one domain into another.

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 needs a screen, an app, a robot, or a subscription.

The whole curriculum is four things: narrate what's happening, ask questions, let them fail, and build things together.

The milestones aren't a checklist -- your kid might be a pattern-recognition wizard who could not care less about sequencing, and that's completely fine. The point was never to grade your child. It's to learn to recognize computational thinking while it's happening, so you lean into it instead of walking right past it.

It's happening right now. In the blocks, in the spoon drops, in the twenty-minute negotiation over whether pants are strictly required today.

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.

The Naptime Startup: Real Math for Parent Founders

Diana Park — Sat, 11 Apr 2026 13:26:14 +0000

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.

Originally published on Raising Pixels for parents who build.