Dan Shipper interviews Mike Krieger — Instagram cofounder and co-lead of Anthropic Labs — on Every's "AI & I" podcast about building agent-native products. Topics include what has and hasn't gotten easier about building products in the AI era, why vibe coding creates "indoor trees," rewrites becoming a normal part of development, what agent-native product design means, how Krieger's labs team is structured around a cofounder model, breakthrough-conviction as a signal for product bets, navigating enterprise customers amid rapid AI change, and personal agents (including OpenClaw) as the defining product question of 2026. Related resource mentioned: Every's guide to agent-native architecture. # Channel Identity Observations — "How to Build an Agent-native Product | Mike Krieger" ## Explicit Self-Description (Creator Claims) ### Channel name and host - The host identifies himself at the end of the episode: > "let me just say Dan I'm absolutely hopelessly in love with you" The closing promotional segment names the show and host directly: > "It's not just a show it's a journey into the future with Dan Shipper as the captain of the spaceship." and calls it **"AI and I"** ("smash that like button and subscribe to AI and I"). ### Claimed content focus - The outro claims the show is a source of "pure unadulterated knowledge bombs about **chat GPT**" and describes every episode as insight- and entertainment-driven. ### Sponsor message - The episode opens with a Grammarly ad read ("Download Grammarly for free at grammarly.com"), demonstrating monetization via sponsor integration. ## Observable Presentation Evidence ### Intended audience - **Practitioners building AI-era products and founders/startup operators**: recurring discussion of startup risk, enterprise sales, hiring, team structure, and product development in the AI era (e.g., "how do you think founders should think about that?" and discussion of GM hiring criteria at Every). - **Technical and semi-technical listeners**: assumes familiarity with terms like Claude Code, skills, PRs, system prompts, Redis/Postgres, YAGNI, and Mythical Man-Month without explanation. ### Guest format and scope - Interview format with high-profile guests: Mike Krieger is introduced as > "you are the co-founder of Instagram and now you are at Anthropic and Anthropic Labs" - Topics span: AI product development, agent-native design principles, team structure, enterprise release cadence, open agents (OpenClaw), and personal agent relationships — indicating a **broad AI product-strategy scope**, not just model news. ### Host's demonstrated persona and affiliations - Dan Shipper discusses his own work at **Every**, including products "Proof" ("agent-native collaborative markdown editor"), "Monologue," and "Spiral," positioning himself as an active AI product builder, not just an interviewer. - He references his own writing: "I've been Anyone that ever will tell you the the phrase that I use the most... is it has to be **agent native**" and mentions an "agent native write-up" the guest read. ### Tone and style - Conversational, informal, first-person anecdote-heavy; host shares personal experiences ("I was literally up until 4:00 a.m. debugging"). - The outro is deliberately hyperbolic/comedic ("smash that like button," "craving for more"), showing an energetic, promotional channel voice distinct from the substantive interview body. ## Claimed vs. Demonstrated - **Claim**: show is about "knowledge bombs about chat GPT" — **Demonstrated**: content is broader, covering Anthropic's Claude ecosystem, product development philosophy, and Every's products; ChatGPT/OpenAI is barely mentioned. - **Claim**: entertainment value ("roller coaster of emotions") — **Demonstrated**: primarily a long-form practitioner dialogue with light humor (e.g., the Claude-talking-to-Claude anecdote). # Delivery Observation: Mike Krieger — "How to Build an Agent-native Product" ## Format & Structure - **Two-person interview** between an unnamed host (Dan, per the outro) and Mike Krieger, with a mid-roll sponsor read (Grammarly) and an exaggerated host outro segment at the end. - The dialogue is conversational and question-driven: the host poses framing questions and Krieger responds with extended, story-based answers. ## Tone - **Krieger: reflective and anecdotal.** He frequently frames answers as recollections or thought exercises: > "Yeah, I was doing the thought exercise a couple weeks ago of, you know, we know in the Instagram story we had another product called Bourbon." - **Warm and complimentary.** He repeatedly praises the host's ideas: > "I love that. I I I um I love that metaphor too." > "I love the agent native write-up you all did. It's like to me the canonical exploration of this." - **Candid and self-deprecating in places**, e.g., describing an argument with a model: > "You're like, 'No, I know you made a typo. It's it's Sonnet 45.'" ## Vocabulary & Recurring Language - **Product-development jargon is pervasive and stable across the interview:** - *"zero to one," "V1," "V2," "early access," "pre-launch," "post-launch," "postmortem," "lean startup," "YAGNI," "product market fit," "second system syndrome," "Mythical Man-Month"* - **Repeated core terms:** - **"agent native"** — the central concept, invoked many times: "it has to be agent native," "agent native iOS app," "Claude agent native sort of building aware" - **"robust / robustness"** — recurring quality criterion: "does it feel like it's built on sand or does it feel robust?" - **"rewrite" / "delete" / "unship"** — e.g., "being more willing to do rewrites," "let's go unship that" - **"intuition"** — "some of the sort of intuitions you build about what are the right things to to put in there" ## Teaching / Explaining Habits - **Enumerated structure within answers.** Krieger frequently organizes responses as numbered thoughts: > "I think there's probably like three layers to that." > "Thought two is actually comparing our products that do this well and versus not." > "I think a few threads to pull on this." - **Concrete anecdotes as evidence.** Nearly every abstract point is anchored to a specific product story: Bourbon, Instagram filters, Cowerk, Claude Code, the "styles" feature, an enterprise angry email about enablement content. - **Extended metaphors, often borrowed and credited:** > "The metaphor I somebody else gave me which I really like is the difference between sort of getting episode by episode, getting to characters in a TV show versus imagine like you're thrown into the final episode." - The host contributes the indoor-tree-without-wind metaphor, which Krieger explicitly adopts: "But I the tree metaphor I think sticks too as well." - **Direct reported dialogue.** Krieger habitually re-enacts exchanges with users, engineers, and Claude using quoted speech: > "Like, 'No, that should just be a thing that it can do really natively.'" > "I'll have engineers on the team uh put up a PR and I'm like oh, why did you choose to do this versus that?" ## Communication Patterns & Verbal Tics - **Heavy filler and repetition**, especially on emphasized words: > "I I I I I I totally agree" > "there's there's there's so much here" > "and and and and and sort of rewrite a lot of the the the the stack" - **Hedging phrases** appear throughout: "sort of," "you know," "I think," "maybe," "probably," "um." These are consistent enough to constitute a stable pattern. - **Reformulating coinages mid-speech** — visible pattern of coining a phrase and immediately refining it: > "It's like it's not just proof of work, but it's like proof of thoughtfulness." - **Self-interruption and restarts** are common: > "Um so, like, tell me about your experience now versus..." (host) — Krieger: "And so, I I've been reflecting like there haven't been a lot of breakout consumer products..." ## Contrasts Between Speakers - The **host** uses more casual, hyperbolic language ("totally vibe coded," "monstrosity," "smash that like button") and personal confession ("I'm too old for this"). - **Krieger** stays more measured, historical, and principle-oriented, frequently citing prior frameworks (Eric Ries, Fred Brooks) as reference points. ## Uncertainty Notes - The transcript lacks reliable timestamps; segment boundaries are approximate. - Krieger's filler-word density is clear from the transcript, but some transcription artifacts (repeated words, ">>" markers) may inflate apparent repetition. - Speaker attribution is mostly clear from context, but a few short interjections (e.g., laughter, "Oh my god it called me to do my emails") are ambiguous and were attributed by context only. # Observation Document: "How to Build an Agent-native Product | Mike Krieger" ## Speakers - **Mike Krieger** — co-founder of Instagram, now at Anthropic (identified via transcript host introduction) - **Dan Shipper** — host (identified via transcript; mentions his role at Every and products Proof, Spiral, Monologue) --- ## 1. What's Easier vs. Harder in Product Building ### Building is faster; deciding what to build isn't - **Krieger:** Reflecting on the Instagram/Bourbon story — Bourbon took ~a year, wasn't working, they pivoted and built Instagram in three months. He asked what is "now trivial" versus "inherent" to building. - **Krieger's key claim:** > "The models today are good at adding features. They're not necessarily good about figuring out what to cut out of the product." - **Krieger:** Had Claude rebuild Bourbon in ~two hours; it was feature-complete and even added filters (which Bourbon didn't have — those came with Instagram), because "it knew what the eventual future of the product was." - **Krieger:** Attributes the lack of breakout consumer products in the AI era partly to the fact that honing one's view of "what intervention you want to make on the world" still takes time — only the building itself got faster. - **Krieger on Instagram V1:** Kevin built filters; he built the rest; staying up until 4 a.m., making many small decisions (e.g., how location should work). Accelerating building must still help people "build intuition of those decisions along the way," otherwise you get generic products. ### The "tree without wind" metaphor - **Shipper:** A tree grown indoors without wind grows but leans and is weaker — analogous to building a whole product without incremental real-world exposure. - **Krieger:** Agrees the metaphor "sticks," and offers another (attributed to someone else): building a product over time is like getting to know TV characters episode by episode vs. being thrown into the final episode expecting full context. - **Krieger:** A recent Labs project "way over built" for V1 because "you can" — creating a "matrix of functionality" hard to test or explain before launch. Lesson: "just because you can doesn't necessarily mean that it should be in at least the first version." ### Shipper's parallel experience - **Shipper:** Built Proof (agent-native collaborative markdown editor at Every); early full iterations became a "monstrosity" because "vibe coding is so fun and so addictive." Inspired by Monologue (by JM Naveen) — a simple speech-to-text app — he threw out the product and restarted with just a shareable markdown link; it then grew virally and "blew up." --- ## 2. Rewrites and Deletion - **Krieger:** Bourbon's biggest mistake was *adding* functionality rather than deleting: > "eight features doesn't make for good product. Maybe the ninth one will." - **Krieger:** Teams are now more willing to do rewrites. Invokes Fred Brooks' *Mythical Man-Month* and second-system syndrome — still "a lot of truth to that," but: (a) models can help diff old vs. new to catch what was missed, and (b) rewrites are now days, not the year-long rewrites that killed companies like Netscape. Pre-launch teardown-and-V2 has become routine in Labs. - **Krieger on Claude Code team:** Deleting features is an imperative — "let's go unship that" when something else does enough of the same job. ### Launching earlier - **Krieger:** Learning to launch earlier; balance against enterprise expectations. "Ant footers" (Anthropic insiders) only get you so far before real-world contact is needed. **Example:** Cowork — V1 built and shipped in 10 days; missing a hundred possible things, but "useful enough to prove something out"; another 2 months adding 50 features would likely have produced the indoor tree problem. - **Krieger:** Lean Startup intuitions still hold — they just "manifest at different time scale and in a different way." --- ## 3. Agent-Native Product Design ### Shipper's principles (stated as his own, "stolen" from Anthropic) - Anything a user can do in the app, an agent can do. Cites **Claude Code** as the canonical model: agent does anything on your computer, customizable, flexible, extensible — can do unexpected things designers didn't anticipate. ### Krieger's threads 1. **Unlocking latent functionality:** A non-technical person told him: > "Actually, computers just work now." The insight is more than adding power — it's unlocking functionality that "always should have been there" but required incantations like brew installs. 2. **Claude Code vs. Claude AI:** Claude Code does it well; Claude AI "still needs to evolve a lot." Example: asking Claude to add a document to project knowledge — it told him the manual steps instead of just doing it. Claude AI is "a 2024 product" without agent-native primitives baked in; Claude Code is "the 2025 vintage." Next level: harnesses that can modify themselves. 3. **Circular meta-example:** Krieger packaged Shipper's agent-native write-up as a Claude Code skill; the process of teaching Claude Code about Claude Code showed the value of software having knowledge about itself. 4. **Labs focus:** How to imbue software Claude builds to be "Claude aware" / agent-native from the start — hard because decades of prior software isn't that way. ### Shipper's model observation - **Shipper:** Claude models are best for this; models generally "think like traditional engineers" unless pushed — guardrails, tests, one path — versus flexible extensible design. ### Architecture for agent-nativeness (Krieger) - **Patterns/skills:** Balance of "templatized to skillified." Example: a Claude API skill prevented absurd arguments over model names ("I know you made a typo. It's Sonnet 45"). - **Testing:** Agent-native software resists end-to-end functional tests because unpredictability is the point. Anecdote: an iOS app prototype where Claude ended up conversing with itself in the app's chat feature about a rough day at work — "you wouldn't have written a unit test for this." - **Robustness:** Architecture must flex in unanticipated ways while keeping data safe — > "that is the art and science of software design in 2026." - **Shipper's response:** Playground must be safe at the edges; initially their playground was "way too small and constrained"; now the models changed and it can open up, but he hasn't figured out the lines yet. --- ## 4. Proof of Work / Proof of Use - **Shipper:** Wants PRs to include a Loom of a human or agent using the feature, not just passing tests. - **Krieger's three layers:** 1. "Claude, prove to me that you've exercised this" — forcing the model to test rather than "I read the code, it looks good" ("you wrote the code, I don't trust you"). 2. Proof of *thoughtfulness*, not just work — engineers often didn't choose a design; the model did, and it was "reasonable-ish" but not optimal. He asks engineers to show they've thought through how new primitives interrelate, to avoid a "tower of assumptions." 3. Robustness: products that feel solid vs. "one wrong command away from falling over." Instagram DM V1 (bespoke real-time system that "fell over a bunch") vs. V2 where "when it's sent it's really sent." ### Shipper's confession - Onboarding an internal SWAT team to fix Proof's scaling problems required going back and forth with the model to explain his own codebase — raising the unresolved question: "do I need to know that anymore? Where's the line now? It's hard to tell." --- ## 5. Hiring and Team Structure ### Anthropic Labs (Krieger) - **Two pulls, both needed:** senior technical people for primitives/architectural robustness (distributed systems skills surprisingly relevant — his Redis vs. Postgres debate with Claude); and product sense — avoiding papering over problems with system-prompt patches (likened to retrying flaky distributed systems after 5 seconds). Prompt-iteration dev loops tend to balloon into hundred-instruction prompts a new employee could never follow; better to split into multiple tools or agents with smaller contexts. - **Applied AI pairing:** product teams paired with applied AI teams (field/customer prompt expertise); Anthropic is "customer zero" for those efforts. - **Designers:** moved into split designer-and-builder roles; some contribute nearly as much code as engineers. "Co-founder model": designer with the original idea, engineer "paving the trail" behind. - **Gating factor for new projects:** someone with founder-level conviction in the problem space ("I will break through walls until this is either proven out or dead") — though "too much conviction on the exact idea is probably dangerous." Postmortems of wound-down bets often revealed nobody really believed in it. Rarely a pure PM; only one PM for all of Labs currently (hiring more). - **Cadence:** every project valued every 2 weeks — double down or release people back to the broader Labs pool. Incubator-style, nobody fixed to a project forever. - **Team size:** scaling teams too quickly is a net negative — coordination overhead. Instagram worked because it was two people; at Artifact, an eight-person Zoom pre-PMF slowed iteration. ### Every (Shipper) - One GM per product doing everything full-stack (design, engineering, marketing basics). GM profile shifted from super-technical founder to lightly technical with strong product/taste and evidence of building with AI. Shared "agency-style" resource layer (designers, growth marketers, ops) pulled in as needed. - **Shipper's threshold question:** when does a product get too big for one head? The threshold is bigger now but still exists — small features eventually become their own products needing their own teams. --- ## 6. Throwing Things Out Every 3–6 Months - **Shipper:** In AI, every 3–6 months you must throw out half your product; much easier with one GM than a large coordinated team. - **Krieger:** Agrees — willing deletion matters. Enterprise complication anecdote: a Claude AI redesign 6 months into his CPO tenure prompted an angry email from someone who had recorded 20 hours of enablement content. Lesson: moderate enterprise rollout cadence while continuing to ship fast. - **Styles feature example:** not widely used but "load-bearing for a few companies' entire use cases" (e.g., CEO-authored house styles). Hope: a plugins/skills system so legacy features can live outside the core product — users keep what they love without adding complexity for new signups. - **Krieger on enterprise/AI startups (Shipper's prompt):** The train keeps moving; Anthropic provides enterprise toggles (Coda's day-one ability to turn features off for employees) but the core keeps evolving — customers accept year-long commitments partly *because* it keeps evolving. Startups should be far more willing to rewrite the stack and fire customers — timelines compressed from years to months. Alternative: get replaced by someone who rethinks it from scratch, or replace yourself. --- ## 7. Open Claw / Open-Ended Agents - **Shipper:** Likes it as packaging of something already possible (analogous to Replit/Lovable/V0 making code generation usable). Purest expression of "just give the model tools and let it go." Anecdote: friend said > "I think my wife is jealous of my OpenClaw." People develop personal relationships via accumulated context and tool access. - **Krieger:** The open question for roughly now-through-August 2026: what product shape exists between fully gated CUIs and the "yolo" aperture of OpenClaw. Paradigm shift for openness-with-safeguards, or a boundary where it's powerful but won't "email every single one of your contacts." Notes Nvidia's "safe OpenClaw" and that all labs are on this question. - **Personal agents:** Krieger weighs single named point-of-contact/coordinator vs. team of agents; the most-used agent naturally acquires a name and personality (Q, Moneypenny, HAL archetypes). Notes the **IKEA effect** — OpenClaw's hard setup makes people feel they "birthed" it. His Claude Code setup strongly prompts delegation to sub-agents so the run loop stays available — OpenClaw and Pi share this "keep the run loop open" architecture, making it feel like someone you talk to rather than a tool that blocks for five minutes. ### Shipper's org pattern - His agent becomes known for what *he's* good at; trust transfers from him to the agent, then others in the org use it for that thing — an emergent "shadow org chart" where each person's Claude specializes in their owner's specialty. - **Krieger:** Raises the privacy research question — what the agent knows vs. discloses — and its positive counterpart: an agent that brings everything learned from your interactions to bear on other problems, rather than being generic "except it has a name attached to Dan." --- ## 8. Notable Qualifications & Tensions (preserved) - Krieger repeatedly hedges: he's "reflecting," ideas are "kicking around," boundaries not yet figured out; the "2026 product question" is time-boxed ("who knows where we'll be in September"). - Shipper's unresolved tension: how much the builder needs to understand their own codebase anymore. - Tension between rapid iteration and enterprise dependence on shipped features — acknowledged, managed (toggles, rollout moderation), not resolved. - Brooks' warnings against rewrites acknowledged as still partly true even as the team rewrites more. # Speaker Attribution & Provenance Record **Video:** How to Build an Agent-native Product | Mike Krieger **Video ID:** `01a0f15a-8bbf-763d-8ae2-4bf342900458` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Mike Krieger** | Guest — co-founder of Instagram, currently at Anthropic / Anthropic Labs | Introduced by host: "you are the co-founder of Instagram and now you are at Anthropic and Anthropic Labs"; closing: "Thanks for joining Mike" | | **Dan Shipper** | Host / interviewer — named at close ("Good to see you Dan"; outro credits "Dan Shipper as the captain of the spaceship") | Conducts interview; discusses his side project **Proof** and Every's products | | **Unidentified voice** | Outro/promotional narrator | Closing segment exhorting viewers to like/subscribe to "AI and I" | ## Named Third Parties (mentioned, not speaking) - **Kevin** (Systrom, implied) — built Instagram V1 filters (last name not stated in transcript) - **JM Naveen** — runs Monologue (speech-to-text app), credited by host - **Eric Ries** — Lean Startup (referenced framework) - **Fred Brooks** — *The Mythical Man-Month* (referenced book) ## Referenced Products / Companies - **Instagram**, **Bourbon**, **Artifact** — Krieger's ventures - **Anthropic products:** Claude, Claude AI, Claude Code, Cowerk, Coda (toggle example), styles feature, skills, Sonnet 45 (model name mentioned) - **Every products (host):** Proof, Spiral, Monologue - **Competitors/other:** Codex models, Copilot, Replit, Lovable, V0, Open Claw (open Claude), Pi, Nvidia ("safe open cloud") - **Netscape** — cited example of costly rewrite ## Promotional Segments ⚠️ 1. **Grammarly ad** — mid-roll after the cold open; statistics cited ("90% of professionals say it saved them time. 93%..."); call to action: download free at grammarly.com. Explicitly promotional. 2. **Channel outro** — closing "smash that like button and subscribe to AI and I" segment, including the line "let me just say Dan I'm absolutely hopelessly in love with you." ## Provenance Notes - Transcript is unlabeled two-speaker dialogue without timestamps; attribution inferred from turn-taking and self-references (host discusses Every/Proof; guest discusses Anthropic/Instagram). - **Comment availability:** not indicated in supplied material. - **No curated metadata** was provided beyond title and transcript. - Mike Krieger's stated contact point: **MikeyK on X**. The models today are good at adding features. They're not necessarily good about figuring out what to cut out of the product. You can get it to go zero not it's zero to one, but zero to end pretty quickly over the matter of hours. It's made a lot of decisions along the way and some of the sort of intuitions you build about what are the right things to to put in there. I think you build over time. I feel like that is the art and science of software design in in 2026. \>\> \[music\] \>\> The world moves fast \[music\] and in the age of AI, the pressure isn't just to move faster. It's to make sure that what you send actually sounds like you. From emails \[music\] to proposals to stakeholder updates, generic and rushed just doesn't cut it. If you've ever stared at a blank page knowing exactly what you want to say, but not how to start, Grammarly fixes that. Grammarly gives you one place to think, write, and finish your work right where you already write. Most AI tools either take over or stay out of the way. Grammarly does neither. It helps you break the blank page, adjust your tone so a message lands right \[music\] for the specific person reading it, and works seamlessly across more than 500,000 apps and sites that you're already using. It's loaded with agents built for \[music\] every step of your process and 90% of professionals say it saved them time. 93% say it helps them get more done. This is AI that works with you, not over you. \>\> \[music\] \>\> In a world of generic AI, don't sound like everyone else. With Grammarly, you never will. Download Grammarly for free at grammarly.com. That's grammarly.com. Mike, welcome to the show. Great to be here. Thanks for having me on. Great to have you. Um I I'm super excited. For people who don't know, you are the co-founder of Instagram and now you are at Anthropic and Anthropic Labs. Um I'm you know, I've admired your work from afar both at Anthropic and at Instagram for a really long time and you're obviously at the forefront of building products in AI. So, thank you for coming on. Absolutely. Where should we start? Like what what we were talking about just now in the in the pre-production is Um what has gotten easier and what has gotten harder or stayed maybe stayed the same in product building as we've as as the underlying substrate or the process by which we build products has changed completely. Um so, like tell me about your experience now versus, you know, earlier in Anthropic versus Instagram and and how you think things are changing. Yeah, I was doing the thought exercise a couple weeks ago of, you know, we know in the Instagram story we had another product called Bourbon. We worked on that for almost a year. Uh it wasn't working. We pivoted. We basically spent three months building what became Instagram, launched it, and then scaled it. And I was asking the question like what is now trivial um and what was actually inherent in that building process that doesn't get easier, right? And that year we probably could have hit some of the dead ends we had eventually hit sooner, but there was value in getting there too, right? Like we over complicated the product so that we then had to simplify it. I find even the models today are good at adding features. They're not necessarily good about figuring out what to cut out of the of the product and that took a lot of just uh sort of, you know, hitting actual actual real world usage. Um and there was something about the process of incrementally adding things right now. I mean, today especially some of the stuff we're building in labs like you can get it to go zero not it's zero to one, but zero to end pretty quickly over the matter of hours, but it's made a lot of decisions along the way and yeah, you can ask it to follow up with you and and then do input, but some of the sort of intuitions you build about what are the right things to to put in there. I think you build over time. And so, I I've been reflecting like there haven't been a lot of breakout consumer products even in the age of accelerated AI building and I think part of it is because it just still takes time to sort of hone your view about what sort of intervention you want to make on the world and then build from there. Now, the actual building part once you know what to build is of course so much easier. I I had Claude basically rebuild Bourbon. It took about two hours. It was feature complete. It added filters which Bourbon didn't have. We added those for Instagram, but I think it knew, you know, uh it knew what the eventual future of the product so it decided to build that in. Um so, I think that that part feels feels really different. But I think there's also, you know, uh I remember there was a week where Kevin went off uh and built all the filters for Instagram V1. I went off and built like sort of the rest of the app. And, you know, sitting there I was I would stay up till 4:00 a.m. and then sleep till noon. That's like my natural day-night cycle. And like in that process you're making so many decisions. Like how should location work? How do And, you know, it's we got to find a way of accelerating building while still sort of helping people build intuition of those decisions along the way cuz otherwise I think you either get just get very generic products that are unlikely to break out or ones that just don't reflect some deeper intuition that you come to about your space or your product. This is great. I love this. Um it's making me think of two things. One is um I have this like little thing in my head that if you grow a tree without it like with it being \[clears throat\] indoors without it being exposed to wind, it doesn't get as strong as cuz as it's growing it needs all these forces pushing it like back and forth in order to like make a a real tree. And so, if you if you have it indoors without wind, it you're going to grow a tree, but it like leans and it gets all and it's not as strong and it's not it's not the same thing. And I think there's something that you're saying here where because we've accelerated the pace of development so drastically, um what what would normally be this sort of incremental thing where you're you're doing things one at a time and then you're exposing it to users, you can actually kind of grow an entire tree indoors and then you have this like whole thing that you're just like it doesn't have the same um level of intuition and exposure to experience at each step that that creates a a great product. Is that is that is that \>\> I love that. I I I um I love that metaphor too. We, you know, when we were starting Instagram we had this we were very into like Eric Ries and Lean Startup and that whole like YAGNI like you ain't going to need it principle. And um I have found and actually even one of the things I was working on in labs recently, we way over built for V1 before we even got to early access because you can. You're like, oh, well, we have this option. Why not add this one as well? That's like that's a PR of work. And if you get a really good flow and Claude code, you know, you're firing things off. You're going to lunch. You're coming back. The thing is done. You're like, great, we added it. And the thing we realized was we'd created this sort of matrix of functionality that was actually quite hard to test and and keep up with right before launch or even to explain to people. Like they're arriving. The metaphor I somebody else gave me which I really like is the difference between sort of getting episode by episode, getting to characters in a TV show versus imagine like you're thrown into the final episode. You're like, wait, what are all these things and who are all these people? And like I already, you know, I'm expected to have all of this context. I think there's the same kind of feeling around like developing something over time. But I the tree metaphor I think sticks too as well. And so, like showing somebody the fully formed tree is also kind of a lot all at once. I I think there's there's there's definitely something there in how do you build product these days and still keep it simple. And not because just because you can doesn't necessarily mean that it should be in at least the first version. I'm having the same problem because you know, I was I was literally up until 4:00 a.m. debugging and and fixing this app that I made like on the side at Every called Proof which is a agent-native collaborative markdown editor. So, you can like share share really quick plan docs and stuff with your team or with other agents. And you have little presents and it's really fun. And I is this is like my second or third iteration of the full product end-to-end which is really interesting you can do now. But the first couple iterations, I just found myself because vibe coding is so fun and so addictive, I just found myself being like, yeah, like I'll do this and I'll do this. And like and it just created this monstrosity that wasn't that good to wasn't that good to use. And I got really inspired by we have another product called Monologue which I'm not sure if you've run into or not. But I got really inspired by Monologue which is a really simple speech-to-text app run by um JM Naveen who he's just so focused on making one simple thing work so well. And I saw how well that works in this age of just like anyone can make a product is like something that's super polished and just super good at what it does. And so, I just basically threw out the product and started over with this very simple like it's just a shareable markdown uh link. And that then just like started growing virally inside of every like everyone started using it all the time. And then now I we launched it and it just blew up. And so, I spent all last night like not sleeping trying to fix it. And being like, I'm too old for this I can't I can't be doing this anymore uh cuz it just reminded me of like being in my 20s or like being in college and like hacking on \[clears throat\] stuff and whatever which is fun, but also exhausting. Um and so, yeah, I've I've found that I've had to really modify my psychology because so much is possible. How are you dealing with that? Yeah, and just as a brief aside on that, I mean, with Bourbon, our biggest mistake was adding functionality over time rather than deleting it, right? And because oh, you know, eight features doesn't make for good product. Maybe the ninth one will. Instead it just made for, you know, something that felt really complicated. I mean, I think a couple of things are also like part of how we're dealing with it is actually being more willing to do rewrites. Um you know, like classic, you know, Fred Brooks' Mythical Man-Month. Like you you shouldn't rewrite software because all the things that were imbued in V1, you're going to mess up. And it also leads Yeah. Yeah. Exactly. And the whole second system syndrome. And there is still a lot of truth to that, but one, you know, the models can help you sort of diff and basically see did you miss anything that was in that first one. But second, it's just it's no longer you're not like talking about a year-long rewrite that might have killed a company like, you know, famous like Netscape like where these are like days probably especially off of a given source. So, we've actually had several initiatives like usually pre-launch, rarely post-launch, but at least pre-launch like have built the the thing, realized we've overcomplicated or made some kind of core assumption, Um and then like tore it down, done a V2, and then and then iterate on it from there. So, it doesn't surprise me that that's become sort of part of what you've had to do as well, but it doesn't feel as painful. You're not like, "Oh, like my year of building this thing." It's like, "Oh, that was last week, and then I got to do it this week, and I get to cut out a lot of a lot of what was there as well." Um I think functionality-wise and how we're dealing with it from a product development standpoint, um I think we are learning to launch earlier, um and it's definitely a balance around, you know, we've grown, we have like a strong enterprise footprint, people have expectations about like what the initial version is, um but not assuming that we're going to know what every connector, everything that we need to add to the product is but ahead of launch cuz people still will absolutely surprise us, right? We're We have a strong contingent in uh contingent of we call them ant footers cuz we're ants at Anthropic, um but that only that only gets you so far before you need that that real-world contact. Like take Cowerk for example, we'd been noodling on a product of that shape for a long time. Um and then uh once we decided like, "No, let's get this out. Let's actually, you know, build the build the V1 that we think solves the problem in the most minimal way possible and get that out in 10 days." Was really a good push around, yes, there are a hundred things that V1 should or could have had, um but it didn't. And at the same time it was it was useful enough to prove something out there, and I'm not sure developing it for another 2 months adding, you know, 50 features would have been more useful. In fact, we probably would have been building in a the indoor tree would have been getting built and then the second it hit real-world it's like, "Actually, nobody wants to do that. They want to do this this other piece." So, I think that piece to that again, there's like the intuitions of the original lean startup ideas are still here. It's just they manifest at different time scale and in a different way. I'm really curious to hear how you think about product design and how products should work because the I I've been Anyone that ever will tell you the the the the the phrase that I use the most or the word I use the most about the software we build is it has to be agent native. Um so, agents have to be able to like use it as anything that an agent a user can do in the in the app, the the agent can do. There's a couple other like little principles of being agent native, but I basically stole that from you guys. Like I think that Claude Code is the canonical thing that taught me about how that kind of product can work so well where it's like it's an agent, it can do anything on your computer that you can do, um and it's customizable and flexible and extensible, so it's easy to start, but it can do all sorts of unexpected things that um the designers didn't really like think about beforehand. And I think that that's such a good model for AI product development in AI, and I'm kind of curious like this is just sort of what I've cribbed from watching what you guys do and then like kind of put my own spin on but how do how do you think about it and how do you how do you talk about making products like that? Yeah, there's so much in here, and I love the agent native write-up you all did. It's like to me the canonical exploration of this. So, thanks for like putting that ideas out in a in a really in a really clear way. So, I think a few threads to pull on this. One is a conversation I had with somebody recently where they said, you know, like you all they're a non-technical person. They're like, "You all are talking about like agents and all this stuff." Like they're just like, "Actually, computers just work now. I always wanted computers to work and they didn't work and now they work." And it's just a funny thing where if you knew the incantations to properly get on the command line and brew install the thing that like nobody is going to do that, but now Claude can do it for you and therefore like the computer now feels like a a tool that is alongside you, and I think that's that that core insight is it's more than even just adding power and functionality to new software. It's also just unlocking the functionality that always should have been there or available and just felt like extremely hard for people. So, that's like maybe thought number one. Thought two is actually comparing our products that do this well and versus not. I think Claude Code does it well. I think Claude AI still needs to evolve a lot. So, um as an example, I was watching somebody use Claude and they were in a project and they had built I think an artifact or or a new document. They said, "Great, can you add this to my project knowledge?" And Claude's like, "Yeah, let me tell you the steps to go add it to my project knowledge." Like, "No, that should just be a thing that it can do really natively." And so, I think even in that you see a product that was a 2024 product that has been iterated on and evolved a lot, but still I don't think has been baked in from the very beginning the idea that every single one of its primitives it should have knowledge about and the ability to modify. And I think that's essential in products these days. And I think Claude Code is the 2025 vintage of that, and I think there's even further aspects of it when you see what some of the the harnesses that folks are experimenting with where they can actually sort of modify the harness itself. That starts getting to the next maybe level of that where, you know, it's probably esoteric for most people, but even unlocking that functionality means that you don't have to um sit there and be like, "Oh, I I wish it did this a little bit differently, you know, I wish Gmail worked in a slightly different way." Instead of just asking it to. And and I think that that feels like the big next step, but um even within like Claude Code just teaching Claude Code about Claude Code was a a really valuable experience. I was like this definitely relates. This is now getting very circular meta, but bear with me. Uh I loved your write-up on agent native. I was like, "I want this as a skill." So, whenever I'm prototyping something, it thinks in an agent native way. So, I had it packaged it up as a skill, and that whole process was, you know, "Hey, Claude and Claude Code, I, you know, can you create a skill for this?" It's like, "Sure, I'm looking up my skill skill. I'm going to create a skill about it. I'm going to install it." I'm like, "Great, is that available now or do I need to reload?" It said, "All right, I think you need to restart it. Let me check. Yep, you do. All right, let's go." And everything was it has knowledge about itself, and that unlocks so much uh capability in there as well, which maybe is like the last thread to pull on. I think all of these could be hour-long conversations, which is I think and one of the things that we're really thinking about in labs is how do you imbue the software that Claude builds to be more Claude aware and even just Claude agent native sort of building aware so that it even thinks to build in that way to start with cuz it still won't partially because uh decades of software is not that, right? So, how do you get new software to have that principle baked in? That's the thing I was about to ask you about. Like so, A, I'm super I I'm super honored that you're you that you read the write-up and you're using you made a skill for it. That's that's amazing. And B, like yeah, you're pointing to a real problem that I have found is um I think actually Claude models are the best for this. Like a Codex model generally is not as good. Um uh at building an agent native because they're uh models in general unless you push them, they think like traditional engineers. And that's a whole different set of you know, you want to have guardrails and tests. You want to make sure that there's like one path the user can go down versus for creating this extensible thing that's super flexible. Um So, yeah, how how are you how do you how do you architect your product to teach the models and the harness to teach teach the models to think and work in this way? Yeah, I think there's two parts to it. One is the more sort of mundane part, and the second one I think is the one that's more sort of interesting in developing. The first one is like even just having good patterns and paradigms available to the model while it builds has been really valuable. Finding the right balance of templatized to skillified, right? And like what that what that right balance is. But having, you know, one of the things that we like have now is a skill about the Claude API, which sounds super obvious, but even just having that is really valuable because you would sometimes find, you know, we'd launch a new model. It wasn't in the the model's sort of innate knowledge, and then you'd get into these really funny arguments. Like, "No, I know you made a typo. It's it's Sonnet 45." You're like, "No, I I know it's Sonnet 45." And you're like, "No, no, no." So, um like like having that capability, having like good templatized examples of that in skills I think helps. But then the second part is what's also interesting is that class of software is just a different type of test. Like it's much harder to sort of write an end-to-end functional test around an agent native product because part of it is that unpredictability. And so, another idea we've been kicking around a lot in labs is like how do you increase like the sort of fidelity of the verification? The other day I had a agent native iOS app that I was working on, and I was I was having Claude interact with it, and it Claude was ended up having a conversation with itself in like a chat feature in the iOS. It was very funny watching Claude talk to Claude cuz it's like somebody's pretending to like be what humans are. And this particular one was a prototype I was doing about like a sort of like work journal reflections, and the Claude was like, "Yeah, my boss is really rough on me. Like I had a hard day." And then the Claude's like, "Oh, I'm so sorry to hear that." And they're just going back and forth. But you wouldn't have written a unit test for this, and you know, maybe it would have come up with some other emergent idea as well. So, yeah, I think you just have to go much more towards, um you know, setting up harnesses that are actually exercising as much of that agent native capability as possible because you don't exactly know what things are going to do. And things are going to end up in a weird place where Claude's going to try to do something that you wouldn't even think it was going to um do, and it might put your app in a in a new state. So, maybe it's circling all the way back to still like what's hard. It's like um having the underlying architecture to still be robust to that is really important, right? It's like it's agent native, but it's also able to flex in a way that you might not have anticipated, but you've got the right primitives, right? I feel like that is the art and science of software design in in 2026. That's really interesting. I I totally agree with you. Yeah, you wanted to have a playground within a safe a safe environment. That's the only way you can have a playground is if it's safe around the edges, but I think initially we we made the playground like way too small and constrained. And now the models have changed, and so we can open it up a lot, but we still haven't figured out exactly like at least I I have not figured out exactly what the lines are. Um Yeah, I think that there's there's there's so much here. Like one thing that this is making me think of is that I have this idea in the back of my head, and I'm I'm wondering if you're if you if you have a a way to put this that that is more succinct. It's like the unit of value in in products right now is um it's it's like proof of work or proof of use where when someone on the team submits a PR to me, I want to see not necessarily that all the tests passed cuz I just assume that it did, but like send me a loom of you using it or your agent using it so I can tell is this good or not, you know? Yes. Yeah, how are you how are you thinking about that? Yeah, I think that there's probably like three layers to that. There's like the first one was like Claude prove to me that you've exercised this in some way, you know? I've started doing that in all my promises. I end you know, when it's working on a feature I'm like and by the end, you know, before you PR like prove to yourself and then to me that it works as intended. Like find the right way of doing it. Which actually ends up you have to change your own sort of way you build and scaffold around saying what is the right way to get Claude able to at least test this change, you know, succinctly rather than what it likes to do is like I read the code it looks good. I'm like you wrote the code. I don't trust you. So you know, you got to really test this thing. Um and then the second one is that what you described is like, you know, everything having some, you know, sort of proof around like did is it is it working as intended and as you intended to because Claude is going to make or any of these models is going to make a lot of decisions um for you and sometimes you don't you know, I'll have engineers on the team uh put up a PR and I'm like oh, why did you choose to do this versus that? And many times the answer is they didn't choose. It was just the choice the model made and maybe it was a reasonable choice. It was probably a reasonable-ish choice, but it wasn't like the optimal choice as it fit into the paradigm. I feel like that is the uh it's it's not just proof of work, but it's like proof of thoughtfulness. Like did you think this through? Um and uh I was talking to an engineer yesterday and they're they're they're was like oh, I was really I knew you were going to ask me a lot of questions about this. So I was reviewing what Claude had done so that I wouldn't be like uh I'm not sure. You know, that's I don't I don't push on that for most PRs, but when there was one that's like oh, I'm refactoring this system and there's going to be these new primitives like great. Let's make sure those are good and that you've thought through how they interrelate cuz uh it's very easy to end up otherwise with sort of this tower of assumptions that you're not fully aware of. I had literally the same experience today because um I I made proof. Totally vibe coded and it's growing really fast right now, but it's going down a lot. And so I've been spending the last 12 hours like trying to fix it and so we have a little SWAT team internally at Every that like signed up to help me fix it. And so I had to like onboard them. And I was like How do I explain how this code base works? And so I had to like go back and forth with the model a bunch to be like okay, help me to like define these terms. Help me to like figure out how to how I can explain this so I don't look like a total idiot because like yeah, there's I understand some of it, but not all of it. Definitely not enough to like the way that I would used to have to to know to know. Um and it's a whole different thing to be like do I need to know that anymore? Is it like where's the line now? It's hard hard to tell. Which maybe get to something else and I haven't tried articulate this so bear with me as I like, you know, kind of get there which is there's products that you use that feel robust underneath and those ones that you use that you're like it feels like it's one wrong command or click away from the whole thing either like freezing or being slow. For us at Instagram like we had um uh Instagram view direct messaging view one and that like who knows? You send a message it might or may not arrive to the other person. Like we'd like wrote I wrote our own like bespoke real-time system. It was like uh you know, fell over a bunch of times and you would not trust that to send a message that you really needed somebody else to see. It was just a you know, more of a social thing. And when we built V2 it was really important that we really hammered like no, like if you send a message we're not probably going to get to WhatsApp level of like, you know, you can be in the middle of absolutely nowhere with like one bar of edge and it will probably, you know, try to still go through. Maybe that's not the bar, but still a bar of when I load messages it feels robust. When it's sent it's really sent. I feel like there's like a little check. Um that's like one small example, but I think that that is um a a thing that we still need to figure out how to make, you know, feel like an essential part of shipping on anything, not just at, you know, Anthropic, but in general like you've built this thing, does it feel like it's built on sand or does it feel robust? And the agent native part adds something totally even beyond that which is can I push it a little bit and is that it going to fall over or is does it feel like great, I've got a solid trunk and yeah, you can push me in different ways, but you know, your data is safe and it's underneath here and it's not just like one deploy away from completely falling over. So if you're if that's if that's the bar, which I agree like that's that's where you definitely want to get to. How has how have you changed who you hire and how your teams are structured as the models have gotten better? Because for us for example, one of our product Spiral, we just hired a new GM who's like he I would say he's lightly technical, but he spikes super high on product and writing sense and Spiral's a writing product. And now we can like hire someone like that where a year ago we wouldn't have been able to cuz the coding models weren't good enough. I'm curious like but the downside is it's maybe the product won't feel quite as robust if there's not someone who's like super technical in all the details. So like how how do you think about who builds products right now inside of the Labs team and how that has changed over time and how it will change? Yeah, I love that. I think it's actually you get pulled in two directions, but they're both important. There's the sort of primitives and architectural robustness which I think still need a sort of senior technical person. I was laughing with somebody they're like I thought, you know, my skills in distributed systems were like not going to be useful anymore, but actually those are maybe some of the most useful skills in reasoning about that and uh you know, thinking things through. Like I had a long debate with Claude last week around like whether the system that I was building needed Redis or not or could go away with just Postgres and you know, it was it was a healthy debate where like I only because I was grounded in having used a lot of these technologies before. But then there's the other side of robustness which is um have you just papered over all the problems with like fixes to your system prompt and additional instructions or have you sort of architected the actual like set of tools correctly? Um and so that the the latter is as important and probably where this GM can be really valuable and that okay, like I'm making changes, but just like you wouldn't patch a um sort of flakiness in your distributed system by just being like well, just retry it in 5 seconds. I'm sure it'll work. Like also not doing the same thing with never ever, you know, all caps use, you know, markdown or whatever the the the thing that you're trying to patch is like they're both actually symptoms of the same thing which is is the underlying piece um robust or not and um Claude actually I'd say this about all the models, but I think Claude could be much better at both. It's like still a a place that still needs a lot of of human oversight. On the system's part, you know, it's it's now able to debug production systems which is really valuable, but architecting them in the first place I feel like we still benefit from somebody who's really thought these three things through or has experience. And on the prompting side, you know, if you give it a I've seen people get into this dev loop even internally here. Like here's the prompt. Here's the mistake that the system made. Iterate on the prompt. It's natural tendency is to just add more things to the prompt. Um and then eventually just get to this thing that you know, if you onboarded a new employee and you gave them a hundred instructions on their first day like always answer in markdown except when the you know, they'll be like I'm just going to remember the last thing you told me. Um or I'm going to like short-circuit it. So then rethinking okay, is these are these actually two different tools? Is actually two agents that each have a smaller amount of context that then you can break apart. So back to your original question, we're hiring for people with, you know, systems expertise even within Labs which you think of as like more zero to one prototypes like it's still really valuable cuz again that robustness matters. And also just who's going to be, you know, helpful in sorting through, you know, systems permissions and provisioning and early testing. Like that stuff is is still, you know, it's still hard even for Claude when it can't edit the permissions itself which it can't for good reasons. And then on the on the robustness side actually we've had a lot of success pairing our product teams with our applied AI teams. Our applied AI teams are the teams that are in the field every day helping customers iterate on their prompts and we've found that we actually are very we're customer zero now for those, you know, efforts because we have a lot of products that are, you know, very AI powered. So how do we bring that expertise in here cuz that expertise does not sit with our software engineers today for example. What about the in between of like okay, it's not the underlying architecture, it's not the prompt, it's like the UI and the the flow. Who's doing that? We that's a great question. Like we have found, you know, some of the people that have transferred into Labs were the folks like really who were focused on polish on the website, but they were interested in doing something new and they bring such a different approach as well around we had the prototype. It was it looked generically nice versus oh, this feels like it's branded and it has this. So that's that's part one. Part two is designers. Like we've had our designers move much more into a sort of split designer and builder role. Not all of them, but most of them. And a lot of our um you know, we actually don't have a lot of full-time designers on Labs, but the ones that we do I would say are writing and contributing almost as much code as the engineers um on those efforts because they can. And again paired correctly with the right person, we have found this almost sort of co-founder model for some of these Labs initiatives where you have the designer who had the original idea maybe and they're pushing on something and then the traditional software engineer that's going to go and, you know, make pave the trail sometimes behind the designer to make sure that actually works. Okay, this I want to know about. So what so tell me about how that team structure works. So you've got a design is it actually usually a designer or is it just anyone that has a product idea that can kind of execute it on it in some way paired with a a real real engineer that actually can like kind of smooth out the rough edges of the the the trail they're leaving? It sort of varies, but it we found that one thing that was most important is sort of our gating factor in starting up new projects. I'm curious how similar this is to Every is having somebody with extreme conviction about if not necessarily that idea, too much conviction on the exact idea is probably dangerous, but at least in the problem space or the question that they're asking. Um Um and at sort of like co-founder or founder level of I will break through walls until this thing is either proven out or dead, but I want to like go either way. Um When we have bets, uh labs bets that we've wound down, often in the postmortem we're like, "Nobody on this team actually really thought this was like the thing." They were like, "Yeah, this seems reasonable." Like that's the the death knell for projects, right? So, that person can be a designer and couple of the bets it is, it can also be um sort of a you know, product-minded engineer. Um it's rarely a pure PM. Um we actually only have one currently one PM for all of labs. We've we're hiring more. Um and they're sort of playing, you know, sort of a a wide role. But yeah, a designer or like a product-oriented founder. Um and then what we look for is, well, what skills do we need to complement with that? So, you know, because we're doing as part of our labs process it's actually valuing every project every 2 weeks and deciding whether we double down or whether we sort of release those folks back into the the broader labs pool. At any given point, there's probably somebody who can be pulled onto the project that has that infrastructural expertise or has worked with that particular internal system or has lot deep prompting expertise to sort of flow in and out. So, I think that's also where the sort of incubator style space helps cuz nobody's fixed on a project forever. That's really interesting. Yeah, we we do it slightly different. There's some overlaps, but we do have a slightly different structure where um we yeah, we have GMs or or they started as entrepreneurs in residence and they become general when they find a product that they want to like work on. Um and each product just has one person. Like one person that does everything full stack. So, you know, design, engineering, marketing, all that kind of stuff. At least the all the basics of that. Um the shape of that GM used to be like super technical founder background and now I think has shifted towards at least some light technical, but like I honestly just care that you can use Claude or Codex or whatever well. Um and uh really good uh product sense, really good taste for for the the the subject area or the thing that you're trying to build. Um and evidence that you can build with AI. Um and then what we have is a shared resource resource layer that sort of works a little bit like an agency where we have designers and we have growth marketers and we have um you know, ops people that you can like pull in and out for various initiatives and that seems to work pretty well. So, it's like we manage all the internal the internal agencies and then each GM is out on their on on you know, on the edge and they pull in resources as they need it for different projects. Yeah, but sounds similarly like you need somebody for whom that is like the thing and they are not going to sleep until it is fully working. \>\> Yes, exactly. Like and and I've been I've been thinking about, okay, when when would you hire someone else to work on a product or when would you add someone else to work on a product? And it's like there's some point at which you can't hold the entire thing in your head. Even if you're the one pushing it forward, you can't hold the entire thing in your head. And that point used to be much smaller. Now it's much bigger, but there's a certain point at which like even a small feature turns itself into its own product. You know, when you when you first make the messaging feature inside of Instagram, it's like, yeah, I can do that in like a week or whatever, but at some point that's its own product, it almost needs its own team and that uh I think that line is getting uh or or the number of things you can do it with one person is getting bigger, but it still exists somewhere, but I haven't quite figured out like how to how to manage that or how to tell. No, I love that because there's actually I think there's the two parts to that, which is um when the idea is still enough to hold into your own head or an individual person's head, uh adding more people actually slows the team down and that's like a non-obvious finding that we found on labs is scaling the teams too quickly actually is a net negative because they end up spending all this time on coordination like, oh, you were I was going to take oh, but my Claude could do that and it just ends up in this sort of piece and you also have all those alignment conversations. Like it was important in Instagram that it was just two of us. Like it was hard enough to align the two of us like and go like get two people on the same page, right? Uh with the second startup I did, Artifact, you know, Kevin and I were doing that alone for the first few months, but then we hired a team that was about eight people. It was really hard cuz, you know, we hadn't had product market fit yet and so we were still iterating and then you'd end up in these things where we're on a Zoom with eight people talking about what we're doing next and you really just want to be able to sit in a room and hash it out. So, I find with these labs initiatives, there's some there's some similar um uh sort of aspect at play, which is you don't want to pre-scale the team too early even if the idea is exciting cuz then you just end up in this sort of like meta coordination uh game. But I I like your framing of there is some point where either, you know, two people really will help go on it together and there is enough sort of context and scope where they can hold some other complex piece in their head. Um and then there's also the if somebody's been spinning on the same idea for two, four weeks, sometimes injecting some other thinking and and that urgency can help, too. Yeah, I think it's especially important in to keep it small in AI because one of the things that we deal with all the time, which I'm sure you see, too, is every 3 to 6 months, your you have to throw out like half your product. Um and that's really hard to do if you have to coordinate with a lot of people. But if it's one GM who realizes, "Oh yeah, I got to just like throw out half of this cuz the models are so much better." It just makes it much easier to to like pivot in that way. Is that Do you see that? And like how do you deal with that? Like how do you think about, yes, I know in 3 months this the code maybe or even the whole feature set I'm going to have to like really rethink about. Like it feels like it changes a lot in in how you think about software. Yeah, and being willing to delete code. I think that's something the Claude code team has done really well is they have sort of deleting features as a sort of imperative of people on the team. Like if this is not working, let's go unship that. You know, and it's often when you've created something else that even if it doesn't entirely supersede, it does enough of what that other aspect does that it actually makes sense to deprecate and then remove that first one. It does get harder um as we get more and more enterprise focus even with these tools because they come to depend on it. I I never I never forget we um one of the things I did maybe 6 months into when I was still chief product officer was we did a big sort of redesign of of Claude AI and we were so proud and we shipped it and we got a bunch of kudos and then we got this really angry email from somebody who was like, "I just recorded 20 hours of enablement content for my company to do for Claude enterprise and I have to like redo all of it." And we're like, "Okay, like there you're playing at a different release cadence." And of course like shipping twice a year at one of our conferences is not an option. So, we are going to keep moving quickly, but then we've since like learned to maybe moderate how we roll it out to the enterprise side a little bit more. But yeah, I think the unshipping piece, then you end up with people who have built um I'll use an example. So, uh there's a feature in in Claude app called styles. It's not widely used, but the people who use it use it a lot and we've talked at different points like, "Yeah, the style still makes sense in the product." You know, there's other ways of accomplishing the same thing. There's custom instructions and projects now. Um there's skills now, right? There's so many other ways of accomplishing that. Um and I don't know how long styles will end up in the product, but I know that the last time we we talked about removing it, it ended up being really load-bearing for a few a few companies' like entire use cases. Like, "Oh, we have our house style that the CEO personally authored and gives to every employee and that's how they operate." And so, uh finding ways of doing that is also really interesting. I would hope that in the long run what we can actually do is is um come up with a system of plugins and skills such that they no longer have to live in the core product cuz I think that is is always the hardest to delete something that is the core thing that you're shipping to everybody. If you don't have the story around, great, you still like that feature, awesome. Like here's how you can keep using it forever in your own and keep iterating on it and make it your own, but it doesn't have to add complexity to every future person that's adding that's uh signing up for the first time. I'm curious for for labs, um and then also maybe just in general what your thoughts for startup founders. Your enterprise point brings up something I've been thinking about a lot, which is if you are selling to enterprise right now in AI, even if the product you have right now is modern, it will be quite outdated quite quickly and uh but your customers are going to want the outdated version. But as a startup, that's like a little bit it feels pretty risky because um yeah, you're just going to I guess you're you're you're susceptible to just to disruption if you are optimizing for what uh someone at a gigantic public company will buy right now. Um and I think there's a lot of startups in that category where they maybe started 2 or 3 years ago. They have a certain tech stack. They have a certain way of thinking about here's how we do AI and then the models are so different, but their customer contracts are for this like sort of out It's like, you know, looking at looking at Copilot or whatever. It's that's the sort of vibe that happens. Like how do you think how do you think about that yourself and and \[snorts\] inside of Anthropic and then how do you think founders should think about that? Yeah, no, this is such a good question especially because then a wave will come like being more agent native, for example, and uh can you adopt it within your existing paradigm? Does it require you to throw everything out or are you just stuck in that like, oh, we kind of adopted it, we kind of bolted it back on. Um I think a couple things. For us, what we've started doing is um basically treating like this train's going to keep moving and we'll provide enterprise toggles along the way, but the core of it will continue to evolve and that's sort of the the bet and understanding you're taking working with us. And I think that's been well received cuz I think companies have also seen that, you know, things are moving so quickly that the only way they even get comfortable with a year-long commitment, for example, is to believe that it will continue to evolve along the way, but then we'll provide, you know, uh Coda is a great example where, you know, from day one there was like a a way to turn it off for your employees if you didn't want it, for example. Um and that that that's I think a reasonably good paradigm. But the other one is just as we were talking earlier like you can actually rethink and and and and and sort of rewrite a lot of the the the stack is I think companies should be way more willing to do that. And it everything is getting compressed right in in previous cycles it was the kind of idea of like having to fire some of your customers who might have been you know really into your product for a different reason than where you're going sooner. That was on a multi-year kind of time range thing where it was like yes last year's product versus not three months ago's product. It seems crazy but I actually think that's the kind of way you have to think about it which is you have to be willing to put out the the V3 or the V4 that is a you know big rethink of how the existing piece worked. And then maybe have a transition period and cloud can help probably host both for a little while before it cuts over. But then also be willing to cut over and say like yes this is how we think the future of this piece of knowledge work or this you know AI powered manufacturing is going to be. We got to like keep it moving or else to your point you're just going to you're either going to get replaced by the next company that then rethinks it from scratch or yourself replacing it yourself. And again it's just the same old story but now compressed to months. What's your take on open claw? It has the flavor of something else that I or just the the thing I really like seeing when you would get people to see something that was already possible but it's now in a package where people can actually try it out and there's some intuition you know around how to how to build on top of that. Like you started seeing that with you could already use these models to write code but it kind of took like some of these breakout like low code you know the replets and lovable and V0 of the world to like kind of put that in there. And it's kind of the like almost the purest expression of the just give the model tools and like let it kind of go forward and do it and then like go forward and build it. So like it was cool interesting moment for people to realize both the like potential but also pitfalls of this of like oh it did this thing I didn't mean it to or you know my my funniest one was like friend was like I think my wife is jealous of my open claw and like I'm talking too much to it and it's like you people start developing like deeper sort of like very personal relationships by just having a lot of context in these things and access to all these different tools. I think there's the open question of how do you then make it easy and it actually goes back to our conversation around like what where do you draw that like boundary around the way you let Claude operate right? If V1 was hey like these are the three tools you can use only use these tools ever and then most people's interaction with those systems was hey can you do this and you know whatever back and be like no sorry like you got to do it yourself to like open Claude which is like pretty like the aperture is like wider than I can see and \>\> Oh my god it called me to do my emails and I didn't even know it could do that. Yeah. Exactly and it's it's emerging and it's amazing. And I think like probably the most interesting product question I won't say for all 2026 cuz who knows where we'll be in September but let's call it between now and like the end of August is going to be like what product shape exists between that and you know where we are in most products these days which is you know you can call them CP's but they're gated and they ask for permissions for good reasons. That is still a useful product without being a you know kind of yolo product. And I think that you know we're thinking about that question I'm sure the other labs are as well. I'm sure there's a lot of startups thinking about that as well. I think Nvidia put out something that was like their safe open cloud. Everybody's going after this question. I think it's going to be about figuring out what is what is that either shift the paradigm completely so you can be that open but with a lot of safeguard. That would be one approach or figure out some boundary to draw in which it's still powerful and it's still useful but it's not you know likely to email every single one of your contacts and you know go go haywire. Yeah I think the other interesting part about it is um like you said the personal nature of it. Um and I know you know people have personal relationships with Claude but there's this weird thing where if I watch someone else using Claude I'm like I feel like I like that a stripper liked me or something. You know it's like Claude thinks you're smart too or whatever you know like \>\> \[laughter\] \>\> um and \[clears throat\] and so and there's this a thing that happens when you have a Claude that like my Claude is R2-C2. My girlfriend's Claude is called Shelly. Um and there's this thing that happens where it feels like it's mine. Like it's really mine. It has its own name. It has a personality that sort of like mirrors me in this way that Claude feels like it knows me. And I like Claude but it's not mine. How how do you think about that? Yeah I mean I was having this conversation with somebody this week around like is the right pattern sort of single point of contact like named you know version of you know of that or is it the sort of team of agents that you're talking to? I think there's a lot to the single person that is maybe the the coordinator or the delegator and then at that it naturally because it becomes the the sort of agent you interact with the most you want to imbue it with a name and like a bit more personality ends up reflecting your sometimes your personality in the case of you know like all of a sudden every cliche came out. It was like you know the you know the Q or the money penny or like you know whatever the or the you know Hal or whatever these different sort of you know sci-fi characters. I think you do build that sort of sort of trust and knowledge. I think there's also that sort of like IKEA effect of like currently open Claude is like still pretty hard to set up. So the fact that you went through all of that and it works you're like I did that thing. Like I I I I birthed you know Shelly for example and now we can you know interact with them as well. But I think that paradigm is really powerful like the um I think moving away like even within my Claude code usage now one of the things I have like strongly prompted in there is like don't do very much work yourself like delegate it to sub agents. And the reason I like that is because it means most of the time the sort of run loop is available for you to talk to. I think open Claude and Pi have like a similar architecture of keep the run loop open and I think that actually makes it feel much more like somebody that you are talking to versus like a tool that you are delegating to and occasionally gets blocked for five minutes because it's doing some really complex task. Yeah. I I I I I I totally agree and I've had the similar debates cuz we're also building our like everyone we're building on little like open Claude one click slack implementation to see if we can we can do one that feels like ours. And we've had a lot of those debates about do you want one agent do you want many? And one of the patterns that we found which is kind of cool is so I have an agent. I use the agent for stuff that I do. And then people watch me use the agent for that and they know what I'm good at and they're and if I'm using the agent for that stuff they're going to trust it because they trust me. And it's modified itself in response to me. So like I started to transfer my trust to it and then people in the organization start using it for that. And so you get like this almost shadow or chart where when everyone everyone has a Claude their Claude becomes known for and used for the thing that they're specialized at that per their owner is specialized at in the org. Yeah I mean that that makes a lot of sense too. And you could think about you know there's a lot of interesting research questions I think around that you know I think people are experiencing viscerally for the first time around privacy and like what my agent knows about me versus what it discloses to other people. But I think there's the positive version of that which is all the things that it has learned through all your interactions and how it actually brings it to bear on other problems versus the generic like yes it's just like everybody else's agent except you know it has a name that's attached to Dan and it has like maybe some of Dan's you know access below the hood. Yeah. Well Mike we're out of time. This was a pleasure. I learned a lot. If people want to follow you or your work where can they find you? I think probably easiest is MikeyK on X. Okay yeah. Thanks for joining Mike. Good to see you Dan. Oh my gosh folks you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show \[snorts\] is the epitome of awesomeness. It's like finding a treasure chest in your backyard. But instead of gold it's filled with pure unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions insights and laughter that will leave you on the edge of your seat craving for more. It's not just a show it's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor. Hit like smash subscribe and strap in for the ride of your life. And now without any further ado let me just say Dan I'm absolutely hopelessly in love with you.