OpenAI stopped reviewing AI code line by line, and PMs are shipping prototypes with real payments

You have been running product teams under one old rule: describing the work is cheap, building it is not. So you wrote specs, drew wireframes, and spent weeks describing a future before anyone paid to build it. That rule just flipped. Now a PM or designer can build a working version in an afternoon, add real payments to it, and ship it. Let me catch you up.

The deep cut

• Building is cheap now, so judgment is the job. When a PM can build both a three-step and four-step flow in hours, The Product Journey says choosing what deserves the build is the scarce skill.
• The prototype has to keep the spec's forcing function. A PRD made you think through edge cases; a demo that lets you skip that thinking just builds the wrong thing faster.
• The harness, not the model, decides if you can trust the work. OpenAI's Codex takeover shows the win came from the loop around the model, not the model alone.

The two-week doc you can now build in an afternoon

The math changed. A working prototype that used to need design, engineering, and coordination can now be produced in hours. The Product Journey puts it plainly: when building is cheap, you don't have to be as good at predicting the answer, you can build something and find out. Instead of debating whether a workflow needs three steps or four, a PM builds both and watches someone use them.

This is not theory. Phil Morton walks non-technical UX people through building a first side project with Claude Code or Codex on a $20 plan, no coding background assumed. And Paweł Huryn shows a PM wiring real Stripe payments and a firewall into a live SaaS app. The gap between an idea and a shippable thing is closing on your team, whether you planned for it or not.

What the doc did that the demo forgets

The PRD was never only a way to talk to engineers. It was a forcing function. Writing a good one made you think through edge cases, failure modes, and constraints. The act of writing created clarity that did not exist before. Kill the doc and keep the reflex, or you lose the thinking.

The catch is that a cheap prototype can hide a bad idea. A beautiful demo can still encode a wrong assumption, and a five-minute AI workflow can be completely disconnected from the real data, permissions, and infrastructure underneath. As The Product Journey frames it, the cost of producing an answer fell, but the cost of knowing whether the answer is good did not. The new failure is not that PMs stop prototyping. It is that they prototype everything before defining the question.

So the spec does not die, it changes shape: intent, prototype, examples, constraints, and evals. The document explains why, the prototype shows what, and the evals define what good looks like.

The plumbing decides if you can trust it

Building the screen is the easy part. The hard part is the system around the model that decides what it can touch. One PM's harness writeup lays it out: agent equals model plus harness, and the harness is where AI stops being a model problem and becomes a product problem. Permissions, memory, retries, and when to ask a human are all product decisions now, not engineering afterthoughts.

Aha! learned this by rebuilding. Their Builder for PMs keeps authentication, SSO, and databases as fixed, pre-built components rather than letting the model generate them, because that cuts cost and guarantees reliability the AI cannot. The judgment call is knowing which parts stay locked down and which parts the agent gets to build.

Same lesson on cost. Measuring an agent by token price misleads you. A run that costs 20 cents but succeeds 60% of the time can cost more than a 50 cent run that succeeds 95%, because someone still has to catch and fix the failures. Think in cost per accepted outcome, not per run.

The workflow you hand off, not just the product

The bigger shift is not that PMs can code. It is that recurring work gets captured as reusable procedures. Wyndo calls these skills, a standard operating procedure written for an agent, following Garry Tan's line of "thin harness, fat skills." A skill is a compact version of your judgment about one kind of work: how to do it, what to check, and what good looks like. Peter Yang turned 15 manual podcast steps into 8 chained skills and saved five hours a week.

Then there is the review process itself. Huryn argues engineers should stop reviewing AI-generated code line by line and review artifacts instead. OpenAI is already there: PRs per engineer are growing like a hockey stick, and VP Venkat Venkataramani says the old way of code review makes less and less sense. They now run agentic reviews through separate lenses, security, performance, infra, on every change. That was impractical with humans. It is routine with agents.

The through-line: as coding gets delegated, deciding what to build and setting the standards the agents follow becomes the work that only you and your team can do.

Three questions for your team

• Which of our recurring PM and design tasks should become a documented skill this quarter, and who owns writing the first one?
• In our next review, can we replace the slide deck with a working prototype someone outside the team clicks through cold, and are we ready to watch instead of defend?
• Before we let a non-engineer ship anything with payments or user data, who owns the harness decisions on permissions, PII, and what counts as "done"?