Vibe Coding for Teens: 6 Habits That Separate Builders

Last updated: October 2026

Vibe coding for teens is no longer a novelty, and it looks different from what most parents picture. Programmer Simon Willison notes that the term was coined by Andrej Karpathy in February 2025, and he gives the cleanest working definition I know: vibe coding means "building software with an LLM without reviewing the code it writes". By November 2025 it was Collins Dictionary's Word of the Year, defined there as "the use of artificial intelligence prompted by natural language to write computer code."

Across August and September I taught two teenage students who build with an AI coding agent in their lessons. One is making a game. The other builds web apps. Both work on a subscription their parent owns, with the parent's knowledge. Anthropic's consumer terms say Claude users must be at least 18, and I do not set teenagers up with accounts of their own. One of them once said something unprompted that I keep coming back to: working with the AI "taught me to speak very specifically." My addition was to talk to it the way you would explain something to a five-year-old. Every habit below is a version of that one sentence.

Six habits, in roughly the order they show up. What convinced me they are habits and not quirks is simple: two students, working independently, in separate lessons, landed on the same ones.

Key Takeaways

• Vibe coding, in the strict sense, means not reviewing the code the AI writes. The teens who get furthest keep the speed and add a handful of habits around it.
• Two teenage students, working independently, arrived at the same six habits. That is a pattern, not an anecdote.
• Most of the habits are about writing things down precisely: bugs, decisions, and the shared rules parallel work depends on.
• Keys and third-party tools are the one area where a slip can cost money or security, so they are the habit to teach first.
• Anthropic's terms require Claude users to be 18 or over. In my lessons, the parent owns the subscription and the teen works on it with the parent's knowledge.

In this post: Bug file · Spec first · Plan or just try · Shared contract · Laptop is not a test · Keys and sources

1. The bug file with stable IDs

Here is what it looks like without the habit. A teen notices a small defect mid-build, says "I'll fix that later", and moves on. By the third session there are a dozen of these living only in their head, and a fresh session of the agent knows about none of them.

One student hit this first. Small defects were piling up with nowhere to go, so we made a bugs folder with one Markdown file in it. Every entry gets a stable ID, a clear description, and the session it appeared in along with the commit that was current at the time. An entry looks something like this (the example is mine, not the student's):

## BUG-014
What happens: the settings menu opens behind the game, not on top of it.
First seen: session 5, commit a41c9e2
Status: open

The stable ID is the part people skip, and it is the part that matters. A numbered list reshuffles when you add or remove an item, so "bug 3" means something different next week. An ID stays with the same bug forever. The session and commit tell a future session what the code was doing when the fault appeared. The agent added a rule of its own: when a bug is fixed, it should leave a one-line record in that session's report instead of simply vanishing from the file.

In the next session, the first fix came straight out of that file, committed with the tests passing. The file did its job on its first outing.

The other student got to the same place from a different direction. After a build, we ran a structured bug hunt: dated, one line per issue, each one marked as a real defect or user error. One reported "bug" turned out to be a slip in how the app was being used. It stayed in the log as a note, because the next person will make the same slip.

Then came the part that made the cost visible. We fixed the defects one at a time. The first fix took ten minutes and about fifty thousand tokens, and seeing that number made the price of bundling several fixes into one prompt very concrete.

Two students, two versions of the same professional habit. It is the grown-up form of what I teach younger children when I refuse to fix their code for them: name the fault precisely before touching anything.

The fix: Give every bug a stable ID, the session it appeared in, and a one-line status. Fix one per prompt, and look at what each fix cost.

2. Spec first, with the rejected options written down

This is the habit that surprises parents, because it looks like the opposite of vibe coding.

Before a larger project, one student spent a full hour in the agent's planning mode answering structured questions, and not a single file was written until it was done. The output was a specification and a domain model, which is a plain description of the things the app deals with and how they relate to each other. Decisions got made on purpose: how data gets in, where it lives in the first version, which formats it exports to, how large a document it has to handle. The agent researched the main library it would depend on instead of guessing, and picked one under the MIT licence so there would be no licence surprises later.

Then came the part I now pass on to other students. The student had the agent write down every planning question, the answer chosen, and the alternatives it offered. Not only the decisions. The options that lost as well.

Here is the shape of that record, with an invented example rather than the student's real one:

Why bother? Because the day the eventual user says "this isn't what I wanted", you can go back to the exact decision, see what else was on the table, and change course deliberately instead of starting over or guessing. It became a habit, not a one-off.

An hour of answering questions before any code exists is hard for a teenager, and that is part of the point. Tahir, a parent whose son is learning Python with me, wrote in his review that "He explains clearly and creates great challenges that help tremendously." A planning session with no visible output is one of those challenges. It feels slow, and it is the reason the build afterwards is fast.

The fix: Before any big build, run a planning session and save the result as a decision log: question, answer, and the alternatives that lost. Keep it in the project folder where the agent can read it.

3. Plan when it's new, just try it when it's known

Habit 2 has a trap in it. A teen who learns that planning works starts planning everything, and a forty-minute planning session for a two-minute feature is its own kind of waste.

Earlier lessons with one student had pushed hard on planning first. Then came the counterweight. The student wanted to plan a mini map because it felt complicated. My steer was to skip the plan and just ask for a basic version. It worked first time.

The rule I gave afterwards is short enough to remember. Plan when the thing is new or expensive to redo. Just try it when it is a well-known pattern and cheap to retry.

A mini map is a solved problem. Thousands of games have one, and the agent has seen endless examples of how they work. A narrator whose emotions change over the course of a game is not solved in the same way. There is no standard version to copy, the choices ripple into dialogue and art, and getting it wrong means redoing a lot. That one deserves a conversation before any code.

The skill here is not planning or not planning. It is telling the two situations apart quickly, and teenagers get good at it once someone names the difference out loud.

The fix: Before planning, ask two questions. Has this been built a thousand times before? Is it cheap to redo? Two yeses mean just try it.

Most of these habits arrive faster when someone reviews the work every week. That is most of what my 1-on-1 sessions are.

4. Parallel work needs a shared contract

Once a teen discovers that an agent can work while they wait, the next idea is always to run several at once. Both of my students got there, and both learned the same lesson from opposite ends.

In one student's project, the agent was asked to launch four agents on an empty repository. It pushed back: four agents starting from nothing would produce four codebases that do not fit together. It proposed writing the scaffolding and the shared type definitions first, so all four would code against the same contract, and only then splitting the work into separate folders.

What happened next was the second lesson. Three of the four agents stopped mid-task when the usage limit hit. The fourth finished. When agents can die on a limit, ask each one for a written report of what it did before its context is gone. Agents also cost more usage and are not always faster, because coordinating them takes time of its own. Kids misjudge usage in both directions, which I wrote about in Nine Minutes for Nothing.

The other student, meanwhile, ran two agent sessions at once on separate tasks to cut down the waiting. The student told each session that the other existed and might change code it had not written, and added that to the project's instruction file as a standing rule. Then came a good question: how do two sessions avoid stepping on each other? The student suggested a shared file both could write to. We looked at three options:

• Give them clearly separate work: different systems, different files. The simplest answer.
• Separate Git branches, merged later. The proper answer once parallel work is routine.
• One session running two agents under an orchestrator. The clean version of the shared-file idea.

Output doubled. But they still sat and waited, just for two things instead of one. The student named it: parallel work fixes throughput, not idle time. The fix for waiting is giving the human something to do, like reviewing the last build's code, designing the next item or sketching a layout. The student started doing exactly that without being told. One practical footnote: the laptop struggled with two sessions, and a third froze it.

The fix: Before splitting work, write the shared contract: folder layout, shared types, and which files each agent owns. When agents might hit a limit, have each one write down what it has done as it goes.

5. Your laptop is not a test

Every young builder believes their app works, because it works for them.

One student had a live web app, and on their own machine everything behaved. But pushing to the main branch is what deploys the live site. Local code and live code are different things, and the gap between them is where most of the pain lives. It is the single most common failure I logged when I counted what actually breaks when kids set up AI coding tools.

So I did the test the student could not do alone. I signed in from my own machine with my own account, created some data, signed out, signed back in, and checked the data was still there. That second-user test proved the data persisted. It also turned up broken buttons the student had never seen, because they had only ever used the app the way its builder uses it.

The same student had a related problem in another lesson. A scrolling effect was "not smooth enough", and they could not put into words why. Describing it was going nowhere. Connecting a browser-automation tool changed that: the agent could take screenshots of the page and judge it for itself. It is the same reason a screenshot beats a paragraph when kids build with AI. Letting the agent see beats describing to it.

Then the better question arrived, late: was the design itself wrong? Polishing an effect is wasted effort if the effect is the problem. Question the design before you polish it.

The fix: Before calling anything done, have one other person use it on another device. When something looks wrong, give the agent a way to see the page instead of describing it.

6. Keys and sources are your responsibility

This is the habit where mistakes cost money, so I teach it properly and then check it.

An API key is a password that lets an app use a paid service. The rules I give teenagers are short. Never paste a real key into the AI chat, and never send a screenshot that contains one. Ask the agent what the variable should be called, then type the value into the .env file yourself. Three files do three jobs:

.env            real values the app reads         never committed
.env.local      overrides for this machine only   never committed
.env.example    the same names, no real values    safe to commit

# .gitignore (keeps the real ones off GitHub)
.env
.env.local

A .gitignore file tells Git which files to ignore when you commit, and GitHub's own guide to ignoring files points out that a file already committed has to be untracked first. A private repository is not a guarantee either. For damage limitation, set spending limits and daily caps, and remember that a key can be revoked and replaced in one click.

One student explained all of this back to me correctly and unprompted, which is the best comprehension check I know. Then reality tested it twice. One key was exposed during a lesson, pasted where it should never have gone. We replaced it with a new key, and a check confirmed it had never been committed or pushed. Later, an AI audit of a different project found another key hardcoded and committed to a repository, which is the harder case. GitHub's guide to removing sensitive data is clear about the order: as a first step you revoke or rotate the secret, before worrying about the history.

Tools are the same kind of responsibility. Instead of being told which extensions to install, the same student asked the agent to search the official marketplace and GitHub and recommend what would help build a better interface. Good instinct, with two rules attached. Install at project scope, not globally, because tools you are not using still get read on every project, costing tokens and attention. We learned that live when an unrelated design tool fired on the wrong project. And vet the source: official marketplaces and well-starred repositories only. Claude Code's own documentation on plugin security says an installed plugin "can execute arbitrary code on your machine with your user privileges." For a teenager installing things, that sentence is the whole lesson.

The other student learned the repository version of this. They made the game's repository public so they could share it, which meant anyone who found the profile could download the whole thing. The right move was to keep it private and add specific people as collaborators, which GitHub's guide to inviting collaborators walks through: Settings, then Collaborators, then add people by name.

The fix: Keys go in .env, typed by hand, never into the chat. Tools come from official sources, installed at project scope. Repositories stay private, with named collaborators.

Frequently Asked Questions

What is vibe coding? Building software by describing what you want to an AI in plain language and letting it write the code. In the strict sense Simon Willison uses, it means building without reviewing the code the AI writes. Many people now use the term more loosely for any AI-assisted building.

Is vibe coding good for teenagers? Yes, with habits around it. The speed is real and very motivating. What separates teens who ship from teens who stall is mostly the six habits above: writing things down, testing beyond their own laptop, and treating keys and tools with care.

Can a teenager have their own Claude account? No. Anthropic's consumer terms require users to be at least 18. In my lessons the parent owns the subscription and the teen works on it with the parent's knowledge. Other tools set their own rules, which I have gathered in how old you have to be to use ChatGPT and other AI tools.

Does my teen still need to learn to code properly? Yes. Every habit here depends on understanding what the agent produced. A useful bug entry needs someone who can describe a fault precisely, and a shared contract only works if someone understands the types and folders it defines. Teens who can read code direct the agent far better than teens who cannot.

What should a parent check first? Three things: that no API key appears in the chat history or in any committed file, that spending limits are set on every key, and that the repository is private. None of it needs coding knowledge, and all of it can be checked together in ten minutes.

Start here

If your teen is going to act on one habit this week, make it number 6. It is the only one on the list where a slip can cost real money before anyone notices. The other five save time. This one saves you from a bill.

1. Sit with your teen and check that .gitignore lists .env, and that no real key appears in any file the repository tracks.
2. Set a spending limit or daily cap on every API key the project uses.
3. In the next session, start the bug file: one Markdown file, stable IDs, and the session and commit on every entry.

After that, in my experience, the bug file pulls the other habits in behind it. A teen who learns to write faults down precisely starts doing the same with decisions. If you would like a second pair of eyes on your teen's setup, book a free Discovery Call.

From the session logs of Kids Coding Tutor: 1-on-1 Scratch, Python and AI tutoring for children ages 8 to 16. The habits above come from two real teenage students, anonymized.