When the PM Ships Code: A Working Agreement with Engineering

LinkedIn introduced an Associate Product Builder program that combines product, design, and engineering skills¹. When PMs build software, teams need to agree on which work they own and where engineering takes over.

A written agreement gives the team a basis for deciding who builds what, how the handoff works, and what review is needed before code reaches production. The mechanics of prototyping itself (tools, the one-page companion, what to hand over) are covered in From PRD to Prototype. This one covers the team.

The role is splitting

Userpilot's 2026 trends analysis describes two archetypes pulling apart². The builder-PM is AI-native, ships prototypes themselves, and works on teams that deliberately blur the PM/engineer line. The integrator-PM is high-EQ, cross-functional, and owns the roadmap in messy B2B environments where alignment is a human problem before it is a technical one. These are the author’s descriptions of the market, not fixed categories every PM must fit.

Product leaders do not agree on where this lands. Jenny Karuna, CPO at Katch, describes two camps: one says PMs now write code and we will see more hybrid roles like forward-deployed engineers and product engineers; the other says AI frees PMs to focus on deciding what to build, with the classical PM-engineer partnership intact. Her bet is a messy middle where both models coexist³.

The working agreement should reflect the team’s responsibilities, dependencies, and review requirements. Discuss those needs before deciding how much code the PM should own.

The division of labor

LogRocket's definition of a product builder is a useful anchor: someone who takes an idea from zero to one with minimal dependency on other teams, contributing through execution instead of requesting it⁴. That sentence describes the prototype phase. It does not describe production, and the rest of this article divides up the gap between the two.

Here is the default agreement. Adjust it, but write your version down.

The payoff for dividing it this way is speed of learning, not lines of code. The LogRocket author models the shift like this (his estimates, not a measured study): time to first user feedback drops from four to six weeks to one to two; ideas tested per quarter rises from two or three to between six and ten; engineering hours consumed by failed ideas drops from 400-plus to under 100⁴. Treat the specific numbers as one practitioner's modeling. The proposed benefit is that PM-built prototypes let engineering concentrate on ideas already tested with users. Measure whether that happens on your team.

If you want your own baseline instead of someone else's model, measure how long an idea currently takes to reach a user on your team.

The handoff

The collaboration pattern that works, per LogRocket: the builder-PM creates the first version of a feature, then works with a senior engineer to make it scalable and production-ready⁴. Two rules keep that pattern safe.

Rule one: estimate production work separately. Use the prototype to explain the intended behavior, then let engineering assess what can be reused and what needs rebuilding. In Veracode’s 2025 evaluation of more than 100 models, 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities⁵. That result describes the tested samples, not every AI-generated prototype. A working demo still needs review before production.

Rule two: build and maintain shared guardrails. A Thoughtworks team was asked to scale a vibe-coded prototype built by a non-technical "citizen builder" in their own global marketing org, and found serious cracks that prevented it from going to production safely⁶. Part of the cause is structural: AI agents prioritize the path of least resistance and frequently recommend insecure configurations⁶. What fixed it was not banning the builders. The org compiled its security rules into a structured context file loaded as rules the model must follow, treated AI permission requests with caution, added a security intelligence feed, and built a shared secure-by-default starter harness, jointly owned by the business functions, engineering, and security. The team reports rolling the platform out to 150 users during the hackathon after adding those controls⁶.

Prototype code moved into production without review can create maintenance and security problems the team has not agreed to accept. Technical debt management covers what that costs and how to pay it down.

The trust problem

The PM and engineer need a shared understanding of what a working demo proves and what remains to be done⁴. LogRocket frames the underlying change precisely: PM influence is moving from authority-based (roadmap ownership, coordination) to capability-based (demonstrated output)⁴. That only works in your favor if the output holds up under review.

What breaks trust from the PM side: pushing unreviewed code toward production, treating the prototype as "80% done," or sneaking in a "small fix" without review. Stack Overflow's 2025 survey found the top frustration with AI tools is output that is "almost right, but not quite" (66%), and 45% of developers said debugging AI-generated code takes more time than expected⁷. Include that review and debugging effort in the plan.

Engineering can also make collaboration harder by blocking agreed prototype work or applying inconsistent review standards. Match the review to the software’s use and risks.

Review etiquette for PM contributions, where the agreement allows them:

• Keep PRs small and scoped to one thing.
• Label what is AI-generated and what you actually understand.
• Respond to feedback on the code. Do not relitigate product priority inside a review thread.
• Never merge on your own approval. Reviewer rules are part of the shared agreement.
• If review concludes the thing should be rebuilt, accept it. That outcome is the handoff working as designed.

If you mapped stakeholder currencies in Stakeholder Management 101, this is that framework applied at close range. Agree on how prototype work can reduce demands on engineering, and track the support and review time it still requires.

What stays PM work

Karuna's line is the one to keep: "as execution gets cheaper, the critical skill becomes choosing what to execute." And again: "the hardest and most valuable part of product work is no longer writing the code. It's deciding what's worth coding in the first place"³. Her second durable skill is taste, meaning editorial judgment: use AI assistants for breadth and exploration, then apply taste as the filter³.

The Userpilot author lands in the same place from the other direction: "everyone is about to be able to build. Nevertheless, the problem was never building but building the right thing"².

Building adds a capability to the PM role. Problem framing and judgment still guide which prototypes to build and what to learn from them.

FAQ

Do PMs need to write production code now? No. In the working agreement above, the PM ships prototypes, internal tools, and evidence. Production code, security, and scale stay with engineering, including rebuilds of PM prototypes. The skill you need is taking an idea to a working first version, not maintaining it in production.

How do I propose this without starting a turf war? Bring the agreement, not a finished PR. Show your engineering lead the division-of-labor table, ask what they would change, and start with the lowest-stakes lane (an internal tool touching no customer data). Review how the first project went before expanding the scope.

I'm an integrator-PM in a messy B2B org. Does this apply to me? You may spend more time coordinating decisions than building prototypes. The agreement still helps: decide which responsibilities your team needs you to take on, rather than choosing a label first.

Who reviews the PM's code? Whoever engineering designates, at the same bar as a peer's code in that lane. A throwaway prototype may need no review at all; an internal tool needs a real one; anything aimed at production goes through the full handoff with engineering estimating it as new work.

Can the prototype just ship if it works in the demo? Not if it touches authentication, payments, or personal data. A demo shows the behavior you tried, not that the software is ready for production. The full handoff checklist (companion page, prompt history, list of what is faked) is in From PRD to Prototype.

Sources