Last week, Andrej Karpathy stood in front of a room at Sequoia‘s AI Ascent event and told everyone that vibe coding (a term he invented and made popular) was already obsolete. The future, he said, is agentic engineering. He went on to list exactly what agentic engineering actually involves: 

• writing design specs
• supervising plans
• inspecting diffs
• writing tests
• building evaluation loops
• managing permissions
• preserving quality

I was pleasantly surprised to see this list of activities. In fact I posted about it on Linkedin and added in this bit: strip the engineer-specific vocabulary, and you have product management.

I was surprised with the response in the comments. Engineers pushed back hard saying that agentic engineering is technical and that it requires understanding the codebase. Product managers showed up in the replies sounding almost relieved, like someone had finally described their job in a way their organization might take seriously. Both groups were reacting to the exact same list. They just couldn’t agree on what to call it.

That disagreement is interesting in that, depending on who is doing the talking, the work could take a different form. The question is, should it? Let’s take a detailed look. 

Karpathy described a job. It already has a name.

Walk down his list and translate each item out of engineering vocabulary and into the work itself.

Writing design specs means someone is deciding what should be built and writing it down clearly enough that someone, or something, can act on it without you in the room. That is problem definition and hypothesis writing.

Supervising plans is looking at a proposed sequence of work and deciding whether it is actually heading somewhere worth going. That is prioritization and it involves human judgment to drive it.

Inspecting diffs is examining what got produced and deciding whether it solves the problem you set out to solve. That is the difference between “the thing was built” and “the thing delivered customer value.”

Writing tests and building evaluation loops is defining, in advance, what “works as designed” should mean and then checking what was built against that definition instead of against your hopes or your boss’ expectations. The test is (or should be) based in outcome thinking. It is the entire reason success metrics should exist.

Managing permissions is deciding who gets to change what, and where the boundaries sit. That is scope and stakeholder alignment as well as alignment with the predefined goals.

Preserving quality is holding a line on what is good enough to ship when every incentive in the building is pushing you to ship faster. That is the hardest judgment call in product work, and it’s nothing new. It’s always been this way.

Karpathy did not describe a new discipline. He described the fundamentals of product management.

Why the bottleneck moved

As execution increasingly stops being the bottleneck, the next bottleneck becomes visible. And the next bottleneck is decision-making, direction and prioritization. It is, at its core, knowing what to build, for whom, to help them do what, and what market signals will tell you it worked.

This is the same constraint I wrote about when Steve Blank’s customer development model started straining under AI. The risk is no longer building too slowly, it is building too much, too confidently, toward the wrong outcome. Karpathy is describing an engineering-centric view of this problem. He is an engineer talking to engineers, so he reached for the language they understand. But the thing he is pointing at is not engineering in the “writing code” sense. It is the discipline of deciding. Engineers are now spending their days doing it because their coding agents do the typing for them. They are discovering, in real time, that the typing was never the whole picture nor the hardest part.

The uncomfortable part

Here is where this potential disconnect between engineering and product management gets a little dicey. For years, a meaningful share of the engineering world treated product management as ceremonial overhead. Product managers were the people who wrote the tickets, ran the standup, and slowed everything down. And, for better or worse, there were and still are a high percentage of teams that have their PM’s doing exactly these things. I have sat in rooms where “do we even need a PM on this one” was a serious question.

Now the most respected voice in AI research has stood on a stage and described the essential, irreducible (and often invisible) work of building software and it is, almost line for line, the product management job. Not the ticket-writing version. The real one.

If you are a product manager who has spent years being told your job is administrative, this is the validation you have been waiting for. It is also a warning. The work was always experienced decision-making and continuous learning. If you spent those years doing the clerical version instead, the part that just became valuable is the part you may have allowed to atrophy.

If you are an engineer now doing “agentic engineering,” you have inherited the product management job whether you wanted it or not. The agent will write the code. It will not tell you whether the code was worth writing. That part is yours now. Or, perhaps, this is the wake up call to build a stronger collaboration with the folks in the product management org. 

How do we bring agentic engineering and product management together? 

Take Karpathy’s seven items. Treat them as a self-audit, not necessarily a vindication or  celebration.

For each one, ask the honest version of the question. Not “do I do this?” Everyone can claim they do. Ask yourself which version of the job you’ve been doing, the administrative version or the one based on experience and expertise?

Specifically, challenge yourself:

• Do I write specs that frame a problem worth solving or specs that describe a feature someone already decided on? 
• Do I supervise plans by asking whether the destination is right or by checking that the dates line up? 
• Do I inspect what got built against the outcome it was meant to achieve or against the ticket that told someone to build it? 
• Do my tests measure whether a real person’s behavior changed or whether the feature shipped? This last one is the difference between an output and an outcome, and it is the muscle AI is least able to fake for you.

The admin version of every one of those activities is now automatable, and it will be automated. The judgment version is the job. It was always the job. AI just removed every place that was left to hide from it.

Karpathy called it agentic engineering. Call it whatever helps your organization take it seriously. But do not mistake the renaming for a new skill. The skill is fundamental and has been around for decades. What is new is that AI has made it more than clear that this is where the real value of product management lies.