When I began my AI apprenticeship at Miami EdTech, I was the one learning.
I learned how to work with Arduino, program sensors, troubleshoot hardware, and understand how software and physical systems interact. One of my biggest projects involved helping develop a semi-autonomous vehicle, where I gained hands-on experience with programming, sensors, power connections, and robotics.
This summer, my role changed.
Instead of being the apprentice asking questions, I was helping approximately 20 high school students answer theirs.
As part of Miami EdTech’s 2026 Summer Youth Internship Program (SYIP), I helped design and lead a five-week experience that introduced students to Python, Linux, Raspberry Pi, robotics, AI, computer vision, and autonomous navigation.
I thought I was going into the summer to teach students about technology.
I didn’t expect them to improve the technology I was teaching them.
And I definitely didn’t expect them to teach me.
First, We Had to Build the Cars
We divided the students into five teams of four, with each team receiving a Freenove Smart Car Kit built around a Raspberry Pi.
One of my first concerns was simple: How are four students going to work on one car?
I worried some students might dominate the project while others watched. Instead, the teams quickly figured out how to divide responsibilities, communicate, and solve problems together.
Then they surprised me.
I had planned two full days for assembling the cars.
They finished in one.
Suddenly, one of my first lessons as an instructor was that my curriculum wasn’t going to survive contact with my students exactly as I had designed it.
I had to adjust.
That became a theme throughout the summer.
The Students Started Finding Solutions I Hadn’t Considered
Once the cars were assembled, we moved into Linux, Python, and programming the Raspberry Pis.
I created documentation showing students how to navigate directories, execute commands, access their code, and run Python scripts through the Linux terminal.
At one point, I asked students to bring Python scripts from GitHub into their projects. My approach was straightforward: create the necessary files, copy the code, paste it into the project, and run it.
Then one team found another way.
They figured out how to copy and transfer the files directly through the Linux terminal. They even generated a terminal-based interface that made the process easier.
I had never done it that way.
That was a great moment because the students weren’t simply following instructions anymore.
They were engineering.
They saw a process, questioned whether there was a better way to accomplish it, experimented, and found one.
As the instructor, I had to be comfortable saying, “That’s actually better.”
Then They Started Improving My Code
One of the biggest lessons of the summer came from line tracing.
We programmed the Freenove cars to detect and follow a line, but the cars weren’t always accurate.
One student began experimenting with the values in the code.
His solution was surprisingly simple: slow the car down.
By reducing the speed, the car became more accurate at following the line.
Another student experimented with obstacle avoidance. The car uses an ultrasonic sensor mounted on a moving servo “head” to detect objects around it. The student adjusted the code controlling the head movement so the sensor could detect obstacles more effectively.
I eventually incorporated student improvements into the scripts I maintained on GitHub.
That was one of the most rewarding parts of the experience.
The curriculum wasn’t just something being delivered to students anymore.
Students were helping build it.
Sometimes the Best Lesson Starts With a Car Driving Into a Wall
Of course, not every experiment worked.
One day, the students decided to race their Freenove cars.
The race started.
One car immediately launched backwards and straight into the wall.
The room erupted in laughter.
It was funny, but it also became a pretty good debugging exercise.
We discovered that the motors on the cars were reversed. Instead of simply fixing the problem for them, we turned it into an assignment. Each team had to modify the code so that when the software told the car to move forward, the hardware actually moved forward.
Later, another team tested obstacle avoidance.
The car was supposed to detect objects and navigate around them.
Instead, it hit a trash can.
Then it hit the wall.
More laughter.
But nobody stopped.
They wanted to figure out why it happened.
That’s something I came to appreciate about teaching robotics. Failure is visible.
When you’re programming entirely on a computer, a mistake might mean an error message appears on your screen.
With robotics, your error might drive into a trash can.
And that can make debugging a lot more interesting.
Debugging Isn’t Just About Code
The students also learned that when you’re working with physical computing, code is only one place where something can go wrong.
At one point, a team couldn’t get the servo controlling their car’s sensor head to work correctly.
We examined the software.
Then we checked the hardware.
Eventually, I discovered the problem: the power and ground wires were connected backwards.
Another time, two students from different teams investigated a clicking sound coming from a motor. They removed it and discovered a damaged gear inside.
Those experiences taught students to ask different questions.
Is it the Python script?
Is it Linux?
Is it the sensor?
Is it the wiring?
Is the component physically broken?
Real technical problem-solving means being willing to investigate all of those possibilities.
Eventually, students started helping one another troubleshoot instead of waiting for me.
For me, that was one of the clearest signs they were becoming more independent.
From Apprentice to Mentor
A lot of what I taught this summer came directly from experiences I had as an AI apprentice at Miami EdTech.
Early in my apprenticeship, I learned to work with Arduino. Later, I helped develop a semi-autonomous vehicle. Those experiences taught me about sensors, programming, electrical connections, troubleshooting, and the relationship between hardware and software.
At the time, I was the learner.
I didn’t necessarily realize those experiences were also preparing me to teach someone else.
During SYIP, a student could come to me and say, “The sensor isn’t working.”
That question didn’t intimidate me because I had been in that position before.
I knew what it felt like to stare at something that should work and wonder why it didn’t.
My apprenticeship taught me to experiment.
Teaching allowed me to pass that mindset on.
The Curriculum Became Something We Were Building Together
One of the things I’m proudest of is seeing the Articulate course I created for the Freenove Car Kit become an actual learning resource for students.
Creating it forced me to think carefully about sequencing.
Should students program before they build? How much Linux do they need before running Python? When should we introduce robotics?
But students taught me that curriculum development is iterative.
They moved through some lessons faster than I expected. Other concepts required more support. Hardware failed. Cameras weren’t detected. Wires were reversed. Students discovered solutions I hadn’t considered.
Every one of those moments gave me information about how the curriculum could improve.
In some ways, teaching the curriculum felt like testing software with real users.
You can design what you think is the perfect experience.
Then people actually use it.
That’s when you find out what works.
What 20 Students Changed About How I Think About AI
Before this experience, I might have focused heavily on someone’s existing technical background.
Can they code?
Do they know Linux?
Have they used a Raspberry Pi?
Do they understand robotics?
Those things certainly help.
But after teaching this summer, I think some other qualities matter just as much.
Are you willing to learn?
Will you ask questions?
Can you work with other people?
What do you do when your first solution fails?
Some students entered the program having never written code, executed Python from a Linux terminal, assembled a Freenove Smart Car, or operated a Raspberry Pi.
Five weeks later, they were troubleshooting sensors, modifying Python scripts, experimenting with autonomous navigation, and helping other students solve technical problems.
And sometimes they were showing me better ways to do things.
That changed the way I think about learning AI.
You don’t have to know everything before you start.
You have to be willing to build something, break something, ask why it broke, learn from the people around you, and try again.
That’s what I watched these students do all summer.
And somewhere along the way, I realized that’s exactly how I learned too.
