AI Course

Two habits matter more than any tool. First, check the result: an AI answer, picture or code change is a draft until you have read it, tested it or compared it with a source. Second, protect secrets: never paste passwords, API keys or other people's personal data into a chat, a prompt or a file you share. Keys belong in environment variables or in a .env file that is never committed to Git.

A hallucination is a confident answer that is wrong or made up, which is why you always check. An API is a door that lets your own program send a prompt and get the answer back, usually with a secret API key. A chatbot only answers, but an agent can also act: read files, run commands and use tools, step by step, toward a goal. Open source or open-weight models can be downloaded and run on your own computer; closed models are used only through the company's app or API.

• Google — Machine learning glossary

A large language model (LLM) is one kind of AI. Many text-generating LLMs predict the next token from the available context. Image generators, classifiers, and rule-based systems can work differently. Fluent language is not evidence that a system is alive or that its output is true.

• NIST — Generative AI profile

A role can guide tone, but does not grant expertise or guarantee compliance. Ask for sources when needed and verify that they support the claim. Compare two prompts on the same examples. Share only necessary information; a clearer prompt can help, but cannot remove every model limitation.

• Transformers — LLM tutorial

Treat a prompt like a draft. Read the answer, find what is missing or wrong, and add exactly that to the prompt: "use simpler words", "give three options", "cite the source". For hard tasks, ask the model to plan first and answer second, or split the task into smaller prompts. For coding agents, the long-lived parts of the prompt — the rules, commands and style — go into a project file such as CLAUDE.md or AGENTS.md so you do not repeat them every time.

• Anthropic — Prompt engineering overview
• OpenAI — Prompt engineering

Our toy lab uses a simple word tokenizer, not a production LLM tokenizer. An ID is just a label: ID 8 is not twice the meaning of ID 4. A context window limits how many tokens a model can use; the application may select, summarize, or discard material to fit.

• Transformers — Tokenizers

Modern Transformers use attention to combine information from positions in the available context, so a token's representation can change with its sentence. Similarity is not truth or identical meaning. The famous king − man + woman analogy is an illustrative result from some word embeddings, not a universal equation. Search compares query and document vectors in a compatible embedding space.

• Attention Is All You Need

Fine-tuning changes model weights; LoRA trains smaller adapter matrices while base weights can stay frozen. RAG retrieves material and supplies it as context without requiring weight updates. BM25 ranks lexical matches using term frequency with saturation and document-length normalization; embedding retrieval compares learned vectors. Either can miss evidence or retrieve misleading text. A chat message is not automatically a training update.

• Attention Is All You Need
• Retrieval-Augmented Generation
• LoRA

Try greedy and sampling modes several times in the builder. Sampling can repeat the same result. Temperature zero does not guarantee identical output across real systems: model versions, context, tools, and numerical execution also matter. Then compare a vague question with one giving a goal, context, and a way to check the answer. Test a factual claim against an original source; use hints and explain the result in your own words.

• Transformers — Generation strategies
• PyTorch — Reproducibility

A language model predicts likely text, so a fluent answer can still be wrong. Ask for sources and open them, compare numbers with the original, and ask the model to list its assumptions. For important facts, check a second, independent source. Saved instructions and projects let ChatGPT remember your preferences, but they are still instructions, not guarantees, so keep checking.

• OpenAI — Prompt engineering

Generated pictures often hide small errors: wrong letters, extra fingers, impossible shadows. Always zoom in and check. Do not use a generated picture to pretend that something really happened, do not imitate a living artist or a real person without permission, and say that a picture was made with AI when it matters. Read the terms of the tool before using pictures commercially.

• OpenAI — Image generation
• Google — Gemini image generation

Inside an AI tool, commands that start with a slash control the tool itself: /init writes a project instruction file, /help lists the commands, /clear starts a fresh conversation and /exit leaves. Unit 11 of the shell course shows how to install AI coding tools and check them with --version; install commands change, so compare them with the official page. Press Ctrl+C to stop a command that is still running. When an AI agent proposes a command, read it before allowing it — rm -rf deletes files for good, with no recycle bin.

• The Linux command line for beginners

On GitHub, use issues to describe a task, branches to work on it without disturbing the main code, and pull requests to review it. Keep repositories that contain private work private, and never commit a .env file or a key; once it is pushed, assume it has leaked and replace the key. Codex and Claude Code can open pull requests too, but a person should read the diff before merging.

• GitHub — Hello World

Three NumPy ideas carry the rest of the course: shape (how many rows and columns), broadcasting (an operation is stretched across the whole array automatically) and vectorised maths (working on the whole array instead of writing a Python loop). All the code in this course runs in your browser. On your own computer, install Python 3, make a virtual environment with python -m venv .venv, and install NumPy with pip install numpy.

• NumPy — the absolute basics for beginners

The example below applies a rule written by a person. Change the score or threshold and predict the output before running it. A function uses return to give a value back; print only displays it. Test boundary cases such as a score exactly equal to the threshold. This rule-based program has no learning step.

• Python tutorial

You are still the developer. Read every change before you accept it, commit to Git after each working step so you can go back, and test on a real phone width. Never let the agent put passwords or API keys in the page — a homepage is public, and everything in it can be read. When the page works, it is ready to publish: the next chapter puts it on the internet with Cloudflare.

• MDN — Your first website

Everything you publish is public, so check that no keys, private notes or .env files are in the folder. Each deployment gets its own preview address, and the production address shows the latest one, so you can test before sharing. A custom domain such as myname.com can be added later in the dashboard. You can ask your coding agent to run the deploy commands, but read them first and never paste your Cloudflare API token into a chat.

• Cloudflare Pages — Direct Upload
• Cloudflare Pages — Git integration

Releases go through tracks: internal testing, closed testing, open testing and production. New personal developer accounts must first run a closed test with at least 12 testers who stay opted in for 14 days in a row before they can apply for production access, so plan your testers early. Every release is reviewed by Google, and each update needs a higher version code. Rules and screens change, so follow the official Play Console help next to this chapter.

• Play Console Help — Testing requirements for new personal developer accounts
• Flutter — Build and release an Android app

Every uploaded build can go to TestFlight first, so testers install it before the public does. When you submit for release, Apple's App Review checks the app against its guidelines. Common rejections: the app crashes or has placeholder content, the privacy details are missing, there is a login but no test account for the reviewer, there is third-party login without an equivalent privacy-friendly option such as Sign in with Apple, or the app is only a website wrapped in an app with little to do (the minimum-functionality rule, guideline 4.2). Read the rejection message, fix exactly that and resubmit.

• App Store Connect — Workflow
• App Review Guidelines — 4.2 Minimum functionality
• Flutter — Build and release an iOS app

A sub-agent is a helper the main agent starts for one part of the job. It has its own fresh context window, so it can read many files or search widely and report back only the conclusion, keeping the main conversation short. Sub-agents can also run in parallel on independent parts. In Claude Code they are Markdown files with a name, a description, allowed tools and instructions in .claude/agents/ (for the project) or ~/.claude/agents/ (for you). Give a sub-agent a narrow job and only the tools it needs, and remember that its report is still a draft you check.

• Anthropic — Building effective agents
• Claude Code — Subagents

Good coding requests are specific: what to change, in which files, how it should behave afterwards, and how to check it (a test, a command, an example input and output). For a bigger task, ask for a plan first. When Codex is finished, read the diff, run the tests yourself, and commit only what you understand. codex exec runs a task without the interactive screen, which is handy in scripts.

• OpenAI — Codex
• AGENTS.md

Claude Code asks before it edits files or runs commands, and you decide whether to allow an action once, for the session, or always. Permission rules live in .claude/settings.json, and plan mode lets Claude Code read and propose a plan without changing anything. Start strict, loosen only what you trust, and never allow a command you do not understand.

• Claude Code — Overview
• Claude Code — Memory (CLAUDE.md)

Give the agent ways to check itself: tests, a command that must succeed, or an example of the correct output. If a session heads in the wrong direction, press Esc to stop, say what was wrong, or undo with Git and make a fresh request; long sessions collect confusing context, and /clear starts clean. For work you repeat, save the steps as a skill (see the Agent Skills chapter).

• Claude Code — Common workflows

Knowing three agents is useful because each model has different strengths and blind spots. A good habit is cross-checking: ask one agent to make a change and another to review it, or ask several to analyse the same problem separately and compare — where they disagree, open the files yourself and decide. Keep the same project rules for all of them in AGENTS.md, which many agents read, so they follow the same instructions.

• Antigravity — Getting started (CLI)

The description decides when a skill is used, so write it with the words people really say and state what it is not for. Keep the instructions short and concrete, move long details into separate reference files, and test the skill with requests that should and should not use it. Skills can run scripts, so install skills only from sources you trust, and read them first. SONUB itself is built with several skills — one of them writes the beginner pop-ups for terms you see on this site.

• Agent Skills
• Claude Code — Skills

The more an agent can do, the more your instructions matter. Give it only the folders it needs, say what it must not do (delete, send, buy), ask it to stop and ask when it is unsure, and check the result against the originals. A useful habit from software teams is cross-checking: give the same question to two or more AI tools, compare the answers, and decide from the evidence, not from the majority. SONUB's own developers work this way — one question goes to several AI models, and every claim is then checked in the source files.

• Claude — Get started with Cowork

A loop is only as good as its finish line. "Make it better" never ends; "all tests in tests/ pass and the page loads without errors" can be checked. Always set a limit — a maximum number of rounds, a completion phrase the agent may say only when it is true, or a token budget — or the loop can run all night and spend money for nothing. Start loops on a fresh Git branch, keep the project's rules in CLAUDE.md or AGENTS.md, and check the result yourself: "done" from an agent is a claim, not a proof.

• OpenAI Cookbook — Using goals in Codex
• Claude Code plugin — Ralph Loop

An agent running all night needs guard rails. Give it a clear goal with a finish line and a limit, run it on a branch, and let it commit so you can review the work in the morning. Keep API keys in environment variables, never in the repository, and set a spending limit with your AI provider. Protect the server: SSH keys only, a firewall, and regular updates. Check on the session with tmux attach or by reading the Git log, and stop it with Ctrl+C or tmux kill-session -t agent.

• tmux — Getting started

A neuron can combine inputs as z = w·x + b and apply an activation function. Sigmoid maps a finite real number to a value between 0 and 1; it is one activation, not the definition of every neuron. Other networks use ReLU or GELU. Implementing sigmoid shows a building block, not a trained network. The missions then introduce models fitted from data; passing examples is a checkpoint, not proof of generalization.

• scikit-learn — Linear regression

The neighbor count k and tree depth are hyperparameters chosen outside fitting; coefficients can be learned parameters. Use a validation split or cross-validation to choose settings, then reserve the test set for the final estimate. Repeatedly tuning to test results makes that estimate optimistic. Report the split, baseline, score, and errors. One small Iris experiment is a first project, not proof that a model works for every population or task.

• scikit-learn — Common pitfalls
• scikit-learn — Iris dataset

The loss measures how surprised the model is by the real next character — the average of minus the log of its probability. A perfect model would have a loss of 0. Real LLMs use tokens made of several characters and look at a much longer context, but the loop is the same: text → IDs → probabilities for the next token → pick one → repeat.

• Andrej Karpathy — makemore

Watch the loss fall as the steps go by: the network is learning. The generated text now forms real words because it sees more context. Temperature controls how adventurous generation is — below 1 picks safer characters, above 1 takes more risks. Large LLMs have billions of weights and train on enormous amounts of text with GPUs, but each training step is this same idea.

• Bengio et al. — A Neural Probabilistic Language Model

This code trains one attention head with a context of eight characters, entirely in NumPy, and prints the attention weights of the last character, so you can see which earlier characters it relies on. A real transformer stacks many layers with many heads each, adds feed-forward layers and normalisation, and trains with an optimiser such as Adam on far more text. Everything else — tokens, embeddings, softmax, loss, gradient descent and sampling — you have now built yourself.

• Attention Is All You Need

Training repeats one step: take a batch of text, predict each next token, measure the error (the loss), and nudge every parameter to make it smaller. Watch two numbers — the training loss and the validation loss on text the model has not seen; if only the training loss falls, the model is memorising. When training ends you have a checkpoint file with all the parameters. On a Mac use the mps device, on an NVIDIA card use cuda, and otherwise the cpu with a smaller model. The browser chapters before this one built the same pieces by hand in NumPy; here you use them at real size.

• Andrej Karpathy — nanoGPT
• Andrej Karpathy — nanochat
• OpenAI — Language Models are Unsupervised Multitask Learners (GPT-2)

Runners differ in where they run and which file formats they read. PyTorch runs your training checkpoint directly; llama.cpp and Ollama run GGUF files on ordinary computers and phones; browsers and phones can also use ONNX or Apple's and Google's own runtimes. Many runners offer a local API, so your own app can talk to a model on your computer exactly like it talks to a cloud API — with no key and no data leaving the machine. Your nanoGPT checkpoint becomes runnable in these engines after a conversion step, which the next chapter does.

• llama.cpp
• Ollama — API

To use it on a phone there are two ways. The quick way: copy the GGUF file into an app that already contains a runner, such as PocketPal AI, and chat offline. The builder's way: embed the runner in your own app — for example llama.rn in a React Native app or a llama.cpp binding in a Flutter app — ship or download the model file, and call it from your code. Everything stays on the phone, so it works without the internet and keeps data private, but it is slower than the cloud and uses battery, so keep prompts short and models small. Another way is to keep the runner on your computer and call its local API from the phone over the same Wi-Fi — easier, but it works only near that computer. Do not confuse embedding a model in an app with embeddings, the vectors from the embeddings chapter; a small embedding model on the phone can also search your own notes.

• llama.cpp — quantize
• PocketPal AI
• llama.rn

The presentation matters as much as the code: show the plan, one moment when the AI got something wrong and how you noticed, the tests or checks you ran, and what you would do next. Credit honestly — say which parts you wrote, which the AI wrote, and how you checked them.