From a conversation to a pull request

It gets most concrete in a single flow, the way I imagine it and already build parts of it today. You can read it as a small story — from the first idea to a finished pull request.

It starts with a meeting. Fireflies records the conversation, transcribes it, and creates a summary. That information lands in Obsidian automatically and extends my digital brain. Codex or Claude reach into that knowledge and additionally have access to GitHub. With that they know the documentation, the architecture, the codebase, and the current state of development — all at once.

Now a new feature request appears. Instead of pouring it straight into a ticket, my skill automatically asks follow-up questions and sharpens the requirement until it actually holds. From the result, the AI writes a complete Jira ticket. And this ticket is no generic suggestion: it follows our internal structure, takes into account the current state of the software, existing patterns, and known technical decisions. It reads as if written by someone who knows the product — because, through context, the AI actually does.

In the next step the AI can even generate working code, write the first tests alongside it, and prepare it as a pull request. And here is the line that matters. What comes next belongs to the developers: review, architecture, quality, security, scaling, edge cases, performance, the final decision. The AI delivers the first draft. Not the solution. Tools like Claude Code, OpenAI Codex, GitHub Copilot or Devin already show how far that first draft reaches — and just as clearly where it stops. A pull request no one reviews with real judgment is not acceleration; it is a time bomb with a CI pipeline attached. The gain doesn’t come from the machine writing. It comes from a human only having to check, instead of starting from zero.

I’ve written more fully elsewhere about this idea — that Product Owners end up opening their own pull requests. What I’m describing here is the machinery underneath it: the concrete path by which a conversation can, in the end, become code, without responsibility getting lost anywhere along the way.

If I follow this setup to its conclusion, it changes more than my day. It changes the role itself. I believe Product Managers will work considerably more technically in the future. Not because they replace developers — I think that idea is wrong, and I’ll come back to it — but because AI, for the first time, gives them tools to actively contribute themselves.

Concretely: Product Managers will write better documentation, better tickets, do better discovery, understand the code better, prepare first technical approaches, keep knowledge bases maintained almost as a side effect, and support developers better because of it. The arithmetic behind it is simple. Developers gain time, Product Managers gain understanding, and products gain speed.

The role shifts fundamentally with that. The Product Manager becomes less an administrator of tickets and more a systems designer — a translator between business and technology, and increasingly a designer of intelligent workflows. The core of the profession doesn’t actually change. What changes is how much of it one person can carry.

One point I want to make so clearly at the end that it can’t be misread: AI does not replace developers. My conviction is the exact opposite. The more capable AI becomes, the more important good developers get. Because architecture, quality, security, scaling, performance and long-term maintainability remain human responsibility — and the cheaper the first draft becomes, the more hangs on the judgment of whoever reviews it. AI delivers the first draft. Humans own the result. That is where I see the future of modern product development — and, incidentally, the answer to the question I began with. It was never the tools. It was always the question of what you build from them.