Resources · Learning Brief · 2026-05-25
Learning Brief — May 25, 2026
Listen to this episode
04:57 · Auto-generated at 1:30 PM PT
Learning Brief — 2026-05-25
What we covered
- AI news: No AI News Today — Input Contains Only Consumer Hardware Deal Coverage
- PM news: The AI Paradox: Why More Automation Actually Means More Human Work
- PM learning: The AI Paradox: Why Automation Creates More Human Work, Not Less
Mental model
Automation doesn't eliminate work; it shifts it toward judgment and review—the move is to measure whether you're freeing humans for higher-leverage decisions, not just saving time.
Summary
No AI news notes were available.
Dan Shipper just published something that should shift how you think about AI's impact on product teams. His thesis is counterintuitive but worth sitting with: as AI automation scales, we don't get fewer humans doing the work — we get more humans needed to oversee, refine, and direct the AI doing it.
Here's the PM angle. Shipper argues that the CLI era is over. Work is moving inside AI coding environments like Codex and Claude Code, where agents handle execution but humans stay in the loop for judgment calls. That means your product roadmap can't just be "replace humans with AI." It's actually "embed humans deeper into AI workflows."
He makes a specific point that landed hard: every agent needs a human. Not because agents are dumb, but because context, taste, and accountability don't scale without people. That's a product design constraint. If you're building tools on top of AI, you're not optimizing for speed alone — you're optimizing for human oversight at scale.
The second insight is blunt but important. Shipper is wildly bullish on PMs and designers in this shift. Why? Because the work isn't becoming simpler or fewer. It's becoming more nuanced. You need people who can define what "good" looks like when the execution layer is automated. You need people who can catch what the AI missed. You need people who understand the human context the AI can't see.
This reframes a conversation a lot of us are having internally. Instead of asking "how do we use AI to do more with fewer people," the real question is "how do we design products where AI and humans work together in ways that actually improve outcomes?"
If you're building a product that touches AI agents or automation, this matters to your positioning and your roadmap.
Here's the thing that most PMs get wrong about AI's impact on their roadmap: we think automation reduces work. But the actual pattern we're seeing is the opposite. More automation means more humans doing more work, not fewer.
Dan Shipper calls this the AI paradox, and it's a mental model that should reshape how you think about feature prioritization and team scaling over the next two years. The insight is this: when you automate a task, you don't eliminate the work—you change its nature. You move from doing the work to managing, reviewing, and refining what the AI produces. And that turns out to require more human judgment, not less.
What that means in practice: take code generation. You'd think Claude or Codex writing code means engineers write less code. Instead, engineers now spend time prompting the AI, reviewing its output, catching edge cases it missed, and integrating it into larger systems. The work shifted from writing to directing and quality-gating. Same with design—AI can generate layouts, but a designer still needs to evaluate them, adapt them to brand, and make the calls that matter.
The move here is to stop thinking of AI features as labor-reduction plays and start thinking of them as leverage plays. You're not hiring fewer people; you're changing what your people do. A PM should ask: what's the new bottleneck after we automate this? Usually it's human judgment, taste, or context that the AI can't provide alone.
Shipper makes a bold claim that follows from this: PMs and designers are about to become more valuable, not less, because every AI agent needs a human in the loop. The agent can generate a hundred options, but a human has to decide which one matters. That's where the real work lives now.
For your roadmap, this changes the calculus. When you're evaluating an AI feature, don't measure success as "how much time does this save?" Instead ask: "Does this shift work toward something our team is actually better at?" If you're moving engineers from boilerplate to architecture decisions, that's a win. If you're just moving them from writing to debugging AI output without adding value, that's a trap.
This week, pick one automation you've shipped or are considering. Map out what the human workflow looks like after the AI does its part. Where's the friction? That's where your next feature lives.