Teaching Kids to Prompt AI: Why the Verb Matters Most

Last updated: August 2026

Teaching kids to prompt AI well has almost nothing to do with prompt length. In July one of my students, Alice, 15, told her AI coding assistant to "change everything" when she meant one section of her website. It changed all twelve files in the project. She had to undo the work and redo it properly scoped.

Days later the same student gave the same tool a far broader instruction, on a stronger setting, across her entire site. That time it changed exactly two things and wrote her a list of problems it had deliberately left alone. The difference was not how much she asked for. It was the verb she used and whether she gave it a stopping condition.

Key Takeaways

• "Change everything" produced a 12 file rewrite when one section was intended. Vague scope plus an open imperative is the worst combination.
• "Make it beautiful" produced flowers on the blocks of a Tetris game. Aesthetic words carry no shared meaning.
• The broadest prompt of the month produced the most restraint, because it included a standard and a way back.
• Over-specifying is its own failure. Long, detailed prompts give the model more to misread and it drifts further from what your child pictured.
• The reliable habit is to describe the shape, bound the scope, and iterate one change at a time.

Table of Contents

• The 12 File Overwrite
• The Flowers on the Tetris Blocks
• The Prompt That Behaved Perfectly
• Why Longer Prompts Are Not Safer
• The Four Rules I Now Teach
• Frequently Asked Questions
• The Bottom Line

The 12 File Overwrite

Alice was working on the hero section of a portfolio site she is building. She wanted a change applied across that one section, and she wrote a short instruction telling the assistant to change everything.

It did. Twelve files, the whole project. Nothing was lost, because she had been committing her work regularly and could step back, but the session lost time and she had to write the instruction again with the scope stated explicitly.

The interesting part is that her prompt was short. Most advice about prompting tells you to add more detail, and more detail would not have helped here. What was missing was a boundary. "Change everything" is an instruction with no natural place to stop, so it did not stop.

The Flowers on the Tetris Blocks

The same lesson arrived from a completely different direction with Umar, 16, who was building a Tetris game as his first project.

He asked the assistant to make it beautiful. It rendered flowers on the falling blocks.

This was the sharpest teaching moment of that session, and Umar got the point immediately once he saw it. "Beautiful" is not a specification, it is a feeling. The tool had to guess, and it guessed flowers. When he replaced it with concrete direction, retro, glowing, a specific colour scheme he actually wanted, he got something close to what he had in his head on the first try.

I now use this as the standard example when a student reaches for an aesthetic word. If you cannot point at something that looks like what you mean, the tool cannot either.

The Prompt That Behaved Perfectly

Here is the case that changed how I teach this.

Later in the month I set Alice a homework task: use the strongest model available, tell it to sweep the entire site and improve whatever it could, and make sure there is a way back if anything breaks. That is a much broader instruction than "change everything." It covers the whole project rather than one section.

It came back having made two changes. It removed a font file that was being downloaded but never used, and it added support for the setting that tells a site to reduce animation for people who get motion sickness, which is a genuine accessibility improvement documented at MDN's reference on prefers-reduced-motion. It also made itself a backup before starting.

Then it did the thing I did not expect. It wrote out a list of other problems it had found and deliberately not touched, including missing real contact details and the absence of navigation on mobile, and left those as her decision.

The widest instruction of the month produced the most conservative behaviour. The reason is in the wording. "Improve what you can" contains a judgement call and an implicit standard. "Keep a way back if anything breaks" tells it that caution is valued. "Change everything" contains neither. It is a command with no test for when the job is done.

Why Longer Prompts Are Not Safer

The instinct once a kid has been burned is to write much longer prompts, specifying every detail up front. That fails differently.

I watched Alice do this repeatedly in her early sessions. She would picture a finished, animated result and try to describe all of it in one go. The output drifted further from what she wanted, not closer. The more detail you hand it at once, the more there is to interpret, and interpretation is where it wanders.

What worked was the opposite. Describe the shape and stop. "Four categories at the top, someone clicks one, the items come up" was enough to get a correct first version. The animation, the hover behaviour, and the colours all came afterwards, one at a time, each one checked before the next was added.

There is a related structural habit worth teaching alongside this. Rather than editing the thing you already like, have the tool build a clearly labelled copy underneath it, work on the copy, and only replace the original when the copy is better. Alice used this on every section after she learned it, and it removes the risk from the whole question. Even a badly scoped instruction can only damage the copy.

The Four Rules I Now Teach

These came out of July and I now give them to every student working with AI coding tools.

1. Name the boundary, not just the task. Say which section, which file, which area. "Only work inside the testing area" is one clause and it prevents the twelve file problem entirely.
2. Never use a feeling as a specification. Beautiful, clean, modern, and cool all mean nothing. Replace them with something concrete, or better, with a picture of what you mean.
3. Give it a standard and an escape hatch on big asks. "Improve what you can, keep a way back" is safe on a whole project. "Change everything" is not safe on one section. The Claude Code documentation covers the permission modes that make this safer still, and they are worth setting up before handing a child the keyboard.
4. One change, then look. Land it, check it, then add the next thing. Kids want to describe the finished result. The finished result is what you arrive at, not what you ask for.

The fourth is the hardest to teach because it goes against how a 15 year old imagines the work. In 20 years of teaching kids to code, across more than 200 students, the pattern is consistent: children describe destinations and adults describe next steps. Learning to describe the next step is most of the skill.

Frequently Asked Questions

What is the most common prompting mistake kids make? Using an aesthetic word as an instruction. Beautiful, cool, and clean feel specific to the person typing them and carry no shared meaning at all. This produced flowers on a Tetris game in one of my sessions.

Should I teach my child to write long, detailed prompts? No. In my sessions long prompts drifted further from what the student pictured, because more detail means more to misinterpret. Describe the shape, get a rough version, then refine one thing at a time.

How do I stop an AI tool from breaking my child's project? Have it build a labelled copy of the section rather than editing the original, and commit finished work regularly so there is always a version to return to. Both habits make a badly worded instruction survivable.

Is it worth using the more powerful AI models for a child's project? Sometimes, and it is a skill in itself. In my sessions the stronger model on a broad instruction behaved more cautiously and flagged issues rather than forcing changes. It also consumes far more of your usage allowance, so it suits hard passes rather than routine work.

At what age can a child learn to prompt properly? I have taught the same principles to children as young as 10. The rules do not change with age, only the examples do. What changes is how much supervision is needed when something goes wrong.

Related Articles

• When Should Kids Start Using AI Coding Tools?, the readiness question that comes before this one.
• What Happens When a 10-Year-Old Directs an AI Game Builder, the same skill in a much younger student.
• What I Tell Parents About Kids Using AI for Homework, where the line sits between using a tool and outsourcing the thinking.

The Bottom Line

The quality of a child's prompt is not measured in words. It is measured in whether the instruction has a boundary and a stopping condition. "Change everything" broke twelve files. "Improve what you can, keep a way back" swept an entire site and changed two things carefully. Teach the boundary and the rest follows.

Want to know whether your child is actually driving these tools or just watching them work? Book a free Discovery Call and I will walk through what your child can do unsupervised today and what still needs someone beside them.