Andrew Ng's AI Engineering Skills Map: What Enterprise Teams Should Standardize

Andrew Ng's map is a skills framework, not a product architecture. This article asks a narrower enterprise question: which mechanics should engineers understand and own, and which repeatable runtime, access, governance, reuse, and evidence primitives can a platform standardize without replacing that judgment?

Andrew Ng's four top-level skills are deceptively simple:

1. Building and deploying AI applications
2. Software engineering fundamentals
3. Using coding agents
4. Shaping the build

The useful signal is what the list refuses to collapse. AI engineering is not reduced to prompting; coding agents do not erase software fundamentals; deployment is part of the craft; and product judgment sits alongside implementation. The map therefore treats AI engineering as a combination of systems work, software engineering, agent-assisted development, and judgment.

1. A skills map is not a product checklist

The wrong way to use Ng's map would be to draw four boxes and claim a platform "solves" each one. Skills are human capabilities. Product judgment, architecture judgment, debugging ability, evaluation design, and customer understanding do not disappear because a company buys infrastructure.

The more useful enterprise translation is this: standardize the repeatable mechanics so engineers can spend more of their scarce judgment on the parts that genuinely require judgment.

2. Building and deploying AI applications: this is where the platform map is strongest

Ng's August 21 follow-up breaks building and deploying AI applications into six capabilities: LLM foundations, grounding models with data, building agentic systems, evaluation-driven development, operating in production, and machine-learning foundations. The important point is that these are engineering skills, not vendor categories. A platform can operationalize parts of the work; it cannot substitute for knowing why one architecture, model, evaluator, or failure policy is appropriate.

LLM foundations → AI Gateway can standardize access, not understanding

Engineers still need to understand model behavior: context windows, caching, knowledge cutoffs, sampling, reasoning effort, tool calling, latency, cost, and provider-specific behavior. TrueFoundry AI Gateway can standardize how routed model traffic is accessed and governed—unified APIs, routing and fallbacks, RBAC, rate limits, budgets, guardrails, and OpenTelemetry-compatible observability—but it does not remove the need to understand those model tradeoffs.

Grounding models with data → governed access, not “RAG in a box”

Ng treats grounding as an architectural menu rather than a synonym for vector search: engineers may choose prompt context, retrieval, tool calls, vector indexes, knowledge graphs, semantic layers over structured data, or combinations of them. There is no universal “grounding → MCP Gateway” mapping. When an application exposes retrieval or data access through MCP tools, MCP Gateway can govern that access path through discovery, authentication, tool-level permissions, downstream credentials, guardrails, approvals, observability, and audit. If grounding happens directly inside the application or through a vector store, knowledge graph, or semantic layer that does not traverse MCP, that path remains outside MCP Gateway.

Building agentic systems → architecture first; TrueForge maps to the harness/runtime branch

Ng's August 21 expansion treats agentic systems as an architectural spectrum rather than a single framework choice. At one end, an application can execute a comparatively explicit workflow of model calls. At the more open-ended end, an agent harness lets the model repeatedly choose its next step while the surrounding runtime manages tools, context, execution, safety boundaries, and continuation. In between are hybrid systems that combine explicit workflow structure with agentic nodes.

That means the underlying skill is architecture judgment: deciding what should be deterministic, what should be delegated to a model, what may run in parallel, what tools the system may call, how memory and long-session context should work, when multiple agents help, and what fallbacks, guardrails, and governance are required.

TrueForge maps strongly to the harness/runtime branch of that design space. Its documentation defines an open-source agent harness that runs the model/tool loop, connects to MCP servers, manages long-task context, treats isolated sandbox execution as a tool, pauses for human approval, supports subagents, and persists sessions across reconnects and restarts.

The mapping becomes concrete in the AgentSpec. A reusable agent definition can specify the model and parameters, instructions, MCP servers and tool filters, approval policy, Skills, sandbox behavior, context management, response format, and iteration limit. Those are runtime choices an engineer may need when implementing an agent-harness architecture.

Evaluation-driven development → structured evidence, not a built-in evaluator

Ng treats disciplined evaluation and error analysis as a core AI-engineering skill. The platform implication is not “buy an evaluator.” It is that evaluations need reliable evidence about what actually happened: prompts and responses where retained, model/tool choices, intermediate steps, failures, latency, cost, and the surrounding task context.

TrueForge makes its runtime structure explicit through an Agent → Session → Turn → Event → Delta model. The documentation distinguishes these objects precisely:

‍