Andrew Ng names five skills for using coding agents. The third assumes your tests actually ran.

You use a coding agent every day now, and your hands know it. Work that used to take an afternoon closes in twenty minutes. But when somebody asks what you actually got better at, you have no answer, because there is nothing to point at except the feeling of moving faster.

And then there are the other days. You hand over one task, the agent runs for forty minutes, and what comes back is fourteen files already edited with the whole test suite green, every check reporting a pass. You skim it and merge, because you do not know where to start reading. Two weeks later you find the thing that was wrong in it from the first day.

Looking back, none of that was a skill problem. It was a naming problem. A skill with no name cannot be practised, because you never know what you are practising.

On 4 September 2026, Andrew Ng published the third part of his AI engineering skills map, on using coding agents. What that post does is take one large undifferentiated feeling, being good with agents, and cut it into five names you can pick up one at a time.

Productize uses coding agents to build and run production systems every day, and publishes the process as posts on this blog. So this piece walks Andrew Ng's five in his order first, and only then gets to the thing we measured ourselves and found the map does not ask.

Part 1The three-step workflow under all five skills

Andrew Ng's AI engineering skills map names four top-level skills: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build. Part 1 already went through the first box, six sub-skills of it. Part 2 already went through the second, five pillars of it. This page stays in the third.

Andrew Ng opens by saying why this box earns a name of its own: skill at steering agents, both to write code and to carry out non-code work such as analyzing data or managing system operations, is what lets you get a lot more done. He also says this box moves faster than anything else on the map, because proprietary agents like Claude Code, Codex and Cursor and open agents like OpenCode and Pi both progress in strides, through the harness and through the model. Which means keeping up is not a summary you read once. It is a continuous process of experimentation, building and learning.

Before the skills themselves, Andrew Ng lays one layer of foundation. From interviewing dozens of top AI engineers and reflecting on how his own team works, he found a consistent high-level workflow, in three steps.

Planning covers brainstorming, which may include research, experimentation and understanding the existing codebase if there is one, and writing a spec that captures requirements, technical design and architecture, followed by generating an execution plan. It also includes going back over your own plan to interrogate key assumptions and check for security holes, overengineering and other gaps.

Execution is where you build, test and verify, with the right balance between agent autonomy and human oversight. Two halves: having the agent build the thing at a calibrated autonomy level, and verifying what comes back through automated checks, human checks, or both.

Deployment and monitoring is shipping it and then watching. The shipping half may be gated by a CI/CD pipeline or by additional human gates. The watching half is using agents to read logs, surface issues, and propose and execute improvements.

Andrew Ng points out himself that this looks much like the workflow people used before coding agents existed. What changed is the weight. Far less of the work is now the code, and far more of it is deciding what to build, designing the architecture, writing the spec, and verifying outputs.

The other thing he stresses is how loosely the steps hold. Each one varies enormously in length between projects, and steps can be omitted. The spec for a greenfield prototype, meaning one built from scratch, might be loosely described in a quickly written prompt, while the spec for a brownfield project with many users might take far more effort to write and verify. The workflow is also highly iterative, and skilled developers know when feedback from a later step should send them back to an earlier one: when verification fails, they know how to steer the agent to rebuild and fix; when monitoring surfaces an issue, they know how to have agents update the system and redeploy.

The five skills below are what make that workflow walkable. They follow Andrew Ng's order, which is the order of exposition rather than of importance.

Part 2The five skills, in Andrew Ng's order

1. Directing the workflow

The first skill is knowing how to navigate each step above. Andrew Ng defines it as deciding how much human effort and how much agent effort to spend on each, and when to go back to an earlier step to iterate.

What sits underneath those decisions is a deep understanding of the tradeoffs between speed, cost, technical risk and human effort. Once that is in place the rest becomes answerable: how much to research and plan up front, which critical work stays under human ownership, how to choose the architecture, how much detail to write into a set of planning artifacts such as a spec, and how to decompose the work into verifiable steps.

Our own reading is that directing does not mean instructing more. It means knowing which step you are standing in. Someone thin here has exactly one tell: they never leave execution. Prompt, receive, reject, prompt again, all day, without once going back up to fix the plan.

2. Enabling agent autonomy

Once an agent is applied to a step, the next question is how far it walks alone, which is the autonomy level you set. Andrew Ng asks it plainly: do you watch it and go back and forth interactively, or delegate a larger chunk of work to it? And when do you set a clear goal and have it loop until it succeeds?

This skill also carries context management. As the build moves through phases, you calibrate when key learnings, user feedback and assumptions get captured for the agent to use downstream. Andrew Ng singles out one item in that list: assumptions that changed partway through the build. Those are the first thing to go missing, because at the moment one changes, everybody in the room already knows, so nobody thinks to write it down.

Then there is the decision about when to set up many agents running in parallel on a decomposition of the task, whether a human or a higher-level agent orchestrates them, and how to manage human attention across concurrent sessions. Andrew Ng closes this skill on safety: knowing how to run agents safely, setting permissions and gating actions appropriately, so development can move quickly while the risk of leaks, data loss or other damage stays bounded.

3. Reviewing the work

Andrew Ng opens this one with the sentence the whole skill turns on: the output of a coding agent is uncertain. We do not know in advance what good ideas it might come up with, or what bugs it will implement. Reviewing and verifying is therefore not optional, both to get the result you want and to redirect the agent when you have not got it.

What you design is testing and validation matched to the task, applying behavioral and functional verification as needed. You might test user flows, perhaps having the agent provide screenshots as evidence of success or failure. For qualitative and behavioral work, eval sets can carry the judgment, perhaps with a second model scoring the first, which is the pattern called LLM-as-a-judge.

The other half of the skill is deciding how much of that to automate. Some workflows automate testing and validation completely, so the agent can check its own work and know when it has succeeded. But Andrew Ng writes one further sentence here that a lot of readers slide past: you have to evaluate the tests themselves, to make sure they correspond to your aims, and evolve them when they do not. On top of that comes agentic code review, plus AI-enabled security and architecture audits. Where AI review is not sufficient, you judiciously insert human review of code behavior, and infrequently of the code itself, while looking for ways to automate that review further. Finally you verify the deployment, and operationalize monitoring and incident management with agents.

This is the skill Part 3 of this article comes back to, because there is an assumption sitting inside it that the map never states.

4. Customizing the agent and its environment

This skill is about changing both the agent and the place it works, so it can efficiently get the context it needs, reach its tools, and build correctly and quickly.

On the agent side, Andrew Ng names integrating skills, meaning capability packs you attach to an agent rather than the five skills this article has been walking through, along with plugins and MCP servers, and, occasionally, pruning them when they are no longer necessary, such as when a new model obviates an old skill. That second half is the part people forget, because adding something feels like progress and removing something feels like nothing at all. He also names hooks, used to automate repeatable parts of the development process such as triggering code reviews or CI/CD pipelines.

On the environment side, the work starts with keeping the standing context current, files such as AGENTS.md or CLAUDE.md, holding information about the codebase, key architectural assumptions, code style and data access patterns. Then knowing how to preserve state across multiple sessions and across parallel agents, and how to accumulate agent learnings over time, perhaps through post-run retrospectives capturing what did and did not work. Then setting up consistent conventions and structure so the codebase is navigable to the agent, and occasionally clearing out agent-generated debt. And when you work in a team, considering how to coordinate context across different developers' agents.

5. Coding agent foundations

The last skill is the base that makes the other four decide well. Andrew Ng lists it out: understanding how agents carry out codebase search and retrieval, how they manage their context windows, how different operations such as adding tool calls or MCP servers affect context, how agents and subagents interact, and how the agent itself is built by wrapping a harness around an LLM.

The payoff is that the agent stops being a black box and you start recognising its failure modes. Andrew Ng names four: overengineering a simple solution, losing rigor because the agent lacks an explicit verification process, stopping short of the goal, and actions that risk destruction of files or production data. The other payoff is being able to reason about the agent's state, what it currently believes, and steer it by giving it the right prescription or context for that state. And when you are monitoring a long run, the same understanding lets you spot earlier that it has gone off-track and that you need to intervene.

The note Andrew Ng leaves at the end

After the five, Andrew Ng adds a paragraph worth reading whole. He says social media often gives oversimplified descriptions of how to use coding agents. Sometimes, he grants, it is genuinely useful to have agents run autonomously for hours and burn millions or tens of millions of tokens, the units of text a model charges for. But the practical utility of very long-horizon tasks, especially relative to their cost, "has been amplified beyond reality". What actually works is a complex, highly iterative process, where being able to intervene with high-skill judgement gives much better results.

Then he ends the post by saying the series is not finished.

Your skill at using coding agents will make you an effective builder. This positions you to also steer the overall build. I will say more about this in a future post.

The fourth box on the map is shaping the build, and that sentence is the announcement that it is next.

Part 3What the map does not ask: who reviews the reviewer

We have nothing to argue with in the five above. What we would add is one assumption buried inside the third.

"Reviewing the work" is thorough about what to check: tests, evals, agentic review, human eyes at the right moments. But every sentence in it rests on the same silent premise, which is that the instrument doing the checking still works. Andrew Ng does tell you to evaluate the tests to make sure they correspond to your aims, and that is a question about whether the criteria are right. Nowhere on the map is the question one layer before that one: is this checker still alive?

We measured that on 4 September 2026, while repairing Part 2 of this same series. Every number below comes from that day.

A reviewer that loaded none of its rules. We run an AI review bot over our writing, driven by a corpus of house rules. We invoked it through a symlink, a shortcut that points at a real file somewhere else, and its code resolved the rule files relative to the script's own path, which the symlink pointed somewhere else entirely. That round it loaded 0 of 29 rule files into itself. It then quietly picked up a 12-day-old copy of the article from an inbox instead of the current one. What came back was a verdict, the ruling the review bot prints, and it looked completely normal: observations, a confident tone, entirely believable.

The repair nobody re-reviewed. On 31 August the same reviewer had returned 3 findings. We fixed all 3, and stopped there. Nobody sent it back for another pass. When we reopened it on 4 September, clearing what was still in there took 13 more rounds, 8 on the Thai side and 5 on the English. So "3 findings, all fixed" never meant zero were left. It meant we had stopped counting.

A reviewer checking the right thing, but not the thing that was broken. That bot checks language, and checks it well. What it never once asked was whether the article had read the source it was citing. With nobody asking, Part 2 shipped naming 0 of Andrew Ng's 5 pillars, in both languages, with no diagram of the map anywhere on the page. It argued from a map the reader could not see.

A verdict is not evidence that the mechanical check ran. That review bot is read-only. It cannot run commands, so it cannot run the mechanical lint itself, and it told us so every single round. The failure was on our side: a verdict that reads as complete feels like a full inspection, and we took it as one while the mechanical checker had not run at all.

A rule that switched itself off on the live path. Our design-time lint gate for web pages carries a rule about how numerals are written. The first line of that rule said: if this is all-files mode, return nothing. And the deploy script passes all-files mode every time. So the rule was off across the entire path that actually ships, and what it printed was the word clean, which is the same word a real pass prints.

A check counting correctly, in the wrong zone. The same gate strips <script> before it checks. One day a gloss of ours landed inside the FAQPage JSON-LD, the structured data written for search engines that never appears on the page itself, instead of in the prose. The gate counted the term as present exactly once, which met the threshold precisely. Every gate went green and the reader never saw the gloss. The lesson generalises cleanly: assert the zone the thing has to land in, not the number of times it appears.

A hook that decided no check was needed. We have a pre-commit hook that classifies which commits touch prose. That day we added one glossary line. The hook classified it as not touching prose, and skipped.

Put together, these are all one shape. Green has two causes: green because nothing is wrong, and green because nothing was checked. Both print the identical string.

And one of them got it right

Not every gate lied to us. The same day, an evidence guard that grades how hard the proof in a change is bounced our commit twice, and was right twice. The reason: what we had labelled a negative control only printed a zero instead of actually failing, so the guard refused to count it as a test. It let us through once we made that control exit non-zero for real.

That is the entire difference in this story. A useful gate is one that rejects weak evidence. A gate that lies to you is one that accepts everything and prints pass. From the chair they feel the same, because both are green. What separates them is the single question below.

Part 4What you do differently tomorrow

If you already use a coding agent daily, the missing piece is rarely another tool. It is knowing which of these five boxes leaves you most exposed, and that answer is sitting in yesterday's work. Nothing to wait for.

Three things you can change immediately. First, next time a gate goes green, open ten lines of its log and look for whether it reports how many files it read and how many rules it applied. If it has never printed those numbers, you are trusting something that has never reported on itself, and that is fixable in an afternoon.

Second, change what you put in the standing context file, from instructions about what to do into a record of which assumptions have changed. Andrew Ng flags this inside the second skill, and it is the most perishable information you have. Writing it down costs a minute. Re-explaining it every session costs forever.

Third, next time you delegate a large chunk of work, choose the autonomy level by asking: if this goes off-track, when do I find out? If the answer is when it finishes, the level you picked is higher than your review can keep up with, and the gap is debt you will pay later.