AI can help children learn coding by explaining an instruction, suggesting a small piece of code, proposing a test or asking where a result differs from what was intended. The useful outcome is a learner who can describe the problem, follow the program’s decisions and explain a correction. Parents can begin with a small task whose rules and answers are easy to inspect, then use AI for a clearly defined contribution.
This guide develops an original classroom book-grouping activity from an ordinary instruction into a testable algorithm. All book records and results are invented for teaching. The activity can be explored with cards, readable pseudocode or a suitable programming environment; it is not an official assessment task. The purpose is to make computational thinking visible while the child decides what the solution should do, checks its behaviour and investigates how it could change.
- Define the problem and expected output before asking AI to write code.
- Choose only the information the task needs and explain what it means.
- Break the work into smaller decisions that can be checked.
- Trace sequence, conditions and repetition using a few concrete records.
- Test ordinary cases, boundaries, missing information and an empty input.
- Repair the reason for a wrong result and rerun relevant checks.
- Keep code readable enough for the learner to explain and modify.
- Follow school and service rules while retaining the child’s usual access supports.
eduKateSingapore · AI and Education
Choose a useful reading route
Start with the question closest to your family, or read the guide in order.
Full chapter index · Read from chapter 1 · Sources and further reading
Contents
Chapters 1–3: Define the problem
Chapters 4–6: Trace and test
Chapters 7–9: Repair and explain
Chapters 10–12: Use and extend
A useful first coding project has a purpose that the learner can explain without mentioning a programming language. “Put these book records into the requested groups” gives a child a clearer starting point than “Build a clever app”. The smaller problem makes it possible to inspect whether the result is right.
Imagine a fictional classroom activity in which book cards need to be divided by their recorded page counts. One group contains positive whole-number counts up to and including 80. A second contains counts above 80. Cards with missing or invalid counts go into a separate checking group.
The cutoff is an invented rule for this exercise. It is not a reading level, a judgement of a book’s value or a recommendation about what a child should read. A short book can be demanding, and page count alone does not describe a reader’s needs. Here, it supplies a clear numerical condition to investigate.
Ask the learner to group three cards by hand before discussing code. Can they explain where a card with 24 pages belongs? What about 120 pages? What should happen when the count is unknown? The answers reveal whether the problem itself is understood.
MOE’s Computing curriculum framework, shown in its 2026 G1 Computing syllabus, includes abstraction, decomposition, algorithmic thinking and generalisation, alongside creating and evaluating computational artefacts. This provides curriculum context for examining both a solution and the reasoning behind it. It does not make this particular activity a requirement for every student.
Keep the child’s current school task in view. A teacher may be developing a specific concept or using a particular environment. Ask which part of the problem the learner is expected to handle and what assistance is permitted. The family exercise can then support that goal without becoming a competing course.
AI can help clarify a confusing instruction, but the child should approve the meaning before proceeding. Ask the tool to restate the task and identify anything uncertain. If it quietly changes the groups or invents a purpose, return to the original request. Understanding the problem is already part of learning to code.
CHAPTER 2 OF 12 · Define the problem
2. Write a specification that settles the important questions
A specification states what a solution is meant to do. For this activity, write the rule in ordinary language: every input record must appear in exactly one output group, and its recorded page count determines the group. The program should preserve the record so a person can identify the book afterwards.
Define a valid page count as a positive whole number. One, 24, 80 and 120 satisfy that definition. Zero, a negative number, a fractional number and an unknown value do not. This is the rule of the exercise, rather than a claim about every way publishing systems might record books.
Make the boundary explicit. “Up to 80” means that 80 belongs in the first group. “Above 80” begins with 81 when the counts are whole numbers. A learner who leaves this detail unstated may later receive code that makes a different decision at the boundary.
Give each fictional card a distinct identifier, such as A or B. This lets the class distinguish two records even if their titles are similar. For the initial task, assume each physical book has been entered once. The algorithm processes records; it does not independently inspect the bookshelf to discover an omitted or duplicated entry.
Decide what the output should show. It should name all three groups, list the records in each and make an empty group understandable. A result that displays nothing could mean that there are no records, that a group is empty or that the program stopped. A clear report distinguishes those situations.
Ask AI to find ambiguity rather than add features: “Read this specification. Ask one question about an instruction that could lead to two different results.” The learner should decide whether the question exposes a real gap. A suggestion about cover colours or book recommendations is outside the current task.
Finally, state what success will look like on a small example before any code is written. This gives the family an independent basis for checking the generated result. If the expected answer is invented only after the program runs, it becomes too easy to accept whatever output appears.
CHAPTER 3 OF 12 · Define the problem
3. Choose a representation and divide the work
A program needs information in a form it can use. A record for this task can contain an identifier and a page-count value. Other details may be interesting, but the classification rule does not need an author’s name, a cover photograph or a description of the reader.
This selective representation is an example of abstraction: keeping the features relevant to the question. It does not mean the omitted features are unimportant in every situation. If the task changed to finding a book by its author, the representation would need to change too.
Use the following six original records throughout the first version. The question mark means that the count is missing. The zero is deliberately invalid under our specification. Neither should be silently converted into an ordinary small count.
| Record | Recorded pages | Expected group |
|---|---|---|
| A | 24 | Up to 80 |
| B | 80 | Up to 80 |
| C | 81 | Over 80 |
| D | 120 | Over 80 |
| E | ? | Needs checking |
| F | 0 | Needs checking |
Now divide the work into responsibilities: read a record, check whether its count is valid, choose a group, add the record to that group and report the results. These parts connect, but each can be discussed separately. This is a practical way to make decomposition visible.
Ask which part needs to know the cutoff. The classification decision does. The step that reports a list does not need to recalculate the rule if the records have already been assigned correctly. Separating responsibilities helps the learner locate a problem when an output is wrong.
Keep the checking group visible. It represents information that needs attention, not books that have disappeared. If a person later confirms E’s page count, the updated record can be processed again. Guessing a number would hide a data problem inside a tidy-looking result.
AI can propose a representation, then explain how each field serves the specification. Ask the child to remove any field that has no current purpose. The goal is a small model they can understand, while recognising what that model can and cannot tell them about the real objects.
An algorithm is a set of instructions for carrying out a task. Its order matters. In this example, the program must decide whether the count is valid before comparing it with 80. Otherwise, an unknown value may be compared inappropriately or an invalid zero may be placed in the first group.
The following is readable pseudocode, not a particular programming language. It records the logic without requiring the learner to manage all the punctuation and setup of an executable program. A teacher can later help map the same structure into the chosen environment.
SET up_to_80, over_80 and needs_check to three separate empty lists.
FOR EACH record in book_records:
IF its page count is not a positive whole number:
APPEND the record to needs_check.
ELSE IF its page count is less than or equal to 80:
APPEND the record to up_to_80.
ELSE:
APPEND the record to over_80.
END IF.
END FOR.
REPORT all three lists.
Explain the alternatives in everyday language. A record with an invalid count enters the first branch. If its count is valid, the next condition asks whether it belongs in the lower band. If neither earlier branch applies, the valid count must be above 80.
The linked alternatives are important. Each record follows one branch and is appended once. Three unrelated instructions could accidentally place the same record in more than one group if their conditions overlap. Ask the child to identify the point where the decision for one record is complete.
In many programming languages, <= expresses “less than or equal to”. If that notation is unfamiliar, keep the words beside it. The symbol represents a relationship the learner already needs to understand; remembering the characters alone does not establish that understanding.
Trace B through the instructions. Its count is 80, which is a positive whole number. The invalid branch is skipped. Eighty is less than or equal to 80, so B is appended to the first list. The alternative above-80 branch is not also performed.
Ask AI to explain only that trace, using the stated rules. Check whether it changes the condition or evaluates branches that should have been skipped. The learner can then trace another record without the explanation. This creates a direct connection between the written algorithm and the result it should produce.
A loop repeats an operation for several inputs. Here, the same decision process is applied to every record. The child does not need to write a different classification rule for A, another for B and another for C. The record changes; the rule stays the same.
Begin with three empty trays representing the output lists. Read A, decide that 24 is valid and within the first band, and put A into the matching tray. Then move to B. After processing B, the first tray contains A and B, while the other trays remain empty.
Continue with C and D, then E and F. At the end, the first group contains A and B, the second C and D, and the checking group E and F. There are six processed records and six records across the output groups, with each identifier appearing once.
The contents of the trays are the changing state of the activity. A useful trace records that state after a step, rather than only showing the final result. If B disappears later, a step-by-step record can help identify when the result changed unexpectedly.
Make progress through the input explicit. In a card activity, place each processed card in its output tray and take the next unprocessed card. In a program, a for-each loop manages the progression through the collection. Repeatedly examining the same record would not complete the intended task.
Test an empty input as well. If there are no book records, the loop has no records to process. All three lists remain empty, and the report should say so clearly. Empty input is a meaningful case, not necessarily an error.
AI can help produce a trace table for a small input, but ask the child to predict each next state before revealing it. If the tool skips a record, resets a list halfway through or adds one twice, the learner should be able to locate the mismatch against the rule.
Keep the distinction between grouping and ordering visible. This algorithm assigns records to bands and preserves their input order within each list. It does not arrange books alphabetically or by increasing page count. Either of those would be another task with its own rule and tests.
A test combines an input with an expected result. Choose the expected result from the specification, not from the program’s existing output. The purpose is to discover whether the program behaves as intended, including in situations that a convenient demonstration may overlook.
Start with ordinary valid counts, such as 24 and 120, then examine the boundaries. Seventy-nine, 80 and 81 sit just below, at and just above the cutoff. These neighbouring cases are especially useful for finding a mistaken comparison.
Also test the smallest valid count, missing information and invalid values. Our rules allow one page but reject zero, negative counts and fractions. The table provides a small original set whose outcomes can be checked by hand.
| Input count | Expected result | Reason for the test |
|---|---|---|
| 1 | Up to 80 | Smallest valid count |
| 79, 80, 81 | Up to 80; up to 80; over 80 | Cutoff and neighbouring values |
| ? | Needs checking | Missing information |
| 0, −1, 2.5 | Needs checking for each | Values outside the specified valid counts |
| No records | Three empty output lists | Empty input collection |
For the full six-record example, inspect more than the number of cards in each group. Two cards in each tray would also occur if A and C were wrongly exchanged. Counts help identify some errors, but the actual membership must match the expected result.
Ask whether every input record appears once and whether any unexpected record has appeared. These checks express useful properties of the whole result. A program can calculate the right band for each record it handles and still fail if it accidentally skips the final record.
AI can propose an additional test and explain which possible mistake it would expose. The child should decide whether that mistake is relevant to this specification. A useful test adds information; hundreds of nearly identical examples may provide less insight than one carefully chosen boundary.
Passing these tests increases confidence in the cases examined. It does not automatically prove correctness for every imaginable input or every later version of the program. The learner should be able to name the accepted input types and assumptions that define the current task.
Keep the tests short enough to revisit after a repair. The goal is a manageable body of evidence showing what the program has actually done and why those observations matter.
CHAPTER 7 OF 12 · Repair and explain
7. Repair a bug by finding the decision that failed
Suppose a draft program sends B, with 80 pages, to the over-80 group. The screen may look tidy, and all six records may appear somewhere, but the output conflicts with the specification. Begin with that concrete mismatch instead of asking AI to rewrite the whole program.
Trace B through the draft. Imagine that the validation is correct, but the next comparison says “page count is less than 80”. Eighty fails that condition and enters the alternative branch. The first wrong decision is now visible.
The repair is to include equality in the lower band: “less than or equal to 80”. Ask the child why the change belongs there. It follows from the agreed meaning of “up to and including 80”, not from a desire to make one particular test look successful.
Rerun 79, 80 and 81 after the change. The expected groups are first, first and second. Then check the missing and invalid values to make sure the earlier validation still operates. Finally, inspect the six-record output again.
Another possible bug is resetting an output list inside the loop. If the program creates a new empty first-band list before processing each record, earlier entries can disappear. A trace of the lists after A and after B would reveal the problem. The empty lists should be established before the repetition begins.
Keep these two repairs conceptually separate. The first concerns a comparison at a boundary. The second concerns when state is created and preserved. Both can produce wrong outputs, but they require different explanations and changes.
Use AI for a narrow debugging question: “Here is the rule, the input, the expected result and what happened. Help me locate the earliest decision that could explain the mismatch. Do not replace the whole solution.” Inspect whether its diagnosis fits the actual trace.
After a repair, ask the learner to describe the cause in their own words and create another case that would reveal the same kind of mistake. This turns debugging into knowledge the child can use again. A copied replacement may run successfully while leaving the original misunderstanding untouched.
A child can use AI at several stages without handing over the whole project. It can ask about a missing requirement, explain a condition, suggest pseudocode for one decision or propose a test. Choose the contribution according to the learner’s current uncertainty.
If the student understands the rule but is unfamiliar with a programming environment, a small translation may help. Ask for the classification decision in the language or block system the teacher uses. Include the validity rule and the cutoff. Then compare the result with the pseudocode before running it.
If the student does not yet understand why 80 belongs in the first group, translating the entire project into code is unlikely to settle that question. Return to two neighbouring cards and the wording of the specification. The missing concept should guide the next explanation.
Set the size of the request. “Show only how to choose one group for one record” is easier to inspect than “Build a complete library management system”. Additional menus, graphics and features can conceal the decision the child is trying to learn.
Ask the tool to identify assumptions. Does its code expect the input to be a number already? What happens when the value is missing? Does it silently replace an unknown count with zero? The child needs to compare those behaviours with the agreed input rules.
Do not treat a generated explanation as proof that the code behaves that way. The explanation and implementation can disagree. Trace a boundary case through the actual instructions and run a small relevant test when using an executable version.
A useful contribution record can be brief: “I defined the groups and expected results. AI suggested a conditional statement. I changed the comparison to include 80 and checked the neighbouring values.” It should describe what happened, not follow a fixed formula regardless of the project.
For younger learners or settings where direct use is unsuitable, an adult can prepare a short generated example for discussion under the relevant access conditions. The child can still decide whether the example follows the rules. The educational value lies in the reasoning and action the learner performs with the material.
CHAPTER 9 OF 12 · Repair and explain
9. Read and explain code that someone else produced
Reading a solution is a substantial part of learning to code. Before changing an unfamiliar program, ask what information it receives, where it makes a decision and what it produces. The student should be able to connect those parts to the specification.
Names can make that connection easier. A list called needs_check tells the reader more about its role than a list called x. A variable called page_limit can make the cutoff easier to locate if the activity later changes. Names should describe the actual role rather than promise behaviour that the code does not provide.
Comments can explain a reason that would otherwise be unclear. “Missing and invalid counts stay visible for review” describes why the checking group exists. A comment saying “add one” beside an obvious addition contributes less to understanding. Ask whether the explanation helps a future reader make a decision.
Compare two valid solutions without assuming that one surface form is compulsory. One may use nested conditions; another may first select invalid records and then group the valid ones. Evaluate whether each preserves every record, applies the same rules and produces the agreed report.
A shorter program is not automatically more suitable for a beginner. A compact expression may hide several decisions the child cannot yet trace. Conversely, unnecessary repetition can make a small change difficult to maintain. Discuss readability in relation to the learner and the task.
Ask the child to explain an instruction before running it, then predict the result for one record. If their prediction differs from the output, locate whether the misunderstanding concerns the language, the data or the rule. The difference provides a focused question for an adult or tool.
AI can help describe unfamiliar code, but request a connection to the supplied specification and inspect each claim. If the tool says the records are alphabetically sorted, look for an instruction that actually performs that ordering. A description of a feature is not evidence that the feature exists.
Finish by asking the learner to make one justified change and explain its consequences. Reading becomes more meaningful when the child can use the understanding to predict what a modification will do and choose which tests should be repeated.
A correct internal classification still needs a useful presentation. Imagine a classmate receiving three unlabeled lists of identifiers. They may be unable to tell which group is which or why a record needs attention. The report should support the person’s next action.
Name the groups in plain language and show enough information to identify each record. “Up to and including 80 pages” states the boundary more clearly than a vague label such as “small”. The checking group can show the original value rather than conceal it.
For E, report that the count is missing. For F, report that zero does not satisfy the activity’s positive-count rule. These messages help a person decide what information to inspect. They should not invent the correct count or imply that the actual book must be defective.
Use a clear empty state. If there are no records above 80, the report can say that this group has no entries. If the entire input is empty, state that no records were supplied. The distinction helps a user understand whether the program completed the task it was given.
Consider the way the intended reader encounters the information. A colour-only label may be difficult to distinguish or may lose meaning in a plain printout. Text labels provide another way to understand the groups. Ask the learner which information remains available if the decorative features are removed.
A simple usability check can involve a willing classmate or family member. Give them the report and ask where they would look for B and which cards need checking. Observe any misunderstanding without supplying the answer immediately. One person’s response informs this version; it does not establish that every user will understand it.
AI can propose clearer labels or a shorter message, but the learner should check that the wording preserves the rule. “No books found” would be misleading if the input contains records with missing page counts. A more precise message keeps both the data and the limitation visible.
This part of the project connects coding with communication. The student must think about another person’s purpose as well as the program’s internal steps. A successful report makes the next decision easier without exaggerating what the underlying information establishes.
Once the first version is dependable, a changed requirement creates a useful new question. Suppose the classroom activity now uses a cutoff of 60 rather than 80. Which instructions, labels and tests need to change, and which parts can remain?
The validity rule still requires positive whole numbers. The classification boundary changes, and the output labels must describe the new bands. Tests around 59, 60 and 61 become relevant. Merely changing a heading while leaving the comparison at 80 would create a misleading report.
On the original six records, A remains in the lower band, while B, C and D belong above 60. E and F still need checking. The expected group sizes become one, three and two. Ask the student to predict that result before modifying the code.
A more experienced learner could investigate three valid bands: up to 40, 41 to 80, and above 80, plus the checking group. They would need to make sure the conditions cover every permitted count without overlap or a gap. Testing 40, 41, 80 and 81 would help inspect the new boundaries.
Another extension concerns ordering within a group. A classmate may want the records listed from the fewest pages to the most. This adds an ordering task after classification. Ask whether the new request changes group membership or only the order in which valid records are presented.
AI can suggest possible extensions, but choose one that serves a real learning question. The child might compare two ways of organising the conditions or investigate whether a single named limit makes future changes easier. They should state what they want to find out before adding features.
The centre of this work is the dependable understanding of data, sequence, conditions, repetition and tests. The edge is the question the learner has not yet resolved about a changed requirement or a better way to express the solution. That discovery can be new to the child without being a new result in computer science.
Keep the earlier working version and its tests available. A new attempt can then be compared with a known reference. The learner can explain what changed, why it changed and what evidence shows that the revised program now follows the revised rule.
CHAPTER 12 OF 12 · Use and extend
12. Choose support from the learner’s next decision
Parents can support this learning without becoming professional programmers. Ask the child what the program should do, which example they are checking and where the actual result differs. Those questions keep the discussion connected to a problem that both people can inspect.
If the learner struggles to understand the rule, work with physical or written cards. If the rule is clear but the program behaves unexpectedly, trace one record. If the code runs but the child cannot explain it, reduce the example until its decisions can be followed comfortably.
Computer science can also be explored without a screen. The University of Canterbury’s CS Unplugged project provides activities using ordinary materials to investigate computing ideas. The book-grouping activity here is an original example, and families can choose a format that makes the reasoning accessible.
Retain the learner’s usual supports. They might dictate an explanation, use enlarged text, move cards with assistance or direct another person through the steps. Judge the computational decisions being learned rather than requiring every child to interact with equipment in the same way.
For schoolwork, use the actual curriculum and teacher’s instructions. A general coding activity is not evidence that a particular programming language, AI service or form of help is permitted in assessment. Ask a precise question about the task when the conditions are unclear.
If considering additional teaching, ask how the educator makes a learner’s thinking visible. A useful demonstration might include predicting output, finding a boundary mistake and explaining a repair. A polished finished game alone does not show which decisions the student can make independently.
A manageable review can retain the specification, a small set of expected results, one trace and a short account of a correction. Ask what the learner would change if the cutoff moved and which test would detect a missing record. These questions examine understanding beyond the appearance of the final screen.
Use AI where it contributes a helpful explanation, draft or challenge that the child can inspect. The student continues to define, predict, test and revise. The next useful step follows from the decision they can now explain and the question they are ready to investigate, rather than from the amount of code a tool can produce.
Contents · Previous chapter · Next: sources and further reading
Sources and further reading
- Ministry of Education: 2026 G1 Computing syllabus — context for the Computing curriculum framework; not a claim that this activity or subject is compulsory for every learner.
- CS Unplugged, University of Canterbury — resources for exploring computer science with ordinary materials.
Sources checked on 15 November 2026. The book records, grouping rules, pseudocode, tests and family activities in this guide are original teaching examples. They are not official examination questions or evidence of results from a particular AI product.
More guides for parents
Follow another subject or return to a question about your child’s learning.