Lesson 2 of 32 in this sequence

Not completed yet

Saved on this device only — not synced to an account yet.

Learning path

Step 2 of 32

Continue the sequence

ResumeReturn to this step ReviewRevisit the core idea RemediateGet repair practice Next stepChoose the next lesson manually

Completion

Review objectives and instruction
Complete the activity with manual learner confirmation
Answer every understanding-check item
Show completion feedback and reward only after the learner finishes the check

Progress

Step 2/32
15 content types
AI help source context available
Auto-advance blocked

Review objectives and instruction

AI help

Available only with source grounding, privacy limits, age controls, and measurement.

AI source context

Find and Fix the Bug · debugging · algorithm · sequential steps

Evidence: local lesson AI-help metadata only; source-grounding, privacy, age-safety, and measurement hooks do not prove real model quality, production telemetry, child AI approval, or AI tutor production readiness

Production AI readiness not claimed

AI source context

Assessment shape

Local lesson assessment shape is complete.

Local shape only; production answer-attempt telemetry, live ownership/RLS evidence, mastery interpretation, release, and production readiness are not claimed here.

Objectives: 4
Activity: Prompt ready
Quiz items: 3 items, 3 answer keys, 3 explanations
Reward: Completion reward ready

Assessment progress stays manual: do not auto-advance through uncertain answers, failed writes, consent, media, payment, learner choice, or AI-assisted checks.

Learning-loop evidence: Content-map contract only; persistence and production learner-progress writes require route/API evidence.

Manual policy: assessment, media, consent, payment, learner choice, failed writes, and AI-uncertain help stay under learner control.

Prerequisite: Complete or review Being Kind and Safe When Using a Computer; Use with parent or guardian controls for child learners

AI guardrails

Privacy

Do not send raw child free text without consent
Use source excerpts and non-identifying progress state only
Asset is not registry-gated

Age safety

Apply junior audience controls before AI-help claims
Keep child learner AI paths behind guardian/product review evidence before readiness claims

Measurement

Log AI help usage by surface and asset slug
Evaluate answer quality against source-grounded rubric before production-readiness claims
Tie remediation prompts to completion, retry, or review outcomes

Local AI-help guardrails only; they do not prove guardian approval, production telemetry, model evaluation, release, deployment, or AI tutor production readiness.

Source and rights

Source path: koydo-app/scripts/curriculum-authoring
License: ai-generated-koydo
Attribution: Attribution decision needs owner review
AI provenance: claude-opus-4-8

Source review gates: attribution_missing

Local source evidence only; this does not prove publication rights, attribution approval, AI provenance clearance, release, deployment, or production readiness.

Route review

Current route: /library/junior/computer_science/en/lesson/find-and-fix-the-bug
Route source: Fallback route needs owner canonical review
Candidate route: /library/junior/computer_science/en/lesson/find-and-fix-the-bug

Local route evidence only; fallback candidates need owner-approved canonical route policy before route writes, production discoverability, or readiness claims.

Content gates: canonical_target_web_missing_uses_library_fallback

lessonslessonslesson objectivesmedia scenesdrillspractice setsquizzesfeedbackcharacterscitationsconcept mapsprogressresumereviewremediationnext steps

Find and Fix the Bug

with Byte

Byte the friendly robot stands on a colorful floor mat, pointing a glowing finger at a row of arrow cards while a little toy car waits at the start.

Read each step of a short plan in order.
Spot the one step that makes the program go wrong.
Fix the broken step so the plan works.
Test the plan again to check that the fix worked.

Key terms

program: a list of steps that a robot or game follows in order
bug: a step that is wrong and makes the program do the wrong thing
debugging: the job of hunting for a bug and then fixing it
test: running the program again to check that it works

What a Bug Really Is

A bug is not a creepy crawly insect. In computing, a bug is just a step that is wrong inside a program. When the program runs, that wrong step makes it do something you did not want. The good news is that one bug usually lives in only one step. Most of the steps are still doing their job perfectly, so you do not need to throw the whole plan away. You only need to find the one step that misbehaves.

How to Hunt for the Bug

Hunting for a bug is like being a detective. You read the steps slowly, one at a time, and point to each one. Say what each step should do, then watch what actually happens. As long as the program is doing what you expect, keep going. The very first step that does the wrong thing is your bug. Going step by step like this is the smartest way to find a bug, because guessing wildly usually misses it.

Fix It, Then Test It

Once you find the bug, fixing it is simple: swap the one wrong step for the right step and leave the working steps alone. But you are not finished yet. You must test the program again by running it from the start. Testing proves the fix really worked and shows that you did not accidentally create a new bug. Real programmers test after every fix, every single time, because a fix is only finished once the program runs the right way.

Worked examples

Find the bug that stops the toy car reaching the star.

Read step 1: UP arrow moves the car closer to the star, which is what we want, so keep going.
Read step 2: DOWN arrow moves the car away from the star, which is wrong, so this step is the bug.
Swap the DOWN arrow for an UP arrow, then run all the steps again to test.

Answer: Step 2 (the DOWN arrow) is the bug; swap it for an UP arrow and the car reaches the star.

Hi! I am Byte. A program is a list of steps. Robots and games follow the steps one by one. Sometimes a step is wrong. Then the program does the wrong thing. The wrong step is called a bug. We do not throw the whole plan away. We do not start all over. That is too much work! Instead, we hunt for the bug. We read each step carefully. We say it out loud. We watch what happens. When we find the step that goes the wrong way, we have found the bug! Then we fix it. We swap the wrong step for the right step — just that one step. Now we test the plan again. Did it work? Great — the bug is squashed! Stuck? Read the steps slowly, one at a time, and point to each one. The first step that does the wrong thing is your bug.

Activity

Help the toy car reach the star. One arrow is wrong. Find it and swap it for the correct arrow.

Practice

A plan says: open the door, walk outside, then unlock the door. Find the step that is in the wrong place.

Tell a friend why we test the program again right after we fix a bug.

Common mistakes to avoid

If a program has a bug, throw it all away.Only the one broken step needs fixing; the other steps already work and should be kept.
Once you change a step, the fix is done.You must test the program again to make sure the fix worked and no new bug appeared.

Check your understanding

A program does the wrong thing. What do we do first?

We found the bug in step 3. What is the best fix?

After we fix the broken step, what should we do?

Recap

A bug is one wrong step inside a program. Instead of starting over, you hunt for the bug by reading the steps one at a time and watching what happens. When you find the step that goes the wrong way, you swap it for the right step and then test the program again to be sure the bug is gone.

Reflect

When something you built did not work, how did you find and fix the problem?