Skip to content
Hi, Bot
Back to blog
philosophyaiessayfor-kids

The AI builder skills map

Andrew Ng mapped four AI engineering skills for developers. Here is the same map in plain language for kids 8–16 — and the teachers sitting next to them.

August 15, 2026 · Hi, Bot

The internet is loud about AI. New tools every week. Big claims. Lists of “must-learn” skills that somehow need a graduate degree and a free afternoon.

So what is actually worth learning — if you are twelve, or sixteen, or the adult helping them?

Andrew Ng and DeepLearning.AI just published a clear answer for working developers: four skills that show up again and again in real jobs and real projects. We are not rewriting their research. We are translating it for our room — kids who build with AI, and the teachers and mentors who help them do it carefully.

Their map is about AI engineering skills, not only people with the job title “AI engineer.” Same idea as the cloud: lots of builders need the skill; only some people wear the badge. That fits us. We are not trying to mint job titles for eighth graders. We are trying to grow habits that still work when the app icons change.

Here are the four skills, in our words — plus the paper practice that grows each one early.

1. Build AI things you can check

Traditional software is mostly predictable. You write 2 + 2 and you get 4. Every time.

AI is different. You ask a model a question and you don't fully know what comes back. You train a small model and you don't fully know what it will say on a new example. That is not a bug in the universe. It is the nature of the tool.

So the skill is not “make the model talk.” The skill is make something with AI, then measure whether it behaves.

In grown-up language that means things like language models, good context, retrieval (looking things up before answering), agent workflows, and — this is the part people skip — evals. An eval is a simple test: a list of inputs, the answers you expect, and a way to score what the model actually did. When it fails, you do error analysis: which cases broke, and why, before you change anything.

At eight: you build a story helper. You try the same three prompts ten times. You write down when it invents fake facts. That notebook is an eval.

At twelve: you keep three questions the quiz bot currently fails. You fix the prompt or the rules until those three pass. Then you try new ones.

At fifteen: you ship a helper for a club. You keep a small suite of “must not fail” cases — safety, empty input, weird punctuation — and you re-run them every time you change the system.

This is the same verify habit we already teach. Ng's map just names why it belongs in the center of AI building, not at the edge.

If you are the teacher: praise the check, not only the demo. “How do you know it works?” is a better question than “Does it look cool?”

On paper now: Tiny Test First (climb a risk ladder before you bet big) and The Confident Wrong (fluent is not the same as true). The companion sheet Does It Behave? — a kid-sized eval scorecard — lands September 12.

2. Know how software really works

When you understand the basics of software — request and response, data shapes, functions, what “fast” costs, what “private” means — you make better choices. You also give better instructions to a coding agent, because you can name the tradeoff you want.

Without that foundation, “vibe coding” (asking an AI to build while you barely steer) often means the agent quietly picks a stack you cannot defend: slow when it should be simple, public when it should be private, clever when it should be boring.

You do not need a computer science degree at fourteen. You do need systems thinking: inputs, outputs, feedback, failure. You need enough fundamentals that you can say “store this in a table,” “don't put secrets in the page,” or “test the empty list” — and mean it.

At eight: draw the marble run before you build it. Where does it jam?

At twelve: sketch the page: form → request → answer → display. Name what happens when the answer is empty.

At fifteen: argue about cost and reliability out loud. Is this worth a paid API? What happens if the model is down? Who can see the data?

If you are the teacher: when a coding tool suggests a fix, ask the student to explain the tradeoff, not only paste the patch. The explanation is the learning.

On paper now: Ripple Map (change one part, watch the waves) and The Privacy Pocket (secrets stay off the page). Pick the Tradeoff — dials for cost, speed, reliability, privacy, simplicity — lands September 19.

3. Work with coding agents on purpose

Coding agents — tools that plan, write, and edit code with you — are now a core builder skill. Not “let the robot do the project.” Steer the robot.

That means a mental model: what the agent can see, what it forgets, where it guesses. It means managing context — give it the files and rules that matter; don't dump the whole internet. It means choosing when to plan first and when to just try. It means giving the agent a way to check its own work — tests, a checklist, a small eval — so it can close the loop without you hovering on every line.

It also means knowing the danger zones. Don't point an unsupervised agent at a live database with real people's data. Don't ship code you cannot read. A kid who cannot code yet can still ship — but ownership still means understanding what went out the door.

Because these tools change fast, the meta-skill matters too: try new workflows on purpose, keep what helps, drop what wastes tokens and patience.

At eight: you describe a tiny change. You watch the helper do it. You run the project. You say what is still wrong in one sentence.

At twelve: you write a short spec first. You let the agent draft. You run tests. You ask it to fix only the failing cases.

At fifteen: you split work — one agent explores, you decide, another agent implements — and you keep a human gate before anything public.

If you are the teacher: coach intervention. Too much hovering and the kid never learns judgment. Too little and the agent ships a mess. The skill is the dial, not the off switch.

On paper now: Co-Pilot Crew (when to trust, steer, or veto), The Context Brief (vague in, vague out), and Director's Chair (brief the helper, own the ending). The Intervention Dial — a 1–5 captain's dial plus danger zones — lands September 26.

4. Shape what gets built

Agents are getting better at building to a clear spec. So the valuable human work moves earlier: what should be in the spec?

That is product sense in kid clothes. Who is this for? What problem is real? What is the smallest version someone can try this week? When should you slow down because the thing touches privacy, money, or someone else's feelings?

This lands hard in a clubhouse: kids should not wait for a pixel-perfect worksheet and then only “implement.” They should help decide what is worth making — then execute with care. That is agency: pick a problem you care about, ship a version, learn from a real user.

At eight: “Who will play this?” If the answer is nobody, pick a different game.

At twelve: build the one-feature version your sibling will actually open. Cut the rest.

At fifteen: write the goal in one sentence. List what you will not build this month. That list is the craft.

If you are the teacher: protect time for the question before the tools open. Ten minutes of “who is it for / what counts as done” beats two hours of confident wrong direction.

On paper now: The User-First Blueprint (interview before you invent), Write the Spec First (in, out, done, never), and One Goal Shield (say no to just one more feature). The Not-Building List — ruthless cuts as craft — lands October 3.

The skill under the skills

Under all four sits a habit: keep learning. AI moves. Best practices move. A builder who treats last month's tutorial as sacred scripture freezes. A builder who expects to update their map — the way Ng says he will keep updating his — stays useful.

That is not hustle culture for children. It is curiosity with a notebook: try, check, revise, share what you learned.

On paper now: Learn · Unlearn · Relearn and What Won't Change.

Practice sheets for the map

You can start today with the links above — they are already in the printable library. We are also shipping a four-sheet Builder Skills Map companion series, one sheet per skill, on the Saturday drop cadence:

SkillSheetGoes live
CheckDoes It Behave?Sep 12, 2026
FundamentalsPick the TradeoffSep 19, 2026
Coding agentsThe Intervention DialSep 26, 2026
Shape the buildThe Not-Building ListOct 3, 2026

Each one is kitchen-table friendly: paper, pencil, 30–60 minutes, ages that flex from about eight to sixteen. Teachers can run them as warm-ups; families can run them on a Sunday. Activities members get each pack the morning it lands; free subscribers get the same pack after the usual embargo delay.

What this looks like on a Tuesday

You do not teach this map as a lecture with four slides. You run it as a loop:

  1. Shape — name the user and the smallest useful version.
  2. Fundamentals — sketch the system so the tradeoffs are visible.
  3. Build with AI — use models and agents where they help.
  4. Check — evals, tests, a real person clicking it.
  5. Steer — fix the failures; do not only regenerate hope.

Same loop at eight with cardboard and a chat helper. Same loop at sixteen with an API and a paid user. The tools change. The map does not.

If you want the adult, technical version, read Ng's original AI Engineering Skills Map. If you want a place where kids practice these skills with a mentor in the chair next door, the waitlist is open. If you want to start quieter tonight, pick one printable from the table above and run it before anyone opens a chat box.

Keep reading

Get the next dispatch.

Occasional, never spammy.

By submitting, you agree to our Terms and Privacy Policy.