CodeIt guide
Did my kid learn anything, or did AI do it?
Your child built something with AI and it works. Here is how to tell whether they understood it, four checks you can run this week, on any platform.
Short answer: ask them to do four things with their own code, in this order. Find where something is set. Say what happens if you change it. Change it and get the result they predicted. Write something small from an empty file. A child who can trace and modify understood it. A child who can only point at the line has not yet, and that is a starting point rather than a verdict. The four checks are below, with what to say and what a good answer sounds like.
Your child asked an AI for a game. A game appeared. It runs, it looks good, and they are proud of it. You have no way to tell whether they built something or typed a wish and received a result.
Every parent using an AI tool now has this question, and almost nobody answers it well. Platforms report time spent, lessons completed and badges earned. None of those numbers say whether the child understood what is on their screen. Here is how to find out, whatever tool they use.
What "learning" even means when AI wrote the first draft
Drop the idea that learning means typing every character. Following a tutorial line by line, remixing someone else's Scratch project: these are how beginners have always started, and all involved code the child did not invent.
What matters is whether the child can operate on the code in front of them. Four abilities, in order of difficulty:
| Ability | What it looks like | How hard |
|---|---|---|
| Locate | "The speed is set on line 14" | Easiest |
| Trace | "If I change 14 to a bigger number, it falls faster" | Real understanding starts here |
| Modify with intent | Gets a specific result they described first | Solid evidence |
| Build from nothing | Writes something working from a blank file | Hardest |
Most parents fear the child is at zero. Usually they are somewhere in the middle, and the middle is worth something. Nothing on screen tells you which rung.
Four checks you can run this week
None require you to code, and all work on any platform, Scratch, Tynker, Roblox Studio, Lovable, anything.
1. Predict, then run. Ask them to change one number and say what will happen before pressing run. The prediction is the whole test. Being wrong and then saying "oh, I see why" counts as a pass.
2. Break it on purpose. Ask them to stop it working, then fix it. A child who can break a chosen part knows what that part does. One who cannot find the way back was not reading it.
3. Explain one line. Ask what a single line does, in their own words, no jargon. "That makes it move" is a pass if they can point at which part is the moving.
4. What next, and why. A vague answer ("more levels") is fine at first. A specific one ("a second enemy starting on the other side") means they hold a working model of their own program.
A script that works for a non-technical parent:
"Show me the part that makes it move." "If I made that number twice as big, what happens?" "Okay, try it. Were you right?" "Can you break it so it stops working? Now put it back." "What would you add next?"
Five minutes, every couple of weeks. You will hear the change in the answers long before any dashboard shows it.
Why most comprehension quizzes are worth so little
Most platforms attach quizzes to lessons, and almost all ask general questions: what does a for loop do? A child can answer that correctly and understand nothing about the program they just made, or get it right only because they remember the phrasing from a video ten minutes earlier.
There is a sharper kind of question, and the difference is not cosmetic.
| General question | Question from the child's own file | |
|---|---|---|
| Example | "What does a variable do?" | "In your project, what does fallSpeed start as?" |
| Can be answered by | Recalling a lesson | Reading their own code |
| Can be looked up | Yes | No |
| Can be memorised | Yes | No, every project differs |
| Proves | Familiarity with a term | They opened the file and traced a value |
A question drawn from the child's own file cannot be answered from general knowledge, looked up, or shared between two children. There is no way to get it right except by reading what you wrote. That is the entire argument, and it is worth more than any streak counter.
The same logic applies to the wrong answers. If the choices are 0, 1 and 100 and the real value is 3, a child can guess. If the wrong answers are other real numbers from the same file, guessing collapses. Every option looks plausible, and only reading resolves it.
The rule that makes it evidence: first try only
Here is the part most systems get wrong. If a child can retry a question until it turns green, it has stopped measuring comprehension and started measuring persistence with a mouse. Everyone eventually gets 100%.
So the rule has to be: only answers correct on the first attempt count as evidence. Retries still help the child, getting it wrong and seeing why is how people learn, but they should not count toward what a parent is shown. A record built this way is small and honest. One built on retry-until-right is large and meaningless.
What this proves, and what it does not
Answering questions about your own file is real evidence: the child read their code, located something specific, and traced a value. That is the rung most parents fear was never reached.
It is not proof:
- That the child could write the same code from a blank file.
- That they could apply the idea to a different problem next month.
- That they understand why it is written that way rather than another way.
- That they will remember it in six weeks.
Transfer, using an idea in a new situation, is what everyone actually wants, and nobody in this market measures it well. Any product claiming a handful of in-project questions prove your child "understands programming" is overclaiming. The honest version is narrower: here is what they demonstrated, on this project, on the first try.
The fair case for starting from generated code
There is a serious argument on the other side and it deserves a straight presentation.
Working programmers read and modify far more code than they write from scratch. Joining a team means opening a codebase you did not write and finding your way around it. Reading unfamiliar code is not a lesser skill than authoring it, for most professional work it is the more used one. A child who spends a year reading, tracing and modifying real code is practising much of what the job consists of.
The alternative for a beginner was often worse: a blank screen, a syntax error, no idea why, and quitting in week two. That is why Scratch and Tynker use blocks and why CodeCombat and CodeMonkey wrap the work in a game. Generated code removes blank-page failure another way.
The counter-argument is equally real: fluency comes from production, not only recognition. Struggling to make something work from nothing builds durable knowledge that reading does not. Codecademy and Khan Academy are built on that premise, and they are not wrong.
Both are true. Reading-first is a good start and a bad finish. If your child has used AI tools for months and never started from nothing, that is the gap to close, not because the AI work was fake, but because it was one half.
What different tools tell a parent
| Tool type | Examples | What a parent typically sees |
|---|---|---|
| Block-based | Scratch, Tynker | The project itself; judge by looking |
| Course-based | Codecademy, Khan Academy | Lessons completed |
| Game-based | CodeCombat, CodeMonkey | Levels cleared |
| Sandbox | Roblox Studio | Whatever the child shows you |
| Professional AI builders | Lovable, v0, Bolt | Nothing, not education products, and they do not claim to be |
Lessons completed and levels cleared are attendance records. They say the child was present. They do not say what the child could do with their own program, which is what you actually asked.
Disclosure: we make a tool in this space
We build CodeIt (codeitlearn.com), a browser-based studio built for ages 8 to 14, so treat this as an ad. A learner describes a website, game or quiz, and AI builds a working first version in plain HTML, CSS and JavaScript. They then change it in place: moving elements, picking colours and fonts, or asking for a change in plain language. A separate view shows which programming ideas the finished project uses, and links each one to its lesson. Errors are caught in the sandbox, rewritten in plain language and pointed at the learner's own line number, and one button restores the last version that ran. Understanding checks are generated from the learner's own file, with wrong answers taken from other real values in that file, and only first-attempt correct answers are recorded for the parent view. Finished work sits on a shelf on the front page instead of being overwritten by the next project. Profiles for ages 5 to 12 are parent-managed and email-verified; independent accounts start at 13. Free now, no card required.
Who this is not for. We have no study showing this improves learning outcomes, and we do not claim this evidence proves a child could write code from scratch or transfer the idea elsewhere, the limits above apply to us too. Managed under-13 profiles cannot publish publicly. There are 31 beginner Python lessons and no web curriculum; the web side is the builder itself. If your household rule is no AI at all, we generate code, so we are wrong for you. For Minecraft or Roblox mods, see Tynker; for coding games, CodeCombat; for a professional workflow, a teenager should use real developer tools. We have no school, district or teacher-dashboard product.
Common questions
What is the single best check? Ask them to predict what a change will do before running it. Everything else is a variation on that.
My child just says "the AI did it." That is information, not failure. Ask a smaller question, one line, one number.
Should I stop them using AI tools? Not necessarily. Pair it with something requiring production from nothing: a course, a class, or adding one feature unaided.
Questions parents ask first
What is the single best check?
Ask them to predict what a change will do before running it. Everything else is a variation on that.
Should I stop them using AI tools?
Not necessarily. Pair it with something requiring production from nothing: a course, a class, or adding one feature unaided.
What you can do on CodeIt
Last verified 2026-08-25.