When a PM can ship code, What should Engineering do next?

For years, product management has worked like a relay race: the PM writes the requirement, design shapes the experience, engineering turns it into code, and everyone meets later to compare what was meant with what was built.

That handoff model has served us well. But it also creates distance—and sometimes, a few very polished documents that nobody wants to read twice.

Tools like Codex and Claude are changing the equation.

From requirements to something real

A PM can now take a clear user problem, define the workflow and acceptance criteria, and create a working first version. It could be a screen, an API, an integration, or a test.

Not production code, of course. But something real enough for customers and engineers to react to. A prototype that starts a better conversation than a requirement document ever could.

This does not mean PMs replace engineers. It means the handoff gets smaller. Product managers can show what they mean, not just describe it.

So, what changes for engineering?

Here is the question I keep coming back to: if a PM can create a first pass of code that would once have needed engineering time, where should engineering spend its best energy?

On the things that make a product real—and keep it real after the demo is over.

• Architecture that keeps the product flexible as it grows.

• External dependencies that do not break when another system changes.

• CI/CD that helps teams release safely and recover quickly.

• Test harnesses and quality layers that catch problems before customers do.

• Governance for security, privacy, performance, accessibility, and AI-generated code.

The fun part is that the prototype may work in a demo. The important part is whether it survives production on a Monday morning.

Startups move fast. Enterprises need to learn how.

I have seen this work with a couple of startups where I volunteer as an advisor. Startups are naturally nimble. A small team can agree on a problem, try a new way of working, and learn from it quickly. There is less distance between the person with the idea and the person making it real.

It is harder in a large enterprise—not because people do not see the value, but because the change touches mindset, roles, processes, and accountability. Enterprises need process. Security, architecture, compliance, and reliable delivery do not happen by accident.

The goal is not to get rid of process. Process exists for a reason—whether you are in a large enterprise or a startup. The real question is whether it helps the team move forward or simply slows everything down.

We need to make it easier for teams to try things safely, be clear about where AI-generated code can be used, and give people sensible guardrails. Not every small change needs another meeting, another form, or another approval.

It raises the bar for PMs too

A PM cannot simply prompt their way to a solution. They still need to understand the customer, the workflow, the edge cases, and how success will be measured. AI-generated code is a starting point—not a production decision.

The better model is not “PMs code and engineers architect.” It is a tighter partnership. PMs make ideas more concrete, faster. Engineers create the guardrails and foundations that make those ideas reliable.

Qwik Takeaway

Less time translating requirements. More time testing real ideas. The companies that win will not be the ones that remove process; they will be the ones that make good process move at the speed of change.