Building an LLM Robot with My Son — EP 5. My Son's First Day Coding a Robot with AI

The day came when my son wanted to try alone.

Up until now I'd always been close — sitting next to him, typing alongside him, stepping in when errors appeared. But this afternoon: "I'll do it myself." A weekend afternoon. I went to another room.

About thirty minutes later he came out. "Dad, the robot keeps turning left."

---

His First Prompts

Later we looked at everything he'd typed that day.

The first prompt:

"make the robot avoid obstacles by going left"

Claude Code produced code. He uploaded it. The robot moved forward, detected an obstacle, stopped, turned left. So far correct.

After turning, it didn't go forward again. Just kept turning left.

Second prompt:

"make it go forward again after avoiding the obstacle"

Code was revised. Uploaded. This time: detect obstacle, stop, turn left, go forward again.

But every turn was the same fixed angle. If the obstacle was a wall, the robot would keep turning the same way and trace along it.

Third prompt:

"make the turn angle a little different each time it avoids"

After that, things started improving.

---

Where He Asked Claude for Help

After uploading the third version, he noticed something and paused.

Serial monitor output:

dist: 0
dist: 0
dist: 0
dist: 18
dist: 0
dist: 400
dist: 23

Zeros and 400s mixed in constantly. Ultrasonic sensor noise — the same issue I'd mentioned in EP 2.

When 0cm registered, the code treated it as an obstacle and kept stopping. "Why does it keep stopping when there's nothing there?" He couldn't tell whether the problem was in the code or the sensor.

He came to find me. "Dad, something's weird."

We looked at the Serial monitor output together. I explained: ultrasonic sensors occasionally return 0 when a measurement fails. NewPing has filtering options for this. "Tell Claude that," I said.

His fourth prompt:

"if the sensor reads 0 or 400, ignore it and use the previous value"

The code that came back saved the last valid reading and used it whenever the current value was 0 or exceeded MAX_DISTANCE. Uploaded. No more stops from phantom readings.

His expression changed.

---

Something He Found Himself

From there, he kept going on his own.

Fifth prompt:

"when the robot turns left to avoid something, it lurches too suddenly and one wheel keeps lifting up. make the turn smoother"

I hadn't told him to look for that. He saw it happening and figured it out himself. Chassis tilting during sharp direction changes — he noticed it with his own eyes and described it.

Claude Code suggested reducing speed before the direction change and ramping it back up after. He uploaded it. Less lifting.

"A little better."

Not a complete fix. But he identified the problem, described it, turned it into code, and ran the iteration himself.

---

The Full Prompt Log

Eight prompts total that day:

1. "make the robot avoid obstacles by going left"
2. "make it go forward again after avoiding the obstacle"
3. "make the turn angle a little different each time it avoids"
4. "if the sensor reads 0 or 400, ignore it and use the previous value"
5. "when the robot turns left to avoid something, it lurches too suddenly and one wheel keeps lifting up. make the turn smoother"
6. "try speed 200 instead of 150"
7. "200 is too fast. try 175"
8. "remove all the Serial.println from the current code, I'm not going to use the serial monitor"

Prompt 8 was unexpected. He'd either read somewhere or intuitively felt that serial output affects loop timing. When I asked about it: "I thought printing takes time." Not exactly right, but the direction was. He acted on an instinct that turned out to be sound.

Looking at all eight: not syntax, not library names, not code structure. What he learned was how to describe a desired behavior, how to narrow down what's wrong, and how to iterate toward a result through conversation.

---

What He Built That Day

By evening he uploaded the final version. Obstacle detection → speed reduction → left turn (randomized angle) → forward. Sensor noise filtering included. Serial output removed.

He tested it. The robot moved around the living room, navigating around chair legs. One wheel occasionally caught, but it mostly made it through.

"I made this," he said.

Technically, Claude Code wrote the code. But he decided what to build, described every problem as it appeared, and constructed the behavior through eight prompts. He never touched a line of code — and "I made this" wasn't wrong.

That's vibe coding. That's what I wanted to teach with this project.

---

On Coding Without Understanding Code

One thing I'll be honest about.

He doesn't understand the code he built that day. Ask him what any given line does and he can't say. He can't read a compile error. That's true.

Whether that's a problem — I genuinely haven't decided. "Is it meaningful to build something that works without understanding it?" is a fair question. There may be a point later where he has to go back and learn fundamentals.

But I'm not forcing that now. What he's building right now is the experience of describing something and making it real. That experience is what creates interest in understanding. Syntax can come after the curiosity is there.

A ten-year-old learning to ride a bike doesn't study physics first. They ride. Later, if they're curious, they learn why it works.

We're in the riding phase.