Turn “it doesn’t work” into evidence a child can explain and act on.
QB03 Demo Day · Hao Ying · Y
0:00–0:30. Open with the child’s sentence: “It doesn’t work.” The product is not an answer machine. It is a debugging relationship designed to make the child more capable.
Y / Learning
02
The real problem
It doesn’t work.
CODEPORTSWIRINGDIRECTIONMECHANICS
The child sees one failure. Underneath it are five hidden systems—and no usable feedback loop.
0:30–1:15. Don’t frame the child as lacking intelligence or motivation. The cause-and-effect loop is broken. Multiple hidden layers collapse into one unhelpful sentence.
Y / Context
03
The child sees
A physical robot with a history.
What was supposed to happen
Which motor actually moved
What changed since the last run
CONTEXT GAP
A generic chatbot sees
One sentence.
“It doesn’t work.”
No robot state
No grounded evidence
1:15–2:00. Context engineering problem: the human and AI are not looking at the same system. Generic chat forces the child to reconstruct technical context they do not yet know how to describe.
Y / Context alignment
04
The product mechanism
The child and AI debug the same robot.
SHARED DEBUGGING CONTEXT
01 / CODE
What was commanded
The exact program the child ran—not a pasted approximation.
02 / TELEMETRY
What happened
Errors, headings, timing, and inspectable run evidence.
03 / ROBOT PROFILE
What this robot is
Port, motor, direction, and attachment mappings learned interactively.
2:00–2:50. The app builds context automatically. The child does not need to explain the entire robot before asking for help. Emphasize alignment, not “more tokens.”
Y / Learning loop
05
Bruner, carried into computing by Alan Kay
Move it. See it. Explain it.
Enactive / Doing
Move
Run one small physical test.
→
Iconic / Visual
See
Make motion and telemetry inspectable.
→
Symbolic / Language
Explain
Name the fault and choose the next test.
The student should name the bug—not the bot.
2:50–3:40. Credit Jerome Bruner for enactive/iconic/symbolic; Alan Kay made this sequence central to children’s dynamic media. We use it as product mechanics, not decoration.
Y / Product philosophy
06
Capability, not dependency
The useful part is the space we leave.
“有之以为利， 无之以为用。”
What is there provides advantage. What is not there makes it useful.
CODE
TELEMETRY
ROBOT PROFILE
AI GUIDANCE
The child observes · judges · chooses
3:40–4:40. “有” is the infrastructure: code, telemetry, context, AI. “无” is the protected cognitive space. The AI does not immediately answer, rewrite everything, or make the judgment invisible. This is Y’s product discipline.
4:40–7:10. Ask the audience to predict before revealing the answer. Open Practice Mode. Run the 90-degree over-rotation scenario. Narrate: expected, observed, hypothesis, smallest next test. If live fails, stay on this slide and narrate the trace.
Y / Honest simulation
08
Practice without pretending
No Hub? Practice the reasoning—not fake physics.
Scenario 01
Straight-line drift
Compare expected and observed heading.
Scenario 02
90° over-rotation
Read the trace; choose a controlled change.
Scenario 03
Incorrect port mapping
Use the robot profile to expose mismatch.
SIMULATED · CODE IS NOT EXECUTED · CANNOT VERIFY WIRING, MECHANICS, OR REAL-WORLD MOTION
7:10–7:50. This is deliberately not called an emulator or virtual Hub. It rehearses evidence-first reasoning. The persistent disclosure is a product integrity feature.
Y / Real robot evidence
09
Previously tested with a real SPIKE Prime Hub
Code, robot reference, and telemetry in one view.
REAL HUB · REAL RUN · SAVED ROBOT PROFILE
7:50–8:20. I am traveling without the robot, so this is prior real-hardware evidence—not a live claim. Point out connected state, C/D drive mapping, completed program, and telemetry trace.
Y / Real AI coaching
10
Actual Coach Chat after real Hub runs
One observation. One evidence-based next test.
8:20–8:55. These screenshots came from the instruction run with a real robot. Left: Port F was physically absent, so Coach grounded the answer in ENODEV and the saved C/D mapping. Right: after successful runs, Coach asks for a measurement rather than claiming success.
Y / Reusable intelligence
11
More than a prompt
A reusable debugging harness.
TRIGGER
Recognize the debugging moment
Route “it doesn’t work” into evidence collection, not instant advice.
→
CONTEXT
Load grounded robot state
Code, telemetry, profile, boundaries, and the child’s observation.
→
METHOD
Protect student ownership
Expected → observed → hypothesis → one smallest useful test.
7:50–8:40. Tie to QB03 judging: this is a skill/harness, not one lucky prompt. It has a trigger, context contract, method, and boundaries. The same method can move across models and interfaces.
Y / Proof
12
The product is not the proof
Did the child become more capable?
Time to first evidence
How quickly does the child reach an observable robot response?
Adult interventions
Did the system reduce takeover without abandoning the learner?
Fault explanation
Can the child state expected, observed, hypothesis, and next test?
Transfer
Does the child approach the next fault with less random guessing?
8:40–9:30. Be honest: shipped product and passing tests are launch evidence, not learning evidence. The next proof is child behavior. Commit to five child/coach tests and these four measures.
Y / Grow with intelligence
13
Compound capability, not dependency
The robot gets fixed today. The child becomes a debugger for life.
AI creates the conditions for the child to see, judge, and act—then leaves the judgment where it belongs.
9:30–10:00. Close slowly. The robot working is a short-term outcome. A child who can debug the next unfamiliar system is durable capability. Invite questions.
