What is AI Engineering?

Ten years ago, if you wanted software that could summarize a document, answer questions about your company's internal wiki, or write code, you needed a research lab and a few million dollars. Today you need an API key and an afternoon. That shift created a brand new job: the AI engineer.

The problem

Large language models are astonishing and frustrating at the same time. Out of the box, a model:

• Knows nothing about your data — your docs, your customers, your codebase.
• Sometimes confidently makes things up (we call this hallucination).
• Has no memory between requests unless you build one.
• Can't take actions in the real world — it just produces text.
• Costs real money per request and can be slow.

Turning "a model that produces plausible text" into "a product your users trust" is an engineering problem, not a research problem. That is the job.

What AI engineers actually build

A few concrete things you will know how to build by the end of this course:

• Chat assistants grounded in your data. A support bot that answers from your actual documentation instead of guessing. (This pattern is called RAG — retrieval-augmented generation.)
• Agents. Systems where the model doesn't just answer, it acts: searching the web, calling APIs, writing and running code, looping until a task is done.
• Semantic search. Search that understands meaning ("cheap flights to Japan" matches "budget airfare Tokyo") instead of matching keywords.
• Pipelines. Extraction, classification, summarization jobs running over thousands of documents.
• Fine-tuned models. Models adapted to your specific tone, format, or domain.

A new mental model

The hardest adjustment for traditional engineers is that AI systems are probabilistic. The same input can produce different outputs. There is no stack trace when the model gives a bad answer. So the discipline shifts:

# Traditional engineering: correctness is binary
assert add(2, 2) == 4

# AI engineering: correctness is statistical
# You build an evaluation set and measure quality
score = evaluate(model, test_cases)   # e.g. 94% of answers rated correct
assert score > 0.90

You will spend less time on algorithms and more time on evaluation (how do I know it's good?), grounding (how do I feed it the right context?), and guardrails (how do I stop it doing something dumb?).

Why start from binary?

This course starts absurdly low-level: how computers represent numbers and text. That might seem far from ChatGPT, but it's the whole game. An LLM never sees words. It sees numbers. Every concept in AI engineering — tokens, embeddings, context windows, vector databases — is a consequence of one fact: models only understand numbers, so everything must become numbers first. Once you truly get that, the rest of the field stops being magic.

Build it yourself

No code yet — a thinking exercise. Pick a product you use daily (email, your bank app, a food delivery app). Write down:

1. One feature that an LLM could add (e.g. "summarize this long email thread").
2. What data the model would need access to.
3. One way it could fail embarrassingly, and how you'd catch that before users do.

Keep your answer — by the production module you'll be able to actually build it.

Summary

• AI engineering is building products on top of pre-trained models — not training models from scratch.
• Raw models hallucinate, lack your data, have no memory, and can't act; engineering fixes that.
• Core deliverables: grounded assistants (RAG), agents, semantic search, pipelines, fine-tunes.
• The mindset shift: from deterministic correctness to statistical evaluation.
• Everything starts with one fact — models only understand numbers.