23 Jun 2026

PMs Should Code, But Not Like That

Product managers should code. They should also be very clear about what their code is for.

There is a certain kind of product manager who learns just enough code to become dangerous. I know this because, occasionally, I am that product manager.

The fantasy is obvious. You see a small product gap. You know what the button should say, where it should go, and what should happen when someone clicks it. Engineering is busy, as engineering always is, because software has an infinite appetite for time. So you think: how hard can this be?

Now Codex, Claude Code, and the rest of the AI coding tools make the answer feel like: not hard at all. You can describe a change in normal human language and a few minutes later there is a branch with working code. Sometimes it even passes tests, which is rude, because now your bad idea has gained credibility.

This is why LinkedIn is full of people declaring that PMs are all going to code now. PMs will build the feature. PMs will ship the product. PMs will replace the engineering backlog with vibes and a confident prompt.

I think this is exactly the wrong lesson.

AI coding tools make PM coding easier. They do not make product code less real. A PM can now build something much bigger than they personally understand. That feels like leverage. Sometimes it is. Sometimes it is just a faster way to create work for someone else.

A GitHub contributions graph showing 906 contributions in the last year.
The tools make the activity graph look impressive. The graph does not tell you whether the work was the right work.

In my experience, PM coding has two good uses and one very common failure mode.

First: updating frontend copy.

Copy is the perfect PM coding task. The risk is low, the blast radius is small, and the PM is often the person closest to the actual words.

If the empty state is confusing, if onboarding has the wrong verb, if the tooltip is technically accurate but emotionally dead, just fix it. This is one of those rare places where the person with the opinion can safely be the person with the keyboard.

A small code diff changing Twilio integration labels to platform and custom purchased labels.
This is the kind of PM code I trust: a tiny frontend copy change with a small blast radius and an obvious product reason.

Second: building prototypes before engineering builds features.

A PM prototype is not a feature. This distinction matters.

A feature has to survive users, permissions, analytics, billing states, migrations, future refactors, and whatever weird thing your biggest customer does every Friday at 4:58pm.

A prototype has one job: help you learn. It can be ugly. It can be hardcoded. It can have one happy path. It can require you to manually paste in a customer ID while apologizing on the call.

The point is not to sneak a feature into production through the side door. The point is to make the eventual engineering work sharper. You are trying to learn whether the customer understands the workflow, whether the problem is real, and which parts of the idea are obviously wrong once someone clicks through it.

Third: pissing off your engineering team.

This is not a recommended use case. It is just a common one.

The fastest way to annoy your engineering team is to submit a big PR with code you cannot explain. Not code that is imperfect. Not code that needs review. Code where the answer to "why did you do this?" is basically "because Codex told me."

When an engineer reviews another engineer's PR, there is usually a shared contract. The reviewer can ask why something was done and expect an answer: a constraint, a tradeoff, a previous incident, or just "good catch, I will change it."

With a feature-sized AI-generated PM PR, that contract can collapse. The reviewer asks a normal engineering question and gets an answer from a seance. The PM feels interrogated. The engineer feels like they are reverse-engineering intent from autocomplete.

This is shit for everyone involved.

Sometimes I still try something too big. The prototype starts small, the customer feedback is good, and suddenly I have built 40% of a feature that should have had an engineer involved from the beginning.

At that point the right move is to hand it over, explain what you learned, and accept that much of the code may be deleted. The learning is the asset. The code is scaffolding.

Use Codex and Claude Code. Fix copy. Build demos. Compress a week of speculation into a 30-minute customer call. Just do not confuse "I prompted this into existence" with "this is how we should ship it."

Back to blog