To Be an AI PM, Be a PM. To Be an AI Engineer, Be an Engineer.

The titles are everywhere in 2026. AI Engineer. AI Product Manager. AI this, AI that.

There is a quiet assumption behind the trend. That the "AI" prefix is a shortcut. Learn to prompt a model, ship a quick demo, and skip the years of craft that used to come first.

It does not work that way.

To be a good AI Engineer, you first have to be a good software engineer. To be a good AI PM, you first have to be a good product manager. The prefix does not replace the job. It raises the bar on it.

The Prefix Is a Multiplier

Think of it as simple math.

AI Engineer = Software Engineer × AI.

AI PM = Product Manager × AI.

AI multiplies what you already bring. If your skills are strong, it makes them much stronger. But if there is nothing there to begin with, multiplying by AI still leaves you with nothing.

This matters because of how AI actually behaves. It does not hand you judgment. It amplifies the judgment you already have. Give it a strong foundation and it makes you far faster at building the right thing. Give it nothing to work with and it just helps you build the wrong thing faster.

Multiply a big number and you get a bigger number. Multiply zero and you still get zero.

AI Engineer: You Still Need to Be an Engineer

Start with the title itself.

Shawn Wang, known as swyx, coined the term "AI Engineer" in 2023. His definition was never "someone who replaced engineering with prompting." It was a software engineer who builds with AI, using models and APIs to ship real products. The software engineering came first.

Chip Huyen, who wrote the book on it, put it directly. AI engineering "feels closer to software engineering" than to machine learning. The models got easy to call. The hard part, building something reliable around them, is still engineering.

You can see the gap most clearly in how people use AI to write code.

Simon Willison drew a useful line. On one side is "vibe coding," shipping code you have not reviewed, tested, or understood. On the other is what he calls "vibe engineering", where seasoned professionals "accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce." Same tools. Completely different outcomes. The difference is the engineer.

Addy Osmani of Google captured why with his "70% problem." AI gets you 70% of the way fast. The final 30%, the edge cases, the security, the production integration, "remains as challenging as ever." That last 30% is exactly where engineering judgment lives. If you never built it, you get stuck there.

And when nobody is accountable, things break. In 2025, a Replit AI agent deleted a company's production database during a code freeze, wiping data tied to more than a thousand companies. The model went off script. The real failure was upstream. No separation between development and production, no approval gate, no engineering discipline around the agent. The tool did not cause that. The missing fundamentals did.

AI PM: You Still Need to Be a PM

The same pattern holds on the product side.

A working prototype is not a product decision. Knowing how to prompt an LLM does not tell you what to build, who it is for, or whether it is worth building at all. Those are product questions, and AI does not answer them for you.

Marty Cagan made the point well. As AI automates more of the delivery work, product judgment becomes the main job. The thinking that was always the heart of the role does not shrink. It grows.

Andreessen Horowitz reached the same conclusion. As routine work gets automated, they argue that vision, judgment, and taste become more valuable, not less. When execution is cheap, deciding what to execute is the differentiator.

Lenny Rachitsky framed the day to day version of this. PMs will become "editors of super-intelligent suggestions." But you can only edit well if you have the product sense to know which suggestion is right. AI gives you more options. It does not give you the taste to choose between them.

There is honest nuance here. Aakash Gupta argues that AI product sense is its own skill, distinct from traditional product sense. Working with models means new muscles: writing evals, reasoning about non-determinism, designing for outputs you cannot fully predict.

But these new skills do not replace core PM. They multiply it. Your product judgment is the base; AI fluency is the multiplier on top. The stronger your judgment, the more these new skills are worth.

The Data Backs This Up

This is not just opinion. It shows up in the data.

The 2025 DORA report, Google's large study of software teams, found that AI's main role is as an "amplifier." It magnifies an organization's existing strengths and weaknesses. Strong teams use it to get much stronger. Weak teams find their problems get louder. The tool does not fix what is broken. It scales whatever is already there.

Kent Beck, one of the most respected engineers alive, said it about himself back in 2023. "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x." The execution skills got commoditized. The judgment skills, the foundation, became worth more than ever.

That is the whole thesis in one line. AI does not replace the fundamentals. It multiplies them.

What This Means for You

If you want one of these roles, do not chase the prefix. Build the base, then build the AI skills that multiply it. Here is what that looks like in practice.

If You Want to Be an AI Engineer

Master the fundamentals first. Read code, debug it, study system design and architecture until the trade-offs are second nature. Use AI to learn faster, ask it to explain a pattern, walk through a design, or pressure test your thinking. But do not outsource the understanding. The goal is to know why the answer is right, not just to have it.
Learn the building blocks employers actually hire for. RAG, tool calling, MCP and agentic design patterns. Then go deeper into what separates demos from reliable systems: context engineering, deciding what goes into the model's window, and harness engineering, building the loops, tools, and guardrails around it. All of this multiplies solid engineering. It does not replace it.
Treat evals like tests. Hamel Husain argues that the products that fail almost always share one root cause: no real evaluation system. Learn to move past "vibe checks" to systematic measurement that catches regressions before users do. Evals are to AI what unit tests are to code.
Own the production path, not just the prototype. Evals catch regressions, but the last 30% lives here too: cost, latency, and serving the thing at scale. A demo runs once. A real system answers the same questions thousands of times, and every call burns tokens and money. Eugene Yan's fix is to cache responses to cut cost and latency. Learn to watch what a system costs to run, not just whether it works.
Ship one thing end to end. A small working project you fully understand beats any certificate. Build it, break it, fix it, own it.

If You Want to Be an AI PM

Sharpen the core craft. Talk to users. Define the real problem. Prioritize. Build the judgment to tell a good decision from a bad one. None of that goes away.
Build enough AI fluency to lead the work. Learn how LLMs, RAG, embeddings, and prompting actually work. Enough to spot real opportunities and talk to engineers as a peer, not enough to do their job.
Learn evals and LLM-as-judge. Aakash Gupta's transition roadmap puts evaluation at the center of the new skill set. This is the new skill that multiplies classic product sense.
Design for non-determinism, and own the risk. The same prompt can return a different answer tomorrow. So define acceptable accuracy, set fallback behavior for low-confidence outputs, and plan to catch bias and drift after launch. AI hands you outputs you cannot fully predict. Owning that uncertainty is part of the craft now.
Become a product builder, not just a spec writer. The role is shifting toward building. Tools like Lovable, Replit, and Claude Code let you take an idea from zero to one and test it with real users before engineering commits. Use that speed to validate ideas fast: ship variants, run A/B tests, and let real usage decide what works. A day of user data beats a week of debate.

For both, the move is the same. Build the foundation, then let AI multiply it.

The Noun Outlasts the Prefix

Titles change fast. "AI Engineer" may quietly become "Engineer" again. "AI PM" may just be "PM."

What stays constant is the craft underneath. The prefix is a tool. The noun is the skill.

Master the noun, and the prefix takes care of itself.