Ng says respect the org's constraints,
not where to draw the line.

You direct agents as a matter of routine now, and yesterday you shipped something nobody asked for. It was good. People liked it. Nobody asked who approved it.

Then there is the other kind of day, the one you do not retell. You hand over a brief, the agent runs for forty minutes, and what comes back is better looking than what you asked for and is not what the brief said. Or worse: the person who changed the brief was not the agent, it was you. You read the output, something in it bothered you, so you moved the requirement two inches until it sat right, and you told no one.

On screen those two days look identical. In both of them a competent person saw a problem and acted on it without waiting to be told. The difference is whose decision it was, and nothing on the screen tells you that.

This is not only a coder's problem. If you are a PM (product manager) who has started directing agents yourself, you hit it sooner than anyone. For your whole working life your boundary was set for you by other people. You wrote a spec, and someone came back and asked what you actually wanted here. That question was the boundary. When you direct an agent, nothing asks back. It will follow what you wrote all the way to the end, and then fill in what you did not write, and no sound is made while it fills.

On 11 September 2026, Andrew Ng published the last instalment of his AI engineering skills map, on area four: shaping the build. Part 3 of this series closed by quoting his own promise to write about it in a future post. That post has arrived, so this series ends on this page.

Productize has followed Andrew Ng's AI engineering skills map through all three earlier parts, while directing agents to build and run systems that are live every day, and writing the process down as posts on this blog. So this piece walks his four competencies in his order first, and only then turns to the thing we measured ourselves and found the map does not supply.

Part 1The one sentence carrying this whole article

Andrew Ng opens the post with a single sentence that everything else rests on.

When you're skilled at AI Engineering, your best work won't be merely implementing a product that someone else spec'ed out. Instead, you will actively shape the build.

He then gives the history. Before modern AI tools accelerated and expanded what a single developer could do, tech companies had settled on a practice: product managers and designers specify what should be built, and developers build it, with a project manager sometimes driving the timeline on top. Those roles, he writes, are now blurring. A developer skilled at AI engineering does not only build software, they take part in the other roles too. He puts the symmetric case in parentheses: product managers and designers are gaining AI engineering skills and taking part in building software.

The consequence, in his words, is that software development is vastly accelerating, because once you know how to shape the build, you can move faster without waiting for a PM to figure out what to do.

Anyone who directs agents daily recognises that sentence as true. It also opens a question the post never closes: if you no longer wait for the PM, how do you know which things you still have to wait for? Part 3 comes back to it.

Andrew Ng's AI engineering skills map divides top-level skill into four areas: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build. Part 1 covered the six sub-skills of the first area, Part 2 covered the five pillars of the second, Part 3 opened the third into five skills. This page is the last area.

He lists four key skills for shaping the build: driving the build loop, making product decisions, communicating and leading, and high-agency ownership. Below is all four, in the order he wrote them, which is not an order of importance.

Part 2The four competencies, in Andrew Ng's order

1. Driving the build loop

He opens with the sentence the whole item rests on: most software is built via a loop in which you write some code, then get some feedback, and decide what to do next. A skilled AI engineer plays a key role in driving that loop, repeatedly deciding the next step that moves the project forward. His phrase is a bias for action, driving the loop at the high velocity AI has made possible.

He then lists what each turn of the loop actually decides between. You might build a quick prototype to test a technical concept or a user feature, build an MVP to take to users and demonstrate value, add features, or invest in an enterprise-grade system. You ship in small batches, frequently, to keep velocity up.

The other half of the item is timing. You know when to get feedback from users or other stakeholders, and when instead to run a technical experiment, such as training a model, to gather the information that decides the next step. Those calls weigh several things at once: the product vision, the stage of the project, technical feasibility, key risks, effort and budget. For more mature projects he adds one more requirement, which is knowing how to define key metrics and then project-manage the work until those metrics actually improve.

Our own note: agents did not change the shape of this loop, they changed its speed, and the speed is now past what the driver can track. When one turn took three days, you got thinking time between turns without having to schedule it. A turn now finishes in twenty minutes. The slack that used to hold the thinking left along with the time it was made of. The symptom of being thin here is single and easy to spot: the loop turns all day and not one turn ends in a decision written down anywhere.

2. Making product decisions

This item opens with the most quoted line in the post.

Developers don't have to become PMs, but you will make decisions the product spec doesn't cover.

He follows it immediately with the harder half: if you are asked to build without a spec, you know how to develop one.

Underneath the competency he puts product sense, which lets you pick a product direction that meets real user needs without waiting for a PM to make every decision. Then at least a basic design sense, so you build things that are not merely functional but pleasing to use. Then some basic business sense, so you can think through go-to-market, market size, unit economics and profit and loss, and make tradeoffs that are economically sensible.

All of it, he says, is rooted in user empathy, and he insists that empathy has to be continually honed, across a range of methods: quick informal interviews with two or three users, surveys of hundreds, large-scale A/B tests, or analysing the behaviour of thousands or millions of users, with the results fed back into your understanding.

Our own note sits on the phrase "decisions the spec doesn't cover". Gaps in a spec come in two kinds that look identical at the moment you meet them. The first is a thing the owner never thought about, which is yours to fill and they will thank you. The second is a thing the owner did think about, decided, and left out because it seemed obvious. Fill that one and you have not helped, you have overwritten. The map gives you permission to fill the gap and no way to tell which gap you are standing in.

3. Communicating and leading

He opens on scope: AI engineering skills let you take part in a broader scope of work than traditional software development allowed. He refers back to his earlier writing on how specialised developers, frontend developers for instance, are now likely to play a broader full-stack role, and says AI engineering opens the door wider still, into other functions that affect your project such as marketing, finance and legal.

Because the scope is wider, communicating with those functions matters more than it used to. You can play a key role in moving your project forward by aligning and coordinating among stakeholders. He adds, in parentheses, that communication skills also form the foundation for speaking with users and honing that user empathy.

The second half of the item carries real weight. Because AI technology is evolving rapidly, many people outside engineering are trying to understand the technology, its impact on their jobs, and the practices and products it now makes possible. Your technical skill puts you ahead of the game and lets you play a unique role in shaping those perspectives: you can explain why certain initiatives are technically feasible and why others are not. That, he writes, is how you help lead your broader organisation forward.

Our own note: this is the only one of the four items that treats other people as people who need to agree, rather than as friction. It is also the one a solo builder drops first, because when you can build the whole thing yourself, explaining it to anyone before you start becomes a cost you can simply delete. Deleting it does not hurt at all, right up until the day the thing you built touches something that belongs to someone else.

4. High-agency ownership

This is the item Part 3 of this article returns to. He opens on the opportunity: AI engineering skills give you vast opportunities to make a difference. However, many people, including some executives, do not yet understand what AI can do and therefore do not know what good project directions look like.

That, he says, is the opening for someone with technical skill to bridge the gap, and then comes the sentence at the centre of the item.

You can spot problems, propose solutions, and execute on them — being respectful of the organization's priorities and constraints, but without waiting for precise top-down direction.

Hold on to that sentence in full. Part 3 comes back to all of it, including the clause in the middle.

He continues: this skill requires a high degree of agency, in which you identify opportunities, prioritise what matters, and act on them. You also know how to own an initiative end-to-end, take accountability for issues that arise, act in the face of ambiguity, persist through setbacks, and measure your work not by task completion but by the value you create.

He closes the item with a short paragraph on staying current: you invest in improving your skills, track the technology frontier, pick up new tools, tune your workflows, and keep learning, so you get better over time.

The note Andrew Ng leaves at the end

Having walked all four, he closes the post, and the whole map, in one paragraph.

The opportunity to not just build but to shape the build makes AI Engineering more exciting than traditional software development. You are more empowered, have broader scope, and make more decisions. But doing all this well requires a larger set of skills. DeepLearning.AI's focus is to help you, if you wish, become skilled at AI Engineering.

I look forward to the road ahead!

Notice that the middle sentence says the same thing three ways: more empowered, broader scope, more decisions. This is a map of expansion, from end to end. Nothing anywhere on it is a map of stopping, with the exception of half a sentence inside item four, quoted above.

Part 3What the map does not ask: where does your ownership stop?

The short answer is that the map does name that boundary, but it names it as a value rather than as a mechanism. Andrew Ng writes, in plain words, that you are to be respectful of the organisation's priorities and constraints, which is both correct and important. What is missing is any way to tell whether the thing in front of you right now is you respecting a constraint, or you walking straight through one while calling it initiative.

Let us be exact, because this is checkable in one click. The sentence about the boundary is genuinely there in his post, inside item four, in the passage quoted above in full. Anyone who tells you the map never mentions it is wrong.

What is missing is a different thing, and it comes in three pieces.

1. No test for which decisions are yours. The post says you will make decisions the spec does not cover. No line separates the decisions the spec does not cover because nobody thought of them from the ones it does not cover because the owner already decided and thought it went without saying.
2. No stop condition. Every instruction in item four is an instruction to continue: act in the face of ambiguity, persist through setbacks, own it end-to-end. No sentence names a signal that means stop here and ask.
3. No way to tell respecting a constraint from waiting for permission. His sentence holds both in one breath, one as a virtue and one as a defect. From the worker's seat they begin with the identical act: not proceeding, and going to ask someone first.

A value with no mechanism under it cannot be acted on. What happens instead is that everyone quietly supplies their own mechanism, calibrated to how they feel that day, which works extremely well until the day it does not.

13 July 2026: our agent overwrote the owner's brief

Every number below comes from one day's own post-work record. The filename we gave it at the time was "the brief I rewrote".

It was a twelve-hour day, 08:30 to 21:30. The work was a character bible (the document that fixes how each character looks and what its details are) for ten characters for a visual production. By the end of the day it had produced roughly 230 images at a cost of about eleven dollars, across six commits. The work was done by our own agent, following a brief the owner had written.

In that brief, the canon for one character was explicit: a translucent child figure, circuitry and chips embedded in the body, deliberately unclothed. The first round of images came back looking uncomfortable, so the agent decided to add a bodysuit and tunic. The next round still did not sit right, so it swapped that for shell armour.

That is the brief being overwritten twice, and nobody was told, because inside the agent's own head at the time it was not overwriting anything. It was exercising judgement.

The detail that makes it worse comes next. The canon reference file sat exactly where it had always been, all day, and was never once opened. The agent built bibles for ten characters using nothing but a single half-body reference image each, and inferred the rest.

At the end of the day the agent wrote its own summary, stating that it had reviewed the output by eye and everything passed. The owner then went through it personally and circled roughly fifteen defects: objects held with no visible grip, props facing away from the character who was supposed to be reading them, characters with no shoes, asymmetric items mirrored to the wrong side. Twenty-eight images had to be redone. All fifteen of those defects had already passed under the agent's own eyes.

Then the owner typed the sentence that has been a permanent house rule ever since. In the original Thai it reads: if it cannot do it, go use another model. Rewriting the brief is not okay.

Here is where this touches the map. Lay 13 July over Andrew Ng's item four, phrase by phrase.

• Spot problems · yes, the output genuinely was uncomfortable
• Propose solutions · yes, add clothing
• Execute on them · yes, twice
• Act in the face of ambiguity · yes
• Persist through setbacks · yes, regenerating until it looked right
• Without waiting for precise top-down direction · it did not wait at all
• Own an initiative end-to-end · all day

That day passed every criterion on the map, and it was wrong from beginning to end. Not because too little was done, but because what was done belonged to someone else. A map scored on ownership and action has no instrument that can separate a day like that from a good one.

So how do you know which decisions are yours?

The test we use has three tiers. We wrote it before 13 July, and 13 July is what proved that having written it down is not enough: it has to be asked before the work starts, not during the summary afterwards.

The single question that sorts the tiers is if this is wrong, who carries it. Not "is this hard" and not "can I do this".

• Downstream · reversible if wrong, inside a scope the owner already granted, and the consequence lands on the work rather than on a person · decide it, do it, report afterwards, do not ask
• Midstream · recoverable but expensive, or more than one option is genuinely about as good · think it through together, decide together
• Upstream · irreversible · reaches outsiders · touches money · or changes something the owner has already decided · gather the information, give a full recommendation, and let the owner decide

On 13 July, that character's clothing was plainly upstream, because it changed something the owner had already decided and already written down. Asking the question takes a few seconds. Not asking it cost two regeneration rounds plus a quantity of trust that has no price on it.

The test needs no ceremony to be used on ordinary work. Here are three situations anyone directing agents meets most weeks.

Note that the third row is the one that looks most like excellent initiative. It solves a real problem, it fills a real gap in the spec, and it is the only one that has to stop. The size of the idea does not sort the tiers. The price of being wrong does.

What the map is genuinely missing is not the test, it is the stop conditions: the sentences that say when you see this signal, stop and ask. We have three. Each came out of a specific mistake with a date on it.

One: discomfort is not evidence that the brief is wrong. This one comes straight from 13 July. When the output bothers you, the correct order is to open the source document first, then try using the source directly as the reference instead of describing it yourself, then change the tool or the model if that still fails, and then, if you think the brief has a real problem of ethics, law or brand, ask the owner. The only forbidden move is to go quiet and fix it. This worked immediately: the moment we used the canon itself as a direct reference, the image problem disappeared in one round. The answer had been inside the brief the whole time.

Two: a proposal met with silence is a no. If you have offered something twice and the owner engages with everything else but never touches that, the silence is the answer, and the answer is no, not undecided. We measured this one on ourselves: our agent re-pitched a single suggestion roughly thirteen times across several sessions. The owner never typed a refusal once, and instead answered by committing the thing in question and keeping it, which is a clearer answer than words. Every re-pitch after that was not diligence, it was not listening.

Three: a narrow go-ahead is not a scope mandate. When an owner says this is good, they have approved the thing they just read, not the adjacent decision they never chose. On 24 June 2026 we were caught twice in a single session on exactly this: once by treating approval of the content as authorisation to publish in one language when the standard for that piece was two, and once by inventing the release order. The question that prevents it is short. Does this go-ahead still have a decision inside it that the owner never made? If it does, name the decision out loud and confirm it. Do not infer it.

All three are one pattern. A decision the owner has already made does not stop existing because you cannot see it. And the dangerous moment is not the one where you know you are crossing a line, it is the one where it feels like helping.

The counterweight, from Marty Cagan

The one claim in Andrew Ng's post that has drawn a serious argument is that the roles are blurring, and the person arguing is Marty Cagan, writing at SVPG, the Silicon Valley Product Group, on 10 August 2026. His central line:

People that are really good at using the tool are not the same people as those that are really good at creating the tool.

He gives the example plainly: you have to know a lot about sales to make good sales software, but being good at sales does not make you good at making sales software.

At a glance the two men contradict each other. Read slowly and they are answering different questions. Andrew Ng answers what one person is now capable of doing, and his answer is: far more than before, which is true. Marty Cagan answers who is accountable for whether this thing should exist at all, and his answer is that the question does not change owner just because somebody else can now pick up the tool.

Lay that over our own case and it fits exactly. On 13 July the agent's capability was more than sufficient to put clothes on a character. A wider capability did not move the ownership of the question of what that world should be. Capability expands. Accountability does not move with it.

Part 4What you do differently tomorrow

If you already direct agents daily, what is missing is usually not the nerve to decide more. It is a written sentence saying which things are not yours. That sentence can be written today.

Three things you can change immediately.

First, add two lines to the next brief before you send it. The first line starts "decide this yourself" and lists the reversible things. The second starts "ask first" and lists whatever touches outsiders, touches money, or touches something already decided. If you cannot write the second line, that is this entire article's answer to you: you are handing out work without yet knowing where the boundary is yourself, and the person receiving it has no way to know either.

Second, the next time something that comes back bothers you, open the source before you change anything. Then count: of the last five times you nudged something because it did not sit right, how many times did you actually open the source first? Ours on 13 July was zero for the whole day, and the answer was in the source the entire time.

Third, spend fifteen minutes on the last five things you decided on your own and ask, one at a time, if this is wrong, who carries it. Any item where the answer is not you is an item where you picked up something that belongs to someone else without noticing. It is usually the item you are proudest of, because it is the one you put most of yourself into.

All three together take under half an hour, and not one of them needs anyone's approval, which is a funny thing to notice in an article about knowing when to ask. Knowing where the boundary is has always been work that sits inside your own territory.

Which of your four areas is thinnest?

Answer from yesterday's actual work, not from intentions. Whichever question makes you hesitate is the one to spend effort on.

• Driving the build loop · how many turns yesterday ended in a decision written down somewhere? If the answer is none, you turned the loop all day without driving it.
• Making product decisions · the last thing you filled in yourself because the spec did not cover it: how did you know nobody had thought of it, rather than that someone had already decided it?
• Communicating and leading · when did you last explain something to a non-technical colleague before you started building? If you cannot remember, what you are building is touching someone else's work while they still do not know.
• High-agency ownership · what is the last thing you stopped and asked about? If nothing comes to mind, that is not a sign you own your work well. It is a sign you have not met the boundary yet, or you have already crossed it without noticing.

Pick the thinnest one and make it adequate, not excellent. Adequate across all four is worth more than excellent at two and absent at the other two.

Closing the series

The map is complete now. Part 1 took building and deploying AI applications, Part 2 took software engineering fundamentals, Part 3 took using coding agents, and this page took shaping the build. The series ends here.

What this map does very well is the thing a map is for: it tells you what the whole territory contains, and where on it you are standing. Part 1 of this series said that a skill without a name cannot be practised, because you cannot tell what you are practising. This map has given every area a name.

What it does not do is not a flaw in the map, it is a different question. A map tells you how far the territory goes. It does not tell you which part of it is not yours. And in a year when one person's capability is expanding faster than the agreements between people can keep up with, the second question gets more important every month.

Andrew Ng ends his post with "I look forward to the road ahead!", and so do we. One sentence to add: the road really is getting wider, and that is exactly why you want to know where your lane is.

Read back: Part 1, Andrew Ng's AI Engineering Skills Map, whose Part 4 opens the six sub-skills of building and deploying AI applications · Part 2, You did not skip the decision, whose Part 3 takes on data, the one pillar that fails without a sound · Part 3, Using coding agents, whose Part 3 asks who reviews the reviewer.