Andrew Ng’s AI Engineering Skills Map is the best articulation I’ve seen of what it takes to build and ship AI applications. He and his team built it from thousands of job postings, expert interviews, and survey data, and it shows. If you build AI systems for a living, read his piece before you read mine. There are several other maps he provides. My persistent thought, though… is the traditional engineering and developer skillset the one fueling the era of intelligent transformation?
It is the AI maker who will do more to bring about the era of intelligent transformation than the AI engineer will, at least at first. There are hundreds of them for every engineer, they run the processes where transformation actually happens, and the tooling is finally built for them. The question worth asking is what AI engineering skills look like in the hands of someone who was never a developer at all.
The desk clerk at a regional bank is building an agent that answers policy questions the branch used to escalate. The lawyer is grounding an agent on the firm’s clause library and teaching it when to flag and when to stay quiet. The care coordinator is wiring an agent into intake so patients stop repeating their history to four different people. None of these people write code. None of them want the AI Engineer title. And yet look at what they’re actually doing. They’re grounding models in data, designing agent behavior, deciding what good output looks like, and putting the result in front of real users who depend on it. Sounds awfully close to an engineer.
BUT is that engineering?
The maker is doing AI engineering work without being an engineer and without trying to become one. The maker builds tools from systems. The engineer builds systems. The outcomes are the same. The pathway isn’t. And makers think in outcomes: how do I get the result I need? That’s what the map below is for.
And yes, we’ve heard a promise like this before. Citizen development was going to change everything, and in plenty of organizations it stalled. Keep that story in mind, because the reason it stalled is the last row of this map.
The first row is the decision that happens before anything gets built. The middle three will look familiar to anyone who has spent time within any maker platform, because they’re usually the panes on the build screen: instructions, knowledge, skills, tools. The last one is what lets everyone else rely on it.
Platform judgment. The skill every other one depends on, because the first decision isn’t how to build, it’s where: a saved prompt in Claude, ChatGPT, Gemini, or Copilot Chat, an automation in Power Automate, an agent in Copilot Studio or Gemini Enterprise, or a task handed to Cowork. Knowing which fits which problem saves more effort than any build technique on this map, and it rests on a basic education in what each platform can and can’t do. “What is it?”
Instruction craft. Some people sit down wanting to understand a model. Makers aren’t those people (enter my mother), and the average maker will never pick one. In many cases model routing exists so they don’t have to. This skill is simpler to say than to do: telling the agent what to do. Be specific about the job. Give it a role, the constraints that matter, and one example of a good answer. Tell it what to do when it doesn’t know, and tighten the instructions when behavior drifts, because it will. The craft is growing too, because skills are becoming part of foundational instruction. A skill is largely instructions with a name and a trigger, run on demand, and even the harness underneath the agent, once strictly engineer territory, is now something makers choose and author against. “What should it do?”
Knowledge curation. The agent only knows what you give it. Feed it messy or outdated sources and it will answer confidently from them, and no model is smart enough to tell the difference. So the maker is the data steward now, and the training is plain. A tight set of current sources beats a big folder of maybes every time. The maker SHOULD hold the advantage here because they already know where the real information lives, down to the spreadsheet the whole department quietly runs on. “What does it know?”
Component discernment. An agent without abilities is a chat window, and the skill here isn’t adding things, it’s timing: knowing when the job calls for what. A connector when the agent needs to reach the ticketing system. A flow when a request has to travel end to end. A skill when the know-how itself is the value: how we write client emails, how we triage a claim. Watch skills especially, because they’re becoming the new low-code. As a side thought, when does it need to have human review? Or, how about deterministic vs non-? “When do I use what?”
Evaluation discipline. How do we check an agent today? We type something in, look at the words that came back, and call it good. For personal use, that may fly. GUILTY. The moment other people consume what your agent produces, the same habit turns risky, because the misses land on people who didn’t sign up for them. This is an area that all of us just plain suck at. It’s also the exact spot where the first citizen development wave stalled. I was talking with Ashish Bhatia at AICO in Boston about vibe-checking in workforce AI, around two years ago, back when the tooling barely existed. The tooling showed up, BUT the habit stayed with all of us… engineers vibe-check too. This is the skill that separates an agent people use from an agent people trust. “Is it right?”
Every organization I work with is somewhere on the same curve, and it’s a curve about people, not products. It runs Unaware, Literate, Capable, Fluent, Leading.
Unaware means AI hasn’t touched the role yet, or it has and nobody noticed. Literate means the person understands what these tools are and uses them when prompted. Capable means they reach for AI on their own to solve their own problems. Fluent means AI is simply part of how the job gets done, every day, without ceremony. Leading means they’re building agents that other people depend on, and directing agents the way a lead directs a team.
The AI maker emerges in the gap between Capable and Leading, the stretch where someone stops consuming AI and becomes accountable for what it does. Someone might travel it through Copilot into Copilot Studio, or through Gemini Enterprise into the agent platform. Toolset doesn’t matter. What has to change along the way is the person.
So how does a workforce actually start changing? Left alone, it happens organically, slowly and unevenly, one curious person at a time. Built deliberately, it’s how an ordinary organization becomes a frontier one. This is training, adoption, and changing behaviors and norms, not buying products and hoping. I say it often. Product purchase doesn’t equal practice.
If you lead, teach the middle column of the map like the curriculum it is. Stand up office hours where makers bring what they’re building and get unstuck. Form a champions group and let your Capable people run it, because they’ve already raised their hands by building agents whether you sanctioned it or not. Give them environments and governance instead of obstacles. AND for God’s sake measure the program by movement along the curve, not seats deployed!!
So, back to my persistent thought. No. Engineering built the platforms, and it built them well. But the era of intelligent transformation gets fueled by the people who put them to work. There’s a decent chance it’s you.