Six things kids leave with that they didn’t have.

What “outcomes” actually means.

The phrase “learning outcomes” is a textbook term and it covers a lot of ground. What we mean by it here is narrower: durable competencies the kid carries into school, into other projects, into adult life. Not state-test scores. Not Scratch-block counts. The things the kid can do, the habits they reach for, the mental models they hold, after the studio has stopped being the active site of work.

The standard for naming an outcome is strict. It has to be observable. It has to have a research base behind why it matters. And it has to be plausibly a side effect of what the studio is actually doing, not a wish-list item the marketing copy bolted on. Six items pass that bar. Here they are, in roughly the order kids develop them.

1. An iteration habit.

Inside a typical session, a kid reviews dozens of AI proposals. Keep, review, undo, keep, undo. By the time they’ve been in the studio for a month, the reflex is automatic. They don’t ask whether a change is right before pressing the button. They ask whether they like the result after.

That reflex has a research name. Carol Dweck calls it growth mindset: the belief that ability develops with effort and feedback rather than being fixed.¹ Albert Bandura calls the closely related construct self-efficacy: a learner’s belief in their own capacity to influence outcomes through action.² Both bodies of work converge on the same finding. Kids who repeatedly experience their own iteration build durable confidence that they can handle the unknown.

The studio doesn’t teach this in a lesson. It puts a Review button at the center of the workflow and the kid presses it a hundred times. The habit is the curriculum.

2. Working AI literacy.

By the second or third session, kids in the studio have watched AI work, watched it fail, and made decisions about what to keep. That sequence is not what most kid-AI products produce. Most produce kids who treat AI as a finished-answer dispenser.

Duri Long and Brian Magerko’s 2020 CHI paper defines AI literacy as five competencies, none of which is “prompt engineering.”³ Recognizing AI. Understanding what it is. Knowing how it learns. Seeing AI across domains. Programming AI behavior. The studio surfaces all five as visible affordances: the tool-trace pane shows AI working, the ChangeDisclosure card shows what changed, the “same prompt, two answers” quest shows that AI is probabilistic, project files like GAMEPLAN.md let older kids shape AI behavior with written instructions.

What kids walk away with isn’t a vocabulary. It’s a working model. They can tell when AI is doing something useful, when it’s being lazy, when it’s confidently wrong. That model travels. We see it show up when the same kid uses ChatGPT for homework: they push back more, they verify more, they treat the output as a draft rather than a verdict.

3. Authorship instinct.

Ask a 10-year-old who’s spent a few weeks in the studio whether a particular line of their game is theirs or Inkie’s. They usually know. They remember which proposals they kept, which they rewrote, which they ignored. The artifact has a felt provenance.

That instinct is fragile and worth protecting. Edward Deci and Richard Ryan’s self-determination theory identifies autonomy, competence, and relatedness as the three psychological needs whose satisfaction predicts intrinsic motivation.⁴ Autonomy in particular — the felt sense that the work is yours and you chose it — is what keeps a kid coming back to the project on day twenty.

The kid remembers which proposals they kept, which they rewrote, which they ignored. The artifact has a felt provenance. That feeling is the engine that brings them back on day twenty. Self-determination theory, restated for kids and AI

The studio protects authorship by surfacing every AI change as a proposal the kid decides about. There is no “AI mode” that takes the wheel. Inkie does not ship code without a Keep press. The kid is the author of record, every change, every session. The instinct that develops is durable, and it follows them into other creative work: the question “is this mine?” becomes a default they apply automatically.

4. Taste under constraint.

Taste is the hardest outcome to name and the most valuable to develop. The studio surfaces it as a constant low-stakes question: does this proposal fit the project, or doesn’t it? A new character. A different music cue. A change in level pacing. The kid makes a hundred such decisions across a project and slowly develops a sense of what belongs in the thing they’re making.

Mitchel Resnick’s four Ps framework names this directly. Projects: kids build durable taste by working on something concrete they care about over time.⁵ The MIT Lifelong Kindergarten group has spent decades watching kids in Scratch develop project-specific taste; the same pattern shows up in the studio. A kid working on a survival game develops opinions about survival-game pacing. A kid working on a portfolio site develops opinions about portfolio-site typography. The taste is local, and that’s exactly the point.

Constraints sharpen taste. The studio ships real, working artifacts: a deployable URL, an HTML file, a story document. The kid’s decisions have to fit the constraint of a shippable thing. That’s the difference between taste and preference. Preference is what you like. Taste is what you choose under pressure.

5. Public-shipping confidence.

Every Tell and Show project ends with a parent-approved deploy to a real URL. The kid’s grandmother can open it. A school friend can open it. The act of shipping in public, with their name attached, is rare in childhood and significant when it happens.

Resnick’s framework names this too. Peers is the third P: kids build creative confidence by showing work to a real audience, not just to themselves.⁵ The Lifelong Kindergarten studies of Scratch find that kids whose projects are seen by other kids iterate more, take more risks, and develop more durable identities as makers. The studio bakes the peer audience in: the deployed URL is the artifact, and it’s share-ready by default.

What the kid walks away with is the lived experience of having made a thing public. That experience is hard to fake and hard to undo. The next time someone asks “can you make this?” the kid’s default isn’t “I don’t know how.” It’s “I’ve done it before.”

6. A working mental model of how digital things are made.

This is the meta-outcome, the one the other five point at. After a few projects, kids in the studio have a working mental model of how a digital artifact is structured. They’ve seen the project tree. They’ve watched a wizard touch one file and not another. They’ve read the ChangeDisclosure card. They know that the thing they’re looking at on the screen is made of files, and the files are made of text, and the text follows rules.

Bret Victor’s 2012 essay Learnable Programming argues that programming environments should make the runtime visible so the learner can build an accurate mental model of what’s happening.⁶ Ben Shneiderman’s 1983 work on direct manipulation made the same case earlier, in a different vocabulary: learners build understanding when the system is transparent and their actions have visible, immediate consequences.⁷ Both arguments predict that hiding the layers produces kids who treat software as magic, and exposing the layers produces kids who treat software as a tractable kind of thing.

The studio leans on this. View-source is preserved across the site track. Project files are visible in the tree. The wizard’s before-and-after diffs are inspectable. The kid is not handed a black box; they are handed a glass box with an AI partner inside it. After a few months, when they hear that someone built an app, their first instinct is no longer to feel that they couldn’t have. It’s to ask how the app is structured. That shift is the outcome.