By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
Jump to publisher timestampsChapter summaries
First Impressions: Rethinking How to Work With Fable
Dan Shipper introduces Mike Krieger and the premise of looking at Fable 5 beyond day one. Mike describes feeling like a newbie again, since his prompting and task decomposition were out of date. He now delegates complex overnight tasks and trusts them to finish.
- •Day-one impressions matter less than weeks of use, as with earlier Opus releases
- •Mike felt his prompting and task decomposition were out of date
- •He sets off complex tasks at night and finds them done by morning
- •The model recovers from blockers, such as a downed service, by scaffolding a backend and documenting it
- •It feels like a teammate he can delegate a lot of work to
Day-to-Day Flow: Planning, Parallel Sessions, and Effort Levels
Dan asks how Mike actually uses a slow, expensive model day to day. Mike describes up-front architectural planning, turning plans into shareable documents, and running concurrent sessions. He also says Fable is the first model where he has played with effort levels.
- •More architectural planning conversations up front, with pushback based on his Instagram scaling experience
- •Asks Fable for an HTML page or markdown doc to align the team
- •Runs several concurrent sessions and background sub-agents while keeping one fast, high-context Claude
- •Adjusts effort levels, such as medium for UI tweaks, because Fable's range feels wider than Opus
When to Use Sonnet Instead of Fable
Dan asks whether Mike uses Fable for quick questions. Mike says he felt embarrassed asking Fable an NBA question and switched to Sonnet, since the difference is mostly in how much thinking goes into an answer. He sees model choice as a product question for Anthropic.
- •Fable feels like a rocket launcher for a mosquito on quick questions
- •The speed difference comes mainly from how much thinking goes into the answer
- •Sonnet is his pick for fast questions on iOS
- •Ideally users shouldn't have to think so much about model choice
- •A sticky model selection per surface might be one approach
Demo: A Self-Modifying Media Tracker
Mike shows a personal media tracker he built over a weekend in Claude Code. It has an agentic search for adding shows and games, and he extended it so the agent can modify the app from within itself. He frames it as a step toward agent-native architecture.
- •Built on a personal account over a weekend, mostly in the terminal
- •Claude searches for and adds titles, and can research new seasons or sequels
- •Phase one of agent-native architecture is making everything accessible to the agent via tool calls
- •He used managed agents to take edit requests, with previews, a diff view and live reload on his phone
- •It didn't need to be production-grade, but he could keep working on it past the weekend
The Collapse in Cost to Build
Dan asks how the cost of building something like this compares with the Instagram days. Mike recalls roughly five days of all-nighters for Instagram V1 and the slow iteration afterward. He says the biggest change is how many non-builders can now turn ideas into working tools.
- •Instagram V1 took about five days of all-nighters, with Kevin on the filters
- •After launch, iteration was gated by keeping the site up and by week-long features
- •Non-engineers once had to rely on consultancies or overloaded internal tools engineers
- •A recruiter at Anthropic told Mike it was the first time what's in her head and what exists in the world felt right next to each other
- 19:03 – 21:48
Is Software Engineering Over?
Dan asks the question directly. Mike says software engineering has changed dramatically while software development remains essential. Engineers feel a loss of the craft alongside excitement about the amount of work they can now do.
- •The PM/engineering split has become more diffuse
- •Fable is a significant step in how much he trusts the model to see work through and architect reasonably
- •Deciding what's needed and whether the output is good remains a human endeavor
- •Some engineers feel a sense of loss for the old craft while also being excited by their new capacity
- 21:48 – 38:39
How Anthropic's Engineering Teams Work Today
Mike describes what software work looks like inside Anthropic. Humans keep ownership as directly responsible individuals, manage many Claudes asynchronously, and handle production incidents. Prototypes now help settle product debates.
- •Humans still act as DRIs over areas of the product, while many Claudes work for each person
- •Engineers build personal dashboards to track their Claudes and pull requests
- •Understanding code after deployment and incident response is a next frontier for the models
- •Working prototypes now help settle product debates, with PMs showing what works
- •What hasn't changed is ownership
Cost and Pricing of an Expensive Model
Dan raises that Fable is expensive and may limit who uses it. Mike describes phases of corporate AI adoption and says cost should be measured by completing the task to satisfaction. He suggests hobbyists are the group needing the most thought.
- •Fable is more expensive than Opus, but he also calls it cheap for the work it does
- •Companies have moved from adoption struggles to leaderboards to letting effective users spend more
- •His weekend app needed only a bit of extra usage
- •Hobbyists and independents are the group needing the most pricing thought
- •Cost includes the follow-up turns saved when the model gets it right the first time
What Makes the Model Different: System Awareness and Judgment
Dan asks what makes the model different. Mike points to a sense of the whole system, such as reminding him about feature flags. He also cites its judgment in code review, where it can push back, and the value of feedback from heavy users of Claude Code.
- •It reminds him about production concerns like unflipped feature flags and changed contracts
- •It responds to code review thoughtfully rather than reflexively agreeing
- •Reviewers are often another Fable model, and it will push back when it disagrees
- •Feedback from heavy Claude Code testers, including Every, guides what to improve next
Beyond Chat: Interfaces for Delegation
Dan asks whether chat is the right interface for a model used for delegation. Mike says message-passing isn't wrong but names three areas to evolve: decoupling where work happens from where you talk to it, making outputs comprehensible, and multiplayer collaboration.
- •Work should be decoupled from the laptop, as with mobile Claude Code and remote dev boxes
- •Large text outputs need diagrams and progressive disclosure
- •Multiplayer is underexplored, such as incident response or conjoined projects
- •Models are held back by missing abstractions for teammate-level collaboration
Understanding the Work: Verification and Accountability
Dan asks how much one needs to understand what the model produced. Mike says he became verification-pilled and attaches screenshots or video to every pull request. He also says people must stand behind their work and understand its key trade-offs, and he describes the verification tactics Anthropic uses.
- •Every PR should come with a photo or video, such as a screenshot gallery that exposes unseen error states
- •People still need to stand behind work in production and understand the main trade-offs
- •Real flows against staging with real data, plus known-path regression checks and checks on the current change
- •Video with FFmpeg lets Claude catch animation jank that screenshots would miss
- •Claude can build and maintain mock backends and proxies to keep in sync with the real code
Closing the Loop on Bugs
Dan asks about agents that automatically fix bugs and notify customers. Mike describes Fable following up after deploys and showing discernment about what to fix now versus later.
- •It pulls the Slack thread, posts back as Mike's Claude, and shares the PR
- •It follows up once the fix is actually deployed
- •It chose a quick server restart over a deep fix for a memory leak on the weekend
- •Judgment about balancing the immediate fix against re-architecting matters
What to Build: Ideas for Raising the Ceiling
Dan notes that new models raise the floor and the ceiling, and asks for ideas for what to build. Mike suggests expressing your domain's complexity through games, visualizations and simulations, and composing software for problems unique to you. He cites a go-to-market colleague who kept extending her integration over months.
- •Use your deep domain knowledge to build games, visualizations or simulations
- •His wife applies more complex techniques to geothermal simulations
- •Compose custom software for problems unique to you
- •A non-technical colleague's Claude integration grew for months and is now deploying to the whole GTM org
- •Dan reports Fable scoring about 90 on his senior engineer benchmark, versus the previous top of about 62-63
Dynamic Workflows and the Python-to-TypeScript Port
Mike explains why he pushed to ship dynamic workflows publicly and describes using one over a weekend to port a Python project to TypeScript and Bun. He explains how he designed it iteratively in Claude Code. He sees workflows as a middle ground between chat and code.
- •Workflows create scaffolding for deep work and can later tune subtasks to different thinking levels or smaller models
- •The port involved a spec, module-by-module translation, incremental and adversarial testing, and a check for missed items
- •It finished over the weekend with documented exceptions, which he doesn't think earlier models or no scaffolding could have achieved
- •He designed it iteratively in Claude Code, which showed the plan as code
- •Workflows are composed via chat, expressed in code, and executed with a clear UI
Publisher timestamps
- 0:03Introduction
- 1:48How Fable completely reshaped Mike's workflow
- 4:48When to use Sonnet versus Fable
- 10:06What the media tracker Mike built over a weekend reveals about agent-native architecture
- 15:00The cost to build has collapsed
- 38:39The mechanics of verification
- 44:39What people should use the model to build
- 47:24Dynamic workflows
