We Gave Teenagers a Real AI Coding Tool. Here Is What They Did With It.

In June 2026 we ran an AI workshop for a summer camp in metro Atlanta. The organization is D.B.G.E.M., Developing Boys Into Gainfully Employed Men, a nonprofit that runs a two week camp for young men in grades 7 through 12 alongside programming in leadership, skilled trades, aviation, healthcare and financial literacy.

We had three hours and a room of students, most of whom had never written a line of code. We did not give them a simplified classroom toy. We gave them Claude Code, the same agentic coding tool we use to build client systems, running in the same editor we use.

By the end of the session every team had working software running on a screen, and had stood up in front of the room to explain how they built it. What actually decided which teams did well is the part worth writing down, because it is not what most people assume, and it applies directly to how a business should be working with AI.

Teams of three or four. Every student got a role card: Product Lead, Developer, QA Tester, and Designer. Then one rule that sounds arbitrary and turned out to carry the entire session.

Only the Developer types.

Without that rule you get four kids around one keyboard, the fastest typist takes over, and the other three watch. With it, the team has to talk. The Product Lead has to say what they want. The Developer has to translate that into an instruction precise enough to act on. The QA Tester has to describe what went wrong in words rather than grabbing the mouse.

That is the actual skill. Not typing. Describing.

Before any team was allowed to start building, they had to write a five line spec on paper. What it is. Who it is for. The three features it must have. What it looks like. What done means.

Then the Product Lead read it out loud to me, and I either approved it or sent them back.

Several teams could not get through their own spec without arguing about what they were building. That argument is the point. If four people who have been talking about an idea for ten minutes cannot state it in one sentence, no AI on earth is going to build the right thing. The teams that took the paper seriously moved noticeably faster in the sprint. The teams that rushed it spent the sprint discovering they disagreed.

That is not a lesson about children. Watch what happens when a company points an AI tool at a process nobody has ever written down.

Teams shipped playable browser games, single HTML files that open on any computer. An arcade road crosser with lanes of traffic, a river section, score, levels and lives. Two endless runners, one with a rising speed curve and a saved best score. Each one had a win or lose condition and a restart button, because that was in the spec and the QA Tester checked.

Every student took their file home. That mattered more than I expected. A worksheet goes in a drawer. A game you can hand your little brother does not.

Halfway through, each team sent two people to the next team's laptop with ten minutes and one instruction: break it.

They left written bug tickets. What I did. What happened. What should have happened. How bad is it, game-breaking or annoying or cosmetic. Then every team got their tickets back and had to triage: which of these actually matters, and which are we ignoring so we can finish.

Watching a fourteen year old defend a design decision to another fourteen year old holding a bug report is the closest thing to a real engineering meeting I have seen in a classroom. Nobody had to be told to care. Someone had broken their thing.

The quiet kid who is great at finding problems becomes the most important person on the team for ten minutes. That reliably surprises the adults in the room.

The other half of the program is a game we built called the AI Bot Royal Rumble. Teams describe a battle robot in plain English. Weapon, defense, movement, personality, special ability, weakness. The system reads the description, turns it into a fighter with real stats, and the bots fight in a projected arena while a commentator calls the action out loud.

Across the camp, students submitted eighteen bots and we ran twenty nine matches. Teams named themselves things like SPEEDSTERZ and The Gear Grinders. The room was extremely loud.

Here is the design decision that makes it a lesson instead of a toy. Every bot is normalized to the same thirty six point stat budget before it enters the ring. You cannot win by writing that your robot is invincible. If you write invincible, the system reads it as extreme armor and hands you back a slow, overheating machine that cannot turn, and it tells you that is what it did.

That last part is the whole thing. When a team submits a bot, the screen shows its work: which of their words it read, which stats those words moved, and what they forgot to specify. A team that wrote forty careful words gets a stronger fighter than a team that wrote invincible unstoppable god mode, and they can see exactly why.

Students figured out the rule in about two rounds. Specific beats dramatic. Then they went back and rewrote their descriptions.

Strip out the robots and the teenagers and you are left with the same four things that decide whether AI works for a company.

Someone has to decide what to build, and they have to be able to say it in a sentence. The AI will not do this for you, and the vaguer you are the more confidently wrong the output.

Somebody has to check the work. A team that never tests ships bugs. A business that never checks its AI output ships those bugs to customers.

Specific instructions beat impressive ones. The gap between a mediocre result and a good one is almost never a better tool. It is a better description.

And the system should show its work. The reason the bot game teaches anything is that it tells students why they got what they got. Any AI system running in your business should be able to answer the same question: what did you actually do, and on whose instruction. If it can only answer in adjectives, you are trusting it on faith.

We spend a lot of time telling business owners that AI rewards clear thinking more than technical skill. It is a hard thing to prove in a sales conversation. It is very easy to prove in a room of seventh graders, because the ones who thought clearly won, and everyone could see it happen.

We now run this as a workshop for schools, camps, churches and youth nonprofits, and we bring everything: the lesson plan, the handouts, the facilitator software, the arena, and a parent packet that explains in plain English what students will do and which tools they will touch.

One honest note for anyone weighing this. The most common objection is that AI tools teach kids to skip the thinking. We built the session as the direct answer to that objection rather than around it. Nobody types until they have written a spec by hand, every team has to break someone else's work and defend their own, and the finale is each student explaining what they built and what went wrong. None of that can be outsourced to a model.

If that is the kind of session you want in front of your students, the details and the request form are on the workshops page.