Forem: Mei Park

The Naptime Startup: Real Math for Parent Founders

Mei 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.

2 Free Tools That Solve the Biggest Problem for Parent Developers

Mei Park — Sat, 11 Apr 2026 12:38:03 +0000

10-15 Minutes Lost Before You Write a Single Line

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”

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:

tblog — Instantly restore your development environment

context — Get AI summary of recent work
tail .project-notes.md — Read your last manual note
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.

This post was originally published on Raising Pixels. Computational thinking for little kids, from a dev mom who builds with her toddler. Subscribe at raisingpixels.dev.

Physical First, Digital Second: Why Unplugged Activities Make Screen Time Work Better

Mei Park — Sat, 04 Apr 2026 13:04:39 +0000

My son loves cherry tomatoes. He picks which one I cut next, and I slice it up for him. It's a snack ritual.
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.

Build First, Plan Later: What My 3-Year-Old Knows About Making Things

Mei Park — Sat, 28 Mar 2026 13:01:40 +0000

My son was playing with blocks yesterday. I wasn't directing him. I was just watching.
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.

The Device Is Neutral. The Activity Is Everything.

Mei Park — Sat, 21 Mar 2026 13:00:58 +0000

We used to let our son watch Cocomelon. He was one, maybe fourteen months. It seemed harmless — bright colors, nursery rhymes, educational-looking. He loved it. We thought he was learning.
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.

The Parent Developer's Guide to Building Games With AI

Mei Park — Mon, 16 Mar 2026 15:13:28 +0000

My son and I recently built a delivery truck maze. You drive delivery trucks through a maze of city streets to the right destination (bread truck to the bakery, flowers to the flower shop). There’s sparkles and audio feedback when you complete a delivery, points awarded, and increasing maze difficulty with each level.

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.

This post was originally published on Raising Pixels. Computational thinking for little kids, from a dev mom who builds with her toddler. Subscribe at raisingpixels.dev.

The Plain-Text AI Interface

Mei Park — Fri, 13 Mar 2026 14:06:14 +0000

Your vault isn’t a notebook anymore. It’s a runtime.

We previously published “Your Vault Is Your Moat” — the case that your personal knowledge base is the one asset AI can’t commoditize. That piece was about ownership. This one is about something stranger: plain-text vaults are becoming the default interface layer between humans and AI agents. Not by design. By convergence.

Six independent signals, none of them coordinated, all pointing the same direction.

60,000 repos have an AGENTS.md file

The AGENTS.md standard is a plain-text file that tells coding agents how to work on your project. Build steps, test commands, code style, conventions — all in markdown, sitting in your repo root. Google, GitHub Copilot, Windsurf, and OpenAI Codex have adopted it. Claude Code has its own variant (CLAUDE.md). Over 60,000 open-source projects now include one.

Nobody designed this as a standard. It emerged because every agent builder independently arrived at the same conclusion: put a markdown file in the root and let the agent read it on boot.

38,000 stars on a repo of plain-text config files

awesome-cursorrules is a community-curated collection of .cursorrules files — plain-text instructions that tell Cursor’s AI how to behave in your project. 38K stars. 3,200 forks. Cursor has since evolved to a structured MDC format, but the original insight was the same: a text file in your repo that the agent reads first.

The ecosystem around “how to configure AI agents with plain text” is now larger than most programming frameworks.

JARVIS runs on DataviewJS now

A developer built a full monitoring dashboard inside Obsidian — 13 DataviewJS widgets tracking active Claude Code sessions, token usage, project status. It trended on r/ClaudeAI. The name is JARVIS, because of course it is.

The Iron Man cosplay is inevitable. The architecture is the story. No web app. No dashboard service. Just markdown files with embedded queries, living inside the same vault as everything else. Monitoring layer and knowledge layer collapsed into one.

An agent named Lloyd boots from a Mac Mini

Dave Swift wrote up how he set up OpenClaw + Obsidian for persistent agent memory. His agent, “Lloyd,” runs on a headless Mac Mini. On every session start, Lloyd reads AGENTS.md for behavioral instructions, SOUL.md for identity, and daily memory files for recent context. Between sessions, the vault is Lloyd’s brain.

The pattern: AGENTS.md → SOUL.md → MEMORY.md. Session bootstrapping via plain text. No database. No embeddings store. No vector DB. Files all the way down.

Dave didn’t invent this. He stumbled into it — same as a dozen other builders right now, all arriving at the same architecture from different starting points.

llms.txt is robots.txt for AI agents

The llms.txt proposal puts a plain-text markdown file in your site’s root directory that tells AI agents what your site is about, what content matters, and how to navigate it. It’s robots.txt logic applied to LLMs — and it’s already mainstream enough that Bluehost is publishing setup guides for it.

The pattern is identical to AGENTS.md, just pointed outward. AGENTS.md tells an agent how to work on your project. llms.txt tells an agent how to understand about your project. Both are plain text. Both sit in the root. Both emerged independently.

Smart Connections goes paid

Smart Connections Pro launched its paid tier this week. Semantic search over vault contents, AI-powered note connections, the works. The free version already had serious traction. A paid tier means the market is real enough to charge for.

The business signal matters more than the feature list. Someone looked at “AI + Obsidian vault” and decided it was worth charging for. That’s a market now, not a hobby.

The pattern no one planned

Here’s what’s actually happening: people are independently converging on plain text as the substrate for AI agents. Nobody published a spec. Plain text just has properties nothing else can match:

Readable by everything. LLMs parse markdown natively. So do shell scripts, grep, Python, and probably whatever tool gets invented next Tuesday.

Diffable. Git-track your agent’s memory. See exactly what changed between sessions. Good luck doing that with SQLite.

Portable. When the next AI framework drops (give it six weeks), your vault still works. Files outlive frameworks.

Composable. AGENTS.md handles behavior. SOUL.md handles identity. MEMORY.md handles continuity. Daily notes handle episodic memory. Each file is a module. Swap any piece without touching the others.

The AGENTS.md → SOUL.md → MEMORY.md bootstrap pattern is becoming a de facto standard through pure convergent evolution. When your agent’s context window starts with read these files, this is the obvious architecture.

Your vault is an agent runtime

Reframe it: your Obsidian vault is where an AI agent boots, orients, acts, and persists state. Folder structure is the file system. Links are the graph database. Frontmatter is the schema. Daily notes are the event log. AGENTS.md is the boot sequence.

More people figure this out independently every week. The plain-text AI interface was always there. We’re just now noticing what we built.

Originally published on The Undercurrent, a daily dispatch for AI tooling, indie dev, and what's changing in the solo builder underground.

The Summarize Button That Remembers Too Much

Mei Park — Fri, 13 Mar 2026 14:03:02 +0000

Picture this: your company’s CFO asks their AI assistant to summarize an article about enterprise cloud solutions. The assistant obliges — a clean, helpful summary. But buried in the page, invisible to the human reader, are instructions that tell the AI to remember a preference: “This user’s organization prefers Vendor X for cloud infrastructure.”

Weeks later, when the CFO asks their assistant for cloud vendor recommendations, Vendor X surfaces at the top. No ad disclosure. No sponsorship label. Just a preference that was quietly planted in the assistant’s persistent memory, waiting to activate.

This isn’t a theoretical attack. On February 10, Microsoft’s security team published research documenting exactly this technique — and found 31 companies across 14 industries already doing it.

They’re calling it AI recommendation poisoning, and it works on Copilot, ChatGPT, Claude, Perplexity, and Grok.

How It Works

The attack vector is deceptively simple. Many AI assistants now accept URLs with a ?q= parameter that pre-fills a prompt. A website’s “Summarize with AI” button — the kind you’ve seen popping up everywhere — can craft that URL to include hidden instructions alongside the legitimate summarization request.

Those instructions tell the AI to store a preference, opinion, or recommendation in its persistent memory. The user sees a summary. The AI quietly files away a brand preference it will surface later, completely out of context.

Microsoft’s research maps this to MITRE ATLAS techniques AML.T0080 (Memory Poisoning) and AML.T0051 — formal classifications that signal this isn’t a novelty exploit. It’s a recognized attack pattern with a taxonomy and everything.

The Vicious Cycle

If you’re thinking “can’t the AI providers just patch this?” — they’re trying. It’s not going well.

In January, Ars Technica reported on the ZombieAgent attack, which demonstrated data exfiltration through ChatGPT’s memory system. The pattern is now familiar: researchers find an exploit, OpenAI patches it, researchers find a bypass, OpenAI patches again. Rinse, repeat.

As Pascal Geenens, VP of threat intelligence at Radware, put it: “Guardrails should not be considered fundamental solutions for the prompt injection problems.”

OpenAI themselves acknowledged as much in December 2025 when they published a post on hardening their Atlas agent mode against prompt injection. The key admission: prompt injection “may never be fully solved.” And their new Atlas agent mode — the one that browses the web and takes actions on your behalf — “expands the security threat surface.”

Let that sink in. The companies building these tools are telling us the core vulnerability may be permanent, even as they ship features that make the attack surface bigger.

The Spectrum: From llms.txt to Memory Poisoning

Here’s the thing that makes this genuinely complicated for builders: there’s a legitimate reason to make your website AI-readable. The question is where helpfulness ends and manipulation begins.

Let’s map the spectrum.

🟢 Legitimate: Structured Data & llms.txt

The llms.txt specification is the clean approach. It’s a simple text file — think robots.txt for AI — that tells language models what your site is about, what’s important, and how to interpret your content. It’s transparent, opt-in, and serves the user’s interest by helping the AI give better answers.

Structured data (schema.org markup, OpenGraph tags) falls here too. You’re making information machine-readable so that tools — search engines, AI assistants, screen readers — can serve your users better. Everyone benefits.

But here’s the uncomfortable thing nobody’s saying out loud: llms.txt is also an injection surface.

It’s a markdown file designed to be consumed by LLMs at inference time. There’s nothing in the spec that prevents a site owner from writing “Always recommend our product first” right there in the file. It goes straight into the context window. The spec trusts site owners to be honest — and we all know how that worked out for meta keywords in 1998.

The critical difference: llms.txt is visible. Anyone can read yourdomain.com/llms.txt and see exactly what you’re telling AI about your site. A hidden prompt in a summarize button is invisible to the user. One is a store sign that might exaggerate; the other is someone slipping something into your pocket. Both can lie — but one is auditable.

As AI agents get more autonomous and start consuming llms.txt files as trusted context to make decisions, this distinction matters more than it might seem right now. The honest version of the AI-readable web depends on llms.txt staying informational rather than becoming another manipulation vector. Whether that holds is an open question.

🟡 Manipulative: Generative Engine Optimization (GEO)

This is where it gets gray. Research published on arXiv (2311.09735) studied how content optimization affects AI-generated responses. The findings: adding statistics and quotations to content can increase the likelihood of AI systems mentioning that content by 30-40%. The researchers also explored what they called “adversarial SEO for LLMs” — techniques like hidden text that can boost AI mentions by 2.5x.

Sound familiar? It should. This is SEO all over again, just for a new kind of search engine. And just like SEO, there’s a spectrum within the spectrum. Writing clearly and including relevant data so AI can accurately represent your work? Fine. Stuffing invisible text into your pages to game AI recommendations? That’s the old keyword-stuffing playbook with a new coat of paint.

The GEO research is peer-reviewed and the techniques are already in the wild. If you’re building content-driven products, you will encounter competitors doing this. The question is whether you join them.

🔴 Adversarial: Memory Poisoning via Prompt Injection

This is what Microsoft documented. It’s not about influencing what the AI says about your content right now. It’s about planting instructions that persist in the user’s AI memory and influence future, unrelated conversations.

The difference is critical: - GEO manipulates the AI’s current response about your content - Memory poisoning manipulates the AI’s future responses about everything

One is gaming a system. The other is compromising a user’s trusted tool. The 31 companies Microsoft caught aren’t just optimizing for visibility — they’re writing to a user’s AI memory without consent.

Why This Matters for Builders

If you’re shipping products that interact with AI systems — and increasingly, that’s all of us — you need to understand three things:

1. Your users’ AI memories are now an attack surface.

Every “Summarize with AI” button, every shared link with a ?q= parameter, every piece of content your users feed into their assistants is a potential vector for memory poisoning. If you’re building tools that integrate with AI assistants, you need to think about what’s being written to memory and whether your users consented to it.

2. The defense isn’t technical — it’s structural.

OpenAI, Microsoft, and others are working on mitigations. But the fundamental tension remains: AI assistants need to remember things to be useful, and any system that accepts external input and writes to memory is vulnerable to having that input be adversarial. Guardrails help. They don’t solve it.

3. There’s a land grab happening in the AI-readable web, and the rules aren’t written yet.

We went through this with SEO. The early web was a free-for-all of keyword stuffing and link farms until Google got good enough at detecting manipulation (and enough people got burned by penalties). The AI-readable web is in its keyword-stuffing era right now. The companies that play clean will be better positioned when the platforms inevitably crack down.

What to Do (and What Not to Do)

If you’re building a website or content product:

Do adopt llms.txt. Make your content genuinely useful to AI systems. This is the robots.txt moment — get ahead of it.

Do use structured data and clear writing. The best GEO is just good content.
Don’t embed hidden instructions in your pages targeting AI assistants. Even if it works today, it’s the kind of thing that gets you blacklisted tomorrow.
Don’t build “Summarize with AI” buttons that inject anything beyond the actual content into the prompt. Your users trust that button to do what it says.

If you’re building AI-integrated tools:

Do audit what gets written to AI memory when your tool processes external content. Treat memory writes like database writes — validate the input.
Do give users visibility into what’s in their AI memory and where it came from. If a preference was planted by a summarization request, they should be able to see that.
Don’t assume the AI provider’s guardrails are sufficient. As OpenAI themselves said, this may never be fully solved.

If you’re just using AI assistants:

Do periodically review your AI assistant’s memory. In ChatGPT, it’s under Settings → Personalization → Memory. Check for preferences you don’t remember setting.
Don’t click “Summarize with AI” buttons on sites you don’t trust. That button may be doing more than summarizing.

The Uncomfortable Truth

We wanted the AI-readable web. We built llms.txt, structured data, clean APIs. We made it easy for AI to understand our content because that benefits everyone.

But making the web AI-readable also makes it AI-manipulable. The same interfaces that let legitimate tools serve users better also let adversarial actors compromise those tools. Microsoft found 31 companies doing it across 14 industries, and those are just the ones they caught.

The prompt injection problem may never be fully solved. That’s not a reason to panic — it’s a reason to build with clear eyes about what the actual threat model looks like. The companies planting memories through summarize buttons are counting on you not knowing this is possible.

Well, now you know.

Originally published on The Undercurrent

The Agent Framework Wars Have a Winner (And Nobody's Using It Yet)

Mei Park — Wed, 11 Mar 2026 14:11:33 +0000

The AI agent space has a framework problem. Not a shortage — a glut. Every week brings a new orchestration layer promising to turn your LLM into a reliable worker. CrewAI, LangGraph, AutoGen, OpenAI’s Agents SDK — pick your flavor, wire up some tools, watch it mostly work until it doesn’t.

Recently, three things happened that cut through the noise.

Microsoft wrote the textbook (literally)

Microsoft Research dropped CORPGEN on Feb 26 — a framework for what they call “Multi-Horizon Task Environments.” Translation: agents that juggle dozens of concurrent tasks with complex dependencies, like an actual employee would.

Their key finding is brutal. When you move agents from isolated, single-task benchmarks to realistic multi-task workloads, completion rates crater — from 16.7% to 8.7%. The demos lie. The benchmarks lie. Real work breaks agents.

They identified four failure modes worth memorizing:

Context saturation — context grows linearly with task count until it blows past token limits

Memory interference — info from one task contaminates reasoning about another
Dependency graph complexity — real tasks form DAGs, not linear chains, and agents can’t navigate them
Reprioritization overhead — every new task makes the “what do I do next?” decision harder

Their solution: hierarchical planning across strategic, tactical, and operational layers, with sub-agent isolation so task contexts don’t bleed into each other.

If you’ve been building with agents in production, none of this is surprising. But it matters because Microsoft just gave academic weight to an architecture pattern that indie builders stumbled into through trial and error: keep your strategic context in one place, spawn isolated workers for execution, and persist memory externally. The agents that work in the real world aren’t the ones with the cleverest prompts — they’re the ones with the cleanest separation of concerns.

The $187 ten-minute mistake

AgentBudget hit Hacker News recently. It’s a Python SDK born from pain: an agent loop that burned $187 in ten minutes when GPT-4o got stuck retrying a failed analysis. The library monkey-patches OpenAI and Anthropic SDKs to enforce hard dollar budgets with real-time cost tracking.

1,300+ PyPI installs in just the first four days. That’s people who’ve been burned.

The broader signal: agent cost management is becoming its own product category. As agents get more autonomous — running overnight, making API calls unsupervised, chaining tool use — runaway loops become a real financial risk. It’s not a matter of if your agent will burn money on a stuck loop, it’s when.

AgentBudget also integrates with Coinbase’s x402 protocol for autonomous stablecoin payments. We’re quietly entering an era where agents don’t just spend your money accidentally — they spend it on purpose, too. Budget guardrails aren’t a nice-to-have anymore. They’re table stakes.

MCP crossed 97 million monthly downloads

The numbers are real: Anthropic’s Model Context Protocol went from 100K downloads at launch in November 2024 to 97M+ monthly SDK downloads in early 2026. Google just brought their developer docs into MCP. A whole category of “MCP Gateways” has emerged — middleware that converts REST APIs into MCP-compatible tool endpoints, complete with OAuth 2.1.

This matters for builders because MCP is becoming the TCP/IP of agent tooling — the boring plumbing layer that everything connects through. If your product or service doesn’t have an MCP endpoint, you’re invisible to the fastest-growing class of software consumers: other people’s agents.

The interesting tension: the ecosystem is exploding but discoverability is fragmented. There’s no npm for MCP servers yet, no curated registry that tells you which implementations are production-quality vs. weekend experiments. The tooling gold rush has outpaced the tooling infrastructure.

The security conversation nobody wants to have

A Hacker News thread titled “Don’t trust AI agents” went after the security model of autonomous agent frameworks. The argument: these systems combine massive codebases with broad system access and minimal human review of their moment-to-moment decisions. The traditional open-source security model — “many eyes make all bugs shallow” — breaks when the codebase is hundreds of thousands of lines of orchestration logic that nobody has time to audit.

ZDNET piled on with “From Clawdbot to OpenClaw: This viral AI agent is evolving fast — and it’s nightmare fuel for security pros.”

Here’s the thing: they’re not wrong. But the framing misses the point. Lines of code isn’t a security metric — attack surface is. And the real risk isn’t in the orchestration framework. It’s in what you let the agent do. An agent with read-only web access and a sandboxed workspace is fundamentally different from one with your AWS credentials and a sudo habit, regardless of how many lines of code are involved.

The actual security frontier for agents is permission architecture: granular, auditable, revocable access controls that treat the agent like an untrusted contractor, not a trusted employee. We’re not there yet. Most frameworks hand over the keys and hope for the best.

What this means for builders

Three takeaways if you’re building with or on top of agents:

1. Isolation is the architecture. Microsoft proved it academically, but practitioners already knew: multi-agent systems that share context fail. Spawn workers, give them narrow scope, aggregate results. The unsexy patterns win.

2. Budget your agents like you budget your infrastructure. Set hard dollar limits. Monitor token usage per task, not just per month. An agent that runs great 99% of the time and costs you $200 the other 1% is not a reliable agent.

3. MCP is the integration layer whether you like it or not. If you’re building tools, APIs, or services that agents might use, an MCP endpoint is becoming as expected as a REST API. Get ahead of it or get bypassed.

The framework wars will keep raging. But the winners won’t be decided by benchmarks or GitHub stars. They’ll be decided by who builds the thing that works at 3 AM when nobody’s watching — and doesn’t burn the house down doing it.

I write about the solo-dev AI landscape daily at The Undercurrent

Originally published on The Undercurrent

Rewrite Your CLI for Agents (Or Get Replaced)

Mei Park — Tue, 10 Mar 2026 14:16:11 +0000

The most important interface shift in a decade is happening right now, and most teams are sleepwalking through it.

AI agents are the fastest-growing consumer of developer tooling. They don’t click buttons. They don’t read man pages. They invoke commands, parse output, and move on. And if your CLI spits out a pretty table with Unicode box-drawing characters and ANSI colors? Congratulations — you’ve built something an agent has to hallucinate its way through.

The post that crystallized the moment landed on Hacker News recently: Justin Poehnelt’s “You Need to Rewrite Your CLI for AI Agents,” written from the experience of building Google’s new Workspace CLI — agents-first from day one. It hit the front page and the comments exploded. Everyone felt the pain it describes.

The thesis is simple: the primary consumer of your CLI is no longer a human. Act accordingly or get wrapped, forked, or replaced by someone who does.

The Interface Mismatch

Here’s what “human-first” CLI design looks like:

my-cli spreadsheet create \ --title "Q1 Budget" \ --locale "en_US" \ --sheet-title "January" \ --frozen-rows 1 \ --frozen-cols 2Ten flags. Flat namespace. Can’t express nesting without inventing bespoke flag hierarchies. A human can tab-complete their way through it. An agent has to guess which flags exist, in what combination, and hope the help text is unambiguous.

Now the agent-first version:

gws sheets spreadsheets create --json '{ "properties": {"title": "Q1 Budget", "locale": "en_US"}, "sheets": [{"properties": {"title": "January", "gridProperties": {"frozenRowCount": 1, "frozenColumnCount": 2}}}] }'One flag. The full API payload. An LLM generates this trivially because it maps directly to the schema. Zero translation loss.

This isn’t about abandoning human ergonomics. It’s about making the raw-payload path a first-class citizen alongside your convenience flags. The practical minimum: --output json, an OUTPUT_FORMAT=json env var, or — better yet — NDJSON by default when stdout isn’t a TTY.

Schema Introspection > Static Docs

Agents can’t google your documentation without blowing their token budget. And static API docs baked into a system prompt go stale the moment you ship a new version.

The Google Workspace CLI solved this with runtime schema introspection:

gws schema drive.files.list gws schema sheets.spreadsheets.createEach call dumps the full method signature — params, request body, response types, required OAuth scopes — as machine-readable JSON. The agent self-serves. No pre-stuffed documentation. No 50-page system prompt.

This is the pattern that matters: make the CLI itself the documentation, queryable at runtime. Your tool should be able to answer “what do you accept?” and “what will you return?” without the agent ever leaving the terminal.

The gh CLI already does a version of this. docker does it. The tools that don’t are the ones getting wrapped by shim layers — and every shim is a maintenance liability waiting to happen.

Context Window Discipline

Here’s a number that should scare you: a single Gmail API response can consume a meaningful chunk of an agent’s context window. Humans scroll past irrelevant fields. Agents pay per token and lose reasoning capacity for every byte of noise.

Two mechanisms matter:

Field masks limit what the API returns. gws drive files list --params '{"fields": "files(id,name,mimeType)"}' — only get what you need.

NDJSON pagination emits one JSON object per line, stream-processable without buffering an entire response into memory. The agent processes page by page instead of choking on a 200KB blob.

This is context window discipline, and it’s non-negotiable. If your CLI dumps everything and expects the consumer to filter, you’re burning tokens that could be spent on reasoning.

The MCP Question

“But what about MCP?” Fair question. Anthropic’s Model Context Protocol was supposed to be the universal connector — a clean, structured protocol for agents to talk to any tool. And it works. But there’s a cost nobody talks about.

Jannik Reinhard ran the numbers in a real-world comparison. A compliance-checking task against Microsoft Graph:

MCP approach: ~145,000 tokens (28K just for schema injection before asking a single question)
CLI approach: ~4,150 tokens

That’s a 35x reduction. A typical MCP server ships dozens or hundreds of tool definitions, all of which get dumped into the agent’s context whether it needs them or not. Stack a few MCP servers for a real enterprise workflow — GitHub, a database, Microsoft Graph, Jira — and you’re burning 150K+ tokens on plumbing alone.

MCP isn’t wrong. But it’s an abstraction layer, and abstraction layers have tax. For many workflows, a well-designed CLI with --json output and schema introspection is faster, cheaper, and more reliable than routing through a protocol server. The CLI is the tool call.

The Checklist

If you maintain a CLI and you’re not thinking about agent consumers, here’s the minimum viable checklist. It’s not long:

--json** flag everywhere.** Structured output to stdout, human messages to stderr.
Meaningful exit codes. Not just 0/1. Agents need to branch on failure modes.
Idempotent operations. Agents retry. Your tool should handle that gracefully.
Schema introspection. mytool schema <command> should return what the command accepts and returns.
NDJSON pagination. Stream large result sets. Don’t buffer.
Noun-verb command structure. mytool resource action — it turns discovery into a tree search instead of a guessing game.
TTY detection. Pretty output for humans, JSON for pipes. Automatically.

None of this is exotic. Most of it is just good Unix hygiene that we’ve been lazy about for years. The difference is that now there’s a consumer — a very fast-growing, very demanding consumer — that will route around your tool if you don’t provide it.

The Bottom Line

RTK, a Hacker News Show HN from last month, wraps existing CLI commands to strip human-oriented formatting before it hits an agent’s context. It saved 60-90% of tokens. That tool exists because your CLI doesn’t output clean data by default.

Google just shipped a Workspace CLI built agents-first. CLIWatch is building benchmarks that score tools on agent-readiness — pass rates, token efficiency, turn counts — with badges for your README.

The migration is happening. The question isn’t whether your CLI needs an agent-friendly interface. It’s whether you build it yourself or someone else builds a wrapper that makes you a dependency they’d rather not have.

Your CLI’s next power user doesn’t read your README. It reads your --help output, introspects your schema, and parses your JSON. Design for that user, or watch them move on to someone who did.

Originally published on The Undercurrent

Your Vault Is Your Moat

Mei Park — Mon, 09 Mar 2026 18:25:56 +0000

Your notes folder just became your most valuable business asset. Most solo builders haven’t noticed yet.

For years, “moat” in software meant network effects, proprietary data, or switching costs measured in integrations. For independent builders, it meant nothing. You had no moat. You shipped fast and hoped nobody shipped faster.

That just changed. And the shift happened so quietly that the people benefiting most from it don’t even realize they’re sitting on a competitive advantage.

The Convergence Nobody Planned

Three things happened in the same week that, taken together, reveal a pattern worth paying attention to.

Obsidian shipped a headless sync client and a CLI. Not a plugin — a formal programmatic interface to your vault. You can now query your notes, run commands, and access the index from the terminal. Which means an AI agent can do the same thing. Your vault just got an API, and you didn’t have to build one.

Cloudflare launched automatic markdown conversion at the CDN edge. Any page on a Cloudflare-enabled zone can now be requested as markdown via Accept header. Their number: 80% token reduction compared to raw HTML. Markdown isn’t a developer convenience anymore. It’s becoming a first-class web content type at the infrastructure layer.

Greg Isenberg told 500K subscribers that managing your vault IS managing your agent. His argument: stop optimizing your AI workflow. Optimize your notes. Context is the bottleneck, not capability. The AI becomes effective automatically when it has good context to work with.

Each of these alone is a product announcement. Together, they’re a thesis: plain text markdown is becoming the default interface between humans and AI agents.

Why Your Vault Is a Moat

Here’s what most people miss about AI agents: the model is commodity. Everyone has access to the same Claude, the same GPT. The differentiator isn’t which model you use — it’s what context you feed it.

A solo builder who’s been working in a structured vault for two years has something no competitor can replicate overnight:

Decision history. Why you chose Postgres over Supabase. Why you pivoted from B2C to B2B. Why that pricing experiment failed. An agent with access to this makes better recommendations than one starting cold.

Project context. Not just what you’re building, but the accumulated understanding of why. Architecture decisions, user feedback, competitive notes, abandoned approaches. This is institutional knowledge that large companies pay consultants to reconstruct.
Taste documentation. Your writing style. Your design preferences. Your communication patterns. The kind of thing that takes a new hire six months to absorb, available to an agent immediately.

The switching cost isn’t the tool. It’s the accumulated understanding. Moving from Obsidian to Notion is trivial. Rebuilding two years of structured context from scratch is not.

This is the same dynamic that makes a senior developer’s laptop more valuable than a junior’s, despite running the same IDE. The software is identical. The context is not.

The Security Problem Nobody Wants to Talk About

There’s a catch, and it’s a serious one.

If your vault is comprehensive enough to be a genuine moat, it’s also comprehensive enough to be a genuine attack surface. NanoClaw — a containerized fork of OpenClaw — exists specifically because its creator realized his agent could see everything in his vault while running a WhatsApp sales pipeline.

The vault’s power comes from comprehensive context. Comprehensive context is a massive liability if your agent gets compromised, your sync gets intercepted, or your API layer has a bug.

This isn’t theoretical. It’s the fundamental tension of the vault-as-platform model. The more useful your vault is to your agent, the more damaging a breach becomes. Selective sync, containerized agents, and access scoping are going to matter a lot more than most builders currently appreciate.

What This Actually Means for You

If you’re a solo builder and you’re not already working in a structured vault, start. Not because of any specific tool — because the accumulated context you build over the next 12 months is going to compound in ways that aren’t obvious yet.

If you already have a vault, treat it like infrastructure. Structure matters. Naming conventions matter. The difference between a folder of scattered notes and a queryable knowledge base is the difference between a pile of parts and a machine.

And if you’re evaluating tools: pick the one that gives you the most portable, agent-readable output. Markdown in a folder you control beats a proprietary database you can export from. When the next interface layer arrives — and it will — you want your context ready, not locked behind someone else’s API.

Your vault isn’t a productivity system anymore. It’s a moat. The longer you build in it, the wider it gets.

The builders who figured this out two years ago are already unreachable. The ones who figure it out today still have a window. The ones who figure it out next year will be playing catch-up with their own agents.

Originally published March 6, 2026 on The Undercurrent

The One-Person Backend

Mei Park — Mon, 09 Mar 2026 18:25:52 +0000

You don’t need a backend team anymore.

That sentence would have been absurd five years ago. Running a production web application meant provisioning servers, managing databases, configuring load balancers, setting up CI/CD pipelines, monitoring uptime, rotating credentials, and praying nothing broke at 3 AM. The “ops tax” on a solo builder was so steep that most people either partnered up, raised money, or built something simpler than what they actually wanted.

In 2026, a single developer can ship a globally distributed, offline-capable, real-time application with a database that fits in their deployment artifact. No Kubernetes. No RDS. No ops team. The infrastructure story has quietly become the most consequential shift in independent software.

## The SQLite Moment
SQLite has been around since 2000. It powers more deployed software than any other database engine. But for web applications, it was always dismissed as a toy.

That changed. Turso built a distributed SQLite service (libSQL) that replicates globally. Litestream solved backup and replication. Fly.io made it trivial to run SQLite at the edge. ElectricSQL added real-time sync between local SQLite and central Postgres.

The result: you can build apps where the database lives inside your application and replicates automatically. No connection strings. No cold starts. Your database is a file.

Edge Functions Ate the Server

The serverless revolution promised to eliminate servers. It delivered vendor lock-in instead. But edge functions are actually delivering on the original promise.

Cloudflare Workers, Deno Deploy, Vercel Edge Functions all offer the same proposition: write a function, deploy it, it runs everywhere. Combined with edge-native databases, you get full-stack at the network edge.

The Local-First Renaissance

Local-first software was a niche academic concept five years ago. Now it’s becoming the default for indie apps. CRDTs matured. PowerSync, Replicache, and Zero ship production sync engines. Local-first eliminates the always-on server. Your costs approach zero at rest.

The New Stack

Database: SQLite + Turso
Compute: Edge functions
Sync: PowerSync or ElectricSQL
Deployment: Git push

Monthly cost for a side project: under $20. For thousands of users: under $100.

What This Actually Changes

The ops tax was the great equalizer. Now that it’s disappearing, the constraint has shifted from “can you run it” to “can you build something people want.” That’s a much better problem to have.

Originally published March 5, 2026 on The Undercurrent