The most counterintuitive finding in PM-shipped code: engineers are the ones asking for it.
A startup CTO posted: "One of our PMs built and shipped a feature. Not spec'd it. Built it, tested it, shipped it to production. In a day." The engineers on his team loved it.
The CTO explained why: when PMs build their own ideas, their specifications get sharper. They understand what the agent needs to execute well. Sharper specs produce better agent output. The PM who has shipped a few PRs writes fundamentally different specs than the PM who hasn't.
This is the second-order effect nobody predicted. PMs who've shipped code know what's easy and what's hard. They know what a diff looks like. They stop writing 15-page docs that require a 30-minute meeting to decode and start writing 40-line PLANNING.md files with specific metrics, guardrails, and kill criteria.
The third-order effect is that engineering trust compounds. The PM who ships clean, focused, well-described PRs earns more trust than the PM who writes perfect specs. Because the eng team can see you understand their world. You're showing them you respect the process.
At Anthropic, Claude Code reviews first and catches ~80% of bugs. Then a human engineer does the second pass. For PM PRs, the human review is the safety net. PM gets the intent right. Engineer makes sure nothing breaks.
Jiaona Zhang, CPO at Laurel and Stanford lecturer, says her PMs are going beyond prototyping to production. Her designers push code too. Superhuman uses Codex so PMs can contribute lightweight code changes without pulling in an engineer, except for code review.
The irony: the PM who never touches code creates more work for engineers through the translation layer. The PM who ships the small stuff lightens their load while simultaneously earning more trust and writing better specs. The incentives all point the same direction.