Parents are right to ask what another hour at a computer actually contains. A child can spend an hour watching an endless feed, or spend an hour building a game, predicting a movement, finding a collision bug, and explaining why a score changed twice. Both activities use a screen. They are not the same kind of work.
Look at the verbs
A useful coding class can be described with observable verbs: build, test, debug, change, explain, and improve. The student makes decisions that alter a system. When Escape from the Giant Pigeon starts in the wrong corner, the student inspects x and y values. When win and loss happen together, the student decides which state has priority. The screen is showing the material under construction.
Passive screen time usually asks very little of the viewer between one item and the next. Project work creates resistance. The program does not care that the student meant to move upward; it changes the axis specified in code. That resistance is educational because it requires a prediction, evidence, and revision.
What a parent should be able to observe
After class, a student should have something specific to show. It may be a small game, a robot route, a reaction timer, or a state diagram. More important, the student should be able to answer concrete questions: What starts the program? What number controls left and right? What went wrong? Which rule did you change?
A finished project is not evidence that every line was written independently or that every concept is mastered. It is evidence that the class had a visible object around which understanding can be discussed. The demonstration makes vague claims about creativity unnecessary.
Screens still need boundaries
Calling an activity creative does not make unlimited device use harmless. Classes should have a beginning, a task, checkpoints, and an ending. Students should take visual breaks, talk with people, draw plans on paper when useful, and leave the project in a known saved state. A Computer Lab should not become an excuse for random gaming or unstructured browsing.
The School of Code distinction is simple: classes follow a planned learning path, while Computer Lab time provides guided project work. In both cases, the device serves the project. The project does not serve the device.
Ask a better question
Instead of asking only how many minutes involved a screen, ask what the child was doing during those minutes. Did the student make choices, encounter difficulty, inspect evidence, explain a system, and finish a version that can be demonstrated? If the answer is no, the activity may indeed be only more screen time.
If the answer is yes, the computer is functioning more like a workshop bench, notebook, stage, and test instrument at once. That does not eliminate the need for limits. It does explain why active programming can belong in a balanced education.
A simple after-class check
Ask the student to open the project and make one small change in front of you. Change the player speed, move a safe zone, or explain why the score begins at zero. Active work leaves a structure the student can revisit. If the project cannot be changed without starting over, that is useful information about how much was understood.
Also ask what failed. A real build usually contains a wrong turn: x changed instead of y, a loop ran forever, or restart preserved an old value. A student who can describe the failure and the repair has done more than operate an app. The child has compared intention with evidence and revised a system. That is the educational distinction School of Code is trying to protect.