AI Took the Middle. PMs Get Judged on the Ends.

Here’s a test I’ve started running whenever someone shows me an AI integration that works.

Say someone connects an internal tool to Claude in about the time it takes you to ask how long it’ll take. You type a question in plain English and the answer comes back from your own data. Impressive. Then you notice the access token has a row of permission checkboxes, and you ask the obvious question: what happens if we check all of them?

The answer is usually some version of “then it can do anything.” Add records. Delete every record. Swap the logo for a picture of a cat. Nobody’s planning to do that, obviously. But I’ve laughed at that answer more than once, and then stopped laughing, because it’s a little scary how much access you can hand out with one click.

That moment is the other half of something I keep seeing in how product work is changing. AI has taken over the middle of the job: the typing, the pivoting, the reformatting, the drafting. The middle got cheap. The two ends didn’t. What you ask for, and what you let it touch, are now where a PM earns their keep, and most PMs are underinvesting in both.

The middle is the cheap part now

Start with how much of the middle is already gone.

I recently pointed a model at a dataset of a few hundred thousand rows and asked it questions in plain English. This used to suck. Open it in Excel, build a pivot, wait, realize you grouped by the wrong column, wait again. I had answers before my coffee got cold. I know this is trivial. But with all the talk about what AI can do, hardly anyone brings up the data work, or how fast it is.

Every PM also carries a mental list of tools they wish existed. Something that turns meeting notes into tickets and files them. Something that rolls up what engineering is working on into a weekly update for leadership. For most of my career that list just sat there, because nobody was going to spend engineering time saving the PM half an hour a week. Now you can build those yourself in an afternoon. I’ve built both of the ones I just described. Gone are the days of doing that by hand.

The model underneath matters less than you’d think. I’ve tested one prompt across several models and it holds up across almost all of them. Same instructions, roughly the same output. The tools are pulling apart on other things instead. Claude seems purpose-built for long, structured work. ChatGPT is great at forms and slightly complex tasks in that direction. Muse, Meta’s personal agent, is impressive in a way you have to use to believe. Which one you pick matters less than what you tell it.

So if the middle is cheap for everyone, it can’t be where you stand out. That leaves the ends.

The front end: your prompt is your spec now

A lot of code and documents are going to be written with AI. That’s just a fact. What will separate quality is the quality of the prompting. The time you spend on the prompt replaces the time you used to spend handwriting the doc or the code.

Most PMs haven’t made that switch. Watch how a lot of them work with an LLM and it’s a little horrifying. A one-line prompt, a few seconds of thought, paste whatever comes back into the PRD. And the document sucks. You can tell. It has the shape of a spec with none of the thinking. Nobody gave it guardrails or kept it in scope. Someone typed “write me a PRD for this” and hoped.

I get why. Speed is the whole pitch. But give it the right framework and real context, spend a few minutes getting the prompt right, and you save hours of document writing. The trade is so lopsided it’s almost funny that people skip it. I’m not saying prompting is the end-all. There’s still value in hand-editing documents, and I still do it. But a throwaway prompt versus one you actually thought through? It’ll be obvious who spends time refining their prompts. It already is, if you read their docs.

Engineering is going through the same shift, under a different name. An engineering lead I know calls it spec-driven development: you spend far more time defining the spec, then hand the implementation to a model, sometimes a cheaper one, because the hard thinking is done. On small tickets, the developer is basically QA now. The model writes it, the developer checks it.

So engineers are turning into expert spec writers. That doesn’t shrink the job. Writing a spec a model can build from, one that stays in scope and knows what good looks like, takes real skill. Meanwhile product is reforming into builders and prototypers. Things a PM would have filed a ticket for a year ago, they can just build.

The two jobs are walking toward each other, and they meet at the same skill: describing what you want clearly enough that something else can do the middle. If you’re a PM, that skill used to be one part of your job. Now it’s most of it.

The back end: own it, and limit it

The second end is the one PMs think about least. Once the thing is built, do you understand it, and how much did you let it do?

Ownership first. Engineering leads I talk to keep raising the same worry. When most of the code is AI-generated, who owns it? Practically, I mean. The version I keep hearing: a demo breaks, and the person who built it can’t find where the error is coming from, because the AI wrote that part and nobody ever learned where things live.

I don’t need anyone to walk me through the code. I never wanted the tour. I want to know how you did it: the concept of the implementation, where the pieces are, how they talk to each other, why it’s built this way. If a builder can’t explain any of that, it’s a problem no matter who typed it. And you can see the shift when you sit with developers now. Ask about an implementation and a lot of them scroll through the code and narrate it, the way you’d read a colleague’s work. People are less intimate with their own code than they were a few years ago.

The more you trust AI, probably the worse it gets.

One engineer put it in a way I liked. AI-generated code is just another layer of abstraction, like C on top of assembly. Nobody reads their compiler’s output, and that’s fine. But you still have to understand the layer you work in. If your layer is now the spec and the prompt, you’d better understand those. That applies to PMs as much as engineers. If an agent built your prototype, can you explain how it works to the engineer who has to make it real?

Then there’s access. I know an engineer who still sets up DNS records by hand, one at a time, because change the wrong record and the whole domain goes down. They don’t trust AI with it. I used to think that was overcautious. I don’t anymore.

Because look at what the rest of us are doing. I’ve let a personal agent into my email and told it to decide which invites I should accept based on my calendar and my mood. When I installed it on my desktop, it asked for permission to read and write my messages. I clicked yes. I’m still a little amazed that’s allowed. I also don’t want any model training on a dinner conversation I’m having. Both of those are true about me, and I haven’t worked out where the line is. I doubt your users have either.

The market is starting to ask the same question. Okta announced a control plane at its annual conference for managing AI agents’ identities and what they’re authorized to do, and Forrester’s recap headline said the governance and identity details were still unclear (Forrester). That sounds right. Everyone can see the problem, and nobody has a clean answer yet.

For a PM, that makes permissions a product decision. Which roles can do what. Whether a token inherits the creator’s access or gets its own. Whether the default is read-only. What an agent can never do, even if someone checks every box. Those used to be settings an engineer chose late in the build. Once an agent can act on them in seconds, they’re part of the spec.

Plan for next month, not next year

There’s a lot here I’m not sure about.

If you were coming out of college now and applying for your first engineering or product job, what would you even apply for? New grads will learn how to work with AI. That’s the easy part. What they might not learn is what’s under the hood, because they’ll never have to build enough by hand to really get it. And being able to explain how something works mostly comes from having built things the slow way at some point. Maybe that stops mattering. Maybe in a few years nobody reads AI-written code at all and the spec simply becomes the code. I can see that world. I can’t tell whether we get there before or after a lot of teams ship systems nobody can explain, with tokens that can do more than anyone meant.

What I do know is that the planning horizon has collapsed. You can’t think about this in years now. It’s more like: what is next month going to look like? I’ve been in product a long time, through a lot of platform shifts. Nothing has been like this. Nothing. The speed at which jobs are changing, PM included, is unlike anything I’ve seen.

So here’s something you can do in your next spec. Add two sections that most PRDs don’t have. The first says what good looks like, written for the model that will draft the code, the copy, or the prototype. The second says what the agent or integration must never be allowed to do, written for whoever sets the permissions. Both are short. Both take a few minutes most people skip because the tool is fast and the click is easy.

Both are also cheap to get right up front and expensive to fix later. That’s what the ends of the job look like now, and it’s where a good PM shows.