Claude Fable 5 review: what the new Mythos model gets right (and very wrong)

Claire puts Claude Fable 5, Anthropic’s first generally available Mythos-class model, through a series of real-world tests: product specs, agent workflows, design tasks, vision tasks, and multi-agent orchestration. She breaks down what Anthropic is claiming, where the model genuinely feels like a leap forward, and where it surprisingly falls short.

Biggest takeaways:

1. Fable 5 is Anthropic’s first “Mythos-class” model to reach general availability, and it’s crushing benchmarks across the board. It hit 80% on SWBench Pro, significantly outperforming Opus 4.8, GPT-4.5, and Gemini 3.1 Pro. Claire found the model excels in specific areas while falling short in others that matter for everyday product work.

2. The model is expensive by design: $10 per million input tokens and $50 per million output tokens. That’s a new tier above Opus, and it consumes tokens at roughly twice the rate of other models. You need to be strategic about when to deploy this level of intelligence versus using cheaper models like Sonnet or Opus for simpler tasks.

3. Fable 5 works like a “seasoned engineer”—which is both its superpower and its Achilles’ heel. It’s thorough, autonomous, and will investigate every corner of a problem to be 120% sure it’s shipping the right thing. Sometimes you need a model that’s a little less thorough, a little “dumber,” to actually ship something useful quickly.

4. The model is exceptionally good at vision tasks, particularly document formatting and PDF parsing. Claire tested it on creating handwriting worksheets for her 7-year-old and found it dramatically outperformed Opus 4.8—better spacing, clearer layout, appropriate white space. This extends to other vision tasks where you want something to look good or need to parse complex documents.

5. The writing is nearly unreadable for specs and PRDs. Claire found that Fable 5 produces extremely detailed, technically complete documents that are almost impossible to parse. It gets wrapped around the axle on details, creates big blocks of dense paragraphs with internal references, and makes it hard to see the forest for the trees.

6. Design output is shockingly bad, at least for one-shot design tasks. When Claire asked Fable to design a skills registry, it produced fundamentally terrible design: gray, black, red, simple outlines. This was a real surprise given the model’s benchmark performance.

7. The model is conservative on execution and takes “minimal” very literally. When Claire asked it to ship an MVP that would deliver customer value, Fable produced something extremely narrow and not actually that useful. This conservatism may stem from the safety guardrails built into the model.

8. Fable 5 includes specific safeguards for cybersecurity, biology, chemistry, and distillation tasks. Instead of blocking you entirely, it uses a new “fallback” concept—if you get classified into one of these categories, it gracefully falls back to Opus 4.8. Anthropic reports that 95% of sessions don’t hit a fallback, and they maintain a 30-day retention policy solely to catch misuse.

9. Multi-agent orchestration is technically possible but not yet reliable. Claire tested the dynamic workflows and subagent capabilities extensively and had some successful multi-agent runs, but also encountered frequent stalls and errors. She walked away from her laptop and came back to find subagents had stalled after about three hours.

10. The key insight: match model intelligence to task complexity. Claire recommends using it for hard technical problems where extreme detail matters, long-horizon work, and vision tasks. But for front-end work, strategy, specs, and design, other models in the ecosystem will serve you better and cost less.

11. This is “baby Mythos,” not the full Mythos model. Fable 5 has guardrails that the unrestricted Mythos model (available only to Project Glasswing partners) doesn’t have. The underlying model is the same, but Fable is tuned for safety and general availability.

How Braintrust uses AI agents, evals, and CI to ship better software | Ankur Goyal

Brought to you by:

• Guru—The AI layer of truth

• Persona—Trusted identity verification for any use case

Claire sits down with Ankur Goyal, the founder and CEO of Braintrust, to unpack how top engineering teams are using AI agents, evals, and CI to ship better software faster. They get into why agents are now capable of tackling hard infrastructure problems, how to decide what work sits “below the agent line,” and why evals are quickly becoming the modern version of a PRD. Ankur’s core message: the best teams won’t just use AI to write more code; they’ll build the feedback loops, benchmarks, and systems that let AI improve the quality of the product itself.

Biggest takeaways:

1. There’s no staff engineer running as many rigorous benchmarks as someone using an agent. Ankur viscerally disagrees with engineers who say AI can’t handle complicated problems. While models might not be perfect at writing highly concurrent code, they excel at running exhaustive experiments—testing every column store format, every execution engine, every optimization strategy. The baseline of rigor you get from agents is incredible, and there’s simply no excuse anymore to skip benchmarks because they’re tedious.

2. The agent line keeps going up—and you need to identify what’s below it. Many interactions, decisions, and directions that feel like they need human judgment actually fit “below the agent line.” If you took the information from a meeting and gave it to an agent, would it solve the same problem? Increasingly, the answer is yes. The best teams push this line higher by building smart skills and integrations that expand what agents can handle autonomously.

3. Practical quality beats theoretical quality every time. In theory, a human engineer with infinite time and focus might produce better code than an AI agent. In practice, humans lose context over days, have decaying attention spans on hard-but-tedious problems, and skip benchmarks they know they should run. AI agents maintain consistent focus, run every test, and can work on problems continuously for days or weeks. The practical quality of AI-assisted engineering is higher because of sustained rigor, not because the code is theoretically better.

4. You can now bite off much harder technical problems than before. Companies historically avoid major infrastructure changes because the cost of testing alternatives is prohibitively high and the unknown unknowns are risky. With AI agents, you can exhaustively test six different database solutions, run thousands of benchmarks on production-scale data, and make informed decisions about platform shifts that would have been impossible before. The business case for deep technical work becomes much easier when agents do the heavy lifting.

5. Run four to six foreground agents simultaneously—that’s the human concurrency limit. Ankur runs different agents working on different problems. This matches the personal concurrency limit most people can manage; you can’t effectively context switch between more than that. Some agents run locally, and others run remotely on cloud infrastructure with production-scale data. The key is isolation: each agent has its own environment, ports, and services.

6. Evals are the modern PRD—they define what success looks like, not how to achieve it. Machine learning shifts programming from defining implementation details to defining success criteria. Just like the best PRDs include user stories and examples, the best evals include concrete test cases and scoring functions. The difference is that evals quantify success in ways that can be automatically measured and improved. This lets you focus on outcomes while AI figures out the implementation.

7. Build a feedback loop that automatically turns real-world data into evals. For AI product teams, the #1 engineering priority isn’t prompt engineering or picking an agent framework—it’s building a pipeline that summons real-world data and converts it into evals. This is the same principle as investing in CI for traditional software: you’re building the platform that lets agents do the work engineers used to do manually. Without this feedback loop, you’re stuck in whack-a-mole mode, fixing individual cases without systematic improvement.

8. Quantify your designer’s taste so it scales across your product. Ankur runs hundreds of evals to improve things quantitatively, then asks David (their tastemaker designer) for a vibe check every few days. When David destroys his work, Ankur captures the feedback (“David thinks it’s OK to show both languages as long as . . .”) and improves the scoring functions to encode David’s palette. This doesn’t replace David; it amplifies him. They’re able to apply David’s quality bar to more things than he could ever review manually.

9. Product building is now carving, not constructing. It’s extremely fast to create something with too many features, too many buttons, and too much code. The hard part is removing stuff. When customers complain, Braintrust removes the thing causing confusion 90% of the time, making the system work better by eliminating complexity. This is the opposite of traditional product development, where you carefully add features one by one.

10. Invest in CI to earn the ability to move faster—it’s the platform for AI-powered engineering. Every engineer is now building a platform upon which agents do the work engineers used to do manually. For traditional software, that platform is CI. If you feel constrained by velocity, don’t ship crappy stuff faster. Instead, pause and improve CI so you earn the ability to move faster safely. The same principle applies to AI products: build the eval pipeline first, then let agents optimize within that system.

11. When agents fail, close the session and improve the evals—don’t yell or bribe. Ankur’s back-pocket strategy is remarkably disciplined: he doesn’t try to prompt his way out of problems. He closes the session, improves the evaluation criteria or success metrics, and starts fresh. Sometimes this means hand-writing code to better understand the problem (like when he spent a weekend hand-writing a 3,000-line eval that had become trash through vibe coding). The solution is always better evals, not better prompting.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

In this episode, I sit down with Ankur Goyal, founder and CEO of Braintrust, the AI evals and observability platform used by teams like Notion, Stripe, Vercel, and Zapier. This one is for the senior engineers, staff engineers, VPs of engineering, and CTOs in my audience. We get into how coding agents can take on deeply technical architecture and infrastructure work that no single human engineer could tackle before, and then we demystify evals so you can use them to make your AI products better without touching the implementation.

What you’ll learn:

1. How Ankur uses Codex to run week-long benchmark experiments across database indexes, column store formats, and execution engines to speed up slow queries

2. Why he argues there’s no excuse to skip rigorous benchmarking now that agents can run them tirelessly

3. The “agent line” framework: how to decide which decisions, directions, and interactions you can hand off to an agent

4. How I think about the practical vs. theoretical quality of AI on hard technical problems, and why human attention decays on tedious work

5. Why evals are the modern version of a PRD, and how to encode “what good looks like” so a model can figure out the “how”

6. How to build a scoring function live and let an agent improve your prompt inside a safe playground

7. How Ankur turned his designer David’s taste into a repeatable eval so quality scales beyond one person

8. Why fixing your CI is the highest-leverage way to speed up engineering velocity

Brought to you by:

Guru—The AI layer of truth

Persona—Trusted identity verification for any use case

In this episode, we cover:

(00:00) Introduction to Ankur Goyal

(03:00) Using AI agents for database optimization

(06:10) Running exhaustive benchmarks with coding agents

(09:03) Why staff engineers are wrong about AI limitations

(11:30) The “agent line” framework for delegation

(14:00) Ankur’s workflow: running 4 to 6 concurrent agents

(17:16) Technical setup: foreground agents, background agents, and cloud environments

(20:32) Spending time with AI tools

(23:06) Demystifying evals

(26:02) Live demo: Building an eval for documentation answers

(30:20) The alternative to evals: vibe checks and whack-a-mole

(32:09) Capturing designer taste in scoring functions

(33:13) Quick recap

(33:44) Managing velocity and throughput

(35:40) Why CI/CD investment is critical for AI-accelerated teams

(37:30) Ankur’s prompting strategy when agents fail

(39:10) Closing thoughts and how to connect

Tools referenced:

• Braintrust: https://www.braintrust.dev/

• Codex: https://openai.com/codex/

• GPT 5.4: https://developers.openai.com/api/docs/models/gpt-5.4

• Claude: https://claude.ai/

Other references:

• GPT 5.5 just did what no other model could: https://www.lennysnewsletter.com/p/gpt-55-just-did-what-no-other-model

• Paul Graham’s Maker vs. Manager Schedule: http://www.paulgraham.com/makersschedule.html

• tmux: https://github.com/tmux/tmux

• Chris Tate at Vercel: https://www.linkedin.com/in/ctatedev/

Where to find Ankur Goyal:

LinkedIn: https://www.linkedin.com/in/ankrgyl/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Claude Fable 5 is the first Mythos-class intelligence model to be generally available, and I got early access to test it before launch. I walk through what Anthropic is promising, what actually stood out when I used it on real work, and where I think it fits in your AI stack.

In this episode, we cover:

(00:00) Introduction: Fable 5 is finally here

(00:31) What Anthropic says about the model

(05:14) Token-intensive by design

(06:28) Safety classifiers and the new fallback concept

(07:46) Is this or is this not Mythos?

(08:30) New product launches: Managed Agents and more

(09:20) Crushing benchmarks

(09:55) What it’s actually like to use (the good and the bad)

(11:40) Test 1: product graph spec

(12:56) Test 2: designing a skills registry

(14:04) Conservative on execution

(14:43) Test 3: multi-agent orchestration

(15:39) My takeaways

Tools referenced:

• Claude Fable 5: https://www.anthropic.com/news/claude-fable-5-mythos-5

• Claude Managed Agents: https://platform.claude.com/docs/en/managed-agents/overview

Other reference:

• SWBench Pro benchmark: https://www.swebench.com/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Gemini Omni: Clone yourself with AI in under 15 minutes

Brought to you by:

• Merge—Connective infrastructure for production AI

• Jira Product Discovery—Prioritize with insights, build with confidence

In this solo episode, Claire puts Google Flow and Gemini Omni to the test by cloning herself into an AI avatar and using it to build a full hype reel in about 15 minutes. She walks through the whole workflow live: scanning her face, generating scenes, troubleshooting weird outputs, stitching the video together, and reacting to the very real uncanny-valley moments along the way. It’s part tutorial, part tech demo, and part “wait, this is already possible?” glimpse into how AI video tools are making high-quality creative production accessible to anyone with an idea and a laptop.

Biggest takeaways:

1. AI video tools are unlocking creative capabilities for non-video professionals. Claire, who describes herself as “creative, but not video-creative,” was able to produce a complete one-minute hype video without any prior video production experience. The entire process—from creating an avatar to final video—took roughly 15 minutes, demonstrating how these tools democratize creative work that previously required specialized skills and expensive equipment.

2. AI can serve as a creative collaborator, not just a tool. Rather than just generating videos, Google Veo acted as a creative partner, helping Claire brainstorm scenes, develop a storyboard, and think through the overall narrative arc. The AI asked clarifying questions about setting, tone, and style, then proposed a seven-scene structure that Claire could refine and execute.

3. Character consistency remains a major challenge in AI video generation. Throughout the generated videos, Claire’s avatar appeared with different hair lengths, varying backgrounds (some with books, some with plants, different wall colors), and inconsistent environmental details. While the AI pulled some accurate elements from her original photos (like posters in the background), it couldn’t maintain perfect consistency across scenes.

4. Emotional expression is still a weak point for AI avatars. While some scenes looked remarkably realistic—particularly side profiles and serious expressions—scenes requiring emotion fell flat. Claire described one laughing scene as “100% uncanny valley,” noting she looked like she was “on some kind of medication perhaps.” The technology hasn’t quite mastered the subtle muscle movements that make human expressions feel authentic.

5. The workflow from idea to finished video is remarkably fast. The entire process included creating the avatar (a few minutes), brainstorming with AI (a few minutes), generating seven video scenes (several minutes total), and stitching them together in the built-in editor (about five minutes). What would have traditionally required a production team, studio time, and significant budget happened in a single session at a desk.

Shopping with Claude: How to find quality brands, automate returns, and buy things that last 100 years | Nicole Ruiz

Brought to you by:

• Orkes—The enterprise platform for reliable applications and agentic workflows

• Metaview—The agentic recruiting platform for winning teams

Nicole Ruiz has built a Claude-powered shopping system to help her family buy fewer, better things—and avoid the endless noise of Amazon, drop-shippers, and low-quality brands. In this episode, she shares how she uses Claude Projects to vet every household purchase against criteria like craftsmanship, materials, brand history, and return policies, plus how she uses Claude Cowork to make returns faster when something doesn’t hold up. It’s a practical look at how AI can reduce decision fatigue, surface higher-quality products, and help busy parents spend less time managing stuff.

Biggest takeaways:

1. The modern internet shopping experience is broken for people who want quality over convenience. Between paid ads, drop-shipping brands, and knockoff products on Amazon, it’s incredibly difficult to find thoughtfully made items that will last for years. Nicole’s solution: build a Claude Project that holds all her purchasing criteria and trusted brands in one place, so she never has to start from scratch.

2. Keep a running list of brands you trust, and let AI search through them for you. Nicole maintains a list of shops with decades of history, strong return policies, and proven craftsmanship. When she needs something, she asks Claude to search through these trusted vendors first. This flips the typical shopping flow: instead of searching the entire internet and filtering out garbage, she’s searching a pre-vetted list and only expanding if needed.

3. Your purchasing criteria should be written down and reusable. Nicole has specific requirements: natural materials, made to last and repair, decades of business history, strong return policies, and no trendy direct-to-consumer brands that over-invest in advertising. By codifying these criteria in a Claude Project, she removes the mental overhead of running through an invisible checklist every time she needs to buy something.

4. AI can surface brand history and quality signals that would take hours to research manually. When Nicole queries a product, Claude explains why each brand is trustworthy, surfacing details like “This brand has been manufacturing the same tote bag for over 80 years” or “This company got acquired two years ago and reviews have been abysmal since then.” These insights help her make informed decisions without hours of research.

5. The worst websites often belong to the best manufacturers. Heritage brands that have been making quality products for decades frequently have terrible websites that are hard to navigate. This puts them at a disadvantage compared with Amazon or well-funded DTC brands. AI levels the playing field by making it just as easy to shop from a 100-year-old manufacturer with a clunky website as from Amazon.

6. Format your AI shopping results to surface the information that matters most to you. Nicole’s Claude Project presents each product with specific details: product name, photo, price, materials (especially important for avoiding plastic), care and maintenance notes, purchase link, and a brief note on the brand’s trustworthy history. This consistent format makes it easy to compare options and make quick decisions.

7. Use AI to automate the tedious parts of returns and refunds. When a product fails—like J.Crew pants that wore through after six months—Nicole uses Claude Cowork to pull the original receipt from her email, find the order details, and draft a customer service email requesting a refund. What would normally take 10 to 15 minutes now takes 2 to 3 minutes of voice dictation from her phone.

8. AI can identify manufacturing issues by analyzing review patterns. When Nicole requests a return, Claude often discovers that other customers had the same problem with the same product from the same time period, suggesting a manufacturing defect rather than normal wear. This strengthens her refund request and helps her avoid brands with known quality-control issues.

9. Build your shopping system for multiple use cases. Nicole uses her Claude Project in three main ways: “Help me find a can opener” (specific item search), “I have $30 for L.L.Bean; what should I buy?” (budget-constrained search), and “What’s your analysis of this brand I found?” (vetting a new brand). This flexibility makes the system useful for different shopping scenarios.

10. Buying quality items up front reduces household maintenance over time. Nicole’s philosophy is to move as much vetting upstream as possible. She lives in a small Brooklyn apartment with two young children, and every item needs to stand the test of time. By investing time in building a shopping system that prioritizes quality, she spends less time dealing with broken items and processing returns. The goal: buy things that will last for multiple children and can be mended rather than replaced.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

Nicole Ruiz is a writer and parent who has built a comprehensive AI-powered shopping system to help her family buy high-quality, long-lasting items while avoiding the noise of drop-shipping brands, paid ads, and poorly made products. She writes an interview series on Substack about how technology is changing the household.

What you’ll learn:

1. How to build a Claude Project with custom instructions for vetting brands based on heritage, craftsmanship, and return policies

2. The shopping criteria that help surface century-old manufacturers over trendy direct-to-consumer brands

3. How to use Claude to search through trusted vendor websites that have terrible UX

4. Why AI actually helps small artisans and heritage brands compete against Amazon’s infrastructure

5. How to use Claude Cowork to automate returns by finding receipts in your email and drafting refund requests

6. The technique for getting Claude to analyze whether a brand is legitimate or just a drop-shipping operation

7. How to shop within a specific budget or with gift cards using AI assistance

Brought to you by:

Orkes—The enterprise platform for reliable applications and agentic workflows

Metaview—The agentic recruiting platform for winning teams

In this episode, we cover:

(00:00) Introduction to Nicole and AI-powered shopping

(02:29) The problem

(04:55) Building a Claude Project for household purchasing

(07:44) The “anti-to-do list” concept for reducing mental overhead

(10:30) Shopping for a can opener: the system in action

(15:53) How AI helps century-old brands with terrible websites

(18:45) Processing returns with Claude Cowork

(25:06) Using gift cards strategically

(26:33) Vetting brands

(29:40) Recap, lightning round, and final thoughts

Tools referenced:

• Claude: https://claude.ai/

• Claude Cowork: https://www.anthropic.com/product/claude-cowork

Other references:

• Boston General Store: https://bostongeneralstore.com/

• L.L.Bean: https://www.llbean.com/

• Manufactum: https://www.manufactum.com/

• 5 OpenClaw agents run my home, finances, and code | Jesse Genet: https://www.lennysnewsletter.com/p/5-openclaw-agents-run-my-home-finances

• From a $6.90 newsletter to $3M API: How a non-coder built Memelord | Jason Levin: https://www.lennysnewsletter.com/p/from-a-690-newsletter-to-3m-api-how

Where to find Nicole Ruiz:

X: https://x.com/nwilliams030

Substack (The Third Oikos): https://www.thirdoikos.com/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

In this experimental episode, I document my real-time attempt to create an AI avatar of myself using Google Flow and the new Gemini Omni video generation model. I walk through the entire process—from scanning my face with my phone to generating a complete one-minute hype video for the podcast, all in about 15 minutes.

What you’ll learn:

1. How to create an AI avatar using Google Flow in under five minutes

2. Why video AI tools unlock creative possibilities for people with zero video production skills

3. The step-by-step process of generating a full storyboard using AI as your creative producer

4. How to use character consistency features to generate multiple video scenes with the same avatar

5. The uncanny-valley moments you’ll encounter when your AI clone doesn’t quite nail emotions or physics

6. How to stitch together AI-generated scenes into a complete video using built-in editing tools

Brought to you by:

Merge—Connective infrastructure for production AI

Jira Product Discovery—Prioritize with insights, build with confidence

In this episode, we cover:

(00:00) Getting started with Google Flow and Gemini Omni

(01:38) The avatar creation process: scanning and photo capture

(02:55) Using Flow to brainstorm a hype video storyboard

(06:59) Generating the first video scene with the avatar

(08:41) Troubleshooting: accidentally generating images instead of videos

(09:32) Generating all seven scenes for the complete video

(11:37) Reviewing the avatar videos

(13:13) Stitching the videos together in the browser-based editor

(14:32) The complete How I AI hype video

(15:32) What worked and what didn’t

(19:04) Final thoughts

Tools referenced:

• Google Flow: https://labs.google/fx/tools/flow

• Gemini Omni: https://gemini.google/overview/video-generation/

• Veo 3: https://deepmind.google/technologies/veo/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Building an iPhone app with zero technical skills | Bryce Rattner Keithley

Brought to you by:

• WorkOS—Make your app enterprise-ready today

• Metaview—The agentic recruiting platform for winning teams

Bryce Rattner Keithley spent her career in talent and recruiting and had never written a line of code. Then she used AI to build Daily Hundred, a fitness app with custom AI-generated videos of animals doing exercises, and shipped it to the App Store. In this episode, Bryce shares the exact workflow she used with Replit, Claude, Gemini, Higgsfield, and Kling; why being non-technical became an advantage; and what her journey reveals about how AI is changing who gets to build software.

Biggest takeaways:

1. You can build and ship a production iPhone app with zero technical background. Bryce spent her entire career in talent and recruiting, had never written code, and still managed to build Daily Hundred—a fitness app with custom AI-generated videos—and get it approved in the App Store. The entire process took a few months of weekend work.

2. The workflow that worked: Claude as architect, Claude Code as engineer, Terminal as executor. Bryce used regular Claude as her “friend in the cockpit” to plan what to do and how to approach problems. Claude would tell her when to use Claude Code to write actual code. She’d bring the code back to Claude for confirmation, then Claude would tell her what to paste into Terminal. This three-step dance—plan, execute, deploy—let her ship production code without having to know exactly how it all worked.

3. Screenshots and iteration are your best debugging tools. When AI wasn’t understanding what Bryce wanted, she’d either get more literal in her descriptions, completely restart the prompt (not just edit it), or send screenshots showing what she was seeing. Sometimes she’d even draw what she wanted or photograph her own starting position to give the AI a visual reference. The key was trying different approaches rather than getting stuck in one failed pattern.

4. The role of technical expertise is fundamentally changing. Bryce observed that engineers who come into technical interviews focused only on finding a working solution fastest are missing the point—“the robots can find a working solution faster than they can.” The human role has shifted to something broader: understanding the full suite of tools, knowing when to use AI versus when to step in personally, and bringing taste and judgment to the process. What got people here won’t get them there.

5. Hiring for adaptability and openness matters more than ever. In Bryce’s view, people who get territorial about what they used to do or what other people used to do will struggle with relevance. The winners will be those with “the humility and the curiosity to work with others in ways that you haven’t before” and who recognize that “people can contribute in ways that they haven’t before.” The best idea should win, regardless of where it comes from.

The Codex feature that works while you sleep

Brought to you by:

• Mercury—Radically different banking loved by over 300K entrepreneurs

Claire Vo breaks down one of her favorite Codex features: /goal. In this solo episode, she shows how Goals turn AI from a tool you have to constantly babysit into an agent that can work for hours on multi-step tasks. She walks through real examples, including eliminating Sentry errors, cleaning nearly 4,000 emails, and organizing Linear tasks, and shares the six-part framework to write Goals that actually run.

Biggest takeaways:

1. Goals enable AI to work autonomously for hours without supervision. Claire ran a goal in Codex that worked for five hours and 45 minutes—the longest she’s ever had an AI agent run successfully. Unlike standard prompts that require turn-by-turn interaction, Goals create a loop where the AI works, verifies, checks, and continues until it hits the defined outcome.

2. The difference between a prompt and a Goal is fundamental. A prompt is an instruction of what to do (“Rewrite this code”). A Goal is a description of what a good outcome looks like and how to get there (“Reduce P95 checkout latency below a defined threshold while keeping the correctness suite green”).

3. Claire eliminated hundreds of error logs by pointing Goals at her Sentry data. She gave Codex access to every trace of invalid operations, then set a goal: categorize each issue, fix it, then replay all historical examples until every error is solved. The result: zero errors remaining, and instead of bandaid fixes scattered throughout the code, she got a systematic, intelligent framework.

4. Goals work incredibly well for non-technical tasks. Claire cleaned 3,900 emails down to 68 in under four hours by setting a simple goal: categorize all emails, unsubscribe from unnecessary ones, and clean up the inbox. The AI read every email, created labels, clicked unsubscribe links, and left her with only the emails requiring judgment.

5. Strong Goals have six key components: outcome (what should be true when done), verification (how to test it), constraints (what can’t regress), boundaries (what tools and files to use), iteration policy (how to decide what to try next), and stopping conditions (when to ask for help). Product managers who’ve written good OKRs will recognize this framework immediately.

6. Working with Goals feels like managing a colleague, not babysitting a tool. You assign a task, the AI goes away for the time required (whether that’s 30 minutes or five hours), and comes back with completed work for you to review. Claire found herself “twiddling her thumbs” because so much of the work was now handled autonomously.

7. Goals aren’t token-cheap, but they’re worth it. Claire’s email cleanup used about 6 million tokens over four hours. But the alternative—manually categorizing thousands of emails or chasing down hundreds of error logs—would take far longer and be far more tedious.

Claude Opus 4.8 is here. Is it as good as they say?

Claire put Anthropic’s new Opus 4.8 model through real coding, design, and strategy tests across Claude Code and Claude Cowork. She shares where the model shines, where it breaks down, how it compares to Opus 4.7, and what builders should know before using it in production.

Biggest takeaways:

1. The voice and ergonomics are excellent. Opus 4.8 is easy to read, doesn’t have “slop tells,” is token-efficient, and feels conversational without being annoying. It talks enough but not too much, and with fast mode enabled, the experience is snappy. The writing quality is strong and the model follows instructions well.

2. Anthropic is shipping new features alongside Opus 4.8 that expand agentic capabilities. Claude Code now has dynamic workflows that let you spin off hundreds of parallel sub-agents. Both Claude.ai and Cowork now offer effort control from low to max, giving users more control over how deeply the model thinks through problems.

3. Use Opus 4.8 for greenfield prototypes and design work, but test carefully for production codebases. The model excels at one-shot features, has improved design aesthetics (no more italicized emphasis words), and is good at tool use. But for existing codebases, edge cases, and strategy work requiring numerical analysis, you’ll need careful prompting and should double-check anywhere the model expresses high confidence.

4. The model hallucinates when it gets stuck, which is a significant regression. Claire experienced straight-up hallucinations multiple times—something she hadn’t seen in a very long time with modern models. When debugging, Opus 4.8 would make up explanations based on hypotheses rather than actual data. It would confidently state things like “No, I didn’t search GitHub” or “No, I didn’t actually validate that bug” when asked to verify its work.

5. Opus 4.8 struggles to orient itself in existing codebases. When Claire asked it to rebase branches and fix conflicts in her production codebase, it required cycle after cycle of fixes because it kept shipping edge-case bugs. The model couldn’t understand the elevation at which it should be operating or how to properly insert itself into existing code.

6. The model isn’t ambitious enough for truly agentic work. Claire asked it to suggest fun things to build that would impress a 9-year-old, pushing it to explore the edges of agentic coding. While it shipped working code, the results were serviceable but not impressive—not the 10x agentic coding experience she expected from a state-of-the-art model.

7. For business strategy work, Opus 4.7 significantly outperforms Opus 4.8. Claire tested both models on the same strategy prompt, giving them access to three months of business context. Opus 4.7 delivered numbers-anchored, structured analysis rooted in real data. Opus 4.8 was hand-wavy, over-rotated on small data points, and had a harder time discovering relevant information.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

Bryce Rattner Keithley has spent her career in talent and recruiting, working with technical leaders but never writing a line of code herself. Yet she managed to build Daily Hundred—a fitness app featuring custom AI-generated videos of anthropomorphic animals demonstrating exercises—and ship it to the App Store before her software engineer friends. Using Replit, Claude, Gemini, and a relentless beginner’s mindset, Bryce proves that in the AI era, execution is no longer the constraint on good ideas.

What you’ll learn:

1. How to build and ship an iPhone app using Replit without any coding knowledge

2. The step-by-step process for creating custom AI-generated workout videos by combining Gemini images with real exercise footage

3. How to use Claude as your technical architect and Claude Code as your software engineer

4. How to navigate App Store submission requirements (including fixing rejection feedback)

5. Why being hyper-literal in your prompts unlocks better AI results

6. Why a beginner’s mind is actually an advantage when building with AI tools

Brought to you by:

WorkOS—Make your app enterprise-ready today

Metaview—The agentic recruiting platform for winning teams

In this episode, we cover:

(00:00) Introduction to Bryce and Daily Hundred

(04:48) Building with Replit

(06:16) The beginner’s mindset advantage

(11:17) Creating anthropomorphic animals

(22:55) Moving from static image to video

(27:15) The floating genie and other anthropomorphic animal generations

(30:46) Shifting from web app to App Store submission

(36:24) User feedback

(37:41) Lightning round and final thoughts

Tools referenced:

• Replit: https://replit.com/

• Lovable: https://lovable.dev/

• Claude: https://claude.ai/

• Claude Code: https://claude.ai/code

• Gemini: https://gemini.google.com/

• Higgsfield: https://higgsfield.ai/

• Kling: https://kling.ai/

• Railway: https://railway.app/

• TestFlight: https://developer.apple.com/testflight/

Other references:

• How a 91-year-old vibe coded a complex event management system using Claude and Replit | John Blackman: https://www.lennysnewsletter.com/p/how-a-91-year-old-vibe-coded-a-complex

• What Got You Here Won’t Get You There: https://www.amazon.com/What-Got-Here-Wont-There/dp/1401301304

• How Women Rise: https://www.amazon.com/How-Women-Rise-Holding-Careers/dp/0316440124

• A Whole New Mind: https://www.amazon.com/Whole-New-Mind-Right-Brainers-Future/dp/1594481717

• How to Win Friends and Influence People: https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034

Where to find Bryce Rattner Keithley:

LinkedIn: https://www.linkedin.com/in/brycerattner/

GitHub: https://github.com/brk-bot/

Daily Hundred on the App Store: https://apps.apple.com/us/app/daily100-fitness-challenge/id6762108062

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

I got a few hours of early-access testing with Anthropic’s newly released model Opus 4.8. I walk through real coding, design, and strategy tasks across Claude Code and Claude Cowork, and give you my unfiltered view on what impressed me and what didn’t.

What you’ll learn:

1. Where Opus 4.8 excels: greenfield prototypes, one-shot features, and fast execution

2. Where it struggles: the last 10%, edge cases in existing codebases, and hallucinations

3. How Opus 4.8 compares to Opus 4.7 on business strategy work

4. Why I’m still reaching for Opus 4.7 on data-heavy strategy and roadmap work

5. The new features shipping alongside the model: dynamic workflows with parallel subagents and effort control in Claude.ai and Cowork

6. The prompting and harness strategy I’d use to get the most out of it

In this episode, we cover:

(00:00) Introduction to Opus 4.8

(00:44) Benchmark performance and pricing

(01:53) First coding test: Building a prototyping tool

(03:00) Where it failed: The last 10% problem

(03:27) The hallucination problem

(04:23) Testing Opus 4.8 on existing codebases

(05:24) The ambition test: Building games for a 9-year-old

(07:03) Business strategy test: 4.7 vs 4.8

(08:23) The roadmap test

(09:17) Final verdict

References:

• System Card: Claude Opus 4.8: https://cdn.sanity.io/files/4zrzovbb/website/c886650a2e96fc0925c805a1a7ca77314ccbf4a6.pdf

• Introducing Claude Opus 4.8 on X:

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

In this 30-minute episode, I walk through my favorite feature in Codex: the /goal command. I show how Goals transform AI from a turn-based assistant that needs constant ‘what’s next?’ prompting into an autonomous agent that can work for hours on complex, multi-step tasks. I share three real examples: eliminating thousands of Sentry errors, cleaning 3,900 emails down to 68, and organizing hundreds of Linear tasks.

What you’ll learn:

1. What Goals are and how they differ from standard prompts

2. How I used /goal to eliminate hundreds of error logs in my codebase over a five-hour autonomous run

3. The non-technical use cases that make Goals incredibly powerful: cleaning up 3,900 emails in under four hours and organizing hundreds of project management tasks in Linear

4. How to write effective /goal prompts with measurable outcomes, verification methods, and constraints

5. When not to use Goals and what makes a strong versus weak Goal

6. Why Goals represent a fundamental shift in how we work with AI, from babysitting the model to managing it

Brought to you by:

Mercury—Radically different banking loved by over 300K entrepreneurs

In this episode, we cover:

(00:00) Introduction

(01:50) What is /goal and when should you use it?

(02:45) The difference between prompts and Goal-based loops

(04:06) Claire’s first five-hour 45-minute autonomous coding task

(05:05) How to manage a Goal lifecycle: view, pause, resume, and clear

(06:06) How to write strong goals: outcomes vs. outputs

(07:34) The six components of effective Goals

(08:57) Example: Reducing P95 checkout latency with /goal

(09:36) Demo: Using /goal to eliminate Sentry errors in ChatPRD

(13:18) Demo: Burning down Vercel API errors

(17:28) Non-technical use case: Cleaning 3,900 emails with /goal

(21:24) Demo: Using /goal to clean up Linear project tasks

(24:41) When not to use /goal

(26:10) Why /goal changes everything

Tools referenced:

• Codex: https://openai.com/codex/

• Sentry: https://sentry.io/

• Vercel: https://vercel.com/

• Linear: https://linear.app/

Other reference:

• OpenAI blog post “Using Goals in Codex”: https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

How the engineer behind Claude Cowork actually uses Claude | Felix Rieseberg (Anthropic)

Brought to you by:

• Magic Patterns—Prototypes that look like your product

• Guru—The AI layer of truth

Felix Rieseberg, the engineering lead for Claude Cowork and Claude Code Desktop at Anthropic, joins Claire to show how he actually uses Claude in his own life and work. In this episode, Felix walks through building a 3D floor planner from a 2D house plan, using email as a personal inventory database, creating live dashboards from connected apps, and hacking together a $20 hardware “Claude buddy.” He also shares his philosophy for getting more out of AI: go one abstraction layer up, let Claude work in the background, and stop assuming computers can’t solve some of the annoying little problems in your life.

Biggest takeaways:

1. The biggest barrier to AI adoption is people not realizing they can ask AI to solve almost any problem. Felix sees this constantly—the tools are incredibly powerful, but users haven’t built the muscle memory to reach for them. His advice: whenever you’re doing something annoying that doesn’t feel creative, pause and ask yourself if Claude could do it instead. The gap isn’t technical; it’s psychological.

2. Your email is an untapped gold mine of personal data. Felix used his email to inventory all his furniture when moving houses: every purchase receipt, every confirmation, every dimension. Claude parsed it all and built him a 3D floor planner with his actual furniture. This same principle applies to clothing, medical records, travel history, or any domain where you’ve been emailing receipts and confirmations for years. You already have a structured database—you just need to point Claude at it.

3. Go one abstraction layer up, then do it again. Felix started manually entering furniture dimensions into his floor planner, then stopped and asked Claude to figure out what furniture he had. Then he went another layer up and told Claude to find the furniture in his emails. This is the key pattern: every time you catch yourself doing tedious work, ask how Claude could do it instead. Then ask how Claude could figure out what to do without your telling it.

4. Live artifacts are Claude’s answer to keeping your personal dashboards always up-to-date. Unlike static artifacts, live artifacts refresh with real-time data from your connected services—Spotify, Gmail, Calendar, Notion, whatever you’ve authorized. Felix built a personal dashboard that looks like early-2000s software that updates throughout the day. The killer feature: you never have to manually update your pitch deck, your daily briefing, or your personal reports again.

5. Choose Opus when you don’t know what you’re really asking for. Felix’s heuristic for model selection: use Sonnet when the problem is well-scoped and specific. Reach for Opus when you need Claude to interpret what you actually want, not just what you said. It’s the difference between “make me a floor plan with units” (Sonnet territory) and “help me figure out how to organize my life” (Opus territory). For most tasks, Sonnet is perfectly capable, but when you need that extra layer of problem decomposition, Opus is worth it.

6. Kids are the best AI users because they aren’t afraid to ask for things. Felix gets videos from parents showing what their kids build with Claude—custom video games with hand-drawn characters, interactive stories, tools that would have required a software engineer just a few years ago. Adults have spent 20 years in a “mind prison” learning what computers can’t do. Unlearning that is the unlock.

7. When Claude makes mistakes, debug your workflow, not the model. Felix doesn’t curse at Claude (though he notes it’s useful for the team to know when people do). Instead, he asks it: “Here’s what I expected. Can you walk me through where things went differently? How can we prevent this in the future?” Usually the fix isn’t “Claude can’t do this”; it’s “I need to change the prompt, clean up the data source, or set up a dry run.” Treat Claude like a collaborator who needs better instructions, not a tool that’s broken.

What launched at Google I/O 2026 (30-minute day 1 recap)

Brought to you by:

• Magic Patterns—Prototypes that look like your product

• ThoughtSpot—Build AI-powered analytics into your product

Claire breaks down the biggest launches from Google I/O 2026—from Gemini 3.5 Flash and Antigravity 2.0 to Google AI Studio, Omni, Flow, Stitch, and Pomelli. In this episode, she tests the tools live, shares what actually works, and explains where Google is catching up, where it may be pulling ahead, and why its launch-to-availability gap is still such a problem for builders.

Biggest takeaways:

1. Gemini 3.5 Flash rivals leading frontier coding models in Google’s benchmarks while running four times faster. Google positions this as their agentic coding model, optimized for tasks requiring both high reasoning and rapid execution. If the benchmarks hold in practice, this speed advantage could shift the coding agent landscape toward Google’s tools.

2. Antigravity 2.0 brings Google’s IDE to feature parity with Claude Code and Codex—but it’s playing catch-up. The update includes projects (folder-constrained workspaces), scheduled tasks on Cron, and subagents for specific tasks. The UI looks nearly identical to Codex, and the features match what Anthropic and OpenAI shipped months ago. The advantage is speed: if Gemini 3.5 Flash delivers, developers might choose Antigravity for well-scoped tasks that need to ship fast.

3. The /grill-me slash command is Antigravity’s aggressive take on Claude Code’s polite clarification tool. Instead of gently asking questions, /grill-me promises to interrogate your requirements and get to the heart of what you’re building. Whether this is actually more hardcore or just clever branding remains to be seen, but it signals Google’s attempt to differentiate on personality.

4. Google AI Studio now integrates directly with Workspace apps—or it’s supposed to. The promise: build no-code apps that read Sheets, draft Gmails, organize Drive, and see Calendar without setup. Claire couldn’t get it to work during testing. If it delivers, it would capture internal enterprise productivity use cases and personal assistant workflows where Google already owns the data layer.

5. Omni is Google’s answer to Sora, focused on longer, production-quality video. The model creates 10-second videos (versus Sora’s 6 or 7 seconds), maintains character consistency across edits, and allows conversational editing. Claire tested it by animating her kid’s drawing, and the output was impressive. The real power will be in production workflows where you iterate on the same characters and scenes multiple times.

6. Flow is Google’s production-grade video editor built on Omni. It lets you define characters, create avatars, and edit videos conversationally while maintaining cinematic quality. The tool targets creators and marketers who need consistent, high-quality video at scale. Claire tried creating an avatar of herself, but the feature failed—a recurring theme throughout I/O announcements.

7. Stitch and Pomelli are Google’s design and marketing tools. Stitch is like in-browser Figma with streaming design generation, inline AI edits, and code sync. Pomelli creates brand books, campaign assets, and websites from a URL. Both show promise but suffer from “Google slop,” the generic aesthetic of AI-generated design.

8. Gemini’s multimodal capabilities remain its strongest differentiator. For work involving files, videos, or transformative work across modalities (document to video, image to text), Gemini models excel. Claire uses them for generating blog posts from podcast videos and animating drawings. The 3.5 family continues this strength; for these use cases, Gemini’s multimodal performance is best-in-class.

9. The biggest problem: half the features don’t actually work yet. Claire encountered broken features, missing integrations, and “coming soon” disclaimers throughout testing. Workspace integration in AI Studio? Couldn’t access it. Avatar creation in Flow? Didn’t work. When you announce features that aren’t ready, people lose patience and stop trusting your roadmap.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

Felix Rieseberg is the engineering lead for Claude Cowork and Claude Code Desktop at Anthropic. He previously spent five years at Slack building developer tools. In this episode, Felix demonstrates how he uses Claude to solve real-life problems: analyzing floor plans to build interactive 3D house walkthroughs, automatically tracking promises he makes on Twitter, and building a $20 hardware device that physically approves Claude actions with a button press.

What you’ll learn:

1. How to use Claude Cowork to turn a 2D floor plan into an interactive 3D walkthrough where you can move furniture around

2. The “go one abstraction layer up” philosophy: why you should never manually enter data Claude can find itself

3. How to use your email as an inventory database for furniture, clothing, and personal purchases

4. When to use Opus vs. Sonnet 4.6 (hint: it’s about how well you can scope the problem, not technical complexity)

5. How live artifacts work and why they’re powerful for dashboards that refresh with real-time data from your connectors

6. The product philosophy behind making latency delightful

7. How to build your own $20 hardware device using Claude Code (no hardware experience required)

8. Why Felix never reads the code Claude writes and judges it purely on output

Brought to you by:

Magic Patterns—Prototypes that look like your product

Guru—The AI layer of truth

In this episode, we cover:

(00:00) Introduction to Felix Rieseberg

(02:40) Felix’s role at Anthropic

(03:25) The multiple tabs in Claude and why they exist

(05:55) Using Claude Cowork to design a new house using floor plans

(09:52) When to use Opus versus Sonnet 4.6

(12:37) Building an interactive 3D furniture planner

(14:30) Using your email as a source of truth for personal inventory

(15:58) The anti-to-do list: going one abstraction layer up

(23:14) Introduction to live artifacts

(26:02) Building a personal dashboard with live data

(28:37) Being polite to Claude (and why it matters for your humanity)

(30:28) Claude interaction tips

(32:33) Looking at the daily dashboard

(33:55) How live artifacts work with connectors

(35:02) Redesigning the dashboard

(37:55) The biggest gap: people don’t know what problems AI can solve

(41:52) The reverse interview

(42:30) Making latency delightful through asynchronous design

(44:05) The redesigned dashboard

(45:28) AI should free up your creative energy

(46:44) Building a $20 hardware Claude buddy

(52:33) Why kids are magical AI users

(54:30) Recap and final thoughts

Tools referenced:

• Claude Cowork: https://www.anthropic.com/product/claude-cowork

• Claude Code: https://claude.ai/code

• Claude for Chrome: https://code.claude.com/docs/en/chrome

• Claude Desktop: https://claude.ai/download

• Live Artifacts: https://support.claude.com/en/articles/14729249-use-live-artifacts-in-claude-cowork

• Connectors (Spotify, Gmail, Calendar, Notion): https://claude.ai/settings/connectors

• Slack: https://slack.com/

Where to find Felix Rieseberg:

Website: https://felixrieseberg.com/

LinkedIn: https://www.linkedin.com/in/felixrieseberg/

X: https://x.com/felixrieseberg

GitHub: https://github.com/felixrieseberg

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Today is day one of Google I/O 2026, and I walk through every major announcement live—from the new Gemini 3.5 model family to Anti-Gravity 2.0, Google AI Studio, Gemini’s consumer redesign, the Omni video model, Flow, Stitch, and Pomelli. I test them in real time and tell you exactly which ones delivered.

What you’ll learn:

1. How Gemini 3.5 Flash benchmarks against Claude and GPT models on speed and agentic coding tasks

2. How Anti-Gravity 2.0’s new features (projects, scheduled tasks, subagents, slash commands) compare to Codex and Claude Code

3. Why the /grill-me slash command could be a more aggressive alternative to Claude Code’s clarification flow—and how to use it

4. How Google AI Studio’s new Workspace integration is designed to own the internal productivity app use case

5. How Google’s new creative tools work in practice: Omni (video generation), Flow (cinematic video editing and character consistency), Stitch (streaming UI design with inline edits), and Pomelli (brand identity and asset generation)

6. Why Google’s launch-to-availability gap is still a problem—and what to do when a featured product doesn’t actually work yet

Brought to you by:

Magic Patterns—Prototypes that look like your product

Thoughtspot—Build AI-powered analytics into your product

In this episode, we cover:

(00:00) Google I/O 2026 day 1 overview

(01:47) Gemini 3.5 flash

(04:19) Antigravity updates

(06:32) CLI test and agent features

(07:59) Core agent features released today—May 19th, 2026

(09:43) New slash commands

(11:20) Antigravity test results and takeaways

(12:25) AI Studio updates

(13:52) Access issues

(15:20) Gemini redesign

(17:24) Gemini image gen test

(19:16) Omni (video generation)

(22:56) Flow (cinematic editing)

(24:31) Avatar creation test

(26:45) Pomelli and Stitch

(31:13) Recap and final thoughts

Tools referenced:

• Gemini 3.5 Flash: https://deepmind.google/technologies/gemini/

• Antigravity: https://antigravity.google/

• Google AI Studio: https://aistudio.google.com/

• Google Gemini: https://gemini.google.com/

• Omni (video generation): https://gemini.google/overview/video-generation/

• Google Flow: https://flow.google/

• Stitch: https://stitch.withgoogle.com/

• Pomelli (Google brand tool): https://labs.google.com/pomelli/about/

Other references:

• Google I/O 2026 announcements: https://blog.google/innovation-and-ai/sundar-pichai-io-2026/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

HTML is the new Markdown: How Anthropic engineers are building with Claude Code | Thariq Shihipar

Brought to you by:

• Celigo—Intelligent automation built for AI

• Persona—Trusted identity verification for any use case

Thariq Shihipar is an engineer on Anthropic’s Claude Code team. In this episode (recorded live at Anthropic’s Code with Claude event), Thariq shows how he uses HTML artifacts to plan projects, create interactive specs, build throwaway micro-apps, and maintain living design systems that help humans stay in the loop as agents do more of the work. He also explains why engineers are becoming “compute allocators,” why most AI-generated tokens won’t end up in production, and how richer interfaces can lead to better products.

Biggest takeaways:

1. HTML has become the superior format for communicating with AI agents, replacing Markdown for planning and specs. While Markdown was popular because it’s both human- and machine-readable, HTML offers far richer expression—interactive elements, visual mockups, scrollable sections, and better information density. As Claude’s context windows have expanded and plans have grown to thousands of lines, HTML makes it actually possible to engage with the content rather than just skimming or ignoring it entirely.

2. Engineers are becoming “compute allocators” rather than code writers. When Claude can run for eight hours on a single task, you’re really deciding how to spend $500 of compute. The critical skill is no longer writing code; it’s deciding what’s worth building, defining the boundaries of what you need to know, and staying in sync with the agent throughout the process. This happens primarily in the spec and planning phase, making that work more important than ever.

3. You can build custom, throwaway UIs for editing specific parts of your plans. Thariq demonstrates this by taking a data visualization rules table from his implementation plan and asking Claude to create an ideal interface for editing just that section. The result is a beautiful, gamified UI that makes engaging with the content actually enjoyable. This “micro software on top of micro software” approach means you can have the perfect tool for every specific problem, then discard it when you’re done.

4. The future of agent output isn’t more text. It’s more readable interfaces. Thariq says he stopped reading thousand-line Markdown plans and started asking Claude to edit them instead, which made him less involved in the work. HTML changed that: by turning plans into visual, scrollable, interactive artifacts, Claude makes the output easier to engage with, critique, and improve. The lesson isn’t to read less. It’s to make the work legible enough that you actually want to read it.

5. Living design systems in HTML are more effective than traditional design tools. Instead of pointing Claude at a Figma file or GitHub repo, Thariq maintains an HTML file that represents his entire design system: colors, typography, spacing, components. This compressed understanding can be passed around to any project, and Claude can extract design systems from existing codebases and encode them in HTML. It’s both human-readable and machine-readable, with no tradeoff between the two.

6. The best prompts give Claude enough direction but leave room for creativity. Thariq’s prompts are remarkably simple: “Create an HTML file with a plan. Help me visualize. Include excerpts, mockups, code, whatever is needed to give me maximum context.” The key is the ending—“whatever is needed”—which signals trust and gives Claude permission to make decisions. Over-constraining with elaborate system prompts often produces worse results than simple, trusting instructions.

7. Only about 1% of the tokens Thariq generates go into production code. The vast majority go into dashboards, custom interfaces, weekly status updates, and tools for understanding what he wants to build. This is what abundance looks like—when tokens are cheap, you can afford to make everything you interact with beautiful and tailored to your specific needs. The hope is that this richness in the process translates into better final products.

8. Test verification is not the same as testing. This is a nuanced point that Thariq says deserves its own podcast episode, but the core idea is that traditional unit tests are being replaced by verification rubrics, managed agents checking outcomes, and Claude recording videos of what it did. The testing landscape is evolving rapidly, and teams need to think beyond conventional approaches.

9. Just-in-time documentation in whatever format works is better than centralized, templated systems. When creating content is nearly free and AI can find anything, the old anxieties about “source of truth” and standardized templates matter less. What matters is the quality of the ideas and whether the documentation helps you build better products. Thariq sends his manager weekly HTML status updates because they’re more likely to actually get read than Markdown or plain text.

10. Being nice to Claude probably produces better outputs, and it definitely creates a better world. While no one has run a rigorous A/B test, Thariq prefers to build the world where being kind to AI produces better results. When you’re stern with models, their reasoning gets sad (“the user is right to be disappointed in me”), and that’s not the interaction pattern anyone wants to normalize. Treat Claude like a colleague you respect, not a tool you command.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

Thariq Shihipar is an engineer at Anthropic working on the Claude Code team. He’s spent the past several months experimenting with HTML as a replacement for Markdown in planning and implementation workflows, discovering that richer visual formats lead to better human engagement—and, ultimately, better products. In this episode, filmed at Anthropic’s Code with Claude event in San Francisco, Thariq demonstrates how to use HTML artifacts to create interactive plans, build throwaway UIs for specific problems, and maintain living design systems that travel with your codebase.

What you’ll learn:

1. Why HTML has replaced Markdown as the ideal format for AI agent communication and planning

2. How to brainstorm in HTML to get visual mockups and interactive demos instead of text lists

3. The technique for building throwaway micro-UIs to edit specific parts of your plan

4. How to create a living design system in HTML that lives in your repo and travels with every project

5. Why “complexity has to earn its keep” and how HTML helps you stay in the loop without over-constraining Claude

6. The prompting technique that gives Claude flexibility while ensuring that you get what you need

7. Why 99% of your AI-generated tokens should go to planning, interfaces, and communication—not production code

Brought to you by:

Celigo—Intelligent automation built for AI

Persona—Trusted identity verification for any use case

In this episode, we cover:

(00:00) Introduction

(02:39) HTML as the new Markdown

(04:30) The compute allocator mindset

(05:51) How HTML makes specs more engaging

(06:48) Demo: Brainstorming in HTML with Claude Code

(09:24) From brainstorm to full implementation plan

(11:20) Prompting philosophy: Trust Claude but give it constraints

(13:50) The future of PRDs and tech specs

(18:16) Making HTML specs editable

(20:23) The abundance mindset

(24:17) Just-in-time documentation and throwaway software

(25:39) Using plans as artifacts for implementation

(26:39) Demo: Living design systems in HTML

(30:16) Adding comments and annotations to HTML plans

(31:42) Recap: The HTML workflow

(32:21) Lightning round and final thoughts

Tools referenced:

• Claude Code: https://claude.ai/code

• Claude Design: https://claude.ai/design

• AWS: https://aws.amazon.com/

• Figma: https://www.figma.com/

• GitHub: https://github.com/

Other references:

• Anthropic Code with Claude event: https://claude.com/code-with-claude

• SpaceX partnership announcement: https://www.anthropic.com/news/higher-limits-spacex

• Jevons paradox: https://en.wikipedia.org/wiki/Jevons_paradox

Where to find Thariq Shihipar:

Website: https://www.thariq.io/

LinkedIn: https://www.linkedin.com/in/thariqshihipar/

X: https://x.com/trq212

GitHub: https://github.com/ThariqS

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Quests, token leaderboards, and a skills marketplace: The elite AI adoption playbook | John Kim (Sendbird)

Brought to you by:

• WorkOS—Make your app enterprise-ready today

• ThoughtSpot—Build AI-powered analytics into your product

John Kim is the co-founder and CEO of Sendbird. In this episode, John shares how his marketing team built a live swag store with Stripe integration without engineering support, why he tracks every token spent across the org, how he identifies “AI Gods” inside the company, and why the future of work belongs to people with curiosity, agency, and energy, not just years of experience.

Biggest takeaways:

1. The most successful AI transformations treat internal tooling as a product, not a program. John built the “Automators” platform—a gamified internal marketplace where anyone can create a “quest” (a request for automation or tooling), and engineers or AI agents can pick it up and build it. Each quest shows the risk level, weeks saved, and who benefits. People earn experience points for completing quests, which they can exchange for gift cards, tea with executives, or the chance to present their work to the entire company at Wednesday standups. This isn’t a top-down mandate but a product that makes AI adoption fun, measurable, and rewarding.

2. When you give creative teams builder capabilities, they’ll create things that would never make it onto a traditional product roadmap. John’s marketing team built a fully functional e-commerce swag store with Stripe integration, custom designs, and even a Konami Code Easter egg that unlocks secret conference details. In the old world, this would have required two sprints of engineering time and probably would have been deprioritized. Now it shipped in days, delights customers, and generates actual revenue.

3. The biggest unlock for non-technical builders is creating secure, compliant templates they can build on top of. John’s team created app templates where authentication, environment setup, databases, and security are pre-configured and vetted by InfoSec. Marketers, salespeople, and CSMs just extract the template and build their idea on top. This removes the biggest barrier to non-engineers shipping to production: the fear of doing something wrong or insecure.

4. Measure token usage without shame, and create tiers that make it aspirational. John created five tiers: Beginner (under 1M tokens/day), Intermediate, Expert, Architect, Catalyst, and AI God (over 100M tokens/day). Every manager can see where their team members are and tailor enablement accordingly. This isn’t about performance reviews; it’s about bringing people along the journey and making AI fluency visible and celebrated.

5. The goal isn’t just to use AI during work hours but, rather, to smooth the curve so AI works around the clock. John monitors token usage over time and looks for smoothness in the curve. Dips mean people are on weekends or vacation and AI isn’t working. When the curve smooths out, it means AI partners are working 24/7. This is a fundamentally different vision: not just augmenting human work, but having AI fill the gaps when humans aren’t available.

6. Build a cross-functional AI task force that meets weekly to unblock challenges. John created a role called AI Engineer for Internal Operations that reports directly to him and the chief of staff. This person works cross-functionally with the CTO, engineering, and InfoSec to vet tools, set up compliant tech stacks, and remove barriers. They meet weekly as a task force to discuss what’s blocking people and how to enable faster iteration.

7. The most important hiring criteria for AI-first companies are curiosity, agency, and energy—not tenure or experience. John rewrote job descriptions to optimize for people who are curious, willing to go deep, and figure things out on their own. He lowered the bar on years of experience and raised the bar on learning ability. In a world where you can build a custom learning center for any topic in 20 minutes, the constraint isn’t access to knowledge; it’s the drive to learn.

8. Start with your champions, not your skeptics. John’s advice to CEOs struggling with AI adoption: find the people in your organization who are already curious and have agency. Make them the champions. Give them the spotlight. Let them share their work at all-hands meetings. Build energy around their stories. Innovation doesn’t start from theoretical structures—it starts with people who have energy and a story to tell. Once others see what’s possible, adoption spreads organically.

9. Leadership has to model the behavior, not just mandate it. The top token consumers at Delight.ai are the executives. When leaders show up with new capabilities and ship things faster, it signals to the team that this is real and important. John also does one-on-ones with people who aren’t using tokens: “We noticed you haven’t been spending any tokens. Can we help you? What’s stopping you?” This combination of top-down modeling and bottom-up support is what drives transformation.

Spec-driven development: The AI engineering workflow at Notion | Ryan Nystrom

Brought to you by:

• WorkOS—Make your app enterprise-ready today

• Orkes—The enterprise platform for reliable applications and agentic workflows

Ryan Nystrom is a software engineer and engineering manager at Notion, where he works on Notion AI, Custom Agents, and internal systems that help engineers move faster with less busywork. He joined Notion after the company acquired Campsite, the team communication platform he co-founded. In this episode, Ryan shares how his team automates standup prep, ships PRs from a single Notion comment, uses specs as the new source of truth, and why fast CI is becoming essential for AI coding agents. He explains why engineering managers should still write code, how AI is changing meetings, and why great developer experience matters more than ever.

Biggest takeaways:

1. Never prep for standups again by auto-generating meeting notes from all your workstreams. Ryan’s Notion AI agent pulls from Slack conversations, closed tasks, merged PRs, telemetry metrics, and yesterday’s meeting transcript to create a comprehensive pre-read every morning at 9 a.m. This transforms standups from rote status updates into high-bandwidth problem-solving sessions where the team spends 100% of their time on decisions, blockers, and next steps instead of “I did this thing yesterday.”

2. Fast CI is the mathematical limit on your AI coding velocity. If your CI takes an hour to run, your agents sit idle for an hour waiting for test results. If it takes three minutes, you can run 20x more iterations in the same time frame. Ryan’s team is aggressively cutting Notion’s CI to 25% of current time specifically to unlock agent productivity—because agents don’t get tired, don’t sleep, and can work in parallel across VMs if your infrastructure supports it.

3. Background agents that ship PRs from Slack mentions eliminate context switching. Ryan’s “Boxy” system lets him @mention Codex from a Notion task, and 20 minutes later he gets back a PR with implementation, screenshots of UI verification, and a preview URL. This morning a friend texted him a feature request; Ryan wrote four sentences and dropped a screenshot in a Notion task, mentioned Codex, and had a shipped PR before lunch. No IDE, no local environment, no context switch.

4. Specs as source of truth beats code as source of truth for AI-powered development. Notion engineers now maintain Markdown spec files in their repo that describe features in plain English with code pointers and verification steps. When they need to update a feature, they update the spec and point Codex at it—the agent implements everything, runs verification, and ships. The spec’s version history becomes the changelog, and non-technical stakeholders can actually read it.

5. “Yap your spec” is a legitimate development workflow now. Ryan opens Whisper, talks through how a feature should work, gives that transcript to Codex with examples of other specs, and gets back a comprehensive technical document. This is faster than writing and more thorough than typing because you naturally explain edge cases and context when speaking that you’d skip when writing bullet points.

6. Make AI defend its technical decisions. When Codex suggests a change Ryan doesn’t understand, he doesn’t ask, “Are you sure?” He says, “You’re wrong; defend your argument with evidence.” This forces the model to provide cited reasoning instead of just agreeing with whatever the human says. This is especially critical when working on infrastructure you don’t fully understand—you need the AI to teach you, not just comply.

7. The era of the hard skill means engineering leaders should write code again. Ryan manages six people and writes code daily. He works until the minute standup starts without prep because AI handles meeting notes. He ships features from his phone on the subway. The AI tools have eliminated so much meeting prep and information synthesis work that managers can be hands-on again—and in Ryan’s opinion, line managers should be writing code, fixing bugs, and staying close to the work.

8. Changing your tools constantly is energizing, not exhausting, when you’re learning. Ryan changed IDEs, terminals, and workflows more than 10 times in the past year. Instead of feeling chaotic, it feels fresh and joyful. He’s working faster and harder than ever, but in a good way—because he’s experimenting, learning, and building instead of maintaining the same workflow he’s used for over 12 years. The pace of change is the point.

9. Good developer experience for humans creates good developer experience for agents. Ryan’s team built comprehensive CLI tools, clear documentation, and fast CI long before AI agents. Now those same investments make agents more successful—they can verify their own work, follow blessed paths, and iterate quickly. This creates a virtuous cycle: DX investments help agents, and agent infrastructure (like cloud dev environments) helps humans too.

Claude Code just got WAY more powerful

Claire breaks down the biggest announcements from Anthropic’s “Code with Claude” event and what they actually mean for builders shipping AI products today.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

Ryan Nystrom is a software engineer at Notion. He joined in December 2024 after Notion acquired Campsite, the team communication platform he co-founded with Brian Lovin. At Notion, he’s been a core builder of Notion AI and the Custom Agents feature launched in February 2026. He manages a team of six to seven engineers while still writing code himself, currently running Project Afterburner, a push to cut Notion’s CI time to a quarter of its current duration.

What you’ll learn:

1. How to build a Notion AI custom agent that auto-generates your daily standup pre-read by pulling from Slack, GitHub, Honeycomb metrics, and yesterday’s meeting transcript

2. How to configure subagents and MCP integrations within Notion AI

3. How Notion’s internal “Boxy” system lets engineers @mention Codex from within Notion comments and get a full pull request with screenshots in 20 minutes

4. The spec-first development workflow: dictate an idea into Whisper, have Codex format it as a proper spec, commit it to the repo, and let the agent implement and verify it autonomously

5. Why fast CI is absolutely critical in the age of AI coding agents

6. How to prompt AI coding agents to defend their reasoning under pushback

7. Why engineering managers and even senior executives should keep writing code

Brought to you by:

WorkOS—Make your app enterprise-ready today

Orkes—The enterprise platform for reliable applications and agentic workflows

In this episode, we cover:

(00:00) Introduction to Ryan Nystrom

(02:48) How AI has upended 12+ years of the same working routine

(04:30) Project Afterburner: Notion’s push to cut CI time to a quarter

(09:00) Why high-frequency, high-quality meetings beat lower-frequency standups

(11:10) How automated context surfaces every engineer’s work equally

(12:15) Why cutting meeting prep is a burnout protection mechanism

(14:26) The case for engineering managers writing code

(16:13) Inside “Boxy”: Notion’s internal VM-based background agent system

(20:30) Old World vs. New World code review

(24:51) Prompting Codex from Notion comments

(29:20) The emotions around code review

(31:01) Quick recap

(32:00) Spec-first development: writing and checking agent specs into the repo

(35:10) The spec as changelog: version control for how a feature actually works

(37:53) How engineers’ roles are evolving

(39:00) Lightning round

(45:21) Where to find Ryan

Tools referenced:

• Notion AI: https://www.notion.com/product/ai

• Notion Custom Agents: https://www.notion.com/blog/introducing-custom-agents

• Codex (OpenAI): https://openai.com/codex

• Claude Code (Anthropic): https://claude.ai/code

• Honeycomb (observability + MCP): https://www.honeycomb.io

• Whisper (OpenAI voice transcription): https://openai.com/research/whisper

• Slack: https://slack.com

• GitHub: https://github.com

Other references:

• How Stripe built “minions”—AI coding agents that ship 1,300 PRs weekly from Slack reactions | Steve Kaliski (Stripe): https://www.chatprd.ai/how-i-ai/stripes-ai-minions-ship-1300-prs-weekly-from-a-slack-emoji

• Notion 3.3 Custom Agents launch (February 24, 2026): https://www.notion.com/releases/2026-02-24

Where to find Ryan Nystrom:

X: https://x.com/ryannystrom

LinkedIn: https://www.linkedin.com/in/ryannystrom/

GitHub: https://github.com/rnystrom

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

What you’ll learn:

1. How Claude Code routines let you automate recurring workflows on schedules or webhooks

2. What “Outcomes” are and how rubric-based agent grading works

3. How multi-agent orchestration enables specialized AI teams with different roles and tools

4. Why Anthropic’s new “Dreams” memory system matters for long-term agent behavior

5. Why increased Claude Code usage limits are a bigger deal than they sound

6. How Claire thinks about building practical agentic products today

Resources:

• Code with Claude: https://claude.com/code-with-claude

• Claude Code Routines Docs: https://code.claude.com/docs/en/routines

• Define Outcomes Docs: https://platform.claude.com/docs/en/managed-agents/define-outcomes

• Dreams Docs: https://platform.claude.com/docs/en/managed-agents/dreams

• Multi-Agent Docs: https://platform.claude.com/docs/en/managed-agents/multi-agent

• Managed Agent Webhooks Docs: https://platform.claude.com/docs/en/managed-agents/webhooks#supported-event-types

• Codex (OpenAI): https://openai.com/codex

• GitHub: https://github.com

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

John Kim is the co-founder and CEO of Delight.ai, a customer experience platform that’s transforming how companies deploy AI. But what makes John’s story fascinating isn’t just his product; it’s how he’s turned his entire company into an AI-native organization. His marketing team built a fully functional e-commerce swag store with Stripe integration in days. His sales team built their own CRM tools. His recruiting team automated their entire workflow. And it’s all tracked, measured, and celebrated through an internal platform called Automators.

What you’ll learn:

1. How Sendbird’s marketing team built a fully functional swag store with Stripe integration in a day (with no engineering support)

2. How the Automators platform works—an internal marketplace where anyone can request AI tools and engineers (or AI agents) can build them

3. How to create secure, compliant templates so non-technical teams can ship to production safely

4. How Sendbird built a token usage dashboard with five tiers (beginner through AI God) and why tracking the smoothness of the curve matters more than the total

5. Why visible leadership usage is the most powerful adoption signal

6. Why Sendbird rewrote job descriptions to prioritize curiosity, agency, and energy over years of experience

7. How John uses AI for his own learning

Brought to you by:

WorkOS—Make your app enterprise-ready today

ThoughtSpot—Build AI-powered analytics into your product

In this episode, we cover:

(00:00) Introduction to John Kim

(02:45) The Delight.ai swag store built by marketing in two days

(05:51) The before times: when fun had to earn its place on the roadmap

(07:55) Demo: The Automators platform and quest system

(13:47) The AI Engineer for Internal Operations role

(16:06) Demo: The company-wide skills marketplace

(17:19) Treating AI adoption as a product

(18:43) Real wins: team-level and campaign examples

(21:51) Why SaaS isn’t dead—it’s being rebuilt internally

(23:46) Demo: The token tracking dashboard

(26:32) Measuring without fear: setting expectations, not punishments

(28:54) Quick recap

(30:51) Personal AI use cases: endless knowledge at your fingertips

(36:15) Lightning round and final thoughts

Tools referenced:

• Claude Code: https://claude.ai/code

• Codex (OpenAI): https://openai.com/codex

• Obsidian: https://obsidian.md

• GitHub: https://github.com

• Stripe: https://stripe.com

Other references:

• Jason Levin (CEO of Memelord) on How I AI: https://www.lennysnewsletter.com/p/from-a-690-newsletter-to-3m-api-how

• Konami Code: https://en.wikipedia.org/wiki/Konami_Code

• Andrew Huberman’s podcast: https://hubermanlab.com/

• Y Combinator: https://www.ycombinator.com/

Where to find John Kim:

X: https://x.com/doshkim

Instagram: https://instagram.com/dosh

LinkedIn: https://www.linkedin.com/in/doshkim/

Company: https://delight.ai

Delight.ai Spark Conference (May 7, SF): https://delight.ai/spark

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

Demos not memos: How Stripe built their internal AI prototyping tool | Owen Williams

Brought to you by:

• Celigo—Intelligent automation built for AI

• Cursor—The best way to code with AI

Owen Williams is a design manager at Stripe who built Protodash, an internal AI prototyping tool that lets designers and PMs turn Stripe’s design system into clickable, production-quality prototypes in minutes. What started as a set of Cursor rules and React components has evolved into a full prototyping platform that runs in the browser, supports design reviews, and helps teams move from “memos” to working demos. In this episode, Owen shares how Protodash came together, why generic AI design tools often produce “blurple slop,” how PMs became the surprise power users, and what changes when teams can explore real product ideas before writing production code.

Biggest takeaways:

1. Protodash started as a bundle of Cursor rules, React components, and MCP integration—then evolved into a full web-based prototyping platform. The first version was pragmatic: lower the barrier to entry so designers only need to know “npm run dev” and nothing else. Owen bundled Stripe’s design system components, created an MCP server for Sail, and wrote extensive Cursor rules that taught the AI how to use the project. If a user pastes a Figma link, check the Sail MCP server before writing code. If the MCP server is unavailable, don’t just imagine the design system. These rules came from months of iteration and pain points.

2. The biggest mindset shift for designers is not being afraid of the terminal anymore. Owen’s background is engineering-based, and he always valued hiring technical designers who understood enough of the terminal to be dangerous. Pre-AI, that jump to technical competency was really hard. Now you can just ask Claude, “How does Git work?” and it tells you. You don’t even need to know the commands.

3. Generic AI prototyping tools don’t know your design system, and that creates “blurple slop.” Owen was sitting in design reviews watching designers struggle with tools like v0 that produced uncanny-valley Tailwind prototypes. The nav would be off, fonts wrong, components mismatched. Stripe has a high quality bar and a well-defined design system called Sail, so Owen thought: these tools should know about our design system and construct dashboards from those building blocks reliably. That insight led to Protodash.

4. An equal number of PMs and designers now use Protodash, and that’s actually making designer-PM relationships better. Owen’s first reaction when PMs started using it was nervousness—“Oh my goodness, PMs designing.” But it’s been thrilling to see PMs build things that look like Stripe in the right way, explore ideas earlier, and communicate better with their designers. Conversations shift from “Should we staff a designer on this project?” to “Here’s the actual work; let’s discuss how to make it better.” PMs can now unblock themselves, test ideas with users earlier, and advocate for design resources with real prototypes instead of abstract arguments.

5. Prototyping with data in code lets you push the edges of use cases in ways Figma never could. Owen showed a dashboard with almost half a million dollars in gross volume—but what about the zero state? What about a company getting one transaction a day? What about different business models: startup versus enterprise? Before, getting all those states into a Figma file was a mess. Now you can just toggle between them. You can design more-interesting things and have them touch reality sooner.

6. The most valuable internal tools are the ones that match your company’s specific culture and workflows. Owen points out that staffing internal-tools teams has always been hard, but now you can just build tools that evolve the way you work. Design reviews at Stripe have a tradition of sharing Google Docs with tables for feedback—so Owen built a design review mode where everyone can comment on the prototype, get an AI-generated summary, and send fixes directly to the AI.

7. Owen’s rules for working with AI: be specific up front, and as soon as you feel like swearing, slash clear and start again. He has a content background and learned that being specific in the first prompt helps a lot. But the bigger lesson is avoiding sunk-cost fallacy. As someone who’s built a bunch of stuff, you get attached and think “surely I’ll get this to work.” Often just throwing it away and starting fresh is faster. If being loud didn’t work the first time, reset the context window.