When product people open their own PRs

Once you have built a few things yourself, tools that used to be a black box stop being one. GitHub is the obvious example. Git, repositories, branches, the main branch, pull requests, commits, merges, reviews. These stop being words developers say in meetings and become a workflow you understand from the inside. You know what a pull request is for, why review exists, what it means to merge into main and why people are careful about it. And understanding that workflow changes what a Product Manager can plausibly do inside it, rather than just adjacent to it.

Here is the shift I believe in. I don't think Product Managers will keep only defining requirements and handing them across a wall to engineering. I think they will increasingly use AI to turn those requirements into a first technical draft. Not a finished feature, but a starting point that already runs, that you can click, that makes the conversation concrete instead of hypothetical.

I am building toward this in my own work. The goal I have set myself is a working MVP of this model in my day-to-day: a setup where AI takes a requirement and doesn't just write the ticket, but goes further. It generates the ticket, produces a first cut of the code, opens a pull request, drafts the documentation, and handles the recurring glue work around all of it. This is roughly what people have started calling agentic software development, where the AI doesn't just answer but acts, across several steps, with real tools. It is not science fiction; coding agents like Claude Code, Codex, Copilot's workspace and Devin already do pieces of it today, and early teams are experimenting with exactly this, cautiously, with mixed results.

In that world, the Product Manager is no longer only a translator sitting between business and engineering. They arrive with a first, working proposal in hand. The developers then do the part that was always the hard, valuable part, and always will be: architecture, code quality, performance, security, scaling, the edge cases nobody thought of, the review that catches what the draft got wrong. AI handles the operational layer: the first draft, the boilerplate, the tests it can generate, the CI it can wire up, the documentation nobody wanted to write. The human stays responsible for the decisions and for the result.

Done well, two things happen. Product development gets meaningfully faster, because a first draft exists before the conversation even starts. You are editing something instead of imagining it. And the communication between product and engineering gets better, because both sides are finally looking at the same concrete thing instead of arguing about two different mental pictures of the same paragraph.

I know this can sound like a contradiction with where I started. In the first piece I argued that AI should free me from operational work; here I am arguing that product people should take on more of the building. But it is the same move seen from two sides. AI removes the low-value repetition (the status updates, the ticket typing, the copy-paste) so that a higher-value contribution becomes possible: arriving with a running draft instead of a document. It does not pile more work onto the same day. It changes which work is worth a person's time, and pushes the human contribution up the stack, toward judgment and away from typing.

I want to be blunt about the fear underneath all of this, because I do not share it. I do not think developers become unnecessary. I think the opposite happens. The more capable AI gets at producing a first draft, the more valuable experienced engineers become. Someone has to own the architecture, the security, the way the thing scales under real load, and the plain, unglamorous question of whether the generated code is any good. Reviewing is not a lesser job than writing. When the writing gets cheap, the reviewing becomes the job, and judgment becomes the scarce thing.

There is a real failure mode here that I would rather name than hide: a bad first draft can be worse than none at all. Reviewing sloppy generated code (code that looks plausible and is subtly wrong) can cost a developer more than writing it fresh would have. So this only works if the human in the loop is real, and the drafts are good enough to be worth the review. That is the hard, unsolved part, and I don't want to wave it away. If AI-written first drafts plateau just below the bar of being worth reviewing, this whole vision collapses. I am betting they won't. I could be wrong.

But the direction feels right to me. AI changes who writes the first draft. It does not change who carries the responsibility.

That is the whole arc, really. AI changed my ordinary days. That changed how I work. That changed my place on the team. That pushed me to understand the technology instead of managing it from a distance. And all of it adds up to a single bet about where this is going: not Product Managers replacing anyone, but Product Managers taking on more of the making. Arriving with a draft instead of a document, with AI doing the operational work and people still doing the deciding. I don't know exactly how much of this will come true. I am fairly sure the direction is right.