Andrew Ng's AI Engineering Skills Map

If you work with AI right now, you have probably hit the same question we did: what should you learn first, when something new lands every week and nobody can tell you which of it survives six months.

On 14 August 2026, Andrew Ng published what he calls the AI Engineering Skills Map, an attempt to answer that with data rather than instinct. Yesterday he followed it with a post expanding the first skill into six. This article covers the fundamentals first: what the map says, where it came from, and what it means for people who have to build something on Monday.

Productize builds and operates AI agent systems in production and publishes the process as posts on this blog. The final section is the view from using these things daily, not a critique of the map.

Part 1What Andrew Ng's map says

The map names four top-level skills.

In one line each: building and deploying AI applications is making something with a model inside it actually work; software engineering fundamentals is the existing craft, system design, tests, and looking after what is already running; using coding agents is working alongside AI that writes code for you, sizing the task, checking what comes back, and knowing which work should never be handed over, a skill no job posting asked for three years ago; and shaping the build is deciding what to make, for whom, and when it is enough, which is judgment rather than technique.

Where the map came from is what makes it more than one person's opinion. Andrew Ng states it was synthesised from analysing over ten thousand job postings, plus dozens of structured interviews with AI experts, hiring managers and recruiters, along with survey data.

He also explains why he frames it as skills rather than a job title.

I talk about AI Engineering skills rather than the "AI Engineer" role, because the former is much broader.

Which means the map is not written only for people with AI Engineer in their title. It is written for anyone who has to build something with AI, whatever they call themselves.

The most striking thing is what is absent. Across all four top boxes and all six below, not one is called prompt engineering. It did not vanish because it stopped mattering. It collapsed into a larger skill, deciding what goes into the model at all, which is a different size of problem from the "how to phrase a request" advice of two years ago.

Part 2Why the map has this shape

The reason sits in one paragraph Andrew Ng wrote himself, and it is the key to the whole map. The key difference between AI applications and non-AI software is that the former's output is less predictable. You do not know in advance what an LLM will output, or what a trained model will predict on an example it has not seen.

When you cannot predict the output, you can plan the work less. So building becomes iterative: make a piece, look at it, decide what to try next, with each step heavily shaped by the result of the last.

The skill this map is really describing is therefore not a list of tools. It is the ability to decide what to try next, because that is what lets you build reliable systems out of unreliable components.

Once that lands, the six sub-skills read much more easily. Every one of them is knowledge that makes the next decision sharper, not knowledge to be memorised for its own sake.

Part 3What it means if you do the work

The short version is that this map covers a wider group than most people assume. Andrew Ng is explicit that these skills matter for full-stack engineers, data engineers, DevOps engineers, machine learning engineers and AI engineers, not just the last of those.

One more thing to read accurately: the map is built from job postings, so it pictures what companies are hiring for rather than forecasting what comes next. The strength is that it measures something that already happened. The limit is that it always trails what just started.

Part 4The six sub-skills, expanded yesterday

This is the part Andrew Ng just added, zooming into the first box of the map. The six follow his order.

1. LLM foundations

Understanding how a model breaks input into pieces and generates output, so you know when to count on it and when it may fail. The same knowledge carries several further decisions: when a multimodal model earns its place, what to trade off when choosing what goes in the context window, and how to reason about cache hits, meaning putting the unchanging part of a request first so the provider charges less for it, along with the knowledge cutoff, reasoning effort level, sampling parameters, and when to let the model call tools. It is also what lets you pick the right model or mix of models, and reach for fine-tuning or self-hosting when the situation calls for it.

In one sentence: the better you understand how the model works inside, the earlier you can predict where it will fail, and the more accurately you can match a model, or a mix of them, to the job.

2. Grounding models with data

Models need good input context to produce useful output. Having the model search your documents by closeness of meaning before answering, the approach known as RAG, was an early attempt, but the set of grounding techniques has grown well past it. You decide what goes into the prompt directly and what the model retrieves on demand with tools, and which representation fits your data and your queries: a vector index, a knowledge graph, or a semantic layer over structured records such as a customer table. There is also the work of turning text, PDFs, HTML and images into inputs a model can use, and engineering pipelines that keep the data clean and fresh.

3. Building agentic systems

These range from workflows running a predefined sequence of model calls, to harnesses that let a model repeatedly choose its own next step. You choose the architecture, which steps to chain, what to parallelise, where code belongs and where the model belongs, and you build in fallbacks. Designing the loop also means deciding which tools the model may call, what memory architecture to use, how to manage context across long sessions, and when a task genuinely needs several agents rather than one.

The part Andrew Ng stresses is turning a promising prototype into something reliable, safe and secure enough to run for real, which requires understanding guardrails, adversarial inputs, and risks such as data exfiltration.

4. Evaluation-driven development

Andrew Ng gives this the longest treatment and says plainly that in his experience it is the trait most separating people who are great at building AI systems from those who are not: whether you can drive a disciplined evals and error-analysis loop, so your effort keeps landing on directions likely to pay off.

Building good evals is a deep technical skill in itself. You look at real traces and outputs, do exploratory analysis, and combine that with product and business insight to decide what is worth measuring. You also need to know when a deterministic code-based check is right, when to use a model as a judge, when a human belongs in the loop, and how to evaluate your evals so they keep improving too.

5. Operating in production

Different from ordinary software because of unpredictability, cost and latency. First you need observability into how the system performs on real usage: tracking performance, detecting drift, and responding quickly to model failures and security incidents such as adversarial prompt injection. Regression testing and CI/CD lean on statistical evaluation more than traditional software does, and the testing effort should be calibrated to what a mistake would cost. Beyond that comes choosing the right mix of techniques for cost and latency: model choice, distillation and fine-tuning, and simplifying the agentic workflow itself.

6. Machine learning foundations

Modern LLMs are built with machine learning techniques including supervised learning and reinforcement learning. Andrew Ng writes that every engineer he knows who is good at building with LLMs also understands machine learning and deep learning to some depth, and that plenty of applications still call for classical models, whether someone else trained them or you did.

The underlying concepts, bias and variance, error analysis, and engineering your data, remain the core frames for working with any system whose output is uncertain.

Part 5The view from operating agents daily

We have nothing to argue with in this map. What we would add are three things visible only from using these systems every day.

First, in practice the fourth skill comes before the others. Andrew Ng lists evaluation fourth because that is the order of exposition. Asked which to invest in first when time is short, we would say this one, because it is the only one that tells you where the other five need work. Without it, every remaining choice is a guess, and it is the kind of guess that feels like progress.

Second, the short clause about evaluating your evals is where most of our time actually goes. A check you wrote yourself has nobody reviewing it after you, which makes it the most suspicious component in the system rather than the most trustworthy. The only way we know one still works is to deliberately make it go red once and watch.

Third, the sixth skill is the one we are thinnest on. We do not have machine learning foundations at the depth Andrew Ng means, and the cost shows up in ordinary work: when a measurement comes back strange, separating "the model is behaving wrong" from "the sample we measured on is skewed" takes us longer than it should. We write that here because a skills map with every box ticked helps nobody plan. The empty boxes are the part that says where to walk next.

Using the map on your own work

1. Walk the map box by box against what you are building and score yourself roughly: adequate, or empty. Do not plan before you can see that picture.
2. Ask: if this answered wrong today, when would I find out? If the answer is "when someone tells me", the box to invest in first is evaluation, not a newer model.
3. Take your thinnest box and make it adequate, not excellent. Adequate across all six beats excellent at two and absent at four.
4. Write down the boxes still empty. An honest map is the only kind you can plan against.

The value of this map is that it turns "what should I learn first" into a question you answer by looking at what you are already building, rather than by chasing whatever landed this week.

Related reading: openworker review: Andrew Ng's AI coworker · Andrej Karpathy Skills reviewed · AI Product Management: what is left for the PM · Why tests that never fail prove nothing