Should product managers code now that agents can?
Stefan-Iulian Tesoi · · 6 min read
Prototypes, yes; unreviewed production changes, no. A product manager who builds a throwaway prototype with a coding agent reaches a decision in an afternoon instead of a sprint. The same person merging a small production change without review skips the check every engineer is held to, and small changes are exactly where nobody notices the skip.
So the honest answer to should product managers code is about which code, not whether. Claude Code and Cursor have made the typing cheap for anyone who can describe what they want. They have not changed who has to read the result, or who answers for it once it ships.
Should product managers code, and what kind of code?
They should write code that answers a question, and send code that changes the product through the same pull request as everyone else. The useful line runs between code thrown away after a decision and code that stays in the product.
| Kind of code | What it is for | Review it needs | Where it ends up |
|---|---|---|---|
| Throwaway prototype | Answering a product question | None, because it never ships | Deleted after the decision |
| Data query or script | Checking a number before deciding | A second reader on the logic | A notebook, not the product |
| Copy or config change | A small production change | The same pull request review as any change | The main branch |
| Feature work | A production change | Code review, tests and a named owner | The main branch |
The first two rows are where a product manager's code adds the most. The last two are where it causes the most trouble, because they look like the first two and are not.
The product manager technical skills that matter here are mostly reading skills: following a diff, writing an acceptance criterion a machine can check, and knowing which files are dangerous to touch.
Prototypes that answer a question
A prototype earns its place when it settles a question faster than a meeting would. PM prototyping with AI is good at exactly that: a clickable onboarding flow to show five customers, a working pricing calculator to test whether the tiers make sense, a fake integration screen to see whether anyone finds the button. For product managers using Cursor or Claude Code, a prototype like these can take an hour or two, which is less than the meeting it replaces.
Four rules keep a prototype a prototype:
- It lives outside the product repository, in a sandbox or a separate repository, never on a branch of the real thing.
- One question is written at the top, with the date the prototype will be deleted.
- It uses fake data only. No production credentials and no customer records, which is the same line drawn in what permissions a coding agent should have.
- It never runs inside the product. When a real test needs it there, it stops being a prototype and goes through review behind a feature flag, off by default.
A prototype that breaks these rules has quietly become production code with none of the checks production code gets.
Why do small changes from outside engineering skip review?
Because they look too small to be worth anyone's time, and because the author often holds the permissions to merge them anyway. A product manager who set up the repository, the CI or the hosting account frequently has admin rights on it. GitHub's documentation on protected branches is explicit that, by default, the restrictions of a branch protection rule do not apply to people with admin permissions. The setting "Do not allow bypassing the above settings" is what extends them to admins, and it is off until someone turns it on.
So the person least likely to have their change reviewed is often the person with the most access. The change is usually a few lines, such as a pricing-page label or a config threshold, and the agent may have done more than asked. An agent told to change a label can also reformat the file, update a test snapshot so the test passes again, or rename a key a translation file depends on. Its summary says "updated the label", and the summary is a claim. Reviewing what an agent actually did starts from the diff for exactly this reason.
A change too small to review is the change nobody reads until it breaks.
The fix is one review standard for every author, applied without exceptions for title or size:
- Every change to the product goes through a pull request, whoever prompted the agent.
- Branch protection applies to admins as well.
- The reviewer checks the diff against criteria written before the work started.
- The person who prompted the agent does not approve the result.
Who owns a change after a product manager ships it?
The product manager owns the decision and the engineering team owns the code, the same split as for any other change. That split has to be agreed before the first incident, not during it. When the change breaks at night, the engineer on call is the one who has to understand it, and they cannot ask the agent why it renamed that key.
So a change prompted by a product manager carries what every change carries: an item with acceptance criteria, passing tests, and a reviewer who could support it in production. Who owns the backlog draws the same line one step earlier, between deciding what should exist and keeping each item executable.
Laimonade applies that standard without asking who started the agent. A change handed back against an item is checked against that item's acceptance criteria one by one, and an item marked customer-facing waits in In Review for a person to look at it, whether the agent was started by an engineer or a product manager. A coding agent cannot mark its own work done.
What does this do to a product manager's week?
It moves hours from long documents to short, checkable items, and adds a few hours of prototyping that replace meetings. Two prototypes a week at an hour or two each is a common shape, each one ending a discussion that would have taken several calls.
The risk is drift. A product manager who starts shipping production changes because it is faster than waiting for an engineer becomes a part-time engineer, and the deciding work loses those hours. A useful tripwire: if more than one day a week goes into production changes, the role has shifted and nobody chose that. The broader picture in engineering team structure when agents write the code holds here too. The roles stay, and the hours inside them move.
Frequently asked questions
Do product managers need a development environment?
For prototypes, a sandbox is enough: a hosted environment or a separate repository with fake data. A local checkout of the product with production credentials is not needed for anything a product manager should be building, and it widens what a coding agent on their machine can reach. Engineers can set up a prototype template once and share it.
Should a prototype ever become the production code?
Rarely, and never by promotion. A prototype is written to answer a question fast, with fake data and no tests, so it carries none of what production code needs. When the answer is yes, build the feature again as a normal item with acceptance criteria, and use the prototype as the record of what users saw and liked.
Does this blur the line between product and engineering?
It blurs who types, not who decides. The product manager still decides what is worth building, and the engineering team still decides how it is built and whether a change is safe to merge. The line that matters is review: while every production change is read by someone who will support it, the author's title matters very little.