Words and what they mean here.

Most code, when it's wrong, costs you an hour. AFD code, when it's wrong, costs someone else something they can't get back. A bad medication-dosing function. An auth system that leaks user accounts. A children's app that exposes location data. A senior's banking tool that sends money to the wrong place. Code that controls a physical device a human depends on.

The AFD test is not whether vibe coding can produce the code. Vibe coding can usually get you 90% of the way there. The test is whether you, the person directing the agent, can recognize the 10% that's wrong before it ships. For most readers of this curriculum, on AFD code, the honest answer is no.

The pattern, then, is: build as close to the finished product as you can, and then stop. Hand the work to a senior developer, a licensed professional, or a domain expert who is liable for the result. Not because vibe coding failed. Because when the failure mode is 'someone gets hurt,' the person doing the catching has to be someone with credentials and exposure, not you. The curriculum covers AFD in §1.4, references it in §6.4 (secrets), §6.5 (data privacy), and §9.3 (the closing list of what functional looks like), and surfaces it as a checklist item in the PRD and feature spec templates (§§8.1, 8.2).

The word "agent" gets used loosely. The useful definition is the one with teeth: a program is an agent if the LLM is in the loop deciding what to do next, and if "what to do next" can include things other than producing text. A chatbot that only writes responses is not an agent. A program that takes a goal, decides which tool to call, calls it, looks at the result, and decides whether to call another tool or finish, that's an agent.

The reason this distinction matters is operational. Agents have a control flow problem chatbots don't: they can loop forever, call tools incorrectly, or produce results the user can't easily verify. The curriculum's agentic templates (sections 8.7 through 8.9) all include explicit guardrails like step limits, tool allowlists, and output validation, because every agent that lacks them eventually surprises someone.

Almost every agent framework implements some version of the same loop. The agent receives a goal, looks at what it knows, picks a tool to call, calls it, reads the result, and asks itself whether the goal is met. If yes, it stops and returns. If no, it picks the next action and runs the loop again.

The loop is conceptually simple and operationally treacherous. Agents can get stuck (calling the same tool repeatedly with slight variations), drift (forgetting the original goal after a long chain of steps), or loop forever (deciding the work is never quite done). Every production agent runs with a maximum step count, a watchdog timer, or both. The curriculum's templates set these limits aggressively low to start, and let the builder relax them once they've watched the agent work.

This is the term for the broader category that includes agents, multi-agent systems, and AI-orchestrated workflows. The defining characteristic is who decides what happens next: in a traditional system, the developer wrote the if-statements; in an agentic system, the model writes them at runtime by choosing tools and producing outputs.

The trade-off is exactly what you'd expect. Agentic systems are dramatically more flexible, in that they can handle inputs the developer never anticipated, and dramatically less predictable. A traditional system fails the same way every time it fails. An agentic system fails differently every time, which makes the failures harder to diagnose and harder to test for. The curriculum's position is that agentic systems are the right answer for problems where the input space is too large to enumerate, and the wrong answer for problems where correctness is straightforward to specify and test.

Familiar editor, different premise. Instead of completing your next line, it dispatches agents that work through whole tasks (planning, writing, running commands, testing in a built-in browser) while you review and steer, several in parallel.

The interesting part is the artifacts it produces before and after: a plan you approve before anything is written, a live task list you can watch for scope drift, and a walkthrough afterward with screenshots and test logs. That is the verification habit given a user interface, and the same three checkpoints are worth imposing on any agent that lacks them.

It has been an early preview: agent loops, crashes, and the real cognitive cost of supervising several agents at once. Good for exploration, not for anything with a deadline attached.

Every paid API (OpenAI, Anthropic, Stripe, Twilio, Postmark, and most others) issues you a key when you sign up, and that key authenticates every request you send. If the key gets out, anyone who has it can make calls on your account, and you pay the bill.

Keys leak in two reliable ways: they get committed to a public git repo, or they get pasted into a chat with someone who's screen-sharing. Both happen constantly. The defenses are mechanical: store keys in environment variables, never in source code; add `.env` to your `.gitignore` before you write your first line; use a secrets manager (or at minimum, a password manager) for keys you'll use more than once; rotate any key you suspect has been seen by someone else. Most providers will email you when a key gets used from a new IP, but the email arrives after the bill does.

Bedrock is the AWS-flavored way to use Claude, Llama, Mistral, and a handful of other models. The technical difference from calling Anthropic or another lab directly is small (same models, similar latency, similar pricing), but the operational difference is large: requests go through your AWS account, billing rolls up with the rest of your AWS spend, and you can apply IAM policies, VPC controls, and AWS audit logging the same way you would for S3 or RDS.

The reason to use Bedrock is almost always organizational rather than technical. Companies that already have AWS as their platform of record, or that need their model usage to live inside an existing compliance boundary, take Bedrock. Solo builders and small teams generally don't need it and pay a small premium when they use it. The curriculum mentions Bedrock primarily because LeaseDok and the Dynamo platform both use it, and because federal projects often require it.

S3 is the part of AWS that has aged best. The model is dead simple: buckets hold objects, objects have keys, and any object can be fetched by URL if you set the permissions to allow it. Pricing is per gigabyte stored and per request, and at the volumes a small project generates the bill is rounding error.

The curriculum reaches for S3 in two places. The first is document storage for RAG pipelines, where source PDFs, transcripts, or markdown files live in S3 and the indexing pipeline pulls from there. The second is anywhere a project needs file uploads (lease documents, profile pictures, exports) and the team wants those files to be durable, cheap, and available behind a signed URL. Almost every other AWS service can read from S3, which is the real reason it shows up everywhere.

When you start a local LLM, two things happen in sequence. First, the model's weights are read from disk and loaded into the GPU's VRAM. Then the model runs inference, producing tokens. These two phases stress completely different parts of your hardware.

Model loading is bandwidth-bound. A 70-billion-parameter model in 4-bit quantization is roughly 35 gigabytes; reading 35 gigabytes off an NVMe drive takes about 10 seconds, off a SATA SSD takes about a minute, and off a network share takes long enough that you'll wonder if it crashed. Inference, once loaded, is bound by the GPU's memory bandwidth and compute, which is a different number on the spec sheet. People who buy a fast GPU and pair it with a slow disk get a system that feels great once warmed up and miserable to restart. The curriculum's hardware section flags this trap because it's the most common DIY rig mistake.

MMLU, HumanEval, GSM8K, SWE-bench, and a hundred others. Each benchmark is a fixed set of questions or tasks; each model is scored on how many it gets right. The leaderboards are useful because they give you a rough ordering of which models are good at what, and a rough sense of how much better this year's models are than last year's.

Benchmarks are also the most overfit-to artifact in the industry. Every lab knows the benchmark questions, every training run gets evaluated against them, and the score on a public benchmark is a worse predictor of real-world performance every year. The curriculum's recommendation is to use benchmarks the way you'd use a college ranking: as a tiebreaker when you've already narrowed the field by trying the models on your own work. Your own work is the only benchmark that matters for your project.

You write SQL; it handles the scale. There is no cluster to size and no server to keep running, and billing is driven mainly by how much data each query scans, which means an unselective query over a huge table is the expensive mistake, not a long-running one.

For research it earns its place two ways: the public dataset catalogue is a genuine source of real data to work against, and results pull into a notebook in one line of Python. It also has an MCP server, which means a terminal agent can inspect schemas and answer questions in natural language. Read the SQL it generated before you trust the number it hands back.

Git's killer feature is that branches are cheap. A branch is a label that points at a particular commit, and creating one costs nothing. The convention almost everyone follows is: keep `main` (or `master`) as the always-working version of the code, and do every piece of work on a separate branch named after the change you're making.

When the change is done, you merge the branch back into main, usually through a pull request that lets a teammate or a CI system check the work first. The curriculum recommends branching for every change from day one, even on solo projects, because the habit pays for itself the first time a coding agent does something you don't want and you can throw away the branch instead of unwinding the change.

Frontier APIs charge per input token, and the input tokens add up fast: a long system prompt, a CLAUDE.md, a set of few-shot examples, and a chunk of retrieved context might run 30,000 tokens before the user's actual question. If you make ten requests with the same prefix, you're paying for those 30,000 tokens ten times. Prompt caching solves this. You mark the cacheable portion of your prompt; the API processes it once, stores the intermediate state, and on subsequent requests reads from the cache at roughly a tenth of the per-token cost.

The savings are real and the engineering cost is low. Anthropic's prompt caching has been the single biggest cost-reduction lever in most production Claude deployments since it shipped. The curriculum covers it in section 7 alongside the other API economics, because at any meaningful volume it changes which architectures are affordable.

The technique is simple: instead of asking "what's the answer," you ask "think through this step by step, then give me the answer." On problems that require multiple inferences (math, logic, multi-hop reasoning), this consistently improves quality, often by more than a small fine-tuning effort would.

Newer reasoning models (Claude with extended thinking, OpenAI's o-series, DeepSeek-R1) bake chain of thought into the model itself, producing internal reasoning traces before the visible output. For older or smaller models, you still have to ask for it explicitly. The curriculum treats chain of thought as a default move for any problem where the wrong answer is more than slightly costly, and a habit worth keeping even when the model could probably get the right answer in one shot.

Documents are too long to embed whole. You have to break them into pieces. The pieces are called chunks, and how you make them determines whether your `RAG` system is useful or useless.

The variables are size (250 tokens? 1,000? 2,000?), boundary strategy (split on paragraphs? sentences? headings? a fixed token count?), and overlap (do consecutive chunks share content?). A document chunked badly produces retrieval that misses the relevant section because the answer was split across two chunks, or that returns chunks too small to contain the full context the model needs to answer.

There's no universally right chunking strategy. The right one depends on the document type, the question pattern, and the model's context window. The curriculum's RAG section walks through tuning this on a real corpus, because the only way to get good chunking is to look at what the retrieval is returning and adjust until it's returning the right things.

CI is the part that runs your tests automatically when you push code or open a pull request. CD is the part that takes a passing build and deploys it. Together they're the safety net that lets a team move quickly without breaking things, because any change that breaks the tests gets caught before it gets merged, and any change that gets merged ships immediately.

For solo projects with a coding agent doing most of the work, CI is even more valuable than it is for human teams. The agent can write code that compiles and looks fine and is subtly wrong, and the tests are the only mechanism that catches that consistently. The curriculum's recommendation for any non-trivial project is: GitHub Actions running your test suite, gated on every pull request, with deployment to Vercel or Cloudflare on merge. Setup takes an hour; payoff is forever.

Claude Code is a coding agent that runs in your terminal. You point it at a project, give it a task, and watch it read files, propose edits, run commands, and iterate. It's the tool the curriculum is written around for the simple reason that the entire site you're reading was built with it.

What Claude Code does well is sustained work in a real codebase: reading existing code before changing it, asking clarifying questions when a spec is ambiguous, and producing diffs that are reviewable rather than overwhelming. What it does poorly, like every coding agent, is anything where the spec is vague or the tests don't exist. The curriculum's repeated point is that the agent is only as good as the spec it's working from, which is why writing specs is the actual skill the curriculum teaches.

Claude Code pairs with Claude Pro ($20/month, casual use) and Claude Max ($200/month, heavy daily work). The playbook in section 2.6 is written around its specific commands and conventions, but the patterns it teaches transfer to other harnesses: OpenClaude reads the same CLAUDE.md and runs the same /clear and /compact commands; Cursor's agent uses .cursorrules instead but the discipline is identical; Codex CLI uses AGENTS.md. The patterns travel; the exact commands often don't. See section 3.2 for the full agent landscape.

Every coding agent works better when it knows what your project is, what conventions it follows, and what it shouldn't touch. CLAUDE.md is the file where you write that down. The agent reads it on every session, so anything you put there applies to every prompt you send. A good CLAUDE.md covers what the project does in two sentences, the language and framework, the directory layout, the things that have to be true for code to be considered done (tests passing, lint clean, types valid), and the things the agent should never do without asking (delete data, push to main, run paid API calls).

The discipline is the same as writing onboarding docs for a new human teammate: assume they're competent but new, and give them the context that lets them be useful in 30 seconds instead of 30 minutes. The curriculum has a template for it in section 8.3.

OpenAI's GPT models, Anthropic's Claude models, and Google's Gemini models are all closed-weights. The lab trained them, the lab serves them, and you interact with them only through the lab's API. You can't download the weights, run them on your own hardware, or fine-tune them on your own data unless the lab has built a service for that.

The trade-off versus `Open weights` is the central political and economic question of the LLM industry. Closed-weights models are typically more capable and have stronger safety tuning; open-weights models are typically cheaper to operate at scale and let you keep data on your own infrastructure. Most production projects use a closed-weights frontier model for the hard work and an open-weights local model for the high-volume work, and that mix has been stable for the past two years.

Cloudflare started as a DNS and CDN company and turned into a full edge computing platform. For the curriculum's purposes, three things matter: their DNS is fast and free, their CDN sits in front of your site and makes it faster everywhere, and their Workers product runs JavaScript or TypeScript at the edge for things like authentication, request routing, or simple APIs without spinning up a server.

The curriculum recommends Cloudflare for any small project that wants to be fast without thinking about it. The free tier covers more than most projects need, the paid tier is cheap, and the developer experience is among the best in the industry. The trade-off is platform lock-in, which is real but worth it for the simplicity at the scale most curriculum readers are operating at.

A coding agent is the difference between asking an LLM to write a function in a chat window and pasting the result into your editor, and asking it to add a feature to a real codebase and watching it edit five files, run the tests, and report back. Claude Code, OpenClaude, Cursor, Codex CLI, Aider, Devin, and Google's Anti Gravity are all coding agents. They differ in how much autonomy they take, what model is behind them, and whether they live in a terminal or an IDE. They all share the basic move: they have access to your filesystem and your shell, and they use that access to do work that would otherwise require you to copy and paste.

The reason this matters for the curriculum is that a coding agent is what lets a person who can't write code from scratch still ship working software. You write the spec; the agent writes the code; you verify the result. The verification habit (section 6.3) is the part most people skip and the part that separates shipping a thing from shipping a thing that works.

The curriculum's working position is that the agent landscape is more interchangeable than it looks. The patterns of agentic coding (CLAUDE.md, the four-phase loop, session management, the prompt patterns) work across most of these tools with minor adjustments. The exact commands are tool-specific; the discipline isn't. Section 3.2 covers the four agent categories and which one fits which use case.

Serverless platforms (Vercel, AWS Lambda, Cloudflare Workers, others) save you money by tearing down idle compute. When the next request arrives, the platform has to spin a container back up, load your code, and start it. The user waits. That wait is the cold start, and depending on the platform and runtime, it can be 100 milliseconds or 5 seconds.

Cold starts matter when latency matters. An API behind a website that gets hit once a minute will cold-start most requests. An API behind a chatbot will cold-start the first message of every conversation. The mitigations are: keep functions warm with a heartbeat, use a platform with faster cold starts (Cloudflare Workers is currently best in class), or move latency-sensitive endpoints off serverless entirely. The curriculum flags this because the first time a reader's first agent feels slow, this is usually why.

Docker is the containerization tool everyone has heard of, and a container is what Docker produces. The point of a container is that the thing inside it doesn't care what's outside it: the same container that ran on your laptop runs unchanged on a production server, on a colleague's machine, or in a CI pipeline.

For the curriculum's audience, containers matter in two places. First, almost every modern deployment story (Vercel, Railway, Fly.io, Cloudflare Containers, AWS ECS) uses containers under the hood, even if the platform hides the details. Second, running a local LLM via Ollama, vLLM, or llama.cpp is much easier inside a container than installing the dependencies natively. The curriculum doesn't require deep Docker fluency, but a working understanding of what a container is and isn't pays for itself the first time something works on your machine and not in production.

Every LLM has a maximum context window: the most tokens it can take as input plus produce as output in one shot. As of this writing, frontier models sit between 200,000 and 2,000,000 tokens; local models often sit at 8,000 to 128,000. The window matters because anything you want the model to consider has to fit in it: the system prompt, the conversation history, the files the agent is reading, and the response itself.

The practical consequence: large codebases, long documents, and long conversations will eventually exceed the window, and when they do, the model either truncates silently or refuses. This is why `RAG` exists, why coding agents read files on demand instead of dumping the whole repo into the prompt, and why prompt caching is a meaningful cost lever. A 200K-token window sounds infinite until the first time you watch one fill up.

CNNs dominated computer vision for a decade before transformers arrived: image classification, face detection, medical imaging, self-driving perception. They work by sliding small learned filters across an image, building up from edges to textures to whole objects.

They are mentioned in this curriculum mostly to draw a boundary: this curriculum is about building with large language models. A CNN is a different tool for a different job. If your project is "detect defects in photos of parts," the right move may be a vision model or classical CNN pipeline, not an LLM. Knowing that distinction is exactly the kind of tool-awareness this curriculum is trying to build.

A single high-end GPU pulls 350-450 watts under load and dumps that energy into the room as heat. A dual-GPU rig at full inference is roughly equivalent to a small space heater running constantly. This is fine in a dedicated office in winter and noticeably terrible in a guest bedroom in July.

The other half is electrical. A standard 15-amp residential circuit at 120V tops out at about 1,500 watts of sustained draw. A serious rig plus its peripherals can come close to that, and tripping the breaker mid-inference is a particular kind of frustrating. The curriculum's hardware section recommends measuring before buying, picking a room with good airflow or a window unit, and (for any rig with two or more high-end GPUs) running it on its own dedicated circuit. None of this is in the spec sheets.

Every frontier API publishes its pricing in dollars per million input tokens and dollars per million output tokens. As of this writing, frontier models range from roughly $0.50/M input + $1.50/M output (cheap, fast models) to $15/M input + $75/M output (the most capable models). Mid-tier and open-weights models hosted by inference providers fall in between.

The asymmetry between input and output pricing is the most important number in the table. Output is expensive because output is generated one token at a time; input is cheap because input is processed in parallel. The practical consequence: you can afford to send a lot of context, and you can't afford to ask for a lot of output. Almost every cost optimization in production LLM systems comes down to that single asymmetry. The curriculum walks through the math in section 7.

CrewAI is the framework the curriculum uses to teach multi-agent orchestration. The model is straightforward: you define a set of agents (each with a role, a goal, and a set of tools they can use), you define the tasks those agents will work on, and CrewAI handles the message-passing, the sequencing, and the result aggregation. A 'crew' is the set of agents and tasks; you run the crew and you get an output.

The reason CrewAI is in the curriculum and not, say, LangGraph or AutoGen, is that CrewAI's mental model is the closest to how a non-engineer naturally thinks about delegation: who's doing what, in what order, and what does the finished work look like. The curriculum's agentic templates (sections 8.7, 8.8, 8.9 covering Gmail and Calendar, customer scheduling, and inventory and reorder) all use CrewAI as the orchestration layer.

CUDA is the software stack that lets code talk to NVIDIA GPUs. Almost every machine learning library (PyTorch, TensorFlow, JAX, vLLM, llama.cpp's GPU paths) was written against CUDA first and other backends second. The result is that NVIDIA hardware works on day one, AMD hardware works after a weekend of fighting with ROCm, and Intel GPU support is mostly aspirational.

This is the technical reason NVIDIA's market cap is what it is. The lock-in isn't the silicon, it's the software ecosystem built on top of it. The curriculum's hardware recommendations are NVIDIA-only not out of brand loyalty but out of practical experience: building a rig with non-NVIDIA hardware is a project unto itself, and most people who try eventually buy an NVIDIA card to make their actual project work.

Cursor takes the VS Code interface and adds AI features at every level of the editing experience: tab-complete that uses an LLM, inline edit prompts, a sidebar agent, and a project-level chat that can read and edit your codebase. The pitch is that you don't switch contexts to use AI; the AI is always one keystroke away from whatever you're doing.

Cursor and Claude Code are the two coding agents the curriculum's audience is most likely to encounter. They occupy slightly different niches: Cursor is best for someone who wants the AI integrated into a familiar editor and prefers to drive the work themselves, while Claude Code is best for someone who wants to delegate larger chunks of work to the agent and review the results in their terminal. The curriculum doesn't insist on one over the other; it does insist that whichever one you pick, you use it with a CLAUDE.md and a verification habit.

Describe what you want to find out and it writes the notebook, executes it, reads the output, and revises. You can go from a raw CSV to a trained model and charts without typing code.

It is genuinely useful for exploratory work, and it is exactly the situation the verification habit exists for. A notebook that runs is not a notebook that is correct: the agent chose a way to handle your missing values, a train/test split, a metric. Those are methodological decisions, and if you cannot say why each one was made, you cannot defend the result.

Most software is, underneath, a small set of nouns with relationships between them. A scheduling app has appointments, customers, and services. A blog has posts, authors, and tags. The data shape is the document where you spell those out: what they're called, what fields they have, what they connect to, and what counts as valid.

This is one of the artifacts the curriculum insists on producing before any prompts get written, because the data shape is the thing that survives every refactor. Your UI will change three times. Your stack will change once. Your deployment story will change. The data shape, if you got it right, will be roughly the same on day 365 as it was on day one. Coding agents work dramatically better when they have a data shape to refer to, because half of the questions they would otherwise ask you are answered by the document.

You give it a research question. It produces a multi-step plan, which you can edit before it runs, then browses hundreds of sources and returns a report with citations, exportable to a document.

The editable plan is the part that matters and the part most people skip. Accepting the default plan means accepting whatever scope the model inferred; editing it lets you narrow the question, exclude noise, and name specific databases. That is the same discipline as reviewing a specification before an agent builds from it. The leverage is upstream of the output, not in it.

A cited report is not a verified report. The citations are real sources, but whether they support the claim attached to them is still your job.

This curriculum has a 5-step core path that gets a person from zero to shipping. It also has roughly fifty other sections covering things like fine-tuning, multi-agent orchestration, post-quantum cryptography in the auth template, and the cost economics of self-hosted inference. Most of those sections are useful eventually but distracting on day one. They're tagged 'deep-dive.'

The convention is borrowed from technical documentation generally and from the Internet Menace v1 curriculum specifically: a deep-dive is permission for the reader to scroll past. If a section helps you ship the thing in front of you, it's core. If it helps you understand why the thing works, it's a deep-dive. Both matter; the order matters more.

A regular function, called twice with the same arguments, returns the same result twice. That's determinism, and it's the assumption every traditional debugging tool, test framework, and mental model is built on. LLMs break the assumption. Call the same model with the same prompt twice and you'll often get two different responses. Sometimes the difference is cosmetic; sometimes the difference is the difference between right and wrong.

The non-determinism comes from sampling: at each step, the model picks the next token from a probability distribution, and unless you set the temperature to zero and pin the seed (and even then, only on some providers) the picks vary. The practical consequence is that you can't test an LLM-driven feature the way you'd test a regular function. You have to think in distributions: not 'does it produce the right answer,' but 'how often does it produce a wrong answer, and how bad is the worst wrong answer.' Most LLM bugs in production are non-determinism bugs that the developer assumed away.

If you have a frontier model that does a task well and a small model that does it poorly, distillation is the bridge. You generate a training set by running the frontier model on a large set of inputs, and then you train the small model on those input-output pairs. The small model learns to imitate the larger one, often closely enough to be useful on the specific task, at a fraction of the inference cost.

Distillation is how production LLM systems get cheap. Build the system with the frontier model, prove it works, distill the high-volume parts down to a small model running on your own hardware. The catch is that the small model only inherits behavior on the input distribution it was distilled on; show it something different and it falls apart. The curriculum covers distillation as a deep-dive in section 7, because it's a real lever but only after you've shipped something worth distilling.

A traditional server lives in one place: a data center somewhere, with the same fixed latency to every user in the world. An edge function lives everywhere: the platform deploys your code to dozens or hundreds of locations, and each user's request hits the nearest one. The latency advantage is real (often 50-200ms saved on the round trip), and for things like authentication, request routing, and lightweight API calls, that's a meaningful chunk of the perceived speed of your site.

The trade-offs are: edge functions can't run for long (typically 30 seconds maximum, often less), they can't hold open connections to a database in the way traditional servers do, and they have a smaller runtime (no full Node.js, often a Workers or Deno-style subset). For LLM-backed apps, the right pattern is usually an edge function for the routing and a traditional server or serverless function for the actual model call. The curriculum covers this in the deployment section.

An embedding model takes a string of text and outputs a fixed-length vector, typically 768 or 1,536 floating-point numbers. The values themselves don't mean anything individually, but the vectors have a useful property: text with similar meaning produces vectors that are close together in the vector space, even if the words are different. 'The cat sat on the mat' and 'A feline was resting on the rug' produce nearby vectors despite sharing almost no words.

This property is what makes RAG possible. You embed every chunk of your document corpus, store the vectors in a vector database, and when a question comes in you embed the question and find the chunks whose vectors are closest. The closeness is a proxy for semantic relevance, and it works well enough that it has become the default architecture for any system that needs to look things up by meaning rather than by exact match. The curriculum covers embeddings in section 6 alongside RAG.

When code needs to know something that depends on where it's running (which database to connect to, which API key to use, whether this is production or a test environment), the answer goes in an environment variable, not in the code. The code reads the variable at startup and behaves accordingly. The same code runs in development, staging, and production, with different environment variable values in each.

The convention everyone follows is to keep a `.env` file in the project root with the local development values, list `.env` in `.gitignore` so it never gets committed, and set the production values in your hosting platform's dashboard (Vercel, Cloudflare, AWS, all support this). The discipline of putting secrets in environment variables instead of source code is one of the small habits that prevents most catastrophic credential leaks. The curriculum's setup sections enforce it from section 3 forward.

An eval is the AI version of a test suite. You assemble a set of inputs you care about (questions a user might ask, tickets your classifier might see, documents your extractor might process), you have someone (you, an annotator, another model) produce the correct output for each one, and you measure how often your system gets it right.

Evals are the difference between 'I think the new prompt is better' and 'the new prompt is right 87% of the time and the old one was right 81%.' Without them, every change to your system is a vibes-based decision, and over time the vibes drift. With them, you can iterate confidently and notice regressions when they happen. The curriculum covers evals in section 7 and treats them as non-optional for any system serving real users. The Aquaman project Shane built for the OpenAI/SCSP hackathon is largely a story about getting eval discipline right.

If you want the model to produce a specific format (a JSON shape, a writing style, a classification scheme), the most reliable way to communicate that is to show the model several examples of correct outputs, then give it the new input. This is few-shot prompting, and it's named in contrast to zero-shot (just the instruction) and one-shot (one example).

Three to five examples is usually the sweet spot. Fewer than that and the model has too little signal to lock onto the pattern; more than that and you're paying for input tokens without much marginal benefit. The technique works because LLMs are pattern-completers: given a prefix that establishes a pattern, they continue it. The curriculum uses few-shot prompting throughout the templates, and the templates themselves are partially a library of well-chosen examples.

Fine-tuning takes an existing model and continues training it on a curated dataset. The result is a new version of the model that has shifted toward the patterns in your data: a particular writing style, a specific output format, a domain vocabulary, a customer service tone. The shift is durable in a way that prompting isn't, because it's encoded in the weights rather than re-established on every request.

The catch, which the curriculum belabors, is that fine-tuning is almost never the right first move. It's expensive (in both time and money), it locks you to a model version, and most of the things people reach for fine-tuning to do can be done better with a good prompt, good few-shot examples, and good RAG. The exceptions are real (high-volume tasks where prompt-based solutions are too expensive, narrow domains where the base model lacks vocabulary, output formats too rigid for prompting), but they're a small fraction of the situations where someone reaches for fine-tuning. Section 7's deep-dive covers when it's worth it and when it isn't.

The term came from a 2021 Stanford paper and stuck. A foundation model is a model trained at large scale on broad data (text, code, images, sometimes audio) with the explicit intent that downstream applications will adapt it. GPT-4, Claude, Gemini, Llama, and Mistral's flagship models are all foundation models. Their defining property is breadth: they're competent at a huge range of tasks out of the box, and they can be specialized further through prompting, fine-tuning, or distillation.

The curriculum mostly says 'frontier model' instead of 'foundation model' because the frontier framing is more useful for builders making decisions about which model to call. But foundation model is the precise term, and it's worth knowing because it shows up in academic papers, vendor documentation, and policy discussions where 'frontier' would feel imprecise.

Fourier neural operators learn mappings between whole functions rather than fixed-size inputs, which makes them very good at approximating physics simulations (weather forecasting, airflow, materials) at a fraction of the cost of classical solvers.

Like CNNs, FNOs appear here as a boundary marker: "AI" is not one thing. An FNO and an LLM share almost nothing except matrix multiplication. When a vendor says "AI-powered," the useful question is which of these families is doing the work, because that determines what the system can and cannot do.

At any given moment, there are perhaps a dozen models that represent the absolute frontier of what LLMs can do: Claude Opus, GPT, Gemini, and a small number of others, with the names changing every few months. These models are large (hundreds of billions to trillions of parameters), expensive to train, and accessed through paid APIs. They are also, by a meaningful margin, the best at hard reasoning, long-context tasks, and structured output.

The curriculum recommends them for any task where correctness matters more than cost: writing specs, generating code, evaluating outputs, and acting as the brain of an agentic system. The trade-off is straightforward: you pay per token, the data leaves your network, and you depend on a third party for uptime. For most projects most of the time, this trade-off is fine. The curriculum is honest about when it isn't.

A Gem is a named configuration you create once and reuse: a set of instructions the model carries into every conversation started from it. A "Stats Assistant" that always reaches for pandas and scikit-learn. A "Thesis Reviewer" that critiques for clarity and citation gaps and does not rewrite your argument.

The concept is not Google-specific. It is a system prompt with a name and a save button, and the same idea appears as a project context file for a terminal agent, or as a custom instruction block in any chat interface. The value is identical in all three: you stop re-explaining your setup, and the model stops drifting back to generic defaults halfway through a session.

Colab runs Jupyter notebooks on Google's hardware, which is why it is the default environment for data science coursework: no local CUDA install, no driver mismatch, a GPU available on the free tier when one is free.

The trap is the one that catches everyone once. The runtime's disk resets between sessions. Anything you did not write to Drive (a trained model, a checkpoint, an output file) is gone when the session ends or times out. Mount Drive and checkpoint to it, every time, for any run longer than a few minutes.

A CPU has a small number of fast cores; a GPU has thousands of slower cores. For the kind of math LLMs do (large matrix multiplications), the GPU's architecture is dramatically better, often by 10x to 100x for a comparable price. This is why every serious AI deployment uses GPUs and why NVIDIA's stock chart looks the way it does.

For local LLM inference, the GPU does two things: it stores the model weights in its dedicated memory (`VRAM`), and it does the math to generate each token. The amount of VRAM determines what models you can load; the GPU's compute speed determines how fast it generates tokens once loaded. The two numbers are independent, and a rig that has enough VRAM to hold a model but not enough compute to run it usably is a common and frustrating place to land. The curriculum's hardware section walks through both numbers.

Where REST exposes a fixed set of endpoints that each return a fixed shape, GraphQL exposes a single endpoint where the client describes the data it wants and gets exactly that. The pitch is that it eliminates over-fetching and under-fetching: if you need three fields from a user and one field from each of their five posts, you ask for that, and the server returns that, in one request.

GraphQL is overkill for most projects the curriculum's audience will build. It earns its complexity when you have many client applications hitting the same backend, when the data graph is genuinely deep, or when you have a team of frontend developers who'd benefit from the type system. Section 8.6 (the API skeleton template) covers when to reach for GraphQL and when REST is the better answer; the short version is 'REST until proven otherwise.'

An ungrounded model output is a model output that comes out of the weights with no specific source. It might be right; it might be a hallucination. A grounded model output cites the chunk of retrieved text or the section of the document or the row in the database that supports the claim. With grounding, you can check the work; without it, you have to trust the model.

Grounding is especially important for any system where wrong answers have consequences (legal research, medical information, financial summaries, regulatory work). The technical implementation is straightforward: include source identifiers with the retrieved context, instruct the model to cite them in its output, and validate that the citations are real. The harder part is operational: training the people using the system to actually check the citations. The curriculum's RAG section treats grounding as the default, not an upgrade.

An LLM by itself will do whatever it gets convinced to do. An agent built on an LLM, without guardrails, will do whatever it gets convinced to do at scale, repeatedly, with access to tools. Guardrails are the engineering layer that prevents this. They include input validation (rejecting prompts that are obviously trying to manipulate the agent), output validation (checking that the agent's actions are within the allowed set), tool allowlists (the agent can only call tools you've explicitly registered), and policy checks (some classes of action require additional approval).

Guardrails are not a one-time setup; they're a habit. Every new tool the agent gets, every new input source, every new use case introduces new ways the system can go wrong. The curriculum's templates ship with conservative guardrails by default and explicit guidance on which to relax for which use cases. The cost of overly tight guardrails is friction; the cost of insufficient guardrails is the kind of incident that makes the news. The trade-off slope favors caution.

An LLM doesn't know what's true. It knows what's likely. When the likely continuation of a prompt is a true statement, the model says something true; when the likely continuation is a plausible-sounding false statement, the model says that instead, with the same confidence. The false outputs are called hallucinations, and they are not an aberration; they are a direct consequence of how the model generates text.

Hallucinations cluster in predictable places: specific facts the model wasn't trained on, citations and URLs (the model has seen the format and will produce one whether or not the source exists), numbers in domains where it lacks ground truth, and any question phrased in a way that implies a confident answer is expected. The mitigations are mechanical: retrieve real source material via RAG, validate any factual claim against an authoritative source, ask the model to express uncertainty, and never trust a citation without checking it. The curriculum's verification habit is largely a habit of hallucination defense.

The home lab community predates the LLM moment by a couple of decades; it's people running their own servers for fun, learning, and the occasional practical reason. The LLM era added a new use case: running models locally, away from API costs and data egress. A modern home lab might include a NAS for storage, a small server for self-hosted apps (Home Assistant, Jellyfin, a personal RAG over your notes), and an inference box with a GPU or two for running local models.

The curriculum doesn't require a home lab and doesn't push readers toward one early. But for a certain kind of reader (the hobbyist path especially), a home lab is the natural place this curriculum's ideas land. The hardware section covers the build-out as a deep-dive, with honest accounting of what it costs, what it gets you, and which production needs are still better served by paid APIs.

An agent that can send emails, charge credit cards, delete records, or push code to production has a failure mode where an early-stage mistake compounds into a real-world consequence. Human in the loop is the architectural answer: the agent prepares the action, presents it to a human, and only executes after explicit approval. The human is the brake on the agent's autonomy.

The trade-off is throughput. Every approval step is friction, and a system with too many approval steps is just a slower way to do the work manually. The art is identifying which actions genuinely warrant a human checkpoint and which don't. The curriculum's templates use human-in-the-loop liberally for first builds (every email gets reviewed before sending, every calendar invite gets approved before going out), with explicit guidance on which steps to relax once the builder trusts the system. Trust is earned by watching, not assumed.

Pure vector search finds semantically similar content but misses exact-match queries: a user searching for a specific product code, error message, or proper noun gets the closest semantic match, which may not be the right one. Pure keyword search finds exact matches but misses paraphrases. Hybrid search runs both and combines the results, typically by scoring each candidate on both dimensions and re-ranking.

For most production RAG systems, hybrid search is meaningfully better than either approach alone. The implementation isn't hard (most vector databases support it directly, and tools like Pagefind handle it for static sites), but tuning the weights between the two scores is one of those decisions that depends on your corpus and your query patterns. The curriculum walks through hybrid search in the RAG section, alongside the discussion of reranking.

Sending an email twice sends two emails. Charging a credit card twice charges twice. These operations are not idempotent, and any agentic system that might retry them (because of a network blip, because the agent isn't sure if the previous call succeeded, because a user clicked the button twice) has to handle the duplication explicitly. The standard pattern is the idempotency key: a unique identifier the client generates, the server records, and the server uses to deduplicate retries.

For agents, idempotency is the difference between a retry making things right and a retry making things much worse. The curriculum's templates with side-effecting tools (email, calendar, payments, database writes) build idempotency into the action layer rather than asking the agent to handle it. The agent can be wrong about whether a call succeeded; the action layer can't be.

Training an LLM is the expensive, one-time event where the model learns from text. Inference is the cheap, ongoing event where you use the trained model to produce something. From a builder's perspective, training is somebody else's problem; inference is the only thing you ever pay for or wait on.

The economics matter because inference is metered per token in two directions: input tokens (what you send) and output tokens (what the model produces). Output tokens are typically four to five times more expensive than input tokens on frontier APIs, which is why prompt caching, structured outputs, and short response formats all save real money at scale. The latency story is similar: output tokens stream one at a time, so a 2,000-token response is roughly twice as slow as a 1,000-token one. Build accordingly.

LangChain was the first widely-adopted framework for building LLM applications and remains one of the most-installed. It provides building blocks for the patterns you end up needing (loading documents, chunking them, embedding them, retrieving them, threading retrieved context into prompts, parsing structured output) and integrations with most providers and databases.

LangChain has a polarized reputation. Fans appreciate the breadth of integrations and the speed of getting a prototype running. Critics find the abstractions leaky, the documentation drift painful, and the framework's API churn frustrating in production. The curriculum's position is pragmatic: LangChain is fine for prototypes and for projects where its integrations save real time, and worth replacing with direct API calls for production systems where the abstractions become a liability. CrewAI, which sits one layer up for multi-agent work, is the framework the curriculum spends more time on.

Where a LangChain agent runs a single loop and decides what to do next at each step, LangGraph asks you to define the workflow as a graph: nodes are operations, edges are transitions, and the runtime walks the graph based on the state. This makes the control flow visible, debuggable, and easier to reason about, at the cost of having to think harder about the structure up front.

LangGraph is the right tool when your agentic system has known phases (intake, classification, drafting, review, send) and you want each phase to be a separate, testable unit. It's overkill when the system is genuinely open-ended. The curriculum mentions LangGraph as an alternative to CrewAI for builders with a software engineering background; for the primary curriculum audience, CrewAI's mental model is simpler to start with.

Latency is what makes a chatbot feel snappy or laggy, what makes an autocomplete useful or annoying, and what makes an agent feel like it's working or hung. For LLM apps, latency has two parts: time to first token (how long before the user sees anything) and tokens per second (how fast the response streams once started). The first matters more for short responses; the second matters more for long ones.

Frontier API latency is mostly out of your control; you can pick a faster model, but you can't make a given model faster. Local model latency is largely a function of your hardware: GPU memory bandwidth, batch size, and quantization all move the number. Architectural latency (cold starts, network round trips, sequential tool calls) is the part you actually control, and it's usually where the worst bottlenecks are. The curriculum covers latency in section 7 with concrete numbers.

llama.cpp started as a single-developer project to run Llama models on a MacBook and grew into the foundation of most consumer-grade local LLM tooling. Ollama is built on top of it. LM Studio uses it. A lot of the GGUF quantized models you'll find on Hugging Face exist because llama.cpp's format made them easy to distribute and run.

For most curriculum readers, llama.cpp is invisible: you use Ollama, which uses llama.cpp under the hood, and you never touch the C++ code. For readers who want maximum performance on a specific machine, working with llama.cpp directly is worth the additional setup. The curriculum points at it as a deep-dive in the hardware section, alongside the comparison with vLLM (which is the right answer for production-scale serving but not for a single user's laptop).

An LLM is a particular kind of neural network (a transformer) trained on an enormous quantity of text (trillions of tokens) to do one specific task (predict the next token given a sequence of previous tokens). That single capability, scaled up, produces models that can write essays, generate code, answer questions, summarize documents, and follow instructions, none of which they were explicitly trained to do.

The 'large' in the name is doing real work. Smaller language models existed for years before GPT-3 and were not particularly impressive; the qualitative jump came with scale, both in parameter count (billions to trillions) and training data (web text, books, code, scientific papers). Whether the next jump comes from continued scaling or from architectural changes is one of the live debates in the field. For builders, the answer mostly doesn't matter; what matters is the capability available right now, and that capability is enough to build with.

A local model is any LLM where the weights live on your machine and the inference happens on your hardware. The runtime is usually Ollama (easiest), llama.cpp (most flexible), or vLLM (fastest at scale). The hardware ranges from a Mac mini with 16GB of unified memory at the low end to a multi-GPU rig at the high end.

The reasons to run local: cost goes to zero past the hardware investment, no data leaves your network, and you can run things at a volume that would be uneconomic to do via API. The reasons not to: local models, even good ones, are still meaningfully behind the frontier on hard reasoning, the setup is non-trivial, and the hardware costs real money up front. The curriculum's recommendation is pragmatic: use frontier APIs to learn and to ship, evaluate local for production workloads where the volume justifies the build-out.

Apple Silicon Macs have a property no other consumer hardware has: the CPU and GPU share memory. A Mac with 64GB of unified memory can load a model that would require 64GB of dedicated VRAM on a PC, at a fraction of the price and power draw. The performance per dollar for inference on M2 Ultra and M3 Max chips is, at the time of writing, the best in the consumer market for a single-user use case.

The trade-offs are real. Apple Silicon's compute is meaningfully slower than a top-end NVIDIA GPU, so tokens-per-second is lower. The CUDA ecosystem doesn't run on Mac, so any tool that hasn't been ported to Metal Performance Shaders is unavailable. And the upgrade path is non-existent; the memory is soldered in. But for a curriculum reader who wants a quiet, low-power, no-fuss local inference setup, a Mac mini or Mac Studio with maxed-out memory is one of the cleanest answers available.

Before MCP, every coding agent and every chat client had its own proprietary way of integrating tools. If you wanted Claude to read your Notion, GitHub, and calendar, you wired up three different integrations, each with its own quirks. MCP is the standardized protocol that replaces that mess: an MCP server exposes tools and resources in a defined format, and any MCP-aware client (Claude Code, Cursor, the Claude desktop app, others) can connect to it.

The practical consequence is that the agent ecosystem is rapidly growing a shared library of integrations. Most major SaaS products now have an MCP server (official or community-built), and the catalog grows weekly. For curriculum readers building agents, MCP is the right answer for tool integration whenever a server already exists; writing a custom MCP server for a custom tool is a deep-dive in the agentic templates section.

An LLM, by itself, has no memory beyond its context window. Anything the agent should remember has to be either kept in the context window (short-term) or stored externally and retrieved when needed (long-term). The choice of how to handle this is one of the bigger architectural decisions in any agentic system.

Short-term memory is usually some form of conversation summary or running state object that gets included in every prompt. It's bounded by the context window and tends to drift as the conversation grows. Long-term memory is usually a database or vector store of facts the agent has been told or has observed, retrieved on demand the same way RAG retrieves documents. Most production systems combine both: short-term for the current session, long-term for facts that persist across sessions. The curriculum's agentic templates use a simple JSON state file for short-term memory and SQLite or Postgres for long-term, which covers most of what a small project needs.

A traditional dense LLM uses all of its parameters on every token. A mixture-of-experts model has the parameters split into many specialized sub-networks ('experts'), and a routing layer picks which two or four experts handle each token. The total parameter count can be enormous (Mixtral 8x22B has about 140 billion parameters), but the active parameters per token are much smaller (about 39 billion for Mixtral 8x22B), so inference cost is closer to a smaller model.

Several frontier models (Mixtral, DeepSeek-V3, GPT-4 reportedly) use MoE architectures. For builders, the practical implication is that a model labeled '8x7B' or 'A22B-out-of-180B' is faster and cheaper than its total-parameter count suggests. The trade-off is that MoE models can be harder to fine-tune and harder to serve at low batch sizes. The curriculum mentions MoE primarily for context: it's the architecture behind some of the open-weights models worth running locally.

Every responsibly-released model ships with a model card. It's typically a Markdown document or a section of a paper that covers what the model is, how it was trained, what it's supposed to be good at, what it's known to be bad at, and what failure modes the developers have observed. Anthropic, OpenAI, Google, and Meta all publish model cards; the quality varies, but the format is consistent.

For builders, model cards are the place to look when picking a model. They tell you the context window, the price (sometimes), the training cutoff, the safety tuning approach, and the official intended-use boundaries. They will not tell you whether the model is good for your specific task; only your evals can tell you that. The curriculum's section on picking models walks through reading a model card alongside running quick evals, because the two together give you most of what you need to choose.

The practical use is comparison. Running the same prompt or the same fine-tuning task across several models, from the same place, tells you more about which one fits your problem than any benchmark table will.

It also lowers the cost of deploying a fine-tuned model for a demo (a thesis defence, a poster session) without standing up serving infrastructure yourself. Read each model's card before you build on it: licence terms vary, and "available in the catalogue" is not the same as "licensed for what you intend to do with it."

A trained neural network is, ultimately, a very large set of floating-point numbers organized into matrices. Those numbers are the weights, and they're what the model 'knows.' When you download a model from Hugging Face or pull it via Ollama, you're downloading the weights, formatted in some specific way (safetensors, GGUF, GPTQ, others).

The size of the weights is determined by the parameter count and the precision: a 7B-parameter model at 16-bit precision is about 14 gigabytes; the same model quantized to 4-bit precision is about 4 gigabytes, with some quality loss. This is why quantization matters for local inference: it directly determines whether a given model fits on your hardware. The curriculum's hardware section has a table mapping model size and quantization to VRAM requirements, because that's the question every local-inference build starts with.

A single agent given a complex task often produces mediocre results: it tries to be a researcher, a writer, and a critic in the same context, and the roles bleed together. A multi-agent system splits the work. One agent does the research, another drafts, a third critiques, and the orchestration layer routes the output. Each agent can be tuned for its specific role (different prompts, different models, different tool access), and the resulting system often produces better work than any single agent could.

The trade-offs are cost (every agent step is a separate inference call) and complexity (orchestration adds failure modes). The curriculum recommends multi-agent architectures for tasks where the sub-roles are genuinely distinct and a single agent has been observed to struggle with the role-switching. For simpler tasks, a single agent with a good prompt is the better choice. CrewAI is the framework the curriculum's templates use; the architectural pattern translates to other frameworks as well.

The first generation of LLMs was text in, text out. The current generation accepts images alongside text (you can paste a screenshot, a photo, a chart) and increasingly accepts audio. A subset can produce images or audio as output, though those capabilities are usually behind separate models or modes.

For builders, multimodality opens up tasks that text-only models couldn't handle: extracting data from receipts and invoices, describing the contents of a photo, answering questions about a chart, transcribing and summarizing a meeting recording. The curriculum's LeaseDok project is largely a multimodal application: lease PDFs go in, structured data comes out, with the model reading the rendered images of the pages because OCR alone wasn't reliable enough. Section 8 covers multimodal patterns where they're the right answer.

The constraint is the feature: NotebookLM answers from your uploaded sources and nothing else. It cannot invent a citation, because it can only point at documents you gave it.

That eliminates one failure mode and leaves another intact. It will not fabricate a reference, but it can still misread a source, overstate what a paper concluded, or miss a contradiction between two of them. Grounding narrows where answers come from; it does not make them correct.

For a literature review this is the right tool for the middle stage (after you have gathered sources, before you draft), with a general model doing the synthesis afterward.

The DGX Spark is NVIDIA's small-form-factor inference workstation: roughly Mac-mini-sized, 128GB of unified memory, sold for around $4,000 at launch. The unified memory architecture means the model weights and the working memory share the same pool, which lets a single Spark hold a 70-billion-parameter model in 4-bit quantization with room to spare.

The curriculum mentions it because it's representative of a new hardware category: AI-first desktops aimed at developers and small teams who want serious inference capacity without renting cloud GPUs. Two Sparks running vLLM with Gemma models is the rig Shane uses for the Dynamo and BMD private inference work. For most curriculum readers, a Mac Studio or a single-GPU PC is the better starting point; the Spark earns its keep at the next tier up.

Ollama is to local LLMs what Docker was to deployment: it took a thing that was technically possible but operationally annoying and made it a single command. `ollama run llama3` downloads the weights, sets up the runtime, and gives you a chat interface in about 90 seconds. `ollama serve` exposes an OpenAI-compatible API on localhost, which means anything that talks to OpenAI's API can talk to Ollama with one URL change.

The curriculum uses Ollama as the default local runtime because it's the lowest-friction way for someone with a Mac mini and an internet connection to start running their own models. It is not the fastest runtime (vLLM and llama.cpp both beat it for production workloads), but for learning and for low-volume personal tools, the speed is fine and the convenience is decisive.

Open WebUI is a self-hostable web app that connects to Ollama, vLLM, OpenAI-compatible APIs, or any combination. You point it at your inference backends and you get a chat interface with conversation history, model switching, system prompts, document attachments, and an admin panel. For a single-user home lab or a small team's private deployment, it's the cleanest answer to the question 'how do non-technical people in my house or company actually use the local model.'

The curriculum mentions Open WebUI because it's the front end of the self-hosted AI infrastructure pattern Shane uses: vLLM serving Gemma on the Spark nodes, Open WebUI as the user-facing layer, and a RAG pipeline indexing whatever document corpus the user wants searchable. The hardware section walks through the deployment as a deep-dive.

Meta's Llama models, Mistral's open releases, Google's Gemma, DeepSeek's models, and Qwen are all open-weights. The lab that trained them has released the actual numerical parameters, and you can download them, run them locally, fine-tune them on your own data, and (depending on the license) use them commercially. The lab still controls the training process and the future versions, but the released artifact is yours.

The trade-off versus closed-weights frontier models is the central economic question for many production AI systems. Open-weights models are typically a generation behind the frontier on capability but can be run on hardware you control, at zero per-token cost past the infrastructure investment, with no data leaving your network. The curriculum's pragmatic position is that most projects benefit from a mix: closed-weights for the cognitively hard work, open-weights for the high-volume work, picked deliberately rather than ideologically.

Claude Code is Anthropic's coding agent CLI. OpenClaude is a separate community project that took the same workflow patterns and made them work with whatever model you want behind them. It reads CLAUDE.md natively, supports MCP, runs the same /clear and /compact commands, and interacts with your codebase in roughly the same way Claude Code does. The difference is what's making the decisions: Claude, GPT, Gemini, a local Ollama instance, whatever you point it at via OpenAI-compatible APIs.

The reason OpenClaude matters for the curriculum is that it makes the discipline portable. Sections 2.6 and 6.5 both lean on the idea that the patterns of agentic coding (CLAUDE.md, the four-phase loop, session management, the prompt patterns) are not Anthropic-specific; they're how this kind of work goes regardless of the model. OpenClaude is the demonstration of that claim. A reader running a 70B local model on a Spark in their closet (Part 4) gets the same workflow as a reader paying $200/month for Claude Max.

OpenClaude is not affiliated with Anthropic. It is an independent open-source project; the repository is at https://github.com/Gitlawb/openclaude. The curriculum covers OpenClaude in section 3.2 alongside the other coding-agent options and references it again in section 2.6 as the bridge for non-Anthropic models.

A 7B model has 7 billion parameters. A 70B model has 70 billion. The number is a rough proxy for model capability (more parameters typically means more capable, with a lot of caveats), and it's the primary determinant of how much memory the model needs to run.

Parameter count is not the only thing that matters. Architecture (dense vs MoE), training data quality, and post-training (RLHF, fine-tuning) all move performance independently of size. A well-trained 7B model can outperform a poorly-trained 30B model on specific tasks. But for a quick read on what you're dealing with, the parameter count is the first number to look at, and the second is the quantization, because together they tell you whether the model fits on your hardware.

pgvector adds a vector column type plus nearest-neighbor search operators and indexes (HNSW, IVFFlat) to PostgreSQL. Your embeddings live in the same database as the rest of your data, in the same transactions, behind the same backups.

For most projects in this curriculum's range, "a Postgres database with pgvector attached" beats running a dedicated vector database: one fewer service, one billing relationship, and joins between your vectors and your actual data. Reach for a dedicated vector store only when scale genuinely demands it.

Postgres is the boring, correct answer for nearly any project that needs a relational database. It's been in active development for thirty years, it's free, it runs everywhere, it has world-class documentation, and it's been battle-tested at scales most projects will never reach. Almost every backend framework integrates with it cleanly, and almost every cloud platform offers a managed version (AWS RDS, Supabase, Neon, Render, Fly).

The curriculum defaults to Postgres for any template that needs persistent structured data: LeaseDok, the dashboard template, the API skeleton, the agentic templates' long-term memory layer. It also defaults to managed Postgres rather than self-hosted, because operating a database is a real job and managed services are cheap relative to the time they save. SQLite shows up for projects small enough that a single file is appropriate; Postgres shows up everywhere else.

Casual usage treats 'prompt' as 'the thing the user typed.' Technical usage treats it as the entire input the model receives, which includes the system prompt, any conversation history, any retrieved context (RAG), any few-shot examples, and the user's current message. The whole assembled blob is what the model is responding to, and the user's typed text is often the smallest part of it.

This distinction matters because most prompt-engineering work happens on the parts of the prompt the user never sees. The system prompt sets the role and rules; few-shot examples shape the format; retrieved context provides the facts; the user's message is the trigger. The curriculum spends most of section 4 on this assembly, because the difference between a good and bad LLM application is rarely the user-typed text and almost always everything else.

When you've made changes on a branch and want to merge them into main, the convention is to open a pull request (PR on GitHub, merge request on GitLab). The PR shows the diff, supports comments and review, runs your CI checks, and gates the merge until everything passes. For team work, this is how code review happens. For solo work with a coding agent, this is how you maintain a habit of looking at every change before it lands.

The curriculum recommends PRs even for solo projects, because the alternative (committing directly to main) loses the review step entirely, and reviewing your own diff is one of the cheapest ways to catch problems an agent introduced. GitHub's UI for reviewing PRs is genuinely good; using it on every change is a small habit with disproportionate payoff.

A model trained at 16-bit precision uses two bytes per parameter. Quantizing to 8-bit halves the memory footprint at minimal quality loss; quantizing to 4-bit halves it again, with quality loss that ranges from imperceptible to noticeable depending on the model and the task. For local inference, quantization is what makes serious models fit on consumer hardware: a 70B model at 16-bit precision needs 140GB of memory; at 4-bit it needs 35GB, which is approachable.

The trade-off is that not all quantization is created equal. GGUF, GPTQ, AWQ, and others use different techniques and produce different quality-versus-size curves. The curriculum's hardware section walks through which quantization to pick for which model and which use case, with the general rule that 4-bit is fine for most things, 8-bit for tasks where quality matters more than speed, and full precision only for fine-tuning or research.

RAG solves a specific problem: LLMs can't read your private documents, your customer database, or last week's meeting notes, because none of that was in their training data. RAG is the workaround. You take the user's question, search a body of text for the passages most likely to be relevant, paste those passages into the prompt, and then ask the model to answer using that context.

The pieces are: an embedding model that turns text into numerical vectors, a vector database that stores those vectors and supports similarity search, a chunking strategy that decides how to split your source documents, and the prompt construction that assembles the retrieved context into something the model can use. Each of those pieces has a hundred decisions in it, and the quality of a RAG system is mostly determined by how well those decisions are made, not by which model is doing the generation.

The curriculum covers RAG in section 6, with a working example that indexes a markdown knowledge base and answers questions against it. The most important thing the section says is that RAG is harder than it looks, and that bad RAG is worse than no RAG. Most failures are at the chunking and retrieval stages, not the model.

Every API rate-limits you. The limits are usually expressed in requests per minute, tokens per minute, or both, and they vary by tier (free tier limits are stingy; paid tiers loosen as you spend more). When you hit the limit, the API returns a 429 status code and the request fails until the window resets.

For an interactive chatbot or coding agent, rate limits rarely bite because the human in the loop slows things down. For a batch job or an autonomous agent making many parallel calls, they bite immediately. The standard mitigations are: respect the rate limit headers the API returns (most APIs tell you how many requests you have left and when the window resets), implement exponential backoff on 429 responses, and request a higher tier or rate-limit increase if your project genuinely needs it. The curriculum covers rate-limit handling in the API integration sections.

ReAct stands for Reasoning + Acting, and the pattern is exactly what the name suggests: the agent produces a 'Thought' explaining what it plans to do, an 'Action' specifying which tool to call with what arguments, and an 'Observation' capturing the tool's result. Then the cycle repeats. The thoughts are visible to the user, which makes the agent's reasoning auditable, and the structure makes the control flow predictable.

ReAct came out of a 2022 paper and shaped most of the early agent frameworks. Modern agentic systems often use variations or extensions (function calling instead of text-format tool calls, structured outputs instead of free-form thoughts), but the underlying pattern of interleaved reasoning and action is still the dominant model. The curriculum touches on ReAct as background; the templates use modern function-calling APIs that hide the ReAct mechanics behind a cleaner interface.

OpenAI's o1 and o3, Anthropic's Claude with extended thinking, DeepSeek's R1, and Google's Gemini Deep Think are all reasoning models. They share an architectural pattern: before producing a visible response, the model produces an internal chain of thought, sometimes thousands of tokens long, where it works through the problem. The user sees only the final answer (or, increasingly, a summarized version of the thinking).

Reasoning models cost more per request because the thinking tokens are real tokens you pay for, and they're slower because those tokens have to be generated before the visible response begins. In exchange, they're substantially better on hard problems: math competitions, logic puzzles, multi-step coding tasks, and any question where the right answer requires considering several alternatives. The curriculum covers when to reach for a reasoning model and when a regular frontier model is the better cost-to-quality choice.

A repo is a directory of code plus its full version history. Git tracks every change, who made it, and when. The repo lives both on your machine (where you work) and on a hosting service like GitHub or GitLab (where it's backed up and shared). Cloning a repo gives you the entire history; pushing sends your local changes back up.

For curriculum readers, the most important habits around repos are: every project gets one (even tiny ones), private repos are free on GitHub so privacy is no excuse for skipping git, and `.gitignore` exists for a reason (use it for `.env` files, build outputs, and anything else that shouldn't be tracked). Section 3 of the curriculum covers the setup; from section 4 forward, every template assumes a repo exists.

First-pass retrieval (vector search, keyword search, or hybrid) is fast but rough. It returns the top 50 or 100 candidates that look relevant, but the ordering within that set is often noisy. A reranker takes those candidates and runs a more expensive model on each one (a cross-encoder, or an LLM with a reranking prompt) to produce a higher-quality ordering. The top 5 or 10 from the reranked list go into the final prompt.

Reranking adds latency and cost, and for many simple RAG systems it's not worth it. It earns its keep when the corpus is large, the questions are complex, or the cost of a wrong answer is high. Cohere's reranker, Anthropic and OpenAI as rerankers via prompt, and several open-source cross-encoders are all viable choices. The curriculum covers reranking as a deep-dive in the RAG section, after the basics are working.

After a foundation model is pretrained on text, it's typically capable but undirected: it can complete sentences in lots of styles, including unhelpful or harmful ones. RLHF is the technique that shapes it into something usable. Humans (or, increasingly, other AIs) compare pairs of model outputs and pick the better one. Those preferences train a reward model, and the original model is fine-tuned via reinforcement learning to produce outputs the reward model rates highly.

RLHF is the reason ChatGPT was a usable product and earlier GPT-3 was not. It's also the source of a lot of the model behaviors people complain about (over-refusal, excessive hedging, formulaic responses) because the human raters' preferences shape those behaviors directly. For builders, RLHF is mostly invisible (you use the post-RLHF model the lab ships), but understanding that it happened explains why models behave the way they do. The curriculum covers RLHF as background in section 7.

Self-hosting means you operate the thing yourself. You install it, you update it, you handle the storage and the networking and the backups, and the data never leaves your network. For a database, a chat platform, or a knowledge base, self-hosting is a long-standing tradition. For LLMs, it's a newer option that has become viable as open-weights models and consumer hardware caught up.

The trade-off versus a managed service is the standard one: more control and (eventually) lower per-use cost in exchange for more setup and operational responsibility. The curriculum's recommendation is to use managed services until the volume, the data sensitivity, or the unit economics specifically argue for self-hosting. For a curriculum reader's first project, an API key is almost always the right answer; for a curriculum reader who has shipped three projects and knows what they actually need, self-hosting is worth evaluating.

In a traditional deployment, you rent a server, your code runs on it continuously, and you pay whether or not requests are coming in. In a serverless deployment, you upload functions, the platform runs them on demand, and you pay only for the time they were actually executing. AWS Lambda introduced the model; Vercel, Cloudflare Workers, Netlify Functions, and Google Cloud Functions all offer their own versions.

Serverless is great for variable workloads (APIs that get bursty traffic, scheduled jobs, webhooks) and bad for workloads that need long-lived connections, large local state, or sub-100ms cold-start latency. For LLM apps, the right pattern is usually a serverless function for the request handling and a separate, longer-lived service for things like vector databases or in-memory caches. The curriculum covers the trade-offs in the deployment section.

Where an LLM might have 70 to 700 billion parameters, an SLM has 1 to 10 billion. Phi-3, Gemma 2B, Llama 3.2 1B and 3B, Qwen 2.5 0.5B and 1.5B are all SLMs. Their headline capabilities are well below frontier models, but on narrow, well-defined tasks (classification, extraction, simple drafting, function calling with a clear schema), they often work fine.

The case for SLMs is economic. A model that runs on a CPU or an entry-level GPU has zero per-call cost past the hardware. A high-volume task that gets routed to an SLM instead of a frontier API is the single biggest cost lever in production LLM systems, and the quality cost is often acceptable if the task is constrained well. The curriculum's section on cost optimization treats SLMs as a serious option for any task that has been spec'd tightly enough to evaluate against an SLM's capability.

A spec is the document you would hand to a competent developer to build the thing without further questions. In the curriculum, 'the thing' is small (a feature, a page, an automation) and the developer is a coding agent, but the discipline is the same as it has always been: if you can't say what the software should do clearly enough that someone else could build it, you don't yet know what you want.

The distinction between a spec and a prompt is the thing the curriculum spends the most time on. A prompt is a request you make to a model in the moment. A spec is a document you write down, save in your repo, and refer to repeatedly. Prompts are disposable; specs are durable. Vibe coding is what happens when you only ever write prompts. Spec-driven development is what happens when you write the spec first and let the prompts derive from it.

The curriculum's PRD template (section 8.1) and feature spec template (section 8.2) are the two specs every project should start with. Everything else can be improvised. These two cannot.

You rent spare capacity at a steep discount and accept that it can be taken back with little warning. For long training runs this is the difference between affordable and not.

It only works if your job can survive being killed. Checkpoint frequently to persistent storage, and make the run resumable from the last checkpoint rather than the start. A twelve-hour training job on a spot instance without checkpointing is not cheap compute; it is a coin flip you will eventually lose.

SQLite is, by some measures, the most widely deployed software in history. It's in every iOS and Android app, every Mac, most Linux distributions, every web browser. The reason is that it does one thing well: provide a real SQL database with no server, no configuration, and no operational overhead, all stored in a single file you can copy or back up like any other file.

For curriculum projects, SQLite is the right answer for any data store that fits comfortably on one machine and doesn't need many simultaneous writers. Personal tools, single-user agents, small APIs, and prototypes can all run on SQLite forever. When the project grows past those constraints, migrating to PostgreSQL is straightforward because the SQL dialects are similar. The curriculum reaches for SQLite first and switches to Postgres only when the requirements explicitly need it.

Free-form model output is fine for chatbots and bad for everything else. If your application needs to take a model's output and pass it to another function, store it in a database, or use it as input to a tool, you need that output in a specific shape. Structured output is the answer: you provide a schema (usually JSON Schema), the model produces output that matches it, and you can parse the result reliably.

All major frontier APIs support structured output natively, often with strict guarantees that the output will validate against the schema. For local models, the same effect can be achieved with constrained decoding libraries (Outlines, Guidance, Instructor) that filter the model's token-by-token generation to only allow valid continuations. The curriculum uses structured output in nearly every template that does anything beyond chat, because it's the thing that turns 'the model said something' into 'the system can act on what the model said.'

Supabase is what you reach for when you want a Postgres database plus the things you almost always need around a Postgres database: user authentication, file storage, row-level security, real-time updates, and an auto-generated API. Their pitch is that they're an open-source alternative to Firebase, with the substantive difference that the underlying database is a real, portable Postgres rather than a proprietary document store.

For curriculum projects, Supabase is a strong default for anything that needs a database plus authentication. The free tier is generous, the documentation is good, and the dashboards are polished. The lock-in is meaningful but graceful: because the database is Postgres, you can migrate off Supabase to any Postgres provider with the data layer mostly intact. The auth and storage layers would need rebuilding, but the data itself is portable. The curriculum covers Supabase alongside the other managed-Postgres options in the deployment section.

Every LLM application starts the conversation with a system prompt: a block of text that tells the model what it is, what it's doing, what tone to use, what to refuse, what tools it has, and what format to produce. The user's message follows. The model sees both, and the system prompt's instructions take precedence.

System prompts are where most application-level behavior lives. The same model, with two different system prompts, is two different products. A good system prompt is specific (it spells out the role and the constraints), grounded (it references the available tools and data), and disciplined (it doesn't try to override the model's safety training, which usually backfires). The curriculum covers system prompt construction in section 4, with examples of well-written and badly-written prompts and the differences in resulting behavior.

Latency is how fast a single request feels. Throughput is how many requests you can handle in aggregate. The two are related but distinct: a system can have low latency per request and low throughput (slow but only one at a time) or high latency and high throughput (each request is slow, but many run in parallel).

For LLM systems, throughput matters in two places. For local inference, it's the question of how many users your hardware can serve simultaneously, which is largely determined by GPU memory, batch size, and the inference engine (vLLM is throughput-optimized; llama.cpp is single-user-optimized). For API consumers, it's a question of rate limits and concurrent connection limits set by the provider. The curriculum's hardware section walks through throughput-versus-latency trade-offs for the home-built rig case.

A token is what the model actually sees. The English word 'tokenization' is one token. The word 'antidisestablishmentarianism' is six. A single Chinese character is often two. Punctuation, whitespace, and emoji all count. The exact tokenization varies by model (OpenAI's tiktoken, Anthropic's tokenizer, and Llama's tokenizer all chunk text slightly differently), but the rough ratio for English prose is one token per 0.75 words, or 100 tokens per 75 words.

This unit matters because everything is denominated in it. Context windows are sized in tokens. API pricing is per million tokens. Latency is roughly linear in output tokens. When the curriculum says 'send less context' or 'ask for a shorter response,' what it actually means is 'use fewer tokens,' and the savings are real. A reflexive habit of counting tokens before you send them is one of the cheapest engineering wins available.

Frontier APIs separate the bill into two columns: dollars per million input tokens (what you sent the model) and dollars per million output tokens (what the model produced). The asymmetry between them is the most consequential number in any LLM cost calculation. As of writing, output tokens cost roughly 4x to 5x what input tokens cost on most major APIs.

The reason is technical. Input tokens are processed in parallel; output tokens are generated one at a time, each conditioned on the previous ones. The cost of generating an output token is roughly proportional to the work done; the cost of processing an input token is much lower because of the parallelism. The practical consequence: optimization work pays off most when it reduces output. Asking for shorter responses, using structured output to skip preamble, and keeping responses focused all save real money. Sending more context, by contrast, is comparatively cheap. The curriculum's economics section makes this concrete with worked examples.

Plain text generation lets a model say 'you should send an email to Bob.' Tool use lets the model say 'call send_email with to=bob@example.com and subject=...,' in a structured format your code can actually act on. The function call comes back to the model as an observation, the model produces the next action, and the cycle continues. This is the foundational mechanism of every agentic system.

All major frontier APIs support tool use natively, with the same basic shape: you describe the available tools (name, description, JSON schema for arguments), the model picks one and produces structured arguments, your code executes it, and you feed the result back. Local models support tool use through structured output techniques and through models specifically fine-tuned for it (Qwen 2.5, Llama 3.x, Mistral's models). The curriculum covers tool use throughout sections 5 and 8, because every agentic template depends on it.

A traditional database finds rows that match a condition exactly: WHERE name = 'Bob.' A vector database finds rows that are close to a query vector in some high-dimensional space, ranked by similarity. The query is itself a vector (typically the embedding of some text), and the answer is the top-K closest rows, where 'closest' is computed by cosine similarity or Euclidean distance.

For RAG, this is the storage layer. You embed your document chunks once, store them in a vector database, and at query time you embed the user's question and search. Pinecone, Weaviate, Qdrant, Chroma, and pgvector (PostgreSQL with a vector extension) are the most common choices. For the curriculum's audience, pgvector or Supabase's vector support is usually the right answer; you get a vector database without operating a separate piece of infrastructure. The RAG section walks through the trade-offs.

Vercel is what most curriculum projects deploy to. The pitch is that you connect a git repo, every push to main deploys to production, every other branch gets a preview URL automatically, and the underlying infrastructure (CDN, serverless functions, image optimization, edge runtime) is handled by them. For Next.js apps specifically, Vercel is the canonical home; for other frameworks, it works but with fewer integrated features.

The trade-off is cost at scale. Vercel's free tier is generous, the hobby tier is fine for small projects, and the bills get real once a project has meaningful traffic, big static assets, or expensive serverless executions. For most curriculum projects most of the time, this won't matter; for projects that grow, the right answer might be migrating the static frontend to Cloudflare and the dynamic parts to a custom backend. The curriculum's deployment section covers when each platform is the right call.

A coding agent will tell you it finished. The tests will pass. The output will look reasonable. None of those things are a guarantee that the work is correct. The verification habit is the practice of treating every agent output as a draft until you've checked it against the actual requirement.

In practice, the habit looks like a checklist: did the change do what the spec said? Are there edge cases the agent didn't consider? Does the code do anything besides what was asked? Did the tests it wrote actually exercise the behavior, or are they tautologies? Is there anything in the diff that surprises me? The habit is mechanical, not heroic; it's a five-minute review on every change, and it catches roughly nine out of ten of the failures that would otherwise become production bugs.

The curriculum frames this as a habit rather than a process because that's what makes it stick. Process is something you have to remember; a habit is something you do without thinking. The path to that habit runs through doing the verification slowly, every time, until you can do it fast.

Where Colab is a notebook that disappears, Vertex is infrastructure that stays: persistent environments, guaranteed GPU access, and real API endpoints you can call from something else.

That is the step between an experiment and a thing other people can use. It is also where the meter runs: Vertex is billed per resource, and it is where student cloud credits are routed. Credits spent through Vertex are not the same balance as API calls billed through a separate interface, which is a distinction worth confirming before you assume a job is free.

Vibe coding is what most people do the first time they sit down with a coding agent. You describe the thing you want, the agent produces something, you describe what's wrong, the agent revises, and eventually you have a working piece of software. It is fast, it feels great, and it works for small problems.

It also breaks down quickly. Without a spec, every prompt is its own context, the agent has no durable record of decisions you've already made, and refactors become arguments. The fix is not to abandon prompt-driven coding (it remains the fastest way to get from idea to running code), but to anchor it in a spec, a CLAUDE.md, and a verification habit. The curriculum's name for the upgraded version is spec-driven development, but the work still feels like vibe coding most of the time. The difference is what survives between sessions.

The original Internet Menace curriculum coined 'vibe coding' to describe what was at the time a brand-new style of work. This version retires the term as a recommendation while keeping it as a useful description of what the work feels like.

Where Ollama and llama.cpp are optimized for a single user running a model on their machine, vLLM is optimized for a server hosting many users at once. Its core innovations (continuous batching, paged attention) let it run several inference requests in parallel on the same GPU, dramatically improving the requests-per-second a given hardware setup can handle.

For a home lab serving one or two people, vLLM is overkill and Ollama is the better choice. For a small company hosting a private model that ten or fifty employees use, vLLM is the right answer; the throughput difference at that scale is the difference between needing one GPU and needing four. Shane's two-node DGX Spark setup runs vLLM serving Gemma models, with Open WebUI as the user-facing layer. The curriculum covers vLLM as a deep-dive in the hardware section.

A GPU's VRAM is separate from your computer's main memory and faster than it. The amount of VRAM is the single most important number for local LLM inference: a 16GB GPU can hold a 13B model in 8-bit quantization, a 24GB GPU can hold the same model in 16-bit precision or a 30B model in 4-bit, and so on up the scale.

Apple Silicon Macs are an interesting exception because their unified memory architecture means the same memory pool is shared between CPU and GPU. A 64GB Mac effectively has 64GB of usable VRAM for inference (well, closer to 48GB after the OS takes its share, but still). For NVIDIA GPUs, VRAM is dedicated and fixed; you can't add more. The curriculum's hardware recommendations are largely VRAM recommendations dressed up: pick the largest VRAM you can afford that fits your power and thermal envelope, and the rest of the build follows.

When Stripe processes a payment, Slack receives a message, or a calendar event gets created, those services often need to notify your application. The standard mechanism is the webhook: you give the service a URL, the service makes an HTTP POST to that URL with details about the event, and your code reacts. It's the inverse of an API call (you receiving a request rather than making one), and it's how most event-driven integrations work.

For agents, webhooks are how the system reacts to things in the outside world: a new email arrives, a meeting gets scheduled, a form gets submitted, the agent processes it. The implementation considerations are mostly about reliability (webhook deliveries can fail and retry, so handlers must be idempotent), security (verify the request actually came from the service it claims to come from), and observability (log the payloads, because debugging without them is miserable). The curriculum covers webhooks in the agentic templates.

Most 'agent' projects should be workflows. A workflow is a defined sequence (fetch the email, classify it, draft a response, ask the human to approve, send it) where the LLM does the cognitive work at each step but doesn't decide what the steps are. A workflow is testable, debuggable, and predictable. It's also limited to the problems you can specify in advance.

An agent earns its keep when the steps genuinely can't be specified in advance, when the input determines the path and the path determines the next input. Open-ended research, multi-system troubleshooting, and goal-directed automation across heterogeneous tools are real agent problems. Most 'agent' demos that look impressive are actually workflows in costume; most production 'agents' that work reliably have been quietly converted into workflows after the team got tired of the failure modes. The curriculum recommends starting with a workflow, and reaching for an agent only when the workflow stops being expressive enough.