Non-PMs Shipping to Production and Claude Code Pricing A/B Tests

Lenny Rachitsky / Community Wisdom — Non-PMs Shipping Directly to Production#

Source: https://www.lennysnewsletter.com/p/community-wisdom-what-to-do-when Credibility: High (first-party newsletter, curated community discussion from active practitioners)

What happened: Lenny's Community Wisdom #185 (May 9) surfaces a live tension that's showing up across product teams: what do you do when engineers (and other non-PMs) start shipping features directly to production using AI coding tools, bypassing the traditional product review process? The post aggregates community takes on this, alongside a discussion of Anthropic's reported pricing A/B test on Claude Code and the expanding role of generative AI in games.

Key patterns:

• The non-PM-shipping problem is an emergent consequence of vibe coding tools lowering the cost and friction of building — what used to require a sprint now takes an afternoon
• The debate isn't just about process; it's about whether the PM role as "gatekeeper" is appropriate when build costs drop by 10x
• Claude Code's pricing A/B test is drawing community attention because Anthropic is apparently experimenting with how to charge for agentic tool usage — a genuinely unsettled question for every AI product team
• Gen AI in games is a newer surface area, with community discussing what's actually working versus what's hype

Why it matters for PMs: The non-PM-shipping question is the most immediate one here. AI coding tools don't just accelerate development — they redistribute who can ship. If a frontend engineer can spin up a complete feature in a day using Cursor or Claude Code, the traditional PM discovery-definition-delivery loop doesn't fit anymore. This is forcing teams to decide: do PMs own the decision to ship, or do they own the strategic context that informs decisions others make? These are very different jobs.

The Claude Code pricing discussion is also worth watching. Anthropic A/B testing price points for an agentic coding tool is a signal that even the companies building these tools don't know what users will pay — which means the market for agentic AI pricing is genuinely open. If you're building anything with agentic capabilities, watch how this resolves.

Critical questions:

• Is the non-PM-shipping problem actually a problem, or is it a symptom of PMs being in the wrong part of the value chain (owning delivery instead of strategy)?
• What does "PM approval" mean when a feature takes 4 hours to build and 4 days to get on a roadmap?
• How should teams recalibrate process overhead when the cost of shipping drops — do you reduce gates, or add different ones (like post-ship review)?
• What does Claude Code's pricing A/B test reveal about Anthropic's model for capturing value from developer productivity tools?

Action you could take today: Ask your team informally: has anyone shipped something to production in the last month that didn't go through the normal PM review? If yes, find out whether the outcome was good or bad — that's more useful than any policy debate.

Cursor — PR Review, Parallel Agents, and Split PRs (3.3)#

Source: https://cursor.com/changelog/05-07-26 Credibility: High (first-party changelog)

What happened: Cursor 3.3 shipped on May 7 with three capabilities that collectively push the editor further into the "AI as co-developer" territory: a new PR review experience built into the editor, parallel agent execution for plans (multiple subagents working simultaneously on different parts of a task), and a "Split PRs" feature that breaks large diffs into smaller, reviewable pull requests automatically.

Key technical details:

• PR Review: A full PR review workflow is now available inside Cursor — you can review incoming PRs with AI assistance without leaving the editor. This closes a significant context-switch loop for developers
• Build Plan in Parallel: When Cursor creates a plan with multiple steps, it can now spin up parallel agents to execute different branches simultaneously, reducing wall-clock time for multi-file changes
• Split PRs: Cursor can take a large change and automatically split it into multiple, logically-grouped PRs — addressing a common pain point where AI-generated changes produce huge diffs that are hard for humans to review
• This follows the May 6 Context Usage Breakdown update, which let users see a breakdown of agent context usage across rules, skills, MCPs, and subagents

Why it matters for PMs: Parallel agents and Split PRs are directly addressing the "AI makes a huge mess" problem that developers complain about. Big diffs are hard to review, easy to rubber-stamp, and risky to ship — Split PRs is an explicit acknowledgment that AI-generated code needs to fit into human review workflows, not replace them. This is a product design philosophy worth stealing: when you add AI capabilities that accelerate output, add corresponding features that help humans stay in control of quality. The PR Review feature is also a workflow integration play — the more of the development lifecycle Cursor owns, the higher the switching cost.

Critical questions:

• Does parallel agent execution increase the risk of conflicting changes, and how does Cursor handle merge conflicts between subagent outputs?
• Split PRs is useful, but who decides the right logical grouping — the AI or the developer? If the AI gets it wrong, does it create more review overhead, not less?
• How does the in-editor PR review compare to GitHub's native review experience — is this additive or a replacement workflow?
• As Cursor adds more "agent management" features, at what point does the cognitive overhead of managing agents exceed the productivity gains?

Action you could take today: If your team uses Cursor, try the Split PRs feature on the next large AI-generated change. Ask the developer who reviews it whether the split was logical — that feedback will tell you whether the feature is actually solving the review quality problem or just reshuffling it.

Lenny Rachitsky — Eric Ries on Building for Resilience#

Source: https://www.lennysnewsletter.com/p/how-to-build-a-company-that-withstands Credibility: High (first-party newsletter, named expert source)

What happened: Eric Ries (Lean Startup author) joins Lenny's podcast on May 10 to discuss what it takes to build a company that survives different eras — economic shifts, technology waves, and competitive disruption. The framing includes why most "mission-driven" companies are actually just mission-hopeful, and why only about 20% of founders remain CEO three years post-IPO.

Key patterns:

• The distinction between mission-driven and mission-hopeful is doing real work here: having a stated mission doesn't mean your company is organized around it — most aren't
• The 80% CEO turnover figure post-IPO is a structural observation about what scaling actually requires versus what founding requires
• Ries's Lean Startup framework was built around iterative learning under uncertainty — highly relevant to AI product development where you genuinely don't know what will work until you ship it

Why it matters for PMs: The "mission-hopeful" framing is directly applicable to AI product strategy right now. A lot of teams are building AI features because it's expected, not because they have clarity on what user problem they're solving. Ries's framework for distinguishing real learning loops from theater is useful — are you running validated experiments, or are you shipping and hoping? For PMs navigating pressure to "add AI," having language for the difference between mission-aligned AI investment and mission-hopeful AI investment is genuinely useful in executive conversations.

Critical questions:

• How do you operationalize "mission-driven" at the feature level, not just the company level?
• If Ries's core insight is "build validated learning into your process," how does that change when AI accelerates building but doesn't accelerate learning about whether the thing was worth building?

Action you could take today: Before your next AI feature kickoff, write one sentence explaining which user problem it solves and how you'll know within 30 days whether it's working. If you can't write that sentence, you're probably mission-hopeful on this one.