Home
Jun 7, 2026
View All

When AI Becomes Infrastructure: Taste, Spend, and What Screens Are For

The Short Version#

Tony Fadell's interview on Lenny's podcast is the most useful PM-craft piece of the week: opinion vs. data, the "three generations rule," and why AI still needs screens. Pair that with Ravi Mehta's practical framework for cutting AI token spend 10x, and you get a clean through-line — taste gets you to the right product, discipline gets you to the right cost structure.

Lenny Rachitsky / Tony Fadell — Building Taste, Judgment, and Creativity in the AI Era#

Source: https://www.lennysnewsletter.com/p/father-of-the-ipod-and-iphone-on Credibility: High (first-person interview, primary source, Lenny's Podcast)

What happened: Tony Fadell, who built the iPod, iPhone, and Nest, sat down with Lenny to talk about product judgment in an era where AI can increasingly do the execution. The interview covers when to trust data vs. opinion, why marketing is actually a product function, and his "three generations rule" — the idea that every major product platform takes roughly three generations to get right. He also weighs in directly on AI and why he believes it will still need screens.

Key PM craft patterns:

  • Opinion vs. data: Fadell's framing is that data tells you what users did; opinion tells you what they needed. The job of a PM with taste is knowing when to override the data because you understand intent that the metric can't capture.
  • The three generations rule: Almost every platform that matters took three product generations to find its form. Gen 1 proves the concept. Gen 2 fixes the obvious failures. Gen 3 is where the product actually becomes what it was always trying to be. This is a useful forcing function for roadmap conversations — are you on gen 1 or gen 3 of your AI feature?
  • AI still needs screens: Fadell's counterintuitive take is that voice and ambient AI won't replace visual interfaces. Screens give users confidence in what the AI understood and did. The kill-the-screen narrative is a design problem, not a destination.
  • Marketing as product: He argues that if your product requires a long explanation, it's not done yet. Marketing that has to do heavy lifting is a signal that the product hasn't found its clarity.

Why it matters for PMs: The "three generations" framing is genuinely useful for managing stakeholder expectations around AI features. Most AI features are on gen 1 or gen 2 — they prove a concept or fix early failures. Treating them like gen 3 products (shipping to everyone, optimizing for retention) is usually premature. The data vs. opinion point is especially relevant for AI: when AI outputs become a metric themselves, you need human judgment on whether the metric is the right thing to measure at all.

Critical questions:

  • How do you operationalize "taste" on a team where the PM doesn't have Fadell-level product intuition? Is taste teachable or is it a hiring criterion?
  • Is the three-generations rule still a useful heuristic when AI iteration cycles are compressing timelines from years to months?
  • If screens give users confidence in AI outputs, what does that imply for products that are trying to go screenless (voice assistants, background agents)?
  • When Fadell says AI needs screens, is he talking about transparency and legibility — and if so, are there other interface patterns that achieve the same thing?

Action you could take today: Pull up your current AI feature roadmap and tag each item as gen 1, gen 2, or gen 3. If you're treating a gen 1 feature as a gen 3 product (e.g., measuring retention of something users haven't even formed a habit around yet), that's worth flagging in your next planning conversation.

Ravi Mehta — How to Stop Tokenmaxxing and Cut AI Spend 10x#

Source: https://blog.ravi-mehta.com/p/how-to-tame-tokenmaxxing Credibility: High (first-person framework from a former Roblox CPO, published on his newsletter)

What happened: Ravi Mehta published a framework for diagnosing and fixing runaway AI token spend, which he calls "tokenmaxxing" — the pattern where AI usage scales faster than value delivered, burning through token budgets without commensurate ROI. The post identifies three structural fixes for reducing token burn by an order of magnitude.

Key technical/product patterns:

  • Tokenmaxxing defined: The problem isn't just using too many tokens — it's that token usage is treated as a vanity metric (more = more engaged product) rather than a cost driver that needs to justify itself.
  • Fix 1: Context pruning. Most AI calls send far more context than the model actually needs. Auditing what goes into the prompt and stripping irrelevant history, metadata, or repeated instructions is the fastest lever to pull.
  • Fix 2: Model routing. Not every task needs GPT-4 or Claude Opus. Routing simpler tasks to smaller, cheaper models (and reserving frontier models for tasks that actually require them) can cut spend significantly without degrading user-facing quality.
  • Fix 3: Caching and deduplication. Many products make redundant AI calls for inputs that could be cached. Identifying high-repetition query patterns and caching results is often the highest-ROI infrastructure investment.

Why it matters for PMs: As AI features scale from beta to production, the cost structure changes fast. Token spend that looked manageable at 1,000 MAU becomes a real P&L line item at 100,000. PMs who understand the token economics of their features — and can communicate them to engineering and finance — are in a much stronger position than those who treat AI as a line item they don't own. This also connects directly to the open question around build vs. buy: model routing decisions are increasingly a build decision with real cost implications.

Critical questions:

  • How do you measure ROI on individual AI features when token costs are shared across a platform infrastructure? Who owns that attribution problem?
  • What's the right quality threshold for model routing? How do you know when a smaller model is "good enough" without running expensive A/B tests?
  • Does aggressive caching create user experience problems — e.g., returning stale AI outputs to users who expect fresh responses?
  • Is "tokenmaxxing" primarily an engineering culture problem or a product incentive problem? If teams are rewarded for AI engagement metrics, they won't optimize for efficiency.

Action you could take today: Ask your engineering partner to pull last month's token usage breakdown by feature. If you don't have that visibility, that's the first thing to fix — you can't route or prune what you can't see.

Cursor — SDK Updates and Design Mode Improvements#

Source: https://cursor.com/changelog/sdk-updates-jun-2026 and https://cursor.com/changelog/design-mode-improvements Credibility: High (first-party changelogs, shipped features)

What happened: Cursor shipped two notable updates this week. The SDK update (June 4) adds custom stores, custom tools, and auto-review to the TypeScript and Python SDKs — meaning developers can now control how agent metadata is persisted, expose their own functions to the agent as tools, and route local tool calls. The Design Mode update (June 5) expands what you can do in Cursor's browser: multi-select elements, click or draw changes, and describe UI changes by voice.

Key capabilities:

  • Custom tools via SDK: You can now expose your own functions to the Cursor agent as tools. This is significant because it means product teams building internal tooling can wire Cursor into their own APIs and workflows, not just the defaults.
  • Custom stores: Developers can now control how agent run metadata is persisted — meaning you can route storage to your own systems rather than relying on Cursor's defaults. Useful for enterprise compliance and auditability.
  • Auto-review integration in SDK: The auto-review run mode (which lets Cursor work longer with fewer approval prompts) is now configurable via SDK, giving teams programmatic control over safety guardrails.
  • Design Mode multi-select: You can now select multiple elements together in the browser and Cursor sees their code and context simultaneously. Voice description for UI changes is also now live.

Why it matters for PMs: The SDK custom tools feature is the more strategically significant of the two updates. It's moving Cursor from a developer productivity tool toward an extensible agent platform — one that teams can wire into their own infrastructure. That's a different product category with different retention dynamics. Design Mode voice input is interesting for the vibe-coding use case: it lowers the floor for non-developers making UI tweaks.

Critical questions:

  • Custom tools via SDK means Cursor agents can now call arbitrary external APIs. What are the security and audit implications for enterprise teams, especially in regulated industries?
  • How does Cursor's custom store/metadata persistence compete with what LangSmith provides for agent observability? Is there overlap or is this a different layer?
  • Does voice-based UI editing in Design Mode actually hold up for complex components, or is it useful mainly for simple copy and color changes?

Action you could take today: If your team uses Cursor and builds internal tooling, read the SDK changelog and identify one internal API you could expose as a custom tool. Even a simple one (like pulling current sprint data from Jira) would let you evaluate whether the agent-plus-custom-tools pattern is worth investing in.

Quick Hits#

  • Lenny Rachitsky: Community Wisdom 188 covers bootstrapping vs. funding, vibe-coded app roadmaps, and AI agents + data integrity. Good quick read for PMs navigating the no-code/AI-build wave (2026-06-06): https://www.lennysnewsletter.com/p/community-wisdom-bootstrapping-vs

  • Sarah Guo: Sharp take on AI economic diffusion — "A 'fast' takeoff with slow diffusion (gated by atoms and institutions and people's discomfort with change) looks, from the economy's vantage, less discontinuous." Useful framing for roadmap conversations about AI adoption timelines (2026-06-06): https://x.com/saranormous

  • Pieter Levels: Built a working dot matrix printer in the browser that prints from Windows 3.11. The post itself isn't PM-relevant, but his ongoing pattern of shipping small, weird, complete products using AI is worth watching as a signal for what solo builders can now do in a day (2026-06-07): https://levels.io/dot-matrix-printer-web-windows-311

  • Aravind Srinivas (Perplexity): Posting about personal computers with local models and hybrid inference on Intel Ultra Series 3 laptops. Signals that Perplexity is paying close attention to on-device inference as a product distribution vector — worth watching if you build anything that competes with or depends on search (2026-06-07): https://x.com/AravSrinivas

  • Karri Saarinen (Linear): Linear's Mobile Agent and Pulse are his go-to features. Agent handles most tasks from anywhere; Pulse gives daily project summaries. Clean signal for what "useful AI in a PM tool" looks like when it's actually working (2026-05-06): https://x.com/karrisaarinen/status/2052070381935341958

The Thread#

The cost structure of AI features is becoming a product problem, not just an engineering problem. Ravi Mehta's tokenmaxxing framework, Sarah Guo's diffusion-friction framing, and the Cursor SDK's new metadata persistence controls all point in the same direction: AI at scale requires deliberate architecture decisions that PMs need to understand and own. The teams that treat token spend as an engineering line item they don't touch will get surprised by it. The ones that build cost visibility into their feature instrumentation from the start will have a cleaner path to profitability.

Sit With This#

Tony Fadell's "three generations rule" says every major product platform takes roughly three generations to find its form. Most AI features in production today are on gen 1 or gen 2.

For your AI feature: Which generation is it on, and are you measuring it like it's already gen 3? What would you need to see before treating it as a mature product rather than an experiment?