The PM-Developer Convergence: Reflections from the Coding Agents Conference

This past Tuesday I attended the "Coding Agents: AI Driven Dev Conference" at the Computer History Museum in Mountain View. The event was organized by the MLOps Community and packed with practitioners building on and with coding agents. Demetrios, the host, set the tone early with a riff on "side quests" -- the phenomenon where an ML engineer suddenly finds themselves deep in React, or a front-end dev is building a recommender system, all because agents let you move so fast that scope expands before you realize it.

The talks were excellent, and the energy in the room was high. But what stuck with me most weren't the technical demos. It was the tension between several competing visions of how software teams should work in this new era. Some of those visions resonated. Others, I think, are dangerously incomplete.

"We don't really believe in PMs"

Scott, the CEO of Kilo Code, shared how his team operates. When asked about PM-to-engineer ratios, his answer was blunt: "We don't really believe in PMs at Kilo... every engineer is their own PM." They have one product manager in the entire company, and that person focuses on the horizontal platform, not individual features. Each engineer owns a feature end-to-end, from conception to production to user feedback.

I found this take interesting but not surprising given the context. Kilo builds an agentic engineering platform. Their users are developers. Their engineers are their own best customers. In that world, a developer with deep product instincts is arguably better positioned than a dedicated PM to make the right calls.

But I don't think that generalizes.

Shift Right, Shift Left

I've been thinking about this dynamic for a while now, and the conference crystallized something for me. The PM and developer roles are converging, but the direction of that convergence depends entirely on the product.

In application software -- consumer apps, SaaS products, anything where the end user isn't an engineer -- the Product Manager is the critical role. They hold the keenest perspective on what users need, how they behave, and where the product falls short. These PMs are now picking up developer skills, using coding agents to prototype, build internal tools, and ship without waiting in a sprint backlog. I think of this as a "shift right" motion -- the PM absorbs capabilities that were previously developer-only.

In infrastructure software -- developer tools, APIs, platform engineering -- the opposite is true. The engineer often knows the customer's needs better than any PM could because the engineer is the customer. Here, the developer absorbs product responsibilities. That's a "shift left" motion, and it's exactly what Kilo is doing. It works for them because their product context supports it.

The mistake is assuming one direction fits all contexts. The conference surfaced both patterns. I think the leaders who navigate this transition well will be the ones who recognize which motion their product demands and staff accordingly.

"We actively discourage collaboration"

This was the spiciest take of the day for me. Scott described Kilo's culture as "very anti-collaboration," with each engineer owning a feature solo and collaboration treated as a last resort rather than the default. He framed it as eliminating velocity killers -- alignment meetings, context switching, waiting on others.

I respect the speed this unlocks, and I understand the reasoning. When you're a small team of senior engineers building a developer tool, you can get away with it. But I don't think this is the way forward for most organizations building complex systems.

Development is still a team sport. Building robust systems that handle the real world's edge cases requires multiple humans with diverse backgrounds, experiences, and perspectives. A single engineer's blind spots become the system's blind spots. One person's biases produce brittle software with unhandled failure modes that only surface when customers find them.

I don't think agents save us here, either. Agents inherit the biases of their prompts and the assumptions baked into their context. They're powerful tools for execution, but they don't replace the cognitive diversity that comes from a well-functioning team reviewing each other's thinking.

"You have to read the code"

One of the best takes I heard came from a CEO building what I believe will eventually replace the IDE -- a collaboration and session management tool for coding agents. He described his own evolution: he went from "I don't read the code, I read the markdown docs that lead to the code" to a much more grounded position: you have to read the code.

I agree with this wholeheartedly.

We're seeing coding agents make real progress in generating code that runs and code that appears correct. But that code is also known to carry security vulnerabilities and subtle bugs that don't become obvious until you start hitting edge cases. The base failure rate per PR, as Sid from Anthropic's Claude Code team noted, stays roughly constant. If you're shipping 5x more PRs, you're shipping 5x more bugs -- unless humans are actually reviewing what's going out the door.

We should not be turning our customers into our QA departments. I've seen that pattern too many times over my career, and I'd hoped we were moving past it. Agents accelerate us, but they don't absolve us of the responsibility to understand what we're shipping.

The Real Shift

The conference organizer, Demetrios, nailed it in his opening: we're all becoming "mini R&D departments." Agents are compressing the time from idea to prototype from months to weekends. The cost of building is trending toward zero.

But as Sid pointed out, the problem is shifting from "how do I build this?" to "what should I build?" That's a product question. And answering it well requires taste, domain expertise, customer empathy, and yes -- collaboration.

The tooling is evolving fast. The roles are blurring. But the fundamentals of building great software haven't changed: understand the user, build the right thing, and make sure it actually works before you ship it.

Michael Stricklen is Managing Director and Head of the AI Disruption Lab at EY-Parthenon, where he leads a team applying AI and agentic systems to diligence and value creation for private equity clients.