Andrew Ng's AI Engineering Skills Map, Part 1: Building and Deploying AI Applications

Andrew Ng's AI Engineering Skills Map named four top-level skills a week ago. Now he's cracked open the first one — and it turns out "building and deploying AI applications" isn't one skill, it's six.

On August 21, 2026, Ng published Part 1 of the follow-up series on X, fleshing out the first branch of the AI Engineering Skills Map he introduced on August 14: building and deploying AI applications. The post breaks that single skill into six concrete sub-skills — LLM foundations, grounding models with data, building agentic systems, evaluation-driven development, operating in production, and machine learning foundations — each with its own reasoning about why it matters and what it actually requires day to day.

TL;DR

Why this skill gets six sub-skills and the others don't (yet)

Ng's framing for why "building and deploying AI applications" needed its own depth pass: "The key difference between AI applications and non-AI software is that the former's output is less predictable." Software engineering fundamentals, using coding agents, and shaping the build are all skills that transfer from — or sit adjacent to — traditional software work. This one doesn't. It's the skill for handling a system that behaves probabilistically by default, and Ng says that unpredictability is what forces the six sub-skills apart into their own distinct disciplines rather than folding into general programming know-how.

He's explicit that the map itself comes from the same research as the original four-skill overview: analysis of a large number of job postings, structured expert interviews, and survey responses — not opinion or a personal reading list. Ng also flags this as Part 1 of a series; software engineering fundamentals is next, meaning the other three top-level skills will likely get the same treatment in the coming weeks.

The six sub-skills, in Ng's own terms

1. LLM foundations

Understanding how large language models tokenize input and generate output is, per Ng, what lets you "understand when to count on them and when they may fail." That's the practical payoff — not trivia about tokenizers, but a working model of model behavior you can reason from.

Ng bundles a specific set of concepts under this sub-skill:

• When to reach for a multimodal model versus a text-only one
• Tradeoffs on what to include in the context window
• Reasoning about cache hits, knowledge cutoff, and reasoning effort level
• Sampling parameters and when to use special features like tool calling

The payoff of getting this right, in Ng's words, is that it "helps choose the right model or mix of models and apply specialized techniques when needed, such as fine-tuning or self-hosting models." In other words: LLM foundations isn't academic background knowledge, it's the input to a series of real engineering decisions — which model, how many models, and whether to customize one at all.

2. Grounding models with data

"LLMs require good input context to produce useful outputs," Ng writes, and RAG with vector search was just the first widely adopted technique for supplying that context — not the ceiling on the skill. The set of techniques for grounding models has grown well past a single vector database.

The core decision Ng names: what to put directly in a prompt versus what to let the model retrieve on demand using tools. And once you've decided something needs retrieval, you still have to pick the right representation for the data and the query pattern — a vector index, a knowledge graph, or a semantic layer over structured data (his example: customer records). explainx.ai's own RAG vs. MCP comparison covers exactly this fork — when retrieval belongs in the prompt pipeline versus when it belongs behind a tool call — and its embeddings and vector search guide goes deeper on the vector-index half of that choice.

The less glamorous half of this sub-skill, which Ng calls out directly, is pipeline engineering: turning documents — text, PDFs, HTML, images — into LLM-ready input, and building pipelines that keep that data clean and fresh. Grounding fails quietly when the data feeding it goes stale, not just when the retrieval technique is wrong.

3. Building agentic systems

Ng draws a spectrum rather than a binary: agentic systems range from workflows that execute a predefined sequence of LLM calls, to systems built on an agent harness that lets the LLM repeatedly decide its own next step. The first architectural decision is picking a point on that spectrum — what steps to chain, what to parallelize, and when to use code versus an LLM call for a given step, with fallbacks engineered in.

Inside the agent loop itself, Ng names four more decisions a builder has to make:

• What tools the model can call — including MCP, CLI access, and sandbox execution environments
• What memory architecture to use
• How to manage context over long sessions
• When a task needs multi-agent orchestration instead of a single-agent architecture

Getting a prototype working is only half the skill. Ng is explicit that turning "promising prototypes into reliable, safe and secure agents for production" requires guardrails, handling adversarial inputs, identifying risks like data exfiltration, and governance — the same production-hardening gap explainx.ai covered when a misconfigured multi-agent setup wrecked a production database. Ng also flags that the field itself is moving fast underneath this skill — voice agents, computer-use agents, and generative UI are all agentic patterns evolving in real time, not settled categories to memorize once.

4. Evaluation-driven development

This is the sub-skill Ng singles out above the other five: "The most important trait that distinguishes someone great at building AI systems is whether you can drive a disciplined evals/error analysis loop to drive development." Not a nice-to-have layered on top of the other five sub-skills — the mechanism that makes all of them governable in the first place.

Ng describes evals as "a deep technical skill" with its own internal decisions, not a single technique:

• Exploratory data analysis to understand what's actually going wrong before you build a metric for it
• Deciding what to measure in the first place
• When to use deterministic (code-based) evaluations versus an LLM-as-a-judge versus a human in the loop
• Evaluating your evals — treating the eval suite itself as something that needs to keep evolving, not a one-time deliverable

explainx.ai's guide to evaluating prompts and coverage of real-repo coding-agent evals both work through this exact judge-vs-deterministic-vs-human decision in practice — and LangSmith's recent work on tuned evaluators is a live example of teams optimizing the "evaluate your evals" loop Ng describes, cutting judge cost by 82% without losing agreement with human raters.

5. Operating in production

Ng's framing for why this is a distinct skill from traditional ops: AI software is different "because of its unpredictability, cost, and latency" — the same three properties that made LLM foundations and evals necessary in the first place, now showing up as operational risk instead of design risk.

The concrete responsibilities Ng lists:

• Build observability mechanisms and track performance
• Detect drift in model behavior over time
• Respond to model failures and security incidents — Ng specifically names adversarial prompt injection
• Put in place regression testing and CI/CD calibrated to risk
• Select the right mix of model choice optimization, distillation, fine-tuning, and agentic workflow simplification to optimize cost and latency

That last point matters for a practical reason: production AI systems get more expensive and slower as they get more capable, and the skill is knowing which lever — a smaller model, a distilled model, a simpler workflow — actually moves the cost-latency-quality tradeoff you're stuck on, rather than reaching for the same fix every time. explainx.ai's coverage of why AI models hallucinate and how to catch it is the failure-detection half of this sub-skill in practice.

6. Machine learning foundations

Ng's closing point is a corrective to a common assumption: knowing how to call an LLM API is not a substitute for understanding machine learning. "Modern LLMs are built using machine learning techniques including supervised learning and reinforcement learning," and many applications still require knowing how to use a model — whether it's one someone else trained or one you train yourself.

The specific mental frameworks Ng says stay relevant regardless of whether you touch training code: bias/variance, error analysis, and engineering your data. explainx.ai's AI vs. machine learning vs. deep learning guide maps how these categories relate for readers who need the foundational layer before the LLM-specific one — a useful prerequisite read if sub-skill #6 is the one you're weakest on.

What people are asking

Is this a new framework, or an extension of the original Skills Map? An extension. Ng is explicit that this is Part 1 of a series fleshing out the four skills he already named on August 14 — this post covers only the first of those four, "building and deploying AI applications." The four-skill structure hasn't changed; what's new is the depth underneath skill #1.

Do I need to be strong at all six sub-skills to call myself an AI engineer? Ng doesn't frame it as a pass/fail bar. Read it as a self-audit, the same way the original four-skill map worked: most developers coming from a pure-prompting background are strong on LLM foundations and weak on evals and production operations; most developers coming from traditional ML are strong on foundations #1 and #6 but weak on agentic systems. The map's value is naming where your gap actually is.

Why does evaluation-driven development get called out as "most important" instead of just listed alongside the rest? Because it's the feedback mechanism for the other five. You can't know if your grounding pipeline is retrieving the right context, if your agent architecture is making good tool calls, or if your production system is drifting, without an eval loop that measures it. Ng's ordering implies a dependency, not just a ranking.

What's coming next in this series? Ng says the next post will cover software engineering fundamentals — the second of the original four top-level skills, and the one he's previously argued determines whether a developer can steer a coding agent well or just accepts whatever it produces.

The takeaway

The headline lesson from Part 1 isn't any single sub-skill — it's that Ng put evaluation-driven development at the center of a list that also includes LLM mechanics, retrieval architecture, and agent design. Those three feel like the "real" technical work; evals can feel like the compliance step you do after. Ng's framing inverts that: without a disciplined evals/error-analysis loop, none of the other five sub-skills are actually steerable — you're just guessing whether your last change helped. If you're deciding where to invest first inside "building and deploying AI applications," his own ordering is the answer: get LLM foundations solid enough to reason about failure modes, then build the evals loop before you scale up grounding, agents, or production complexity.

Related on explainx.ai:

• Andrew Ng's AI Engineering Skills Map: The 4 Skills That Matter — the original four-skill overview this post extends
• RAG vs. MCP: Complete Comparison 2026
• What Are Embeddings and Vector Search? Complete Guide 2026
• LLM Context Window Explained
• Evaluating Prompts: How to Measure Quality
• AI Coding Agent Evals on Real Repos
• LangSmith's Tuned Evaluators Cut Judge Cost 82%
• Why AI Models Hallucinate and How to Catch It
• AI vs. Machine Learning vs. Deep Learning: Complete Guide
• Complete AI Builder Bootcamp Guide 2026

Official sources: Andrew Ng's Part 1 post on X · The Batch — DeepLearning.AI

Details reflect Andrew Ng's X post as published August 21, 2026. Ng states software engineering fundamentals is next in the series — explainx.ai will track and cover it as it lands.