AI Course

How to run this chapter in class. Students may read it too.

Introduce the course map (5 min) → show one example of each kind of tool (10 min) → students set up accounts and a course folder (15 min) → safety rules and questions (10 min). Stretch or shorten each part to fit your lesson length.

1. Open this course and walk through the chapter list: getting started → how AI works → using AI tools → developer basics → build and publish → AI agents → agents that keep working → build your own LLM → run your model anywhere → the final project.
2. Ask a chat assistant one short question, then show a coding agent changing one line in a file, so students see the difference between talking and acting.
3. Show where an API key should live (an environment variable or a .env file) and how a .gitignore line keeps it out of Git.

1. List which tools you can already use (ChatGPT, Codex, Claude, GitHub) and which you still need to sign up for.
2. Create an empty folder named ai-course on your computer; later chapters use it.

The student names the three kinds of AI tools with one example each and states the two safety habits.

• No paid plan: follow the demonstrations and use the in-browser practice on SONUB; every concept chapter works without an account.
• A school or office computer blocks installs: use the web versions of the tools and the SONUB shell and Python practice.

• What is the difference between asking a chat assistant and letting a coding agent change your files?
• Where should an API key be stored, and where must it never appear?

How to run this chapter in class. Students may read it too.

Ask students which AI words they have heard (5 min) → explain the words in pairs: prompt/token, training/inference, chatbot/agent (15 min) → word-matching game (10 min) → self-check (10 min).

1. Type a sentence into a tokenizer page or the SONUB tokens chapter and count the tokens together.
2. Ask a chatbot a question it cannot know (a made-up person) and show a hallucination; then show how to check it.
3. Compare a chatbot answering "how do I rename this file?" with an agent that actually renames it.

1. Make your own word card: each of the ten words with a one-sentence meaning and an example.
2. Find one hallucination by asking a chatbot about something very local or very new, and write how you checked it.

Students can explain the ten words in their own words and give the difference between training and inference and between a chatbot and an agent.

• Students mix up training and inference: training = studying for the exam, inference = writing the exam.
• Tokens are confusing: show that a long or rare word becomes several tokens while a common word is one.

• Why can a model "forget" what you said at the start of a very long conversation?
• What is the difference between asking a chatbot and giving a task to an agent?

How to run this chapter in class. Students may read it too.

Ask what students think AI is (5 min) → sort examples into rules, machine learning and language models (10 min) → read and discuss the chapter (15 min) → self-check (10 min).

1. Show three examples side by side: a spam filter written with rules, a photo app that learned to recognise faces, and a chat assistant that generates text.
2. Draw three nested circles: artificial intelligence, machine learning inside it, deep learning inside that, and place language models in the innermost circle.

1. List five apps you use and label each one as rules, machine learning or a language model, with a reason.

The student gives a correct counterexample of an AI system that does not generate words.

• Students think every AI is ChatGPT: show a rule-based spam filter and a recommendation system as other kinds of AI.

• Is a thermostat that follows the rule "heat when below 20 °C" artificial intelligence? Why or why not?

How to run this chapter in class. Students may read it too.

Compare a vague and a precise request (10 min) → improve one prompt together (10 min) → students write and test prompts (20 min) → discuss how to check answers (10 min).

1. Ask "Explain fractions", then the precise version from the chapter, and compare audience, example and activity in the two answers.
2. Add "You are an expert" to a prompt and show that the answer can still contain a mistake.

1. Write a prompt for a topic you are learning that states the audience, one example and a way to check the answer.

The student's prompt names the task, the context, a constraint and a check.

• The answer is still vague: add an example of the output you want and a length limit.

• Which part of your prompt made the biggest difference to the answer?

How to run this chapter in class. Students may read it too.

Show a weak prompt and its answer (5 min) → rebuild it with the six parts (15 min) → students improve a prompt in three rounds (15 min) → compare results (5 min).

1. Ask "write about climate" and then the same request with role, audience, length and format; compare the two answers.
2. Add one example answer to a prompt and show how the style of the result follows it.
3. Ask for the result as a table, then as JSON, from the same prompt.

1. Write a prompt with all six parts for a real task of yours (a study plan, a summary, an email).
2. Improve it twice: each time add one fix based on what was wrong in the answer, and keep all three versions.

The final prompt has the six parts, and the student can point to the change that fixed each problem.

• The answer is too long or too general: add the audience, a length limit and the format.
• The model ignores a rule: move the rule to the end, say it once clearly, and ask it to check the rule before answering.

• Which of the six parts helps most when the answer is in the wrong style?
• Why put long-lived rules in CLAUDE.md or AGENTS.md instead of every prompt?

How to run this chapter in class. Students may read it too.

What a token is (10 min) → count tokens of the same sentence in different ways (10 min) → students tokenise their own sentences (20 min) → self-check (10 min).

1. Split "unbelievable!" into characters, into words and into word pieces such as un + believ + able + !, and count each.
2. Show that IDs are only labels: two tokens with neighbouring IDs can mean completely different things.

1. Write one sentence and split it into characters and into words; write a made-up ID next to each piece.

The student explains why the same text can have different token counts.

• Students confuse tokens with words: show a long word split into several tokens, a punctuation mark that can be its own token, and a space that usually joins the next word in one token.

• Why do AI services often count usage in tokens rather than words?

How to run this chapter in class. Students may read it too.

From IDs to vectors (10 min) → one-hot vectors versus learned embeddings (10 min) → students place words on a 2-D map (20 min) → self-check (10 min).

1. Write a one-hot vector for "cat" in a five-word vocabulary and show that it says nothing about similarity.
2. Draw a 2-D map where cat and dog are close and car is far, and explain that training places them there.

1. Place eight words of your choice on a 2-D map by meaning and explain two of the positions.

The student distinguishes an ID, a one-hot vector and an embedding.

• Students think nearby embeddings mean "true": show two opposite statements about the same topic that sit close together.

• If two sentences have nearby embeddings, what can and cannot we conclude?

How to run this chapter in class. Students may read it too.

Training versus inference (10 min) → the bigram counting example (10 min) → retrieval versus fine-tuning (10 min) → students sort scenarios (10 min) → self-check (10 min).

1. Work through the chapter's sky → red/blue counting example on the board and compute the probabilities.
2. Show an app that pastes a manual into the prompt (retrieval) and explain that the model's weights did not change.

1. Sort five scenarios into training, inference or retrieval, for example "a chatbot reads today's menu before answering".

The student explains what changes during training and what the model uses at inference time.

• Students think a chatbot learns from every chat: explain that its weights stay the same unless it is retrained.

• Why can a model answer about a document it was never trained on?

How to run this chapter in class. Students may read it too.

Instructions versus permissions (10 min) → temperature, top-k and top-p with numbers (15 min) → students predict outputs (15 min) → self-check (10 min).

1. Take scores for three tokens, apply a low and a high temperature, and show how the probabilities sharpen or flatten.
2. Ask the same question twice at a high temperature and show that the answers differ, then explain that neither is checked for truth.

1. For the probabilities 0.6, 0.3, 0.1, say which tokens top-k = 2 and top-p = 0.8 keep.

The student explains that a low temperature makes answers consistent but not necessarily correct.

• Students think the system prompt is a security wall: explain that the application, not the prompt, must enforce permissions.

• When would you want a higher temperature, and when a lower one?

How to run this chapter in class. Students may read it too.

A weak request versus a strong one (10 min) → live improvement in three turns (10 min) → students write and refine their own request (20 min) → compare and check answers (10 min).

1. Ask "Tell me about Korea." Then ask: "Goal: a five-line introduction to Korea for a 10-year-old. Context: they live in Brazil. Constraint: no history dates. Format: bullet points." Compare the two answers.
2. Follow up with a precise change such as "Make line 3 shorter and add one food example" instead of asking again from scratch.
3. Ask a question whose answer contains a number, ask for the source, open it and check whether the number matches.

1. Pick a real task (an email, a study plan, a summary) and write a request with a goal, context, constraints and a format.
2. Improve the answer in at least two follow-up messages and write down one claim you checked and how.

The final request has all four parts and the student shows one fact they checked against a source.

• The answer is too long or too general: add a length limit and an audience, and give one example of what you want.
• The answer invents a source or a number: say so, ask for a link, and treat anything you cannot verify as unconfirmed.

• Which of the four parts changed the answer the most in your example?
• Why can a confident, fluent answer still be wrong?

How to run this chapter in class. Students may read it too.

A weak prompt versus a strong one (10 min) → one edit that keeps everything else (10 min) → students make and edit their own picture (20 min) → review mistakes and rights (10 min).

1. Generate "a cat", then "a watercolour of an orange cat sleeping on a blue chair by a sunny window, wide shot, 4:3", and compare.
2. Edit the second picture: "Keep everything the same, change only the chair to green." Point out anything that changed by accident.
3. Zoom into the result and find one mistake in text, hands, shadows or perspective.

1. Write an image prompt with the subject, setting, style, composition, colours and size, and generate it.
2. Make one edit that changes exactly one thing and note whether anything else changed.

The student shows the prompt, the edit request and one mistake they found in the result.

• The picture ignores part of the prompt: put the most important detail first and remove words that conflict.
• The text in the picture is misspelled: ask for fewer words, or add the text afterwards in a normal editor.

• Why should an edit request say what must stay the same?
• When is it not okay to use a generated picture?

How to run this chapter in class. Students may read it too.

Why the terminal matters for AI tools (5 min) → a live tour of pwd, ls, cd and mkdir (10 min) → students do units 1 and 2 in the SONUB shell (25 min) → the install check from unit 11 (10 min).

1. Open the SONUB shell course and run pwd, ls, mkdir ai-course and cd ai-course in the practice terminal.
2. Type a wrong command on purpose and read the error message aloud together.
3. Show unit 11: the install commands for Claude Code and Codex and how --version confirms the install.

1. Finish shell unit 1 (meeting the terminal) and unit 2 (files and folders).
2. Open a terminal on your own computer and create the ai-course folder from the command line.

The student completes units 1 and 2 and can move into the ai-course folder without help.

• Windows looks different: use PowerShell or WSL as the shell course explains, or keep practising in the SONUB terminal.
• "command not found" right after an install: close and reopen the terminal, then check the PATH part of unit 11.

• What do pwd, ls and cd each tell you or change?
• Why read a command before letting an AI agent run it?

How to run this chapter in class. Students may read it too.

Why version control matters with AI (5 min) → commit, diff and undo on screen (10 min) → GitHub: create a repository, push, open and review a pull request (15 min) → students practise (20 min).

1. In a project folder run git init, git add and git commit -m "start", change a line, then run git diff to show exactly what changed.
2. Create a repository on GitHub, push the project and open a pull request from a branch.
3. Leave a review comment on one changed line, then approve it or request changes.

1. Take steps 1–5 of the Git course (or show that you know them), then make three commits in the ai-course folder.
2. Push the folder to a new GitHub repository and open one pull request that changes a single file.

The student's GitHub repository shows at least three commits and one pull request with a description.

• The push is rejected for authentication: sign in with the GitHub CLI (gh auth login) or a personal access token, and never type the token into a chat.
• A secret was committed by mistake: revoke and replace the key at once, then remove it from the code; deleting the file alone is not enough.

• Why commit before letting an AI agent change your project?
• What does a pull request let other people do?

How to run this chapter in class. Students may read it too.

Check the Python basics (10 min) → NumPy arrays, shape and @ on screen (10 min) → students run and change the example (20 min) → explain softmax together (10 min).

1. Run the example and point at the shape, the broadcast result and the matrix product.
2. Change the scores in the softmax line and show that the probabilities still add up to 1.
3. Write the same addition as a Python loop and as one NumPy line, and compare.

1. Finish the SONUB Python course up to functions, or show the teacher that you can write a small function.
2. Change the example: make a 3×3 array, multiply it by a 3×1 array and predict the shape before you run it.

The student predicts the shape of a matrix product correctly and explains what softmax returns.

• A ValueError about shapes: print the .shape of both arrays; for a @ b the inner sizes must match.
• "No module named numpy" on your own computer: activate the virtual environment and run pip install numpy.

• Why use NumPy instead of a Python loop?
• What do the numbers returned by softmax always add up to?

How to run this chapter in class. Students may read it too.

Run the example (10 min) → change one condition and predict the output (10 min) → students write a small function (20 min) → self-check (10 min).

1. Run the chapter's example code and change the question so the else branch runs.
2. Point out that changing an if-condition is programming, not learning from data.

1. Write a function that answers three different questions with if/elif/else and test it with each.

The student predicts which branch runs before running the code.

• IndentationError: line up the lines inside if and else with four spaces.

• What is the difference between a program a person changes and a model that learns?

How to run this chapter in class. Students may read it too.

Write the brief together (10 min) → the agent builds version one (10 min) → three rounds of "look, ask, check, commit" (25 min) → show the pages (5 min).

1. In an empty homepage folder run git init, start the agent and paste a six-part prompt for a one-page site.
2. Open index.html, resize the browser to phone width, and ask the agent to fix what breaks.
3. Commit, ask for a bad change, then return to the last commit with git restore.

1. Build your own one-page homepage (a club, a hobby, a portfolio) with at least three sections.
2. Make at least three commits with clear messages, one per working change.

The page opens in a browser, reads well at phone width, has no secrets in it and has a Git history of small steps.

• The agent rewrites everything each time: ask for one small change and name the file and section.
• The page looks broken on a phone: ask for a mobile-first layout and check at 390 px width.

• Why commit after every working step when an AI writes the code?
• Why must a public homepage never contain an API key?

How to run this chapter in class. Students may read it too.

What hosting is and why static is simple (5 min) → deploy with Wrangler together (15 min) → change the page and deploy again (10 min) → connect GitHub as the second way (10 min).

1. Run npx wrangler login and npx wrangler pages deploy ./ --project-name=demo-homepage, then open the pages.dev address.
2. Change one line, deploy again, and show the new deployment and its preview address in the dashboard.
3. Show a .gitignore that keeps .env out, and explain why nothing secret belongs in a static site.

1. Publish your vibe-coding homepage and share the pages.dev address.
2. Make one improvement, publish it again and confirm the change is live.

The homepage is reachable at a pages.dev address, an update has been published, and the student can explain what is public.

• "npx: command not found": install Node.js (LTS) first, then open a new terminal.
• The page shows 404: deploy the folder that contains index.html, not its parent folder.

• What is the difference between Direct Upload and Git integration?
• Why is a static site safe to host for free but unsafe for secrets?

How to run this chapter in class. Students may read it too.

From app to store: the big picture (10 min) → build a release bundle together (15 min) → walk through the Play Console listing (15 min) → plan the 12-tester closed test (10 min).

1. Show a release build command (for Flutter: flutter build appbundle) and where the .aab file appears.
2. Walk through Play Console: create the app, the store listing, the data-safety form and the testing tracks.
3. Show where the upload key is stored and why it must never be committed or shared.

1. Write the store listing for your app: name, short and full description, and a list of screenshots to take.
2. Make a tester plan: 12 people, how you will invite them, and how you will keep them in the test for 14 days.

The student can list the steps from release bundle to production, explain the tracks and the closed-test rule, and has a listing draft and tester plan.

• No developer account or not old enough: practise with the listing and tester plan; a parent or the school can own the account.
• The upload is rejected for the version: raise the version code (Flutter: the number after + in pubspec.yaml).

• Why do new personal accounts have to run a closed test before production?
• What happens if you lose your upload key, and how do you protect it?

How to run this chapter in class. Students may read it too.

Apple's path: account → build → TestFlight → review (10 min) → archive and upload together (15 min) → App Store Connect listing (15 min) → rejection reasons and how to answer (10 min).

1. In Xcode choose Product → Archive, then Distribute App → App Store Connect.
2. In App Store Connect show the TestFlight tab, add an internal tester and install the build on a phone.
3. Read a real-looking rejection message together and write the fix and the reply.

1. Fill in a listing draft: name, subtitle, description, keywords, privacy policy address and a demo account for the reviewer.
2. Check your app against the five common rejection reasons and note what to fix.

The student can explain archive, upload, TestFlight and review in order, and their checklist covers the common rejection reasons.

• No Mac or no membership: practise the listing and the checklist, and test the app on Android or the web.
• Upload fails with a signing error: turn on automatic signing in Xcode and choose your team.

• Why test with TestFlight before submitting for review?
• Why does Apple ask for a demo account when your app has a login?

How to run this chapter in class. Students may read it too.

Act out the agent loop with a student as the "agent" (10 min) → watch a real agent's tool calls (10 min) → write a sub-agent file (20 min) → discuss when not to use one (10 min).

1. Give a coding agent a small task and point at each step: the plan, the tool call, the result and the next decision.
2. Ask the agent to search the whole project for one thing and show it handing the search to a read-only sub-agent.
3. Open a sub-agent file in .claude/agents/ and read its name, description, tools and instructions.

1. Draw the agent loop for a task of your own (for example "fix the broken link on my homepage") with every tool it would use.
2. Write a read-only reviewer sub-agent: a description of when to use it, tools limited to reading, and a three-line checklist.

The student can explain the loop, the role of tools and permissions, and why a sub-agent has its own context, and has a working sub-agent file.

• The sub-agent is never used: make the description say exactly when to use it, in the words of the request.
• The agent does too much at once: ask for a plan first and approve one step at a time.

• What is the difference between a chatbot answer and an agent loop?
• Why give a sub-agent fewer tools than the main agent?

How to run this chapter in class. Students may read it too.

What a coding agent does (5 min) → a live task with a clear request (15 min) → students give Codex their own small task (20 min) → review the diffs together (10 min).

1. In the ai-course folder, write an AGENTS.md with one rule, for example "Run python -m pytest after every change."
2. Ask Codex for a small script with a test, approve its steps, and show the test running.
3. Open git diff and walk through every changed line before committing.

1. Give Codex a task that names the file, the behaviour and the check — for example a function that counts the words in a text, with a test.
2. Review the diff, run the test yourself, then commit with a message that describes the change.

The student's commit contains working code and a test, and the student can explain every changed line.

• Codex changes more than you asked: stop it, undo with git restore, and repeat the request naming the exact files.
• Sign-in or plan problems: sign in with your ChatGPT account; if Codex is not included in your plan, follow the demonstration and practise reviewing the teacher's diff.

• What should a good coding request always contain?
• Why read the diff even when the tests pass?

How to run this chapter in class. Students may read it too.

Read the three sources → follow the diagram → compare a direct answer with tool use → explain the summary in your own words.

1. In Codex, send a short greeting. Follow user input, inference and the answer on the diagram.
2. In Claude Code, ask it to explain a file. Identify the model's reasoning and the file access supplied by the harness.
3. Open the LangChain source and locate system prompts, tools, infrastructure, orchestration and hooks.

1. Describe how a simple greeting and a request to read a file each use the harness.
2. Classify a model, system prompt, shell tool and permission check using the three sources.

Explain that short prompts also use the harness, distinguish model, prompt and execution system, and support your explanation with a source.

• If the names are confusing, separate the model that generates a response from the system that runs the loop and tools.
• Without a product account, use the diagram, official texts and a teacher's demonstration.

• Why does a direct answer without a tool call still use the harness?
• Why can changing tool logic affect a model trained with that harness?

How to run this chapter in class. Students may read it too.

Install check and first start (10 min) → CLAUDE.md with /init (10 min) → permissions and plan mode (10 min) → students set up their own project (20 min).

1. Start claude in the ai-course folder and ask "What is in this project?"
2. Run /init, then edit the generated CLAUDE.md to add one rule about tests.
3. Type /plan (or press Shift+Tab until plan mode shows under the input box), ask for a change, and show that nothing is edited until you approve the plan.

1. Start Claude Code in your ai-course folder and write a CLAUDE.md with the purpose, the test command and two rules.
2. Ask Claude Code for a change in plan mode and read its plan without approving it.

The student's project has a CLAUDE.md with a test command and rules, and the student can explain what plan mode does.

• "claude: command not found": repeat the install check in shell unit 11 and reopen the terminal.
• It asks for permission too often (Manual mode): choose "don’t ask again" only for safe commands such as running the tests, never for deleting files.

• What belongs in CLAUDE.md, and why is it read in every session?
• When would you use plan mode?

How to run this chapter in class. Students may read it too.

The five-step loop on the board (5 min) → a live loop on a small feature (15 min) → students run two loops on their project (20 min) → share one thing the agent got wrong (10 min).

1. Ask: "Add a function that returns the most common word in a text, with tests. Show me the plan first." Correct one detail of the plan.
2. Let it edit and run the tests; when a test fails, show how it reads the error and fixes the code.
3. Review git diff and commit; then make a bad change on purpose and undo it with git restore.

1. Run one complete loop on your project: a goal with a check, the plan, the change, the tests, the diff, the commit.
2. Run a second loop that improves something from the first, and write one sentence about what you corrected in the plan.

The student's Git history shows two commits made through the loop, each with passing tests.

• The agent says the tests pass but they fail: run the test command yourself and trust the output, not the summary.
• The conversation gets confused: commit or undo what you have, use /clear, and start again with a short, precise request.

• Why are several small loops better than one big request?
• What do you do when the agent goes in the wrong direction?

How to run this chapter in class. Students may read it too.

Three agents side by side: Claude Code, Codex, agy (10 min) → install and sign in to agy (10 min) → the same small task in two agents (20 min) → compare and decide (10 min).

1. Run agy in the practice project and ask it to explain the project structure.
2. Give the same bug to agy and to Claude Code or Codex, and compare the two plans.
3. Ask one agent to review the other agent's change and show how you decide between them.

1. Write an AGENTS.md with your project rules and check that two agents follow it.
2. Give one task to two agents and write a short table: what each did, what was better, what was wrong.

The student has run agy on a project, compared two agents on the same task and can explain why cross-checking catches mistakes.

• agy does not start or cannot sign in: check the official install page and sign in with a Google account in the browser.
• The agents give different answers: that is the point — open the files they point to and let the evidence decide, not the majority.

• Why can two different AI agents find more mistakes than one?
• Why put the rules in AGENTS.md when you use several agents?

How to run this chapter in class. Students may read it too.

What a skill is and where it lives (10 min) → read a real skill together (10 min) → students write a small skill (20 min) → test when it triggers (10 min).

1. Open the example SKILL.md and point at the name, the description and the steps.
2. Put the skill in .claude/skills/weekly-report/ and ask "Write my weekly report"; then ask something unrelated and show that the skill is not used.
3. Make the description vague and show how the skill becomes unreliable.

1. Write a SKILL.md for a task you repeat (a summary, a checklist, a report) with a clear description and three to five steps.
2. Test it with two requests that should use it and one that should not, and note the results.

The skill has a name, a description that says when to use it, numbered steps and a check, and it is used correctly in the tests.

• The skill is never used: put the words people actually say into the description.
• It is used for the wrong requests: add what it is not for to the description.

• Why does the agent read only the name and the description at first?
• Why read a skill before installing it from the internet?

How to run this chapter in class. Students may read it too.

What MCP is and its three roles (10 min) → read mcp-server.py together, message by message (15 min) → test it with mcp-client.sh (10 min) → connect it to Claude Code and find where the setting is saved (15 min).

1. Open mcp-server.py and follow one message through it: a tools/call line comes in on stdin, handle() picks the branch, strange_add() runs, and one JSON line goes out on stdout. Point at the tool description that the model will read.
2. Run sh mcp-client.sh and read the replies line by line: initialize, tools/list, tools/call and ping each get one reply, the notification gets none, and all six checks pass. Then add print("hello") to the server, run the client again and show the failure.
3. Run claude mcp add strange-add -- python3 ~/tmp/mcp/mcp-server.py and check it with claude mcp list. Show that no new file appeared in the folder, then show the entry in ~/.claude.json under projects → this folder → mcpServers. Start Claude Code in that folder, ask "Use strange-add to add 2 and 3", and show the approval prompt and an answer that is not 5.

1. Add a second tool to mcp-server.py — for example word-count, which returns the number of words in a text. Add its definition to tools/list, and in tools/call check the tool name to run the right function.
2. Add checks for the new tool to mcp-client.sh and run it until every check passes. Then connect the server to Claude Code and find its entry in ~/.claude.json. Without a Claude Code account, mcp-client.sh alone is enough — it plays the host's part.

The student's client prints PASS for every check, including the new tool, and the student can say where claude mcp add saved the setting and why the server does not appear in another folder.

• The client fails, or Claude Code says that the server failed to connect: a print() or an error message went to stdout. Keep stdout for JSON replies only, write logs to stderr, and run sh mcp-client.sh again.
• The server is missing in Claude Code: you started Claude Code in a different folder. The local scope belongs to the folder where you ran claude mcp add. Check ~/.claude.json, start Claude Code in that folder, or add the server again with --scope user.

• Why does the description of a tool matter as much as its code?
• Why should you read an MCP server before you install it, even if it is popular?

How to run this chapter in class. Students may read it too.

What an agent tool is (5 min) → a live task with limits (15 min) → students design a task brief (20 min) → cross-check two AI answers (10 min).

1. Give Cowork a sample folder of notes and ask for a one-page summary document; point out where it asks for permission.
2. Show a task brief with limits: which folder, what output, what it must not do, and when to ask.
3. Ask the same factual question to two AI tools, compare the answers and check the source.

1. Write a task brief for a real chore: the goal, the input folder, the expected output and three things it must not do.
2. If you have access, run it in Cowork and compare three items of the output with the originals; if not, ask two AI tools the same question and compare.

The brief names the goal, the input, the output and the limits, and the student reports at least one item they checked.

• No paid plan: write the task brief and do the cross-checking task with free tools — the planning skill is the same.
• The agent touched the wrong files: give it a copy of the folder instead of the original, and narrow its access.

• Why should an agent work on a copy of your files at first?
• When AI tools disagree, why decide from the evidence instead of the majority?

How to run this chapter in class. Students may read it too.

Why one reply is not enough for big tasks (5 min) → write a goal with a finish line (10 min) → run a short loop with a limit (20 min) → review what it did in Git (15 min).

1. In Codex type /goal with a measurable objective, then /goal to see the status, and pause it.
2. In Claude Code, set /goal with a measurable finish line ending in “or stop after 20 turns”, check the status (turns, tokens) with /goal, then remove it with /goal clear. Compare by running the same job as a Ralph Loop with a completion phrase and at most 5 rounds.
3. Show git log after the loop and check the work against the finish line.

1. Rewrite three vague requests ("improve my site", "fix bugs", "write tests") as goals with a checkable finish line.
2. Run one loop of at most 5 rounds on a practice branch and write what each round changed.

The goal has a checkable finish line and a limit, the loop stopped by itself, and the student verified the result.

• The loop never stops: stop it with /goal clear (or /cancel-ralph for the Ralph Loop), then add a maximum number of rounds and a finish line that can be tested.
• Each round undoes the last one: the goal is unclear — write the finish line as a test or a checklist.

• Why does a loop need both a finish line and a limit?
• Why should you still check the work when the agent says it is done?

How to run this chapter in class. Students may read it too.

Why a server: always on, always online (5 min) → SSH in with a key (10 min) → tmux new, detach, attach (15 min) → start a limited agent loop and check it later (20 min).

1. Connect with ssh, run tmux new -s agent, start a long command, press Ctrl+b d, log out, log in again and tmux attach -t agent.
2. Inside tmux start an agent with a goal and a round limit on a practice branch.
3. Show where the API key lives (an environment variable) and the provider's spending-limit page.

1. Practise tmux on your own computer or a VPS: create a session, detach, list sessions, attach and kill it.
2. Write a night-run plan: the goal and finish line, the limit, the branch, how you will check it and how you will stop it.

The student can keep a program running after disconnecting with tmux and has a safe night-run plan with a limit and a review step.

• "no sessions" on attach: the session was ended or the server restarted — check with tmux ls and start a new one.
• SSH asks for a password or is refused: add your public key to the server and connect with the matching user.

• Why does a program stop when SSH disconnects, and how does tmux prevent that?
• What three limits should an agent running all night always have?

How to run this chapter in class. Students may read it too.

Average, max and argmax (10 min) → thresholds and activations (10 min) → students do the AI lab missions (20 min) → self-check (10 min).

1. For [0.2, 0.7, 0.1] show max, argmax and the class that argmax chooses.
2. Move a decision threshold from 0.5 to 0.3 and show which examples change class.

1. Complete the average, maximum and threshold missions in the AI lab code mode.

The student explains the difference between max and argmax and why a score is not automatically a probability.

• Off-by-one answers for argmax: remind students that Python counts positions from 0.

• Why might a doctor choose a lower threshold for a warning test?

How to run this chapter in class. Students may read it too.

Train/test split on the board (10 min) → fit and evaluate a model (15 min) → students compare training and test scores (15 min) → self-check (10 min).

1. Split a small table into training and test rows, fit on the first part and score on the second.
2. Show a model that scores 100% on training data and worse on test data, and name it overfitting.

1. Complete the regression and classification missions and write down the training and test scores.

The student explains why a score on the training data is not enough.

• Data leakage: make sure scaling and other preprocessing are fitted on the training part only.

• Your model scores 100% on its training data. What do you check next?

How to run this chapter in class. Students may read it too.

Text into numbers on the board (10 min) → run the code and read the output (10 min) → students change the text and the start character (20 min) → talk about the loss (10 min).

1. Run the code and explain each printed line: the vocabulary, encode and decode, the probabilities after "h", the generated text and the loss.
2. Change the training text to a few sentences in another style and run it again; show how the generated text changes.
3. Point at the probs line and show that every row adds up to 1.

1. Replace the text with three sentences of your own and generate 40 characters from a letter of your choice.
2. Find which character most often follows "e" in your text and check it by counting by hand.

The student runs the code with their own text and explains what one row of the probability table means.

• A KeyError when generating: the start character is not in the text; choose a character that appears in it.
• The output looks like nonsense: that is expected, because a bigram model sees only one previous character.

• Why does a model have to turn text into numbers?
• What would a loss of 0 mean?

How to run this chapter in class. Students may read it too.

Embeddings and a hidden layer on the board (10 min) → run the code and watch the loss (10 min) → students change the temperature and the text (20 min) → explain one training step (10 min).

1. Run the code and point at the loss falling every 50 steps.
2. Change the temperature in generate() to 0.3 and then to 1.5 and compare the texts.
3. Set lr to 5.0 and run again; show that a step that is too large makes training unstable.

1. Change the training text to your own sentences and train again; note the final loss.
2. Try two temperatures and describe the difference in one sentence.

The student shows the loss going down and explains what an embedding and a training step are.

• The loss becomes nan: the learning rate is too high; lower lr below its current value, for example to 0.1.
• Generation fails with your text: the start string must be three characters that appear in the text.

• What does the backward pass compute?
• Why does more context make the text look more like real words?

How to run this chapter in class. Students may read it too.

Query, key and value with an everyday example (10 min) → run the code and read the loss and the attention weights (10 min) → students experiment (20 min) → connect it to real LLMs (10 min).

1. Explain attention with a sentence: in "the dog ran because it was scared", the word "it" attends to "dog".
2. Run the code and read the attention weights of the last character: which earlier positions get the most weight?
3. Remove the mask (multiply it by 0) and show that the loss drops suspiciously low because the model can see the answer.

1. Train with your own text and generate from a start string of your choice.
2. Print the attention weights for another example, such as X[10:11], and describe what the last character attends to.

The student trains the model, shows the loss going down, and explains query, key, value and the causal mask in their own words.

• Shape errors after changing T: the mask and the windows both depend on T, so change T in one place only.
• Training is slow on an old device: lower the number of steps to 200; the loss still falls.

• Why does the model need a causal mask?
• What do the attention weights of one position add up to?

How to run this chapter in class. Students may read it too.

From the three browser chapters to GPT-2: the same blocks, bigger (10 min) → set up Python and PyTorch (10 min) → prepare data and start training (15 min) → sample text and read the loss curve (15 min).

1. Show the GPT-2 block diagram and match each part to the build-llm chapters: embeddings, attention, the next-token scores.
2. Run the Shakespeare character-level training from nanoGPT with a small CPU setting (about 3 minutes) and show the training and validation loss as it prints.
3. Generate text from an early checkpoint and from the final one, and compare.

1. Train the small model on your computer (or on a free cloud notebook) and save the loss values at the start and the end.
2. Change one setting — the number of layers, the embedding size or the training steps — and write how the loss and the text changed.

The student trained a model, has a checkpoint, can show the loss falling and can explain training loss versus validation loss.

• Out of memory: lower the batch size, the block size or the number of layers.
• Training is very slow on the CPU: make the model smaller or use a free cloud notebook with a GPU.

• Why does the same GPT-2 design work at a much smaller size?
• What does it mean when the training loss keeps falling but the validation loss rises?

How to run this chapter in class. Students may read it too.

Weights are just numbers: what is missing? (5 min) → the runner's loop step by step (15 min) → run a small open model with Ollama or llama.cpp (20 min) → call its local API (10 min).

1. Write the runner loop on the board: tokenize → model → scores → sample → append → repeat, and connect it to the sampling chapter.
2. Run a small open model locally (for example ollama run with a 1-billion-parameter model) and show tokens streaming.
3. Call the local API with curl, with "stream": false in the request, and show the whole answer coming back as one JSON object. Without it, a JSON line arrives for every token.

1. Write the runner loop as numbered steps in your own words and mark where temperature is used.
2. Run a small open model on your computer and measure how many tokens per second it produces.

The student can explain each step of the runner loop, has run a local model and knows that a runner can serve a local API.

• The model is too slow or does not fit: choose a smaller model or a more strongly quantized file.
• The answers look strange: the chat template or tokenizer does not match the model — use the files that came with it.

• Why is a weights file alone not enough to chat with a model?
• What is the advantage of running a model locally instead of through a cloud API?

How to run this chapter in class. Students may read it too.

Why phones need small models (5 min) → convert and quantize on a computer (15 min) → run it in a phone app (15 min) → how an app embeds a runner (15 min).

1. Show the file size of the same model at 16-bit and at 4-bit and test both on a computer.
2. Load a small quantized GGUF model into an offline chat app on a phone, turn on airplane mode and chat.
3. Show a few lines of app code that load the model file and stream tokens from the embedded runner.

1. Choose a small open model, find its quantized GGUF file, and estimate whether it fits in your phone's memory.
2. Run it on your phone offline and write the speed (tokens per second) and one thing it does well and one it does badly.

The student can explain conversion, quantization and embedding a runner in an app, and has run a model offline on a phone (or on a computer if no phone is available).

• The app crashes when loading: the model is too big for the phone's memory — use a smaller model or stronger quantization.
• No phone available: run the same GGUF file with llama.cpp on a computer; the steps are the same.

• What do you gain and what do you lose with 4-bit quantization?
• Why is an on-device model good for privacy?

How to run this chapter in class. Students may read it too.

Project ideas and scope (15 min) → students plan and build over one or more lessons → presentations with the Git history and a demo (about 10 min each).

1. Show an example plan with a goal, users, checks and three milestones.
2. Show a finished example repository: the commits, a CLAUDE.md or AGENTS.md, and a pull request with a clear description.
3. Give a short example presentation that includes one AI mistake and how it was caught.

1. Write the one-page plan and get the teacher's approval before you start building.
2. Build it in at least three commits and open a pull request with a description and instructions to try it.

The pull request exists, the project works as described, and the student can explain one AI mistake and one check.

• The project is too big: cut it down to one feature that works from start to finish, then add more.
• The code works but the student cannot explain it: ask the agent to explain it line by line, then rewrite one part yourself.

• Which check gave you the most confidence that your project works?
• Which parts did you do yourself, and which did the AI do?