Applied GenAI Curriculum for AI PMs · Core Sequence
How building on foundation models differs from classic ML and full-stack engineering — and which layer of the AI stack your team actually operates on.
Before you decide whether to build an AI feature, argue about which pattern to use, or ask what your eval plan is, you need a shared map of the territory. This unit gives you that map: what the discipline of AI engineering actually is, why it emerged as its own thing, and — most usefully for a PM — the three-layer stack that tells you where your team's work lives. Almost every disagreement you'll have with engineers is really a disagreement about which layer a problem belongs to. Get this straight now and the next twenty-three units land on solid ground.
ChatGPT and Copilot can look like they appeared from nowhere, but they're the end of a long chain: language models → large language models → foundation models → AI engineering. You don't need the history for its own sake, but each step introduced a vocabulary word you'll use constantly.
A language model encodes statistical information about language — essentially, how likely a word is to appear in a given context. Its basic unit is the token: a character, a word, or a piece of a word (for GPT-4, an average token is about ¾ of a word, so ~100 tokens ≈ 75 words). The full set of tokens a model can use is its vocabulary.
The mental model that matters most: a language model is a completion machine. Give it "To be or not to be" and it completes ", that is the question." A huge range of tasks — translation, summarization, classification, coding — can be reframed as completion. But completions are predictions based on probabilities, not guarantees of correctness. That probabilistic nature is what makes these models exciting and maddening, and it's the entire subject of Unit 02.
Classic ML relied on supervision — training on human-labeled examples, which is slow and expensive (labeling ImageNet's million images at 5¢ each ≈ $50,000; scaling to a million categories ≈ $50 million). Language models scaled because they learn by self-supervision: the labels are inferred from the input itself. The sentence "I love street food." silently generates six training examples (predict "I", then "love", then "street"…). Because text is everywhere — books, blogs, Reddit — you can build a massive training set with no labeling cost. That's what let language models grow into large language models.
"Large" is measured in parameters (variables updated during training). The bar keeps moving: OpenAI's first GPT (2018) had 117M parameters and was considered large; today 100B+ is the rough threshold. The number itself is less important than the trend — bigger models generally have more capacity but need more data and compute.
Extend a language model to handle images, audio, video, and more and you get a foundation model (a multimodal generative one is a large multimodal model, or LMM). Throughout this series, foundation model refers to both. The word foundation is deliberate: these models are important building blocks that can be built upon for many different needs. Two shifts came with them:
First, task-specific → general-purpose. An old sentiment model couldn't translate; a foundation model does both, reasonably well, out of the box. Second, and this is the whole business case: adapting an existing model is radically cheaper than building one — "ten examples and one weekend versus 1 million examples and six months." The three common adaptation techniques you'll hear constantly are prompt engineering, RAG (retrieval-augmented generation — supplement the model with an external database), and finetuning (further-train the model on your data). Whether to adapt an existing model or build your own is the classic buy-vs-build question.
If traditional ML engineering develops models, AI engineering is the practice of building applications on top of foundation models someone else trained. Three conditions together created ideal conditions for its explosive growth:
| Factor | What it means |
|---|---|
| General-purpose capability | Models can now do more tasks, not just existing ones better — expanding the user base and demand for AI apps. |
| Increased investment | Post-ChatGPT capital surge; cheaper-to-build apps make ROI attractive. One in three S&P 500 companies mentioned AI on 2023 Q2 earnings calls (3× the prior year). |
| Low barrier to entry | Model-as-a-service APIs remove the need to host models; you can even build with minimal code, working in plain English. |
The takeaway isn't the statistics — it's the reframing: the center of gravity moved from training models to adapting and evaluating them. That single shift is why the rest of this curriculum spends its time on evals, prompting, retrieval, and production plumbing rather than gradient descent.
This is the most operationally useful idea in the unit. Every AI application sits on three layers. You typically start at the top and move down only as needed.
Giving a model good prompts and the right context, evaluating its outputs rigorously, and building the interface users interact with. Where the most activity — and most PM leverage — lives.
Responsibilities: evaluation · prompt engineering & context construction · AI interface
Tooling to build, train, finetune, and inference-optimize models — plus the dataset engineering that feeds them. This is the layer most associated with traditional ML.
Responsibilities: modeling & training · dataset engineering · inference optimization
The unglamorous, stable base: model serving, managing data and compute, and monitoring. Its core needs barely changed with foundation models.
Responsibilities: serving · compute & data management · monitoring
Three differences stand out:
| Dimension | The shift |
|---|---|
| Modeling | You adapt a model someone else trained rather than train your own — less about modeling, more about model adaptation. |
| Compute & latency | Models are bigger, pricier, and slower, raising the stakes on inference optimization and GPU/cluster skills. |
| Evaluation | Open-ended outputs are far harder to judge than close-ended ones, so evaluation becomes a much bigger problem — the through-line of this whole curriculum. |
Adaptation splits cleanly by one question: does it change model weights? Prompt-based techniques (prompt engineering) adapt via instructions and context — no weight changes, less data, easy to start, sometimes not enough. Finetuning changes the weights — more complex, more data, but reaches things prompting can't. Keep this fork in mind; Unit 05 turns it into a decision tree.
The heavy emphasis on the application layer — especially interfaces — pulls AI engineering toward full-stack web development. Tooling now supports JavaScript, not just Python, and more AI engineers arrive from web backgrounds. The deeper consequence is a reversed workflow:
| Traditional ML | AI engineering |
|---|---|
| Gather data → train model → build product last. | Build the product first with an off-the-shelf model → invest in data and models only once it shows promise. |
This rewards teams that can iterate fast, and it means AI engineers are far more involved in product decisions than ML engineers historically were. For you, that's an opportunity: product and engineering are no longer sequential. You can put a working prototype in front of users in week one — which is exactly what makes the feasibility question in Unit 03 both possible and necessary.
If any of those feels shaky, this is the unit to reread — everything downstream assumes it.