Module 1 — The AI Landscape¶
In this module
- Understand why 2022–2024 was a genuine inflection point for AI.
- Know the key model providers and their flagship models by name.
- Know what LLMs can do well — and where they reliably fail.
- Survey the AI developer tools that have become part of everyday engineering.
- Understand the closed vs open-source model tradeoff at a practical level.
Time: ~25 min · Lab: Lab 1 — Compare Models
Why this matters¶
You can't navigate a landscape you can't see. Before we dig into how these systems work, you need a clear picture of what exists, who makes it, and what it can and can't do. Engineers who skip this orientation end up either over-trusting AI (using it for tasks it fails at) or under-trusting it (not realising what it could automate). This module is your orientation flight — we'll fly high and wide first, then zoom in on the details in subsequent modules.
The AI explosion — why 2022–2024 changed everything¶
For most of its history, AI progress was slow and specialised: a chess-playing system couldn't play Go; a spam filter couldn't caption images. Then, starting around 2017 with the transformer architecture, models began to generalise.
The watershed moment arrived on 30 November 2022: OpenAI released ChatGPT. It reached 100 million users in two months — the fastest-growing consumer application in history at that point. What made it different wasn't just raw capability; it was accessibility. A plain-English chat interface meant anyone could interact with a genuinely powerful language model without writing code. Boards started asking about AI strategy; engineering teams started evaluating APIs overnight.
The 18 months that followed were a Cambrian explosion: GPT-4 launched (March 2023), Anthropic released Claude, Google answered with Gemini, Meta open-sourced Llama, and a dozen startups shipped developer tools built on top of these foundation models. By the mid-2020s, AI-assisted coding had moved from novelty to everyday practice for a large share of professional developers. The shift from "interesting research" to "production infrastructure" happened in about 18 months.
Key players and models¶
Here are the organisations and flagship models you'll encounter most often:
- OpenAI — GPT series: The organisation that triggered the current wave. Its flagship GPT models are multimodal (text, image, audio) and the benchmark others aim at.
- Anthropic — Claude: Safety-focused lab founded by former OpenAI researchers. Claude models are known for strong reasoning, long context windows, and careful instruction-following.
- Google DeepMind — Gemini: Google's answer, natively multimodal and tightly integrated with Google services; competes at the frontier.
- Meta — Llama: Meta's open-weights family, downloadable and self-hostable. The most widely used open model family.
- Mistral AI — Mistral/Mixtral: A Paris-based lab releasing compact, highly capable open models; its mixture-of-experts architecture delivers strong quality at a fraction of the compute.
No single provider "wins" for all use cases. Choice depends on capability, latency, cost, data-privacy requirements, and context-window needs — all topics you'll revisit in later modules.
Specific model names age fast
The flagship model names and version numbers move every few months — by the time you read this, the leaders will have shifted (and context windows have largely converged around ~1M tokens at the frontier). Treat every model name in this course as an example of a category, not a current recommendation. For today's best model on a given task, check a live leaderboard such as LMArena rather than any course's snapshot.
How a basic LLM interaction works:
flowchart LR
Prompt["Your Prompt"] --> LLM["LLM"] --> Response["Response"]
The major LLM providers at a glance:
mindmap
root((LLM Providers))
OpenAI
GPT-4o
Anthropic
Claude
Google
Gemini
Meta
Llama
Mistral
Mixtral
What LLMs can do¶
LLMs (Large Language Models) are foundation models specialised for text. They arrive pre-trained on the internet's worth of writing, code, and structured data. That breadth translates into a surprisingly wide set of practical capabilities:
- Generate — write drafts, emails, docs, marketing copy, test data.
- Summarise — condense a 50-page PDF or a long Slack thread into bullet points.
- Classify — label support tickets by topic, sentiment, or urgency.
- Extract — pull structured fields (dates, names, amounts) from unstructured text.
- Translate — across human languages and also between formats (prose → JSON, SQL → English).
- Code — generate, explain, refactor, and review code across most languages and frameworks; write tests; debug error messages.
- Reason — decompose multi-step problems, compare tradeoffs, draft plans.
The software-development analogy: an LLM is like a very well-read junior developer who never sleeps and can produce a plausible first draft of almost anything in seconds — but still needs a senior engineer to review it. The value is in the speed of the first draft; the risk is in forgetting to review.
What LLMs can't do reliably¶
LLMs have sharp edges. Missing these is how teams ship embarrassing bugs:
- Real-time data: Models have a knowledge cutoff — they know nothing about events after their training ended. Asking "What's the current stock price?" will get you a confidently wrong guess.
- Precise arithmetic and symbolic reasoning: LLMs predict plausible text, not
mathematically verified results. They will calculate
13 × 7correctly most of the time, but fail on multi-step arithmetic or large numbers. Never trust them for financial calculations without a code-execution tool attached. - Guaranteed factual accuracy: This is hallucination. A model generates the most statistically plausible next token — not the most truthful one. It will invent a convincing-sounding citation, a fake API method name, or a non-existent legal case. Treat every factual claim as a hypothesis that must be verified.
The common thread: LLMs are language machines, not knowledge or reasoning machines in the formal sense. They excel at fluent synthesis; they struggle at anything requiring grounding in external, current, or provably correct information.
In plain words
Why does a model that writes flawless code fumble 4,839 × 7,012? Because it isn't
calculating — it's predicting what number tends to follow that question, the way you'd
blurt out an answer to a hard multiplication at a noisy party. You'd say a number,
confidently, and probably get it wrong. That's exactly why we hand the model a calculator
tool (Module 5) instead of trusting its mental math.
When NOT to reach for an LLM¶
Knowing the capabilities is half the literacy; knowing when not to use a model is the other half. Reach for something simpler when:
- The rule is fixed and known. Validating an email, calculating tax, routing by a lookup
table — a regex, a formula, or a
switchis cheaper, instant, and always correct. - You need exact, reproducible answers. Financial totals, compliance decisions, anything audited — deterministic code wins; an LLM only probably agrees with itself.
- A database query already answers it. "What's this order's status?" is a SQL lookup, not a generation task.
- Latency or cost is critical at scale. A model call is roughly 100–1000× slower and pricier than a function call; don't put one in a hot path a few lines of code can handle.
The honest framing: an LLM earns its place when the input is messy, unstructured, or open-ended language — and the output can tolerate "usually right, verify the rest." If the task is deterministic, structured, or must be exactly correct, prefer plain code and call the model only for the fuzzy edges.
In plain words
Don't use a self-driving car to back out of your own driveway. LLMs are for the messy, judgement-heavy stretches of the journey — not the parts a simple rule already nails.
AI tools developers use today¶
Beyond the raw model APIs, a set of developer-facing tools has emerged that embed LLMs directly into coding workflows:
- GitHub Copilot: AI pair programmer inside VS Code, JetBrains, and other IDEs. Autocompletes code, suggests whole functions, and answers questions about your codebase inline.
- Cursor: An IDE built ground-up around AI; supports natural-language refactors across files and codebase-wide context.
- Claude Code: Anthropic's agentic coding assistant that runs in the terminal and operates across files, runs tests, and executes shell commands with your approval.
- ChatGPT: The general-purpose chat interface; useful for drafting, debugging, explaining errors, and exploring ideas when you don't need IDE integration.
These tools run inference against the underlying models on every keystroke or command. As a developer you don't train anything — you consume the model's output via these interfaces or the underlying APIs.
Closed vs open source — enterprise tradeoffs¶
Every engineering team eventually faces this choice:
| Closed API (GPT-4o, Claude, Gemini) | Open weights (Llama, Mistral) | |
|---|---|---|
| Data privacy | Data processed by provider | Fully self-hosted |
| Cost model | Per token | Compute / GPU rental |
| Capability ceiling | Frontier | Catching up fast |
| Customisation | Prompt / fine-tune via API | Fine-tune weights directly |
| Ops burden | None | Your team owns infra |
Open source models are attractive when data privacy is non-negotiable (healthcare, finance, legal), when volume is high enough that per-token costs exceed self-hosted compute, or when you need to fine-tune on proprietary data. The gap in raw capability versus closed frontier models has been closing rapidly — recent open-weight models handle many production tasks that only earlier frontier closed models could a generation or two ago.
Closed APIs win for speed-to-market, maximum capability at the frontier, and teams that don't want to own ML infrastructure. Most proof-of-concept projects start here and re-evaluate later.
Mental model
Think of the AI landscape the way you'd think of cloud infrastructure in 2010: the frontier providers (OpenAI, Anthropic, Google) are like AWS — they absorb the complexity and charge for consumption. Open-weight models (Llama, Mistral) are like bare-metal co-lo — more control, more responsibility, potentially cheaper at scale. Most teams start on the managed cloud and only move when the bill or the data-governance requirements force the conversation.
Hands-on¶
Open Lab 1 — Compare Models. You'll send the same prompt to several models and compare outputs, quality, and latency side-by-side — putting the landscape you just mapped into direct, tactile experience.
Go deeper¶
-
Large Language Models explained briefly — 3Blue1Brown — A compact animated video that explains what an LLM actually does in under 5 minutes; the best first-watch before diving deeper.
-
Transformers, the tech behind LLMs — 3Blue1Brown — If you want to understand why these models are so capable, this animated deep-dive into the transformer architecture is the clearest explanation on the internet.
-
What are Foundation Models? — AWS — A concise, well-structured explainer covering pre-training, fine-tuning, and the economics of foundation models; useful as a reference you can share with non-technical stakeholders.
-
Guide to Hallucinations in LLMs — Lakera — A practical, developer-oriented breakdown of what hallucination is, why it happens, and concrete mitigation strategies (RAG, grounding, evals).
Jargon recap¶
LLM · foundation model · open source model · prompt · inference · hallucination · knowledge cutoff
Check yourself¶
Try to answer before expanding — active recall is what makes it stick.
What kinds of tasks do LLMs do well?
Fluent language work: generate drafts, summarise long text, classify (topic/sentiment/urgency), extract structured fields, translate between languages and formats, write/explain/refactor code, and reason through multi-step problems. Think of it as a fast, well-read junior developer producing a first draft you still review.
What can't LLMs do reliably, and why?
Real-time facts (they have a knowledge cutoff), precise multi-step arithmetic, and guaranteed factual accuracy. The root cause is that they predict plausible text, not verified truth — so they hallucinate confident, wrong answers. Verify factual claims and attach a tool for calculations.
What is the closed vs open-source model tradeoff?
Closed APIs (GPT-4o, Claude, Gemini) give frontier capability and zero ops but send your data to the provider and bill per token. Open weights (Llama, Mistral) give full data privacy, self-hosted cost, and weight-level fine-tuning, but you own the infra and trail the frontier slightly. Most teams start closed and re-evaluate when cost or governance forces it.
When should you NOT reach for an LLM?
When the rule is fixed and known, when you need exact reproducible answers, when a database query already answers it, or when latency/cost is critical at scale. Prefer plain code for deterministic, structured, must-be-correct work; use the model only for the messy, open-ended edges.
Key takeaways¶
- ChatGPT's November 2022 launch was a step-change: it made frontier AI accessible to anyone with a browser, triggering an industry-wide race.
- Five providers dominate the landscape: OpenAI, Anthropic, Google DeepMind, Meta, and Mistral — each with distinct tradeoffs.
- LLMs excel at generate/summarise/classify/extract/translate/code/reason tasks, but they hallucinate, lack real-time data, and can't do reliable arithmetic.
- Hallucination is not a bug to be fixed — it's a property of next-token prediction; design your systems to mitigate it (RAG, grounding, evals).
- Closed APIs offer maximum capability and zero ops; open-weight models offer privacy and cost control — start closed and re-evaluate when the bill arrives.