Why Adult AI Workflows Fail Young Learners Without Thoughtful Educational Structures

In enterprise tech, and many other industries, AI is ultimately judged by one measure: how much friction it removes for what cost. A developer who ships in an afternoon what used to take a week is the story every vendor wants to tell. For professionals (and adults in general), this is the ideal.

For a nine-year-old, it is not. Workplace AI assumes the user already knows enough to judge what it produces. This is based on an adult’s years of experience, engagement and work in a variety of problem types.  A senior engineer can read generated code and spot the bad loop. A child reads the same code and assumes the computer is right. While the tool is identical, the users are entirely different. When we hand children software designed to remove the struggle of learning and growth, we remove the very thing that builds their ability to maximize their leverage as an adult.

Many AI-Native Tools Assume Expertise Kids Don’t Have Yet

Professional coding assistants are built around completion: finish the line, generate the function, fix the error. Each step assumes a qualified expert can quickly tell a plausible answer from a correct one. Children are still building that judgment, learning the parameters that work or don’t, and they build it the slow way – by trying something, watching it break, and working out why to then succeed.

Learning science has names for this. Psychologist Robert Bjork calls it “desirable difficulty”: effort that feels inefficient in the moment but produces learning that lasts. Education researcher Manu Kapur’s work on productive failure shows that students who wrestle with a problem before being shown the solution often understand it more deeply than students who get the answer first. An AI assistant that fixes the bug on the first prompt skips the wrestling, which leads to the child getting working code, but losing the lesson that builds lasting skill.

What a Guardrail Looks Like in Practice

Recently at one of our centers, a nine-year-old student was building a 2D game in JavaScript. Sprites overlapped, triggers fired at the wrong moments, and the game kept throwing errors. An adult developer would have pasted the code into an assistant and accepted the fix in seconds. However, because the user is a child, the instructor took a different route and asked questions instead. Where did you expect this sprite to be when the trigger fires? What happens to its position on the next frame? The student went to a whiteboard and sketched the coordinates. Only then did they use an AI tool, to locate where the conflict was, not to rewrite it. The fix was the student’s, and so was the understanding of why it worked.  The student did not encounter the same challenge again during their Javascript program because they locked in the struggle and lesson unearthed by the errors.

Even further, AI wasn’t banned in that session. It was guided and placed with intention. The instructor used AI with the child side-by-side after the errors were complete to explore other ways to solve the same problem. Today, in most learning settings, guardrails like these should live in people: instructors deciding which tools a child uses, when, and for what. That works, but it doesn’t scale. It also asks educators to compensate for products built for someone else.

Kid-first AI should carry those guardrails itself. It should point a child to where a problem is rather than hand over the answer. It should hold back corrected syntax on the first ask and move from a question to a hint to a partial example. It should explain the child’s own code back to them instead of replacing it, and ask them to predict what their code will do before they run it. The principle is simple: explainers over generators. A generator answers “what’s the code?” An explainer answers “why isn’t mine working?” Only the second one builds an AI future-ready adult.

Achievement Must be Felt, Not Just Logged

Digital progress is easy to ignore. A progress bar tracks every child and ticks forward with automated updates and communications. Young learners need the extra step and effort from educators and tools that allow them to see, hold, and share their accomplishments. Martial arts figured this out long ago – every belt ceremony is in front of peers and family, turning months of invisible effort into a moment a child remembers.

The same need holds for learning to code (or any academic subject). When a student stands up to receive new recognition for skills they earned through struggle, the ceremony reinforces exactly the habit that matters: persistence pays off. It also tells parents and classmates that effort is what counts, not output. AI makes output cheap, and not in a bad way, which makes celebrating effort more important than ever.  The journey becomes more important.

A Lesson for Enterprises

This isn’t only a children’s problem and today’s children are tomorrow’s workforce. Enterprises are automating the entry-level work that used to train junior engineers: boilerplate, simple bug fixes, first-draft code. Today’s senior engineers built their judgment on problems no tool solved for them before AI. If AI absorbs that work, organizations risk a generation of developers who can prompt and build but can’t diagnose and perfect. That is the same senior judgment AI-generated code depends on for review.

The fix mirrors the classroom. Treat early-career staff as learners, not just throughput. Turn on explain modes for junior developers, measure juniors on growing judgement in addition to velocity, etc.

Enterprise tools are designed to remove struggle and they should.  We must acknowledge however that education is built on struggle. Instead of a one-size-fits-all approach to AI in relation to ages and use cases, we should differentiate how AI applies to adults vs. K-12. If we hand children the answers before we ask them the questions, we’ll raise a generation of prompt typists instead of independent thinkers, and we as enterprises will inherit them.