Anthropic Speeds Code Output Eightfold as AI Reshapes Engineering
Lenny's Podcast
The massive acceleration of AI-generated code eliminates traditional development bottlenecks, shifting the primary engineering challenge from manual typing to asynchronous agent orchestration and high-level verification frameworks.
## Background
Published on June 21, 2026, on YouTube by Lenny's Podcast, this episode features an in-depth conversation with Fiona Fung, the engineering leader behind Claude Code and Cowork at Anthropic. The page description outlines how Fung's 25-year career across Microsoft, Meta, and Anthropic provides a unique perspective on how software development is changing as her teams ship eight times more code than before using AI.
## TL;DR
The conversation explores how AI-native development has radically transformed the software engineering role, multiplying code output by 8x and shifting the primary developer bottleneck from manual syntax compilation to systemic validation and creative ambition. Fiona Fung details Anthropic's adoption of 'trust but verify' development models, asynchronous AI agent routines, and a 'bad vs. sad' quality framework designed to protect user experience amid massive development velocity. She also addresses the cultural side effects of AI engineering, such as agentic loneliness and increased context switching, while emphasizing the enduring need for deep systems expertise, high-agency accountability, and adaptive, just-in-time planning methodologies.
## Atmosphere & style
The episode has an incredibly forward-looking, pragmatic, and deeply authentic vibe, balancing high-level organizational philosophy with the grounded realities of cutting-edge engineering leadership. Fung speaks with a blend of seasoned industry wisdom and fresh, infectious enthusiasm, creating a collaborative and intellectually stimulating dynamic with Lenny. The narrative arc moves from technical revolution and metric restructuring to deeply personal reflections on digital empathy, mentoring, and craft, leaving the listener feeling inspired by the technical possibilities yet anchored by a profound, human-centric approach to culture and community.
## Key takeaways
- [00:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=0s) Anthropic engineers are shipping an average of 8 times as much code per quarter compared to the 2021-2025 baseline, shifting the primary bottleneck from writing code to builder ambition.
- [09:27](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=567s) The rapid code volume multiplier under AI-pilled teams renders traditional quarterly feature lists obsolete, prompting the use of automated monthly strategic reviews.
- [09:27](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=567s) Fiona automated her morning management workflow using an AI 'routines' feature to aggregate multi-channel feedback, highlight themes, and prepare PRs.
- [14:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=880s) The framework for quality control has shifted to checking specifications into repositories for AI to validate, serving as a modern evolution of Test-Driven Development (TDD).
- [16:55](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1015s) Hiring has bifurcated into two specific modern engineering profiles: creative 'dreamers' with strong product sense, and deep systems experts needed to verify model outputs.
- [35:09](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2109s) The engineering frontier is transitioning from synchronous prompting to an asynchronous workflow where fleets of agents independently detect bugs and spin up PRs overnight.
- [39:38](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2378s) The tech industry is experiencing a distinct vibe shift away from 'token maxing' and raw lines of code toward measuring strict ROI and concrete business outcomes.
- [44:25](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2665s) To manage high code velocity, Fiona introduced the 'bad vs. sad' framework to differentiate between catastrophic product failures and frustrating but recoverable user pain points.
- [49:35](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2975s) Anthropic requires all engineering managers to start as individual contributors to build technical rapport and prevent arbitrary management intervention.
- [55:09](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3309s) Orchestrating concurrent asynchronous agents creates an unexpected psychological phenomenon of 'agentic loneliness,' leading teams to adopt social structures like pairwise programming lunches.
- [58:41](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3521s) Running multiple asynchronous agents concurrently causes a severe drop in the traditional deeply satisfying engineering 'flow state' while increasing the cognitive load of context switching.
- [58:41](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3521s) Product Managers and non-experts are increasingly leveraging AI to ship features and code directly, which shifts the data science role toward auditing sloppy, AI-generated work.
- [01:08:48](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4128s) Organizational design faces unresolved structural challenges regarding the limits of fully automated reviews and how to build qualitative frameworks that evaluate if a user experience feels right.
- [01:12:48](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4368s) Advanced AI has not decreased engineering demand, but engineering education must adapt through intense apprenticeships to ensure new graduates understand low-level infrastructure.
- [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) To stay highly adaptable to fast-shifting AI landscapes, the Claude Code team abandoned a six-month roadmap in favor of Just-In-Time (JIT) monthly planning managed via a basic spreadsheet.
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=0s) The New Era of High-Agency Software Engineering
The software engineering landscape has undergone a massive paradigm shift, completely lifting the ceiling on what a single person can accomplish. At Anthropic, engineers are now shipping an average of eight times as much code per quarter compared to the baseline seen from 2021 through 2025. Coding is no longer the bottleneck of development; instead, everything has become possible in theory, shifting the real challenge to how ambitious a builder can be.
In this new environment, the individuals excelling the most are those exhibiting the highest levels of proactive agency and initiative. However, this freedom to code at an accelerated pace is closely tied to a culture of accountability. Teams must maintain a clear hypothesis of what they are trying to solve rather than just writing code for the sake of it. Despite the massive productivity gains, this agent-centric world introduces new human challenges, such as a potentially lonely engineering experience. To counteract this isolation, teams like the Claude Code group have initiated pair-wise programming lunches to keep human connection alive. Furthermore, a stark gap is forming between engineers who lean into AI and "kill it" versus those who resist and feel deeply frustrated or fearful. The prevailing advice for those facing this anxiety is to lean in and focus entirely on what remains within their control.
Fiona Fung, the engineering leader behind Claude Code and Co-work at Anthropic, brings a unique perspective to this AI-driven transformation. Overseeing prominent engineering figures like Boris Cherney and Kat Wu, Fung has managed an extensive 25-year career in software engineering. Her professional journey includes running the teams at Microsoft that built TypeScript and Visual Studio, as well as founding the Facebook Marketplace team at Meta, taking it from a mere concept to a platform that generates over $100 billion in Gross Merchandise Volume (GMV) annually.
While at Meta, Fung also managed their first smart glasses product, contributed to the Orion AR glasses, and eventually led infrastructure, growth, integrity, and safety teams at Instagram, overseeing an organization of over 500 people. This deep history in foundational software tools and massive scale platforms grants her an unparalleled lens into where the world of building is heading.
---
[02:35](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=155s) Shifting Milestones: From Vim and CDs to AI Code Generation
Reflecting on the evolution of engineering, the contrast between the early 2000s and 2026 highlights how unrecognizable the day-to-day job has become. Not long ago, 100% of code was written entirely by humans; today, code generation is shifting almost entirely toward AI, echoing Boris Cherney's famous sentiment that "coding is salt." When Fung started her career as an intern at IBM working on the DB2 operating system services team, her environment consisted primarily of Vim and terminal debugging without an Integrated Development Environment (IDE).
Graduating during the dot-com bubble burst of 2000, Fung felt incredibly fortunate to land a role at Microsoft on the Visual Studio team, despite being so naive to the Windows ecosystem that she initially wondered if Visual Studio was just a "better paint program." Working on the Visual Studio editor team introduced her to the power of "dogfooding"—using the very editor she was building to write its code—which allowed the team to give each other rapid feedback in an era before social media existed.
* **Pre-IDE Era:** Development relied on heavy terminal use, text editors like Vim, and minimal access to graphical debuggers.
* **Physical Software Deadlines:** Software was historically printed onto physical CDs and sent to manufacturing, requiring immense up-front planning due to unforgiving shipping deadlines.
* **The Modern Velocity Shift:** With software moving online and AI taking over code generation, engineering time is no longer the primary constraint, completely transforming product throughput.
---
[09:27](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=567s) Management and Quality Assurance on an AI-Pilled Team
In 2026, an "AI-pilled" software team functions with blurred disciplinary lines where everyone—including PMs, designers, and engineers—regularly checks in code. With the sheer volume of code multiplying by 8X, traditional tracking methods like simple bulleted lists of quarterly features are obsolete. To manage this hyper-acceleration, Fung utilizes a Claude Code remote session enlisted across all team repositories, giving her full visibility into active work, metrics, and internal Slack communications.
Instead of using AI strictly to generate pull requests (PRs), Fung leverages these sessions as a modern management technique to guide strategic conversations. Every month, she reviews the team's focus areas, shipped products, and feedback loops via Claude to assess true market impact. She fosters a culture that encourages team members to "make new mistakes" rather than being paralyzed by a fear of failure, noting that aiming for zero mistakes indicates a team is moving too cautiously.
To stay afloat amidst massive streams of incoming communication, Fung automated her morning routine using a feature called "routines" launched a couple of months prior. Rather than manually parsing data over her morning coffee, her automated agent aggregates themes, summarizes multi-channel feedback, and prepares relevant PRs for her to review right as she wakes up.
* **Feedback Aggregation:** The team synthesizes incoming data from internal channels, emails, Twitter, LinkedIn, and external partner logs directly into Slack.
* **Automated Insights:** AI-driven summaries allow engineering leaders to spot systemic quality issues and engineering hot spots that used to require laborious manual reviews.
Code Reviews and the Evolution of Test-Driven Development
The daily ritual of managing shipments has fundamentally shifted. Previously, a manager would look at what people were saying about the current state of Claude Code and Co-work and direct someone to go fix it; now, the AI simply presents the finished Pull Request (PR) ready to be shipped. This transformation extends heavily into code reviews, which was a massive bottleneck when relying solely on human reviewers. While deep subject matter expertise still requires human validation, the framework for "what good looks like" is now checked into the repository as specifications or documentation, allowing Claude to automate the validation against those frameworks.
This shift represents a modern evolution of Test-Driven Development (TDD). The speaker jokes that practicing TDD in the 2000s—where you had to write a failing test before writing any actual code—felt a bit like being forced to "eat the broccoli first" because developers just wanted the thrill of building. While fixing a first bug on Claude Code, the speaker explicitly asked the model to write the test first, make sure it failed, and then apply the fix so the test passed. What used to feel like a development "tax" is now automated, making classic, efficient engineering principles highly accessible because the models handle the grunt work.
The Two Modern Engineering Profiles: Dreamers and Systems Experts
When hiring for engineering teams in this AI-accelerated era, the focus has shifted toward two distinct archetypes. The first profile consists of creative builders with strong product sense, effectively acting as the "dreamers." These are individuals passionate about the product end-to-end, who take an idea, build it, look at user feedback, and continuously polish the experience into something delightful. The second profile consists of deep systems and distributed systems experts. While generalists are valuable, deep subject matter expertise is critical for the "hard parts" to maintain a philosophy of "trust but verify," ensuring human experts check the areas where models still require rigorous validation.
This new dynamic fundamentally changes an engineer's mindset regarding project complexity and ambition. In past conversations, even 10X engineers admitted that hearing a complex feature idea used to prompt a defensive, "No, that's really hard and complicated" response. Now, that mindset has shifted entirely to, "No, that's so possible. I just ask Claude Code to do it." The ceiling of what a single person can accomplish has been lifted. For example, a non-mobile engineer who needed to add a mobile footprint to a feature was able to use Claude as an Android expert partner, successfully delivering the capability across mobile surfaces despite lacking traditional trade expertise.
Cultivating a Growth Mindset and Overcoming Career Fear
The rapid transformation of technical roles leaves some individuals thriving while others are left frustrated, unhappy, or resisting the change. The defining differentiator is a growth mindset—the commitment to "always be learning" and accepting that what served you to get to this point may no longer serve you. Changing behavior is inherently scary for professionals who have historically been successful operating a certain way. Frustration often stems from a fear of losing control, making it vital to reframe the situation from happening *to* you to happening *for* you, focusing strictly on what remains within your personal control.
The speaker shares a personal anecdote from high school to illustrate confronting the unknown. Aspiring to be a visual artist because of a love for storytelling and creation, the speaker realized computers and programming offered that exact same creative outlet. However, computers were expensive, and the speaker's first real access didn't happen until a grade nine typing class, followed by HTML programming. Facing a massive fear of how to afford engineering school in Ontario, the speaker took a proactive step within their control: signing up for a National Bank of Canada high school internship flyer to become a bank teller. Despite accounting being their least favorite class, this minimum-wage job became a multi-year lifeline that funded university expenses, even lasting through the 2000 dot-com crash when traditional tech internships dried up.
- **Key Career Maxims:** * "What would you do if you're not afraid?"
* "Do something scary once in a while."
- **The Concept of the Growth Dip:** Moving away from peak professional efficiency to try something scary introduces a temporary learning dip, which is necessary to keep pushing personal growth.
- **The Podcast's Most Quoted Phrase:** "The cave you fear contains the treasure you seek."
Bridging the AI Gap for Small Businesses and Communities
A stark gap is forming between individuals leaning into AI and those being left behind, prompting a deep interest in helping small businesses adapt. This passion stems from the speaker's personal background as an immigrant child born in Hong Kong who moved to Canada speaking no English. While the speaker's parents worked constantly, their beloved grandmother moved with them to provide care. Isolated by a language barrier, their lives changed one summer when they discovered a local yarn shop owned by a Cantonese-speaking woman. This small business created a vital knitting circle for the grandmother and a space for the speaker to learn macrame, fostering a deep appreciation for how small businesses anchor communities.
This love for small businesses intersected with AI through personal experimentation with Claude Co-work. After using Co-work to effortlessly handle business travel expensing—a task the speaker thoroughly dislikes—it became apparent how revolutionary the tool could be for small business owners who work on razor-thin margins. Witnessing friends sit at bars late at night with physical stacks of bills to manually invoice and expense highlighted a clear use case, as nobody genuinely enjoys back-office administrative tasks. This realization inspired the speaker to begin personally helping local owners adopt these tools to keep from falling behind.
- **Cultural Note:** The speaker humorously predicts that macrame is currently making a major creative comeback.
[28:43](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1723s) Onboarding Small Businesses and Spreading AI Literacy
The speaker recounts the humbling and insightful experience of watching real users, such as local business owners, go through the onboarding flow for Coda and Co-work. This hands-on process proved to be a "win-win" because it uncovered excellent software bugs while simultaneously demonstrating how people use AI tools in unpredictable, creative ways. For instance, a friend who runs two restaurants described her documents and downloads directory as a chaotic "junk drawer" where she knew she had menus hidden but couldn't locate them. By granting Coda directory access, the tool instantly retrieved the files.
Beyond simple search, the restaurant owner utilized the model in a highly localized fashion to balance pricing for locals and tourists. She prompted Claude to analyze "comparables" for her specific style of cuisine within the local geographic area. The resulting market analysis was so accurate that she immediately recognized a competing Seattle restaurant she had personally visited, validating the tool's real-world intelligence.
The conversation then pivots to a broader cultural challenge: how to spread these powerful tools to the wider public, given that many people feel they "don't have time" or outright "hate AI." The speaker advises starting with highly personal, meaningful life changes that AI has enabled, using those as conversational entry points rather than aggressive advocacy. While it can feel a bit awkward initially to pitch friends or local businesses on tools like "Codoxer", sharing these tangible use cases is crucial to preventing a massive, inequitable digital divide. The host echoes this sentiment, noting how sharing a simple tweet about using Codoxer to fill out his son’s summer camp forms sparked widespread realization among his followers about what Claude can actually do.
- A restaurant owner utilized Claude to run a hyper-local market analysis of comparable regional cuisine pricing.
- The speaker emphasizes that AI knowledge must be shared equitably so that the societal divide does not "grow larger and larger."
---
[31:47](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1907s) Uncovering Latent Demand at Anthropic
The host highlights how Anthropic has consistently positioned itself ahead of the market by identifying massive opportunities early, such as leaning heavily into coding and knowledge work, as well as prioritizing the "personality of the model." When asked what Anthropic does differently to capture these shifts, the speaker explains that their teams keep a close eye on "latent demand." They benefit from an internal feedback loop where Anthropic employees are their own "first customers," allowing for rapid iteration on tools like Claude Code.
By paying attention to unexpected user behaviors—such as non-technical users jumping through hoops to use developer-oriented tools—the team works to transform clunky user workarounds into seamless, dedicated products. This exact philosophy led to the launch of "Claude for small business" inside Co-work. After witnessing small business owners struggle to find specific plugins, a dedicated team synthesized these insights into a single, elegant efficiency toggle. The speaker reflects that throughout her software career, "customers will use your product in ways that you did not intend for good or for bad," meaning product success relies entirely on staying close to user feedback and constantly iterating.
- "Latent demand" is identified by watching users jump through hoops to make a product work for an unintended use case.
- The newly launched Claude for small business features a streamlined efficiency toggle built directly into the Co-work experience.
---
[35:09](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2109s) The Shift to Asynchronous Engineering and High-Agency Teams
When discussing how the frontier of engineering is evolving, the speaker reveals that operations are shifting from synchronous prompting to an "asynchronous" style of working. Rather than manually executing individual prompts one after another, engineers can now deploy "routines" that run at designated times to automatically spawn fleets of agents. The speaker shares her own workflow: instead of manually parsing a Slack channel every morning over a cup of coffee, she sets a routine to scan the channel, detect reported bugs, determine polish fixes, and independently spin up agents to address them. As a result, she wakes up to completed Pull Requests (PRs) ready for human review.
This evolving landscape demands a specific team culture. The speaker emphasizes that both the Claude Code and Co-work teams operate on a principle of "high agency with high accountability." Every team member is given the freedom and autonomy to "cook" and solve problems creatively, balanced by strict accountability for what they build or potentially break.
- Routines allow engineers to automate high-level tasks asynchronously, such as checking project statuses or unblocking workflows.
- High agency on engineering teams must be counterbalanced by high accountability to keep development stable.
---
[39:38](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2378s) Reworking ROI and Developer Productivity Metrics
The conversation shifts toward a industry-wide "vibe shift" away from "token maxing"—blindly spending as much capital as possible—toward proving strict ROI and engineering productivity. The speaker notes that historical engineering metrics, like raw lines of code, have always been highly flawed and easily gamified; an engineer might port a massive external library and look incredibly productive on paper, while another might rewrite a framework to generate less code while delivering the exact same output.
Rather than relying purely on automated metric dashboards, the speaker advises leaders to go on a "listening tour" with their senior engineers to understand what is genuinely unblocking them. Senior developers act as force multipliers who can scale best practices across an organization far better than a dashboard can. While metric hill-climbing is useful, teams must always adopt a growth mindset and ask if a given metric is still actively serving the ultimate business outcome, rather than mistaking mere motion for actual progress.
> "Don't forsake motion for progress. Because if you're measuring like, you know, like tool user usage, then you're you're measuring the action, but is it really making whatever the end outcome of yours like important?"
- Measuring raw output like lines of code or token usage often fails to reflect actual business progress.
- In the early days of Facebook Marketplace, the team launched by region and had to continuously audit whether their core metrics were serving their long-term goals.
[42:57](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2577s) Evolving Metrics and the Trap of Metric Blinders
In the early days of launching a product's first region, the team closely monitored the "number of sellers" as a primary metric for expansion. However, they noticed a strange anomaly: the number of sellers in a newly launched area remained low, yet users were consistently finding the items they needed. This led to the realization that the region was being driven by a small group of highly active "power sellers" rather than a massive pool of unique vendors. Recognizing this nuance, the team quickly updated their metrics to reflect how people were actually using the platform, proving that landscapes change so fast that teams cannot afford to have "blinders on" while blindly chasing old metrics.
This philosophy aligns with their internal engineering process, where they utilize Claude to watch pull requests (PRs) shipped per engineer. Rather than obsessing over raw productivity numbers, the data serves as a springboard for meaningful team conversations. The focus shifts away from rigid baselines and toward evaluating real-world impact, discussing unexpected bugs, and understanding the holistic health and context of each engineer's output.
[44:25](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2665s) Managing Speed, Quality, and the "Bad vs. Sad" Framework
To stay on top of an intense velocity of generated code, the team places a heavy emphasis on proactive quality control and early detection of negative trends over time. Rather than relying entirely on generic dashboards displaying metrics like raw time-to-load—which can be difficult to evaluate across highly diverse product surfaces—the speaker introduced a high-level conceptual framework distinguishing between "bad" and "sad" user experiences.
Under this system, a "bad" event represents a severe, irrecoverable error, while a "sad" event signifies a frustrating, yet recoverable pain point. To preserve team autonomy and agency, individual teams define what these thresholds mean for their specific technical areas.
- **Bad experiences:** Drastic failures like CLI crash rates, where the user completely loses their hard work.
- **Sad experiences:** Minor but noticeable bugs, such as a flickering user interface, which can accumulate over time and eventually degrade into a bad experience.
[47:06](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2826s) Monitoring, Testing, and the "Swear Word" Dashboard
A key takeaway for managing unprecedented development speed is shifting the balance of quality control toward automated testing, evaluations (Evals), and continuous monitoring, rather than relying strictly on manual code reviews. Because the volume of incoming PRs makes exhaustive human review nearly impossible, robust monitoring creates a tight feedback loop. This empowers automated agents to understand what success looks like and naturally resolve failures independently.
Capturing the genuine texture of user frustration requires creative tracking methods alongside standard telemetry. The speaker lightheartedly recalls a dashboard implemented last September after an engineer suggested they actively track the frequency of "F-words" and swear words typed by angry users. This "swear word dashboard" has since become a fun, culture-building tool that provides the team with direct, unfiltered insight into user friction and highlights just how complex building delightful, frustration-free user experiences can be.
[49:35](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2975s) The IC-First Approach for Engineering Managers
A unique operational strategy built to match today's fast-moving tech landscape requires every incoming engineering manager to initially start as an individual contributor (IC). Born out of a listening tour conducted with team members, this "player-coach" approach grants new leaders dedicated "maker time" to dive deep into the codebase and intimately understand the product before taking on the heavy responsibility of supporting people. By acting as a peer first, managers naturally build immense rapport with their teammates instead of immediately digging into a traditional "manager toolbox" to perform arbitrary management duties.
Living and breathing the product daily is vital for leadership, even when high-level metric dashboards are readily available. The speaker notes that throughout their career across various engineering organizations, engineers have found it incredibly refreshing to see their leaders personally testing and providing direct feedback on the tools they build.
- **Previous Leadership Scope:** The speaker previously oversaw a large organization of roughly 500 people at Meta before transitioning to their current role.
- **Cross-Product Leadership:** This hands-on, product-testing leadership style was consistently applied across diverse product lines, including VR, smart glasses, and Instagram.
[52:50](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3170s) Re-learning to Ship Software with Claude
Reflecting on their personal engineering journey, the speaker notes that they originally "cut their teeth" at Microsoft, learning its specific codebases, tools, and languages. When they later moved to Meta, they intentionally spent their first quarter working strictly as an IC to fully grasp what it felt like to be a Meta engineer on the ground. However, prior to joining Anthropic, they had not shipped production software since 2017 due to a lingering, common fear of triggering bugs, bypassing proper verification, or disrupting the team's workflow as tool chains evolved.
That anxiety dissolved during their first week at Anthropic. Instead of defaulting to traditional onboarding routines like taking every engineer out for coffee, the speaker treated Claude as an automated "onboarding buddy." They queried the AI about the architecture, used it to design comprehensive manual testing strategies to complement automated testing, and quickly regained the confidence required to ship PRs safely. They note that many long-time manager friends have reached out expressing a similar sentiment, declaring that they are happily "shipping code again thanks to Claude."
[55:09](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3309s) The Changing Role of the Engineer and Agentic Loneliness
As AI tools fundamentally reshape software development, the team frequently debates whether engineers' core coding skills will inevitably atrophy. While early team members like Boris physically hand-wrote the code base in the initial days, modern engineering demands a shift toward a "trust but verify" mental model. Engineers must continually "double click" on the lower layers of their environment to deeply understand their architectural dependencies, ensuring they remain aware of rapid changes and can fully leverage updates.
Interestingly, the team discovered an unexpected psychological side effect of this paradigm shift: exclusively interacting with an AI agent can quickly turn engineering into a "lonely experience." To combat this isolation and maintain a strong collaborative culture, the team implemented structured social and technical events to keep everyone connected.
- **Pairwise Programming Lunches:** Regular sessions where engineers share a meal and program alongside one another, which revealed that different team members utilize Claude's workflows in wildly unique and educational ways.
- **Team Hackathons:** Dedicated collaborative coding events structured specifically to ensure team members preserve real-world human interaction and collective maker time.
[57:17](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3437s) Parallel Play and the Loneliness of the AI Engineer
The rapid evolution of engineering toolchains has introduced an unexpected emotional side effect: loneliness. Historically, engineering was a highly collaborative, team-based endeavor where separate individuals or sub-teams owned distinct layers of the stack—such as backend infrastructure, frontend development, and iOS applications. With AI enabling a single engineer to parallelize their workload—running up to ten Claude agents concurrently to execute multiple complex tasks—the inherent social connection of joint building is beginning to fray.
To combat this isolating shift, teams are experimenting with a concept akin to "parallel play" in childhood development. Engineers work in the same physical or virtual space, building entirely separate things but remaining close enough to observe each other's workflows. This model has proven immensely valuable because the underlying toolchains change so rapidly; watching a peer use tools like Claude Code in unique ways often yields immediate, practical insights for others. When asked how to prevent engineers from becoming over-obsessed with optimizing these workflows rather than executing tasks, the response is relaxed: team enthusiasm remains firmly anchored in shipping higher-reliability architecture and great product experiences, meaning lunchtime workflow optimization debates stay fun without turning into a bottleneck.
[58:41](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3521s) Losing the "Flow State" and the Blur of Roles
The transition to agentic workflows means engineers are losing the classic, deeply satisfying "flow state" that defined the profession for decades. The host, an engineer for ten years, fondly recalls the nostalgic magic of plugging in a music soundtrack, putting your head down to solve a gnarly problem, watching the code compile, and experiencing a massive "aha!" breakthrough when the problem finally cracked. In the modern paradigm, engineers spend far more time orchestrating and waiting for agents to build components. While product success brings a new kind of joy, multiple engineers admit that the hardest, deeply technical parts of the job—the very things they used to love most—are being automated away, forcing a psychological shift in how engineers derive professional fulfillment.
This structural transformation is rapidly bleeding into adjacent roles, most notably Product Management (PM). Because PMs are no longer bottlenecked by engineering bandwidth or scheduling constraints, they can use AI models to roll up their sleeves and ship features directly when engineering teams are fully occupied. However, this blurring of disciplines creates complex downstream challenges:
* **The Verification Bottleneck:** With cross-functional partners contributing directly to the codebase, establishing high-confidence verification systems is critical to ensure quality doesn't degrade.
* **Expanding Automation:** The success of code automation is forcing teams to explore similar automated pipelines for design and data science.
* **The Data Science Dilemma:** Data science roles are shifting drastically. Instead of performing core analysis, data scientists increasingly spend their days auditing sloppy, AI-generated data science work handed to them by non-experts asking, "Can you just make sure this is right?"
[01:01:58](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3718s) Modern Engineering Expectations and the Power of Dogfooding
Engineering managers must fundamentally recalibrate what they expect from their teams compared to a few years ago. Today, it is a baseline assumption that nearly all commits are AI-assisted, and engineers are expected to leverage telemetry, Slack feedback channels, and dashboards natively. Crucially, the elimination of cross-functional dependency blocks means engineers must develop a much stronger product sense muscle, effectively evolving into independent, highly product-minded builders. Roles have blurred to the point where an individual's actual title is simply defined by the highest percentage of whatever task they happen to be executing on a given day.
To maintain an uncompromised quality bar in this blurred environment, a relentless obsession with "dogfooding"—personally living and breathing the product—is essential. While metrics and dashboards have their place, leaders find the most critical insights in specific, anecdotal user bugs. Relying strictly on high-level data can insulate a team from reality, whereas firsthand usage exposes unexpected edge cases and unique vectors that metrics completely miss.
* **The Marketplace Scam:** An execution example occurred after leaving the Facebook Marketplace team; testing the platform personally by trying to sell an old MacBook Air immediately exposed a brand-new, undetected buyer scam vector.
* **The VR Floor-Height Bug:** While supporting VR and AR teams, a leader's specific physical home setup routinely triggered bizarre, reproducible floor-height calibration bugs that automated testing missed.
* **The Polishing Role:** Even when managing highly sensitive operating system codebases where checking in personal code is too risky, leaders can meaningfully contribute by spending dedicated dogfooding time manually vetting the user experience to maintain a strict quality bar.
[01:07:22](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4042s) Field Research, Global Friction, and Unresolved Questions
When direct dogfooding is structurally impossible, engineering and product leaders must pivot aggressively to firsthand customer visits to find growth blockers. During the expansion of Facebook Marketplace into Latin America, data showed that the launch in Chile was underperforming relative to other regions. A tiny three-person research team traveled to Chile equipped with local Android test phones. The moment they landed and opened the app, the issue became instantly clear: the local LTE network infrastructure was drastically slower than US environments, causing the image-heavy Marketplace feed to hang and fail to load entirely. This concrete anecdote perfectly mirrors Jeff Bezos' famous maxim: "if you have the data and you have an anecdote, trust the anecdote over the data."
As the landscape continues to shift, organizational leaders are actively grappling with three massive, unresolved structural questions:
* **Organizational Redundancy:** Do companies still need entirely separate iOS and Android mobile organizations? While deep platform expertise remains vital, the headcount requirement is shrinking because engineers can now easily flex across stacks using AI.
* **Automated Reviews:** How far can fully automated code and design reviews be pushed before losing the irreplaceable perspective of a human expert?
* **The Experience Evaluation Dilemma:** How do you build automated verification frameworks that don't just measure objective technical accuracy, but qualitatively evaluate whether a product's user experience actually feels right?
[01:11:08](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4268s) The Cognitive Burden of Async Agents and Context Switching
The conversation shifts to the operational challenges of managing multiple asynchronous AI agents. The speakers observe that as workflows lean more into async routines, team members face a rapidly mounting cognitive load due to constant context switching. "I do see the context switching load increasing," one speaker shares, noting that they frequently find themselves kicking off tasks only to realize they must later block out dedicated focus time just to catch up on the various streams of async work they have initiated. Managing twenty running agents creates an endless cycle of checking in, reviewing, and trying to remember the precise state of each task.
Ironically, this new paradigm simultaneously complicates and facilitates focus. On one hand, the constant checking disrupts traditional hours-long engineering flow states. On the other hand, resetting to a task is arguably easier because the agents themselves maintain the structural memory. Engineers no longer have to completely relearn the codebase or re-understand the architecture from scratch; the agent simply reminds them of where they left off. The speakers laughingly admit they haven't quite cracked the solution to this balancing act yet, acknowledging that while people naturally want to execute more, doing so without becoming completely fatigued by context switching remains a difficult and annoying problem.
---
[01:12:48](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4368s) The Evolution of the Engineering Role and the Abstraction Layer
The host pivots to a highly relevant topic: jobs, hiring, and the future of the software engineering role. While intuitive logic might suggest that advanced AI would make engineers less necessary, market reality dictates the opposite—companies like OpenAI and Anthropic are hiring engineers "like crazy." One speaker shares a vulnerable reflection on how to foster the next generation of builders when the path to becoming an engineer has fundamentally changed. They express concern over how new graduates can "fast-forward" their growth while still maintaining a deep, foundational understanding of infrastructure and memory allocation. If engineers never actually have to look at code, the incentive to learn these underlying components vanishes.
The speakers muse that perhaps engineering education will shift toward intense fellowship or apprenticeship programs rather than standard three-month internships to cram in critical life and technical experiences. They debate whether the future will resemble a scenario where a retired COBOL engineer has to be pulled out of retirement just to ask, "Do you remember how to write Python?"
Ultimately, they view this transition as a new layer of abstraction, drawing parallels to how software evolved past binary and assembly language. The core of engineering is moving away from years of manual typing toward higher-level problem-solving: determining what interesting problems to solve, deciding which experiences to prioritize, and ensuring that what is built actually resonates and functions as intended rather than just producing architectural "slop."
* **From Punch Cards to Cloud Code:** One speaker shares a heartwarming anecdote about a former manager who began his career in the era of physical punch cards. Today, that same veteran engineer is actively messaging them about applications he is building using Cloud Code, demonstrating an incredible lifelong adaptation to shifting tech landscapes.
* **The Exponential Edge:** Traditionalist engineers often resist AI tooling by pointing out minor model errors. However, because of the exponential rate of improvement, a task that Claude struggles to automate today might be flawlessly executed by the very next model version. The host notes a recurring theme on the podcast: "Build something that is almost working that is at the edge because once the model gets there, you'll be so far ahead of everybody else."
---
[01:18:01](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4681s) Maintaining Human Culture Amid Unprecedented Scale
When asked what keeps them up at night, the speaker bypasses product and engineering challenges—which can be tracked with dashboards and hypotheses—to focus squarely on the human element: team culture. Specifically, they champion a "one team mentality" within the Claude Code and Core teams. They emphasize that culture is a living, breathing organism rather than a static poster slapped on a wall. For them, a healthy culture requires welcoming diverse perspectives and engaging in open, honest debates.
The speaker describes their ultimate workplace nightmare using a popular internet meme: a manager insisting "everything's fine" while sitting in a room that is actively on fire, akin to the famous "This is Fine" dog/cat comic. To prevent this, they explicitly instruct new managers to maintain radical honesty about what is *not* going well so the team can solve problems collectively. The host validates this pressure, pointing out that it is incredibly difficult for individuals to admit they are struggling or falling behind when everyone else on the surface appears to be completely killing it.
* **The Airbnb and Meta Trajectory:** The host recalls their own experience scaling at Airbnb during a period of massive growth. To maintain culture, Airbnb's founders were completely obsessed with values, highlighting them at every all-hands meeting.
* **Sheryl Sandberg's Advice:** The host shares a memory from a fireside chat where an employee asked former Meta COO Sheryl Sandberg how to maintain culture during rapid scaling. Sandberg reframed the stress positively, advising that cultural tension from hyper-growth is exactly "the problem you want to have" because a stagnant company where nothing changes reflects a far worse situation.
---
[01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) Killing Processes and Just-In-Time (JIT) Planning
As the episode nears its lightning round, the speaker leaves the listeners with a core piece of tactical advice embedded in their team's culture: maintaining explicit permission to ruthlessly kill processes that no longer serve a purpose. In a field changing as fast as AI, operational overhead can accumulate quickly. They challenge leaders and individual contributors alike to look at their current workflows, isolate the single most manual, noisy, or dreaded process, and critically evaluate its utility.
To illustrate this, the speaker admits to a lesson they learned firsthand when joining the Claude Code team. Coming in with traditional frameworks, they sought to establish a lightweight, six-month roadmap document to align the team without wasting planning time. While the initial exercise successfully jump-started vital conversations, they looked back a mere three months later and realized nobody had referenced the document because the entire landscape had completely transformed. Recognizing their own misstep, they abandoned the fixed roadmap entirely. When the host asks how they approach planning now, the speaker coins a lean alternative: "I call it JIT planning now, like just-in-time planning."
Fiona explains that their team has shifted from long-term forecasting to just-in-time (JIT) monthly planning because a six-month cycle proved to be too long. While certain projects naturally extend past a single month, their current framework relies on a lightweight alignment process using a basic spreadsheet rather than heavy documentation. To keep everyone on the same page, the team intends to conduct brief weekly check-ins to verify that the month's priorities remain accurate. Fiona notes that she is already brainstorming ways to automate this tracking process further so updating the spreadsheet never feels like an administrative burden or a "tax" on the team.
The host, speaking from a product manager's perspective, finds this simplified system entirely logical and hard to imagine operating any other way, especially since the spreadsheet contains only a small number of high-priority items. Fiona notes that they intentionality limit the scope to maintain focus, giving team members the agency to determine how their individual items best address those overarching goals. While they do align on broader themes during all-team gatherings every six months, they prioritize remaining adaptable because the external competitive landscape shifts incredibly fast. The host jokes about wanting to pull up the spreadsheet on screen and remarks that they could spend the entire podcast dissecting their unique planning methodologies.
---
[01:27:04](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5224s) Lightning Round: Speculative Fiction, Whimsical Movies, and Organic Skin Care
The conversation shifts to a fast-paced lightning round starting with book recommendations. Fiona highlights authors Margaret Atwood and Haruki Murakami for fiction, noting that growing up in Canada exposed her to a lot of Atwood’s work. She appreciates Atwood's "speculative fiction" because it feels like a realistic reflection of what could actually happen to a society if you "squint," while she loves Murakami for his signature "magical realism." For non-fiction or general reading, she recommends *The Little Prince*, a book she reads at least once a year to anchor herself and remember what is truly important. When asked about recent TV shows or movies, Fiona laughs and admits she doesn't watch much television—a trait the host notes is surprisingly common among guests from Anthropic.
Instead, Fiona shares three vintage films she permanently keeps downloaded on her phone for flights. The first is *Amélie*, a whimsical French movie that captures the magic she felt during a high school art trip to Paris when she was 16. The other two are classic Studio Ghibli films: *Spirited Away*, which is one of her favorites, and *Nausicaä of the Valley of the Wind*. Fiona reveals that watching *Nausicaä* at eight or nine years old left a permanent footprint on her heart, directly inspiring many of her core leadership principles. The host chuckles at the unique combination, joking that her top management inspirations are Andy Grove's *High Output Management* and *Nausicaä of the Valley of the Wind*.
- **Recommended Authors/Books:** Margaret Atwood (Speculative fiction), Haruki Murakami (Magical realism), *The Little Prince* by Antoine de Saint-Exupéry (Read annually).
- **Go-To Flight Movies:** *Amélie* (Reminds her of a high school trip to Paris), *Spirited Away*, *Nausicaä of the Valley of the Wind* (Watched at age 8 or 9; inspired her leadership traits).
- **Local Product Discovery:** Sweet Sisters Bodycare, an organic hair, body, and skincare brand based out of Whidbey Island.
---
[01:30:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5424s) Local Business Discoveries and Global Events
When asked about a favorite recent product discovery, Fiona shines a spotlight on Sweet Sisters Bodycare, an organic skin and hair care business based on Whidbey Island. She explains that a few years ago, she developed a painful, bleeding rash on her nose. Despite cutting out all facial lotions, the issue persisted until someone suggested her generic, teenage-era shampoo might be causing a chemical allergy. Switching to the organic formula completely cleared her skin. A recent week of using standard hotel shampoos while traveling brought back minor skin reactions, reminding her of the product's importance and convincing her to start packing travel-size bottles.
The host validates the choice, awarding "big bonus points" for supporting a local business, and uses the travel reference to highlight the global "Code with Claude" events. Fiona confirms she has been traveling for these events, having wrapped up stops in San Francisco and London, with her final upcoming leg taking her to Tokyo the following week.
---
[01:32:45](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5565s) Core Mottos and a Pandemic Act of Kindness
Fiona shares her guiding principles for both work and life. In the professional sphere, her mantra is simply to "keep it simple," avoiding the trap of overthinking by focusing on doing one core thing exceptionally well. For life in general, she relies on the phrase, "in a world where you can be anything, be kind." The host warmly notes that he recently saw that exact phrase written on a wall during a Montessori school tour.
To illustrate the power of small gestures, Fiona shares a poignant story from the height of the COVID-19 pandemic. She was working from home, navigating back-to-back meetings, and trying hard to protect her one-on-one sessions, which she views as critical commitments to her team. Far away in Canada, her grandmother was declining in a care facility. Due to pandemic restrictions, family visits were barred, and video calls were entirely dependent on when busy staff members could assist. Out of nowhere, Fiona's aunt messaged saying her grandmother was available for a FaceTime call exactly at noon—right over a scheduled one-on-one. Fiona sent a frantic, last-minute apology message to her direct report to reschedule. The employee responded with a casual, "Yeah, totally. No problem at all." While it seemed small to the report, that simple, non-judgmental flexibility allowed Fiona to connect with her grandmother, leaving a lasting impression of gratitude.
---
[01:34:55](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5695s) The Binary Art of Knitting and Future Dreams
The host introduces a fun piece of insider observations provided by Boris Cherny, who noted that in critical meetings, you can often hear the distinct "click-clack of Fiona knitting in the background." Fiona laughs, proudly gesturing to the top she is currently wearing and revealing that she knits her own clothes. She draws a playful parallel between knitting and programming, explaining that the two primary stitches—the knit and the purl—act exactly like the binary zeros and ones of computer code. "I'm kind of like a compiler. I'm kind of like... generating an executable when I knit," she jokes, pointing out that concepts like stacks and queues map perfectly onto the craft.
Fiona shares that her grandmother taught her to knit when she was eight years old at a local yarn shop, and the hobby keeps that memory alive. Because she has practiced enough to knit entirely by touch without looking down, it serves as a productive outlet for multitasking, acting much like a fidget spinner during long sit-down sessions. She jokingly admits to a "slight yarn addiction problem" given the massive stockpile she owns. When the host recalls asking Boris what he would do once AGI eliminates the need for human labor—Boris claimed he would make wine—Fiona shares her own post-AGI dream: opening a local community yarn store named in honor of her grandmother. The host quips that they can use AI to automate her invoicing.
- **Knitting as Code:** Fiona views knitting as a binary system where a knit and a purl equal 0 and 1, simulating stacks, queues, and compilers.
- **Multitasking:** She knits entirely by feel during intense meetings to stay focused, comparing it to using a fidget spinner.
- **Post-AGI Dream:** Opening a local community yarn shop named after her grandmother.
---
[01:36:50](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5810s) Connecting Online and Spreading AI Literacy
The host, Lenny, wraps up the conversation by praising Fiona and her team for their profound, fast-growing impact on the technology world. Fiona shifts the credit back to her colleagues, stating she feels incredibly lucky, humbled, and grateful to work alongside such an exceptional group.
For listeners looking to connect or support her work, Fiona directs them to her LinkedIn profile. She explicitly requests honest feedback regarding what is working well and what isn't with their products, and she expresses a keen interest in learning about unexpected, latent use cases. She shares an anecdote about a friend who successfully used Claude to design a structural blueprint for a backyard shed. Finally, Fiona challenges the highly technical or "AI-pilled" listeners to practice a form of digital empathy: taking the time to hold someone's hand—whether a loved one or a small business owner—and personally showing them how AI tools can make a practical, positive difference in their everyday lives. Lenny praises this as an exceptionally thoughtful answer before closing out the episode.
[01:38:25](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5905s) Show Outro and Listener Support
The host wraps up the episode by directing listeners to where they can find and support the podcast. Listeners are encouraged to subscribe to the show on major platforms like Apple Podcasts, Spotify, or whatever their favorite podcast app happens to be. There is a warm, standard call to action asking the audience to consider giving a rating or leaving a review, with the host noting over a fading music track that "that really helps other listeners find the podcast."
To close things out, a central hub is provided for anyone looking to dive deeper into the show's catalog or discover more context about the production. The host bids the audience farewell with a brief, cheerful sign-off, promising to see everyone in the next episode.
* Listeners can find all past episodes or learn more about the show at lennyspodcast.com.
## Notable quotes
> [39:38](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2378s) Don't forsake motion for progress. Because if you're measuring like, you know, like tool user usage, then you're you're measuring the action, but is it really making whatever the end outcome of yours like important? — Fiona Fung
> [01:11:08](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4268s) I do see the context switching load increasing — Fiona Fung
> [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) I call it JIT planning now, like just-in-time planning. — Fiona Fung
> [01:32:45](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5565s) I'm kind of like a compiler. I'm kind of like... generating an executable when I knit — Fiona Fung
## Mentioned
Fiona Fung, Lenny's Podcast, Anthropic, Claude Code, Cowork, Boris Cherny, Microsoft, Visual Studio, TypeScript, Meta, Facebook Marketplace, Instagram, WorkOS, Mercury, IBM, DB2, Windows, Kat Wu, Slack, Twitter, LinkedIn, National Bank of Canada, Coda, Codoxer, Lenny Rachitsky, Jeff Bezos, OpenAI, Airbnb, Sheryl Sandberg, Andy Grove, Margaret Atwood, Haruki Murakami, Antoine de Saint-Exupéry, The Little Prince, Amélie, Studio Ghibli, Spirited Away, Nausicaä of the Valley of the Wind, Sweet Sisters Bodycare, Apple Podcasts, Spotify
Fiona Fung, engineering leader for Claude Code and Co-work at Anthropic, argues that generative AI has removed code production as the primary bottleneck in software development, shifting the core engineering challenge to product agency, architecture verification, and human coordination.
Hyper-Velocity Development and the New Engineering Archetypes (0:00)
At Anthropic, software engineers ship an average of eight times as much code per quarter compared to the baseline between 2021 and 2025. Coding has effectively become commoditized, lifting the ceiling on what individual builders can produce. This transition allows generalists or non-mobile engineers to expand across unfamiliar domains, such as relying on Claude as an Android partner to ship mobile interfaces without traditional specialization.
To support this velocity, Fung identifies two distinct hiring profiles that matter most: creative builders with strong product intuition who iterate rapidly on user feedback, and deep systems or distributed systems experts. Human experts are still required to handle architecture and maintain a "trust but verify" standard, checking critical areas where models require rigorous validation rather than relying entirely on automated output.
Replacing Manual Reviews with Automated Testing and Telemetry (44:25)
With code volume multiplying by 8X, manual code reviews have become unsustainable. Development workflows are evolving into an automated version of Test-Driven Development (TDD), where engineers direct models to write failing tests, implement fixes, and pass validations before shipping finished pull requests. Engineering specifications and acceptance criteria are checked directly into repositories so models can automate validation.
Quality management relies on continuous monitoring, model evaluations (Evals), and direct feedback channels instead of rigid dashboards measuring code volume. Fung uses a "bad vs. sad" framework to distinguish between catastrophic failures, like CLI crashes where work is completely lost, and minor, recoverable frustrations, like UI flickering. The team also monitors user sentiment directly, including tracking the frequency of user swear words in telemetry to surface friction points that aggregated metrics overlook.
Asynchronous Workflows and Blurred Disciplinary Roles (35:09)
Engineering operations are transitioning from interactive prompting to asynchronous routines. Rather than entering prompts sequentially, engineers and managers deploy automated routines that scan Slack channels for reported bugs, plan polish tasks, and spawn fleets of agents overnight to prepare pull requests by morning. At the same time, disciplinary boundaries are eroding: product managers and designers now regularly commit code directly, while engineers are expected to exercise independent product judgment.
This shift creates friction in adjacent specializations. For instance, data scientists often find their roles shifted from core exploratory analysis to auditing AI-generated statistical work produced by non-experts. Additionally, running up to ten concurrent agents introduces a high context-switching burden, requiring developers to dedicate focus blocks simply to review asynchronous work streams.
Managing Social Isolation and Agile Planning at Scale (55:09)
Agentic workflows have disrupted the classic collaborative dynamics of engineering. Operating largely with AI agents risks making coding an isolating experience and breaks the traditional, deeply focused "flow state" that technical builders historically enjoyed. To counteract this, Anthropic teams use practices like "parallel play"—working in shared spaces while running separate agents—and pairwise programming lunches to exchange model interaction techniques and maintain human connection.
To avoid operational drag in an environment that evolves every few months, traditional multi-month planning has been replaced by Just-In-Time (JIT) monthly planning. After observing that a six-month roadmap became completely obsolete within three months, Fung shifted the team to lightweight spreadsheets focused on a small list of immediate priorities, coupled with weekly checks and explicit permission to kill obsolete processes.
As software moves toward higher layers of abstraction, Fung notes that organizations face major unresolved dilemmas: whether specialized platform teams (such as separate iOS and Android units) remain necessary, how far automated code reviews can be pushed without sacrificing human insight, and how to train the next generation of engineers on foundational architecture when day-to-day coding is automated.
## Background
本期内容由知名播客频道 Lenny's Podcast 于 2026 年 6 月 21 日在 YouTube 平台发布。节目对话了 Anthropic 公司 Claude Code 与 Cowork 团队负责人 Fiona Fung，页面介绍重点聚焦其管理一支季度交付代码量较此前激增 8 倍的“重度 AI 化（AI-pilled）”工程团队的实战心得、AI 对工程师与跨职能角色的底层重塑，以及 AI 时代未解的上下文切换与组织文化挑战。
## TL;DR
拥有 25 年工程领导经验的 Fiona Fung 深入剖析了软件工程如何从“以编写代码为瓶颈”全面转向“以自动化验证为核心”的全新范式。她展示了团队如何通过 Claude Routines 异步调度智能体舰队、将“优秀标准”规范入库实现自动化审查，以及为何在 Anthropic 坚持所有管理者必须先从一线 IC 起步深潜业务。面对生产力度量脱离“Token 狂欢”、角色边界全面消融的新格局，她提出了“Bad vs. Sad”质量框架与即时（JIT）月度规划法，并强调拥抱 AI 时代必须以高自主性（Agency）与高担当（Accountability）为双轮驱动，勇于打破陈旧流程并持续弥合技术鸿沟。
## Atmosphere & style
整场对话在兼具硬核技术纵深与温润人文关怀的基调中展开，气氛既敏锐前沿又极其亲切真诚。Lenny 与 Fiona 的互动松弛而默契，不仅有对技术范式剧变的激辩，更穿插着高管边开会边织毛衣、建立“脏话监控大盘”以及在智利现场测速等生动轶事。Fiona 毫不掩饰管理中的真实焦虑与脆弱，从少年时期做银行柜员破除恐惧，到疫情期间面对下属体谅的释然，整个情感曲线在技术狂飙的理性洞察与关照真实个体的感性温情之间自如游走，给听众带来既开阔视野又极具抚慰感的沉浸体验。
## Bulletin
- [08:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=526s) Anthropic 工程师目前每季度交付的代码量已达 2021 至 2025 年基线的 8 倍，软件工程的核心瓶颈已从“编写代码”彻底转移至“代码验证与质量把控”。
- [35:08](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2108s) 工程范式正从同步 Prompt 交互跃迁为异步的“AI Routines（例程）”，系统能在后台自动巡检用户反馈并唤起智能体生成修复 PR，工程师角色从具体操作者转向高层审批者。
- [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) 团队废弃了半年度路线图与繁复 PRD 文档，全面转向基于极简电子表格的 JIT（即时）月度规划，以匹配 AI 时代月度级的技术与业务演进步伐。
- [39:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2380s) 工程度量正经历从盲目消耗 Token 的“Token 狂欢”到关注真实业务成效（ROI）的氛围转变，并辅以“Bad vs. Sad”质量框架来平衡极速交付与系统稳定性。
## Key takeaways
- [08:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=526s) 研发核心瓶颈发生历史性位移：大模型使代码产出呈现 8 倍爆发，传统以编写实现为主的研发流程失效，自动化验证与质量门禁成为软件工程的最关键底座。
- [17:02](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1022s) AI 时代的两类核心工程人才画像：一是具备敏锐产品直觉、能够端到端交付极致体验的“创意构建者”；二是攻克分布式架构与深层系统硬核难题的“系统专家”。
- [18:19](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1099s) 工程师心智转向“野心驱动”：技术的落地壁垒被 AI 大幅抹平，团队面对新需求的本能反应从防御性的“太复杂做不了”转变为“Claude Code 完全可以实现”，个体能力上限被彻底掀开。
- [31:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1906s) 捕获潜在需求（Latent Demand）的产品孵化法：Cowork 正是在发现大量非工程师用户费力使用命令行工具 Claude Code 整理杂务与文档的“非常规用法”后顺势孵化而成。
- [35:08](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2108s) 从同步指令到异步 AI Routines：下一代工作流由例程自动调度底层 Agent 舰队，自主完成夜间巡检与 PR 生成，人类只需集中精力在日历锁定的专注时间进行最终审查。
- [38:06](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2286s) 极致自主性（Agency）必须匹配高担当（Accountability）：团队鼓励员工自由探索解法（Freedom to cook），但每个人必须对其背后的假设及最终交付结果承担完全责任。
- [39:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2380s) 效能度量告别“伪进度”：切忌把忙碌的动作误当成实质的进展，监控 Token 消耗或代码行数毫无意义，团队应以解决核心业务成效（Outcome）为唯一度量标尺。
- [44:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2664s) “Bad vs. Sad”质量治理框架：将不可恢复的致命崩溃（Bad）与可恢复但易累积恶化的体验瑕疵（Sad）分级，并赋予各业务团队自主定义质量阈值的权限。
- [49:34](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2974s) 所有管理者必须从 IC（一线独立贡献者）做起：管理者通过亲自提交 PR 和高频使用自家产品（Dogfooding），才能保持对产品细节的敏感度，并在工程师群体中建立深度信任。
- [55:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3324s) 对抗技能萎缩的“双击展开”原则：即使 AI 代劳了语法细节，工程师依然必须保持对依赖项底层架构机制的穿透力（向下钻取到第 8 层），确保掌握系统的因果链与边界。
- [56:35](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3395s) 应对 AI 开发中的孤岛感与上下文风暴：并发运行数十个 Agent 导致人类大脑上下文切换负荷倍增，团队通过“结对编程午餐”与“并行游戏”恢复工程师之间的协同与技术互通。
- [01:00:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3603s) 职能边界消融与全员构建者化：产品经理借助 AI 能够直接提交代码上线功能，工程师通过接入实时数据对话内化产品感，传统职能壁垒正在被端到端自主交付取代。
- [01:16:23](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4583s) 重新审视失败的自动化尝试：由于底层大模型能力呈指数级跃升，过去在旧版本上跑不通或效果低劣的自动化任务，应在新模型发布后立即重新验证，切忌过早放弃。
- [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) 从六个月路线图转向 JIT（即时）月度规划：AI 时代的快速迭代使得中长期规划迅速失效，团队果断杀死过时流程，改用极简表格对齐当月优先级并每周快速确认。
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=0s) 序幕：编码不再是瓶颈，软件工程进入全新范式
在节目的开篇片段中，Anthropic 披露了一组惊人的数据：如今 Anthropic 工程师平均每个季度交付的代码量，已经是 2021 至 2025 年间平均水平的 8 倍。"编写代码已不再是整个流程的瓶颈，每个人能力的上限被彻底掀开了。"理论上任何想法现在都变得触手可及，真正的挑战变成了：你的野心究竟能有多大？在团队内部，大家反复自问的一个核心问题是："有什么事情是让 AI 做比让我自己做更好的？"
这种剧变对工程师的特质提出了全新要求——那些表现最出众的人，往往具备最强的自主性（agency）和主动出击的能力。但高自主性必须与高责任感（accountability）相辅相成：工程师拥有随意写代码的极致自由，但必须对交付物负责，明确回答"你试图验证的假设究竟是什么"。与此同时，这种全 AI 驱动的开发模式也带来了新的隐忧：当每个人都在高度沉浸地与自己的 AI Agent 单打独斗时，工程协作容易演变成一种孤立的体验。为了对抗这种疏离感，Claude Code 团队近期甚至恢复了结对编程午餐会（pairwise programming lunch）。面对开发者群体中日益分化的态度——有人全面拥抱 AI 创造奇迹，有人则深感挫败、抗拒甚至恐惧——Fiona 强调，消除恐惧唯一的办法就是直面它，专注于自身可控的事情。
---
### [01:05](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=65s) 嘉宾介绍：从基础工具到百亿美金产品的技术掌舵者
主持人 Lenny 隆重介绍了本期嘉宾 Fiona Fung。Fiona 目前在 Anthropic 领导 Claude Code 与 Cowork 团队，统管包括 Boris Cherny 和 Kat Wu 在内的整个工程与产品团队（这两位此前也是 Lenny 播客历史上收听量排名前十的重磅嘉宾）。在加入 Anthropic 之前，Fiona 拥有超过 25 年的深厚工程领导经历：在微软工作了 11 年，负责构建 Visual Studio 和 TypeScript 核心团队；随后加入 Meta，从零孵化并创立了 Facebook Marketplace，该业务如今每年产生超过 1000 亿美元的 GMV；她还曾主导 Meta 首款智能眼镜项目，并参与打造了 Orion AR 眼镜；之后在 Instagram 统领基础设施、增长、平台完整性与安全团队，管理规模超 500 人的工程组织。
作为横跨多个计算时代的老牌技术领袖，Fiona 拥有极其敏锐的视角，能够洞察技术工具演进的真正方向以及工程团队在 AI 浪潮下必须进行的底层重塑。
```mermaid
flowchart TD
accTitle: Fiona Fung 职业生涯关键节点演进
accDescr: 展示 Fiona 从 IBM、微软、Meta 到 Anthropic 的技术与产品发展路径
subgraph Early["早期基建与开发者工具"]
A["IBM DB2 底层系统"] --> B["微软 Visual Studio 核心编辑器"]
B --> C["TypeScript 开发与工程管理"]
end
subgraph Scale["超大规模消费级平台与硬件"]
D["Facebook Marketplace 从0到1 ($100B+ GMV)"] --> E["Meta 智能眼镜 & Orion AR 硬件"]
E --> F["Instagram 基础设施/增长/安全团队 (500+人)"]
end
subgraph Frontier["AI 原生开发时代"]
G["Anthropic Claude Code & Cowork 团队负责人"]
end
Early --> Scale --> Frontier
```
---
### [02:38](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=158s) 回望 25 年工程路：从 Vim、底层系统到互联网泡沫破裂
Lenny 谈及近期在 Anthropic 举办的 "Code with Claude" 活动上听完 Fiona 的分享后备受震撼，甚至开玩笑说翻看她的领英发现她最早竟是从 IBM 起步，如今的行业环境与当年已不可同日而语。就在不久之前，软件行业 100% 的代码还是由人类逐行敲出的，而现在正如 Boris Cherny 所言，“编码问题已被基本解决”，代码正在逐步走向 100% 由 AI 生成，季度代码产出呈现出平稳多年后突然垂直升空的爆炸式曲线。
Fiona 动情地回顾了自己的技术起点。在 IBM 实习时，她在 DB2 操作系统服务团队工作。当时作为年轻工程师的执念是"越往技术栈底层钻、越靠近 OS，技术才越硬核，能学到的东西也越多"。那时候的开发环境极其质朴，主要依赖终端（Terminal）和 Vim，即使有 Eclipse 授权大家也基本不用，调试完全靠命令行终端打转。2000 年正值互联网泡沫（dot-com bubble）破灭，大量科技公司冻结招聘，能拿到微软的实习和全职 Offer 对她而言是无比幸运的事。
- **时代反差**：2000 年初的工程毕业生面临大规模招聘冻结，底层系统开发普遍依赖 Vim 和终端调试，现代意义上的 IDE 尚未普及到每个校园。
---
### [04:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=286s) 走入 Visual Studio：从误认成画图软件到痴迷“吃自家狗粮”
刚进微软时，团队分配完全由公司指定，Fiona 被分配到了 Visual Studio 团队。她坦言自己当时由于来自 Unix 背景的学校，甚至完全不知道 Visual Studio 是什么，还天真地问经理："看这名字，它是不是一款更高级的画图（Paint）软件？"把经理听得目瞪口呆。然而，这个误打误撞的分配最终演变成她职业生涯前 11 年最挚爱的事业。
那也是 Fiona 第一次真正接触现代 IDE。第一次看到图形化调试器、可以自由设置断点、支持多线程调试时，她感受到了震撼的阶跃式生产力提升。更重要的是，她所在的是 Visual Studio Editor 团队——他们直接使用自己正在开发的 VS 编辑器来构建 VS 编辑器本身。这种深度的"吃自家狗粮"（dogfooding）体验塑造了她日后的核心产品哲学：首先为自己和队友打造令人愉悦的极致体验。在那个没有 Twitter 等社交媒体的年代，工程师无法像今天这样瞬间获得海量真实用户的实时反馈，团队内部互为极端挑剔的重度用户，成为了推动产品飞速迭代的最强动力。
---
### [08:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=480s) 从光盘刻录到在线分发：稀缺资源的演进逻辑
Fiona 进一步指出，在早期的软件工程体系中，交付媒介对研发节奏有着决定性的硬约束。当时他们交付 Visual Studio 必须刻录在实体 CD-ROM 光盘上，然后送去工厂压盘、包装上架销售。这意味着项目截止日期是绝对不可逾越的硬指标，一旦错过工厂生产排期，后果不堪设想。
直到软件分发全面转向网络在线下载与云端推送，工程交付的约束条件才发生根本性松动。回溯这段历史，Fiona 总结道：曾经在极其漫长的一段时期里，"工程师的人力时间"是整个科技行业中最昂贵、最稀缺的瓶颈资源。而如今随着 AI 的介入，这一长期存在的前提假设正在被彻底颠覆。
### [08:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=526s) 软件工程瓶颈的转移：从写代码到代码验证
回想过去的软件开发时代，工程师面临的是极其严苛的实体交付节点，比如将软件刻录在光盘（CD）上进行压盘发售。在那个年代，前期的规划必须极其详尽，因为所有人都想确保在固定且无法回退的时间窗口内做出最周全的安排。然而，随着 Claude Code 与 Cowork 等工具的普及，整个范式发生了根本性转移——写代码（coding）已经不再是研发链路上的瓶颈。
在 Anthropic 的团队中，角色之间的传统界限正在被彻底打破。如今不仅是软件工程师，设计师、产品经理（PM）以及团队里的每一个人，都在向代码仓库提交代码（check in code）。这种剧变带来了两个前所未有的维度的冲击：一方面是提交代码的人群变得更多元、跨越不同职能；另一方面是整体的代码吞吐量极其惊人（Anthropic 工程师每个季度交付的代码量达到了以往的 8 倍）。当产出呈现 8 倍爆发时，真正的核心瓶颈全面转移到了“验证”（verification）——如何确保这 8 倍海量代码的质量、可靠性与可用性，成为了现代软件工程最核心的命题。
```mermaid
flowchart LR
accTitle: Bottleneck Shift in Software Engineering
accDescr: 软件工程瓶颈从传统的规划与写代码转移到了现代的验证与质量把控环节。
subgraph Traditional ["传统开发模式 (如光盘压盘时代)"]
A["严格实体交付期"] --> B["繁重的前期规划"]
B --> C["编码实现 (核心瓶颈)"]
end
subgraph Modern ["AI 原生开发模式 (2026年)"]
D["全员构建 (工程师/PM/设计师)"] --> E["高吞吐自动化写代码"]
E --> F["结果验证与质量把关 (新瓶颈)"]
end
```
---
### [10:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=603s) 2026 年的 AI 团队：全员“构建者”与基于 Claude 的管理新范式
在探讨 2026 年一支被“AI 彻底改造”（AI-pilled）的团队到底如何运作时，Fiona 指出，各岗位职能界限正在模糊，所有人正在统一向“构建者”（builder）这一角色演进。面对海量的产出，传统的工程管理方式早已失效，为此 Fiona 设计了一套全新的管理流程：她在云端常驻一个 Claude Code Remote 会话，该实例挂载并同步了团队所有的代码仓库，同时拥有访问团队内部所有 Slack 频道以及各项业务追踪指标的权限。
借由这个系统，Fiona 拥有了全盘的可见度。每月做复盘时，她不再要求员工写枯燥的项目汇报，而是直接共享屏幕，与下属一起在 Claude Code 会话中进行动态回顾：
- 梳理过去一段时间团队的核心聚焦点；
- 盘点上线了哪些功能和产品，其实际表现和核心指标如何；
- 聚合查看各个反馈渠道的用户声音与故障复盘。
过去这些会话主要用来自动生成 PR 或修复 Bug，而现在它变成了管理者与团队成员深入探讨业务影响力的强大载体。这不仅仅是关注“交付了什么”，更是探讨“投放市场后反响如何”以及“是否引入了新问题”。Fiona 提出了一条管理座右铭：“去犯新错误（Make new mistakes）。”只要团队持续保持学习与迭代，犯错是完全可接受的；如果一个人追求零失误，那往往意味着他行动太慢或过于保守。借助 Claude 跨代码、Slack 讨论和故障事故（incidents）进行全局聚合，管理者能够精准提炼出共性主题，迅速发现质量短板并确定未来的重点投资领域。这在过去完全依赖人工梳理的年代是无法想象的。
---
### [12:26](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=746s) 自动化反馈聚合与 Claude Routines 的晨间仪式
面对 8 倍的代码与产品交付速率，管理者的另一个巨大挑战是追踪来自四面八方的用户反馈。过去，Fiona 的晨间固定习惯是端上一杯咖啡，手动刷各个反馈渠道，寻找自己能利用“专注创造时间”（maker time）帮忙解决的缝隙或问题。
但随着团队推出了“Claude Routines”（例行任务），这一工作流被彻底颠覆：
- **全渠道信号归拢**：反馈来源极其分散，包括公司内部反馈、官方支持邮箱、合作伙伴沟通渠道，以及团队成员在 Twitter/X、LinkedIn 和社交媒体上收到的朋友或外部用户私信。团队内部会将这些零散反馈统一转发生态至 Slack。
- **定时后台代劳**：通过 Routines，Claude 会在夜间或清晨定时巡检所有反馈渠道，自动提炼出高频问题和核心主题。
- **从发现到修复闭环**：在早晨 Fiona 醒来时，桌面上不仅摆着一份清晰的反馈摘要，Claude 甚至已经针对部分问题自动生成了可以直接审查合并的 Pull Request（PR）。从过去的“发现问题并指派某人去修”，进化为了“AI 直接把修好的 PR 放在眼前供人类把关”。
---
### [14:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=880s) 代码审查的进化：将“优秀标准”代码化与 TDD 的复兴
在过去，人工代码审查（human code review）是团队研发最大的单点阻塞瓶颈。随着代码产出爆发，团队必须重构审查体系：对于需要深度专业知识（deep subject matter expertise）的核心系统，依然保留资深人类工程师的把关；但对于其余大量代码，则依赖 Claude Code 进行自动化审查。
为了让 AI 审查发挥最大效能，Fiona 团队摸索出了一套核心机制：**将“何为优秀”的框架（framework for what good looks like）直接检入代码仓库**。
- **规范即代码**：无论是内容设计规范、交互层级规范还是系统 Spec，都必须以文件形式存放在仓库中，并且与代码保持同步更新。
- **依据框架对齐**：只要人类清晰定义出评估维度与标准，Claude 就能极其敏锐地以该框架为基准去校验提交的代码是否偏离预期。
这一逻辑被 Lenny 形容为“测试驱动开发（TDD）的终极演进”。Fiona 笑着回忆，在 2000 年代 TDD 理念极为流行，强调“先写失败的测试，再写业务代码实现”，但实际操作中工程师普遍感到痛苦，这就像“被逼着先吃西兰花”，因为大家都渴望享受直接做产品和发布交付的兴奋感。而现在，这一开发范式发生了逆转：Fiona 在 Claude Code 上修复第一个 Bug 时，就是直接指示 Claude“帮我按照 TDD 原则先写一个测试，确保该测试运行失败，然后再编写修复代码让测试通过”。过去像沉重税务一样的测试编写工作如今被模型全额代劳，使得那些经典且优良的工程原则在 AI 时代不仅不会过时，反而以极高的人效重新焕发活力。
### [17:02](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1022s) AI 时代的两类核心人才画像：产品构想者与深层系统专家
当谈到团队的招聘策略时，Lenny 引用了 Fiona 之前提出的一项关键洞察：在由 AI 主导的软件开发时代，她最看重的两类人才分别是“具备敏锐产品直觉的创意构建者（creative builders with product sense）”以及“攻克硬核技术难题的深层系统专家（deep systems experts for the hard parts）”。
Fiona 对此表示高度赞同，并回忆了自己最初加入 Claude Code 团队时的经历。刚加入时，团队内部全都是非常出色的通用型产品人才（product generalists），但很快她就意识到团队缺少扎实的系统底层背景。因此，他们迅速在系统架构和分布式系统领域补充了具有深厚背景的专业专家。Fiona 指出，即便模型能力再强大，软件工程的核心原则依然是“信任但要验证（trust but verify）”。大模型虽然表现优异，但仍有大量复杂边界需要严格验证，因而在那些需要极其深厚的领域专业知识（subject matter expertise）的硬核场景下，资深系统工程师依然是不可或缺的基石。
与系统专家形成互补的则是拥有极强产品直觉的“造梦者”。这类人对打造产品抱有近乎狂热的激情，一旦产生想法就会亲自动手实现，并不断审视用户反馈，反复打磨和优化细节，以确保交付出令人惊艳的绝佳体验。这种全流程端到端（end-to-end）的产品所有权意识，在 Claude Code 的建设中发挥了至关重要的作用。
```mermaid
flowchart TD
accTitle: AI-Native Team Talent Profiles
accDescr: Two key engineering profiles required in the AI era: Creative Builders with product sense and Deep Systems Experts for verification.
subgraph Product["产品创新侧：创意构建者 (Creative Builders)"]
A["产品直觉与狂热激情<br/>(Dreamers / Product Sense)"] --> B["端到端全流程实现<br/>(End-to-End Ownership)"]
B --> C["持续打磨极致体验<br/>(Feedback & Polishing)"]
end
subgraph Systems["底层工程侧：系统专家 (Deep Systems Experts)"]
D["分布式系统与架构底层<br/>(Distributed Systems)"] --> E["信任但需验证<br/>(Trust but Verify)"]
E --> F["攻克底层硬核难题<br/>(Subject Matter Hard Parts)"]
end
Product <--> |"模型放大野心 + 专家护航边界"| Systems
```
---
### [18:19](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1099s) 工程师的思维蜕变：从技术阻碍到“野心驱动”
Lenny 敏锐地抓住了讨论中折射出的一个核心词汇——“野心（ambition）”。他提到最近与一位顶级 10X 工程师的交流，那位工程师坦言，过去每当有人提出一个新功能构想时，他的第一反应通常是防御性的：“别搞了，这太难太复杂了。”然而现在他的思维发生了翻天覆地的转变，第一反应变成了：“不，这完全行得通，我直接让 Claude Code 去做就行了。”当技术的实现成本被大模型骤降后，约束一个人的不再是那些琐碎的实现障碍，而是你敢不敢想得足够宏大。
Fiona 随即分享了一个前一天刚发生的鲜活案例：团队里有一名并非移动端出身的工程师，但当时某个功能急需支持移动端界面。如果是放在过去，工程师多半会望而却步，认为自己不是 Android 专家而无法接手；但如今在 Claude 的协作配合下，这位工程师直接把 Claude 当作搭档，顺利在移动端完成了功能落地。AI 实际上彻底拔高了每一个个体能力的上限（lifted the ceiling），让原本跨技术栈的壁垒变得不复存在。
---
### [19:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1180s) 成长型心态与直面恐惧：从加拿大银行柜员到技术领导者
面对软件工程行业如此激进的范式转移，Lenny 提出疑问：为什么有些人能够迅速适应并大放异彩，而另一些人却充满挫败感、陷入抵触与焦虑？
Fiona 认为，决定性的分水岭在于是否拥有真正的“成长型心态（growth mindset）”。她坦言，自己也是在从微软（Microsoft）跨越到 Meta 的第一年，才真正切身体会到什么是成长型心态——那就是“永远保持学习（always be learning）”，并且清醒地认识到“过去成就你的经验，未来可能不再适用”。对于已经凭借某种特定技能取得成功的资深从业者来说，承认过去的方法不再奏效、必须推倒重来是极其令人恐慌的，但唯有带着好奇心持续拥抱未知，才能在新浪潮中立足。
对于行业内部蔓延的焦虑与挫败感，Fiona 剖析其深层根源往往是“恐惧（fear）”以及随之而来的“失控感”——人们往往误以为一切外部变化都是被动降临在自己头上的（happening to me）。她的破局策略是转变视角，追问：“这是否是为我提供的新契机（happening for you）？在我的掌控范围内，我究竟能采取什么行动？”
为了具象化这种行动力，Fiona 罕见地分享了自己少年时期的真实经历：
- **艺术初心与迟到的电脑启蒙**：高中时的她原本立志成为一名视觉艺术家，当时家用电脑十分昂贵，她家里根本没有电脑。直到高中九年级（Grade 9），学校开设了打字课（typing class），她才第一次真正摸到键盘，随后才在后续课程中接触到 HTML 编程。她发现编程和艺术一样，能将头脑中的故事和创意变为现实，于是拼命补齐理科课程，希望能考入大学工程系。
- **贫困焦虑下的破局行动**：身处加拿大安大略省的她面临巨大的未知——即便有安大略省学生资助计划（OSAP），她也完全不知道能否覆盖学费和生活费。面对上不起大学的巨大恐惧，她决定寻找自己能掌控的事情。碰巧加拿大国家银行（National Bank of Canada）在学校张贴了招聘高中实习生做银行柜员的传单，尽管她高中最讨厌的科目就是会计，且薪资仅为最低工资，她依然毫不犹豫地报名上岗。
- **化被动为主动的人生浮木**：这份柜员工作成了拯救她学业的生命线。她在暑假全职工作攒钱，进入大学后周一到周五上课，周六继续去银行当柜员。甚至在 2000 年互联网泡沫破裂（Dot-com crash）、实习岗位极度匮乏的两年里，她依然靠着周末做银行柜员维持生计，独立赚取了全部学费。
Fiona 强调，每当面临未知的恐惧时，最关键的就是找到那一个“自己能够掌控的最小行动”。她引用了自己最喜欢的两句人生信条：
- “如果你不害怕，你会怎么做？（What would you do if you're not afraid?）”
- “偶尔去做一些令你害怕的事情（Do something scary once in a while）。”
Lenny 对此深感共鸣，并补充了他在播客中最常引用的约瑟夫·坎贝尔（Joseph Campbell）名言：“你害怕进入的洞穴，往往藏着你所追寻的宝藏（The cave you fear contains the treasure you seek）。”Fiona 笑着表示一定要把这句话据为己有。正是在能力处于巅峰与熟练的高原期时，勇敢地迈出舒适区、去挑战那些令人不安的新技术与未知领域，才能在经历短暂的学习低谷后，实现认知与能力的真正跃迁。
### [25:50](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1550s) 弥合 AI 鸿沟：从童年毛线店记忆到赋能小微企业
随着人工智能浪潮席卷各行各业，社会上正迅速形成一条触目惊心的鸿沟：一端是全面拥抱 AI（AI-pilled）、生产力大幅跃升的从业者；另一端则是对新技术感到疏离甚至恐惧、面临被时代抛下风险的普通人群。针对这一分化，Fiona 分享了自己为何如此热衷于帮助小微企业主接纳 AI，而这份初衷深植于她的童年记忆。
Fiona 出生于中国香港，幼年随家人移民加拿大。当时她一句英语都不会说，父母整日忙于生计，照顾她的重担落在了外婆身上。在语言不通且缺乏步行友好街区的异国他乡，外婆感到极度孤独与隔阂。直到某个夏天，祖孙俩偶然走入一家由讲粤语的女士经营的毛线小店。在那里，外婆找到了属于自己的编织圈子并重获归属感，Fiona 也在店里学会了花结编织（macrame）——她笑称这项手艺现在似乎正在掀起复古潮流。这段经历让她深深体会到，街角看似微不足道的小生意，往往维系着一个社区最珍贵的人情味与联结感。
---
### [27:52](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1672s) 用 Cowork 帮餐厅老板清空“垃圾抽屉”：真实场景下的微观实验
进入 AI 领域后，Fiona 发现自己最讨厌的工作环节就是整理差旅发票和报销。当她在日常中使用 Anthropic 内部开发的 Cowork 处理财务报销时，那种如同魔法般顺畅的体验触动了她：既然连自己都对杂务不胜其烦，那些披星戴月、在微薄利润边缘苦苦支撑的小企业主更需要这样的解放。许多餐厅老板在打烊后只能坐在吧台前，对着堆积如山的账单与收据一张张手动核对、录入。
Fiona 随即拉来经营小生意的朋友进行产品试用，不仅在极具冲击力的真实流程中挖出了不少界面漏洞，更目睹了小微企业主意想不到的创造性用法：
- **清理文件“垃圾抽屉”**：一位经营两家餐厅的朋友把电脑里的“下载”和“文档”文件夹变成了塞满各类杂物的“垃圾抽屉”，急需调出几份旧菜单却根本翻找不到。Fiona 协助她授权 Cowork 读取该目录，系统瞬间精准定位并提取出了遗失的菜单。
- **动态竞品价格对标**：找到菜单后，该餐厅老板直接向 Claude 提出业务需求：“我想确保菜品定价对本地常客和外来游客都保持合理。请结合本区域内同菜系餐厅的定价体系，分析我的价格是否具备竞争力。”模型随即输出了一份详尽的市场横向对比分析，甚至精准列举出老板不久前亲自去西雅图探访过的一家优质同类餐厅。
```mermaid
flowchart LR
accTitle: 小微企业使用 Cowork 优化运营流程
accDescr: 展示从杂乱无章的本地非结构化数据到 Claude 自动整理并产出高阶商业洞察的过程
subgraph Input["痛点输入"]
A["凌乱文件堆<br/>(下载/发票/散落菜单)"]
end
subgraph Processing["Cowork 本地读取与解析"]
B["授权访问目录"] --> C["秒级定位关键文件"]
end
subgraph Output["业务赋能与决策"]
D["自动化账单处理"]
E["周边同业定价横向比对"]
end
A --> B
C --> D
C --> E
```
---
### [29:48](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1788s) 如何向怀疑者普及 AI：从生活痛点切入与去神秘化交流
面对社会大众中普遍存在的“我没时间研究”或“我讨厌 AI”等抵触情绪，Lenny 与 Fiona 探讨了如何真正有效地降低普通人接触新技术的门槛。Fiona 强调，推广 AI 绝不能靠空洞的说教或技术炫耀，而应当从身边亲友最切身、最痛苦的琐事切入，用一次微小但真切的“减负”作为破冰抓手。
“知识就是力量。我们必须学会驾驭工具，让它成为光明与黑暗博弈中照亮生活的那束光。”Fiona 坦言，起初向非技术圈的朋友开口并不容易，她甚至有些笨拙地试探：“我其实是做 AI 的，要不要我给你看看 Cowork 到底能干些什么？”但一旦切入实际痛点，原本枯燥的技术演示就会变成充满乐趣的解题过程。Lenny 亦深有同感地补充道，他此前在 Twitter 上分享自己用 Cowork 自动填妥儿子的夏令营报名表格时，大量读者惊叹“完全没想到 AI 还能这么用”。具象化场景的口碑传播，正是瓦解公众抵触情绪、防止技术鸿沟无限扩大的关键钥匙。
---
### [31:46](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1906s) 敏锐捕捉“潜在需求”：Anthropic 持续领先的内省与演进逻辑
Lenny 指出，Anthropic 在行业演进中屡次精准预判了爆发性风口：早早在代码生成（Coding）上建立统治级壁垒、先人一步切入全面知识工作（Knowledge Work）以及对模型“人格气质（Personality）”的深度打磨。他询问 Fiona，Anthropic 究竟依靠怎样的组织机制与文化，才能在其他实验室反应过来之前发掘并重注这些全新机遇。
Fiona 揭示了背后的核心方法论——持续追踪“潜在需求（latent demand）”：
- **自食其果（Dogfooding）的内部放大效应**：Anthropic 内部员工（被称为“ants”）是自身产品的首批重度用户，不仅反馈周期极短，且能在高强度的日常使用中自然筛选出真正的刚需。
- **观察越界行为孵化新产品**：Cowork 的诞生正是因为团队敏锐地捕捉到底层数据异动——大量完全不懂代码的用户，竟然在想方设法用专为程序员打造的终端工具 Claude Code 来管理杂项事务与本地文档。团队顺应这一非典型行为，顺水推舟将其提炼为专为知识工作者打造的全新产品体系。
- **从个案洞察到标准能力产品化**：在 Fiona 与团队深入小微企业实地调研时，用户频繁询问“是否支持某种特定插件”，迫使他们不得不频繁跳转配置。团队迅速收敛需求，推出了集纳各种通用业务能力的一键式解决方案“Claude for Small Business”，直接在 Cowork 中以极简开关形式交付，极大抹平了技术落地的认知门槛。
### [34:17](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2057s) 发现潜在需求：观察用户的“非常规用法”
在软件开发中，用户往往会以开发者始料未及的方式使用产品。Fiona Fung 指出，无论这种意外用法带来的是好是坏，团队最核心的任务就是紧跟用户反馈、快速迭代并持续学习。Lenny 提到，“潜在需求”（latent demand）是播客中经常探讨的概念，其本质正是密切关注那些最初未曾预料、但正在自发涌现的用户行为，进而果断下注、深入探索并围绕它构建专门的产品。
Fiona 强调，团队需要建立明确的假设：当你看到用户为了实现某个目的而不惜“上蹿下跳”（jumping through hoops）、克服层层阻碍时，这就意味着巨大的产品机会。与其让用户费力摸索临时替代方案，不如顺应这种需求，为他们打造一个更加顺畅、体验更佳的原生产品流程。
```mermaid
flowchart LR
accTitle: 捕捉潜在需求的产品迭代循环
accDescr: 展示从观察用户意外行为、提出假设到交付顺畅体验的产品迭代闭环
subgraph Discovery["需求捕捉"]
A["观察非预期行为<br/>(用户费力绕道使用)"]
B["提炼潜在需求<br/>(Latent Demand)"]
end
subgraph Iteration["验证与构建"]
C["建立解决方案假设"]
D["打造顺滑原生体验<br/>与快速迭代"]
end
A --> B
B --> C
C --> D
D -.->|"持续获取反馈"| A
```
### [35:08](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2108s) 研发前沿：从同步 Prompt 到异步 AI “例程” (Routines)
谈及软件工程的下一个前沿阵地以及工程师工作方式的演变，Fiona 认为行业正加速向**异步工作模式（asynchronous work）**演进。过去，工程师使用 AI 的方式主要是同步交互：输入一条 Prompt，等待响应；后来逐步发展为并发启动多个不同的 Prompt。而现在，随着抽象层级的不断提升，全新的范式是编写**例程（Routines）**——由例程自动为工程师生成 Prompt 并调度底层 Agent 舰队。
Fiona 详细分享了自己在管理中如何运用 Routines。过去，她习惯清晨喝着咖啡，手动给 AI 发指令去爬梳 Slack 频道；现在，她直接设定了一个每天固定时间自动触发的例程：
* **自动化巡检与任务拆解**：例程在后台自动调取用户反馈或监控频道，识别出其中暴露的 bug 与体验问题。
* **主动生成修复 PR**：例程不仅分析问题，还会自主唤起（spawn）多个下游 Agent 去尝试完成代码打磨与修复。
* **从决策者到审批者**：工程师或管理者一觉醒来，面对的不再是杂乱无章的未读信息和待办思考，而是已经可以直接审查（review）的代码拉取请求（PR）。
* **自主权递增**：只要下游的自动化验证（verification）足够可靠、测试覆盖足够健全，团队甚至可以放手赋予 Agent 更高的自主执行权限，让它们直接合并发布代码。
这种由例程代理人类日常流程的机制，将工程师从“思考接下来该调遣哪个 Agent”的繁琐操作中解放出来，跃升到了更高的抽象维度。
### [38:06](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2286s) 工程师文化：高自主性（Agency）必须配对高担当（Accountability）
Lenny 谈到经济学家 Tyler Cowen 在其讲座中强调的观点：在当下 AI 浪潮中表现最出色的人，往往具有极强的主动性（initiative）与能动性/自主性（agency）。Fiona 极其认同这一特质，并透露在 Claude Code 与 Cowork 团队中，“自主性”（agency）正是大家最看重的品质。
不过，Fiona 强调自主性必须与**高担当（high accountability）**一体两面地存在：
* **充分的探索自由（Freedom to cook）**：团队鼓励每个人对系统痛点提出自己的解法，拥有全权施展拳脚的自由空间。
* **坚守假设与结果负责**：放权并不等于放任，每个人必须明确自己的核心假设是什么、正在解决什么本质问题，并对交付的最终业务与技术结果承担完全责任。这种“高自主性 + 高担当”的双轮驱动，构成了 Anthropic 敏捷研发文化的基石。
### [39:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2380s) 生产力度量反思：告别“Token 狂欢”，回归真实业务成效
近期业界心态发生了一场微妙的转向（vibe shift）——从此前不计成本拼命消耗 Token 的“Token 狂欢（token maxing）”，转向严肃审视投资回报率（ROI）：这些 AI 投入究竟带来了什么实际产出？成本几何？曾任 Meta 研发生产力产品负责人的 Boris Cherny，也一直在探讨这一行业难题。Lenny 问及：虽然 Anthropic 内部拥有用不完的免费 Token 优势，但管理团队该如何衡量当今工程师的真实生产力与 ROI？
Fiona 回顾了研发度量指标在业界的演变路径：
1. **代码行数（Lines of Code）**：最原始的吞吐量度量，但极易被粉饰，比如工程师仅仅引入一个第三方库并将其提交入库，代码行数就会瞬间暴增。
2. **有效代码行数（Significant Lines of Code）**：试图剔除无用代码，但当团队升级了现代开发框架后，生成的代码量反而变少，产出价值却保持不变甚至更高。
3. **PR 合并时长（Time to Land PR）**：虽然关注了流程效率，但依然停留在动作层面。
针对这些局限，Fiona 提出了核心建议与洞察：
* **警惕“伪进度”**：切勿“把忙碌的动作误当成实质的进展”（"Don't forsake motion for progress"）。仅追踪 Token 消耗量或工具使用率，衡量的只是动作本身，而非业务结果。
* **输出（Output）服务于成效（Outcome）**：必须把视野拉远，审视所做的代码输出是否真正契合要解决的问题和核心目标。
* **开展深度倾听之旅（Listening Tour）**：在单纯依赖监控看板之外，领导者应当走进团队开展面对面交流，尤其要重点倾听资深工程师（Senior Engineers）的反馈。了解哪些工具真正顺手、哪些环节存在阻塞。资深工程师不仅能带来灵感碰撞，更能在整个工程组织中起到倍增与规模化推广的最佳实践效果。
* **随时警惕指标失效**：即使确立了一个便于做“爬山算法”（hill climb）优化评估的量化指标，也必须始终保持成长型思维，动态检验该指标是否依然在忠实地服务于最初设立的业务愿景。
### [42:54](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2574s) 警惕盲目指标：从 Facebook Marketplace 悟出的动态调整法则
聊到衡量产出时，Fiona 分享了早期在 Meta 搭建 Facebook Marketplace 的关键经历。当时团队采取按区域逐步铺开的策略，核心目标是在扩张前确保产品体验足够让人惊艳。在首个区域上线初期，团队死盯着的核心指标之一是“卖家数量”（number of sellers）。然而上线后他们惊讶地发现，该区域的卖家总数非常低，但买家却能极其顺畅地找到自己想要的商品——这恰恰达成了产品的根本诉求。经过深入调查，团队才意识到虽然卖家数量少，但当地出现了一批极具活力的“超级卖家”（power sellers）。
如果团队死板地把卖家数量作为继续扩张的硬性门槛，很可能会做出错误的战略判断。这件事深刻印证了一条规律：用户使用产品的方式往往会超出你的预期，团队必须“小步快跑、持续迭代并从中学习”（ship, iterate, learn）。因此，不论是衡量研发效能还是产品表现，都不能戴着有色眼镜盲目坚守过去的陈旧指标。外部环境与用户行为变化极快，衡量成功的标尺本身也需要动态校准。Lenny 对此呼应道，这正切合 Fiona 之前提到的管理方式——让 Claude 追踪工程师的 PR 提交，但关注点从不是冰冷的数字，而是以此为引子，去深聊 PR 带来的实际业务影响或潜在 Bug。
---
### [44:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2664s) 质与量的平衡：“Bad vs. Sad” 质量评估框架
当代码生成速度呈爆发式增长时，如何在海量 PR 涌入的情况下守住质量底线？Fiona 强调，团队的核心策略是转向“前置主动质量控制”（proactive quality），尽早捕捉隐患，并在此基础上建立了一套高维的“Bad vs. Sad”（严重错误与体验瑕疵）评估框架。在跨多端、多业务面的产品中，如果只看单调的性能仪表盘（如页面加载时长），很难判断一个具体数值对全局体验究竟好不好，而这套框架化繁为简：
```mermaid
flowchart TD
accTitle: Bad vs. Sad 质量分级与升级路径
accDescr: 展现不可恢复的严重故障与可恢复痛点之间的层级关系及叠加效应
subgraph EvaluationFramework ["质量分级框架"]
B["严重错误（Bad）<br/>• 不可逆/致命故障<br/>• 例：CLI 崩溃、用户丢失进度"]
S["体验瑕疵（Sad）<br/>• 可恢复的不顺畅体验<br/>• 例：界面闪烁、轻微卡顿"]
end
subgraph Impact ["影响与处置机制"]
S -->|"瑕疵不断累积<br/>叠加质变"| B
Team["赋予业务团队高度自主权<br/>（Agency）"] -->|"自主定义该业务面的<br/>Bad 与 Sad 阈值"| EvaluationFramework
end
```
- **严重错误（Bad）**：指毁灭性、不可恢复的致命故障。例如在 Claude Code 的命令行终端（CLI）中发生崩溃，直接导致用户丢失上下文和未保存的工作进度。
- **体验瑕疵（Sad）**：指用户体验上的痛点，虽然令人不适但可以自行恢复，例如界面发生偶尔的闪烁或短暂停顿。
- **自主权与累积效应**：Fiona 提醒道，“当 Sad 体验不断堆叠时，就会彻底恶化成 Bad”。Anthropic 赋予各个子业务团队极大的自主权（agency），由各团队根据自身模块的特性，自主定义什么算 Bad、什么算 Sad，并设定对应的治理目标。
---
### [47:06](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2826s) 闭环测试与另类监控：从自动评测到“脏话监控大盘”
面对指数级增长的代码吞吐量，传统的“堆人力肉眼审查 PR”模式已经彻底失效。Lenny 总结道，控制质量的关键抓手必须从人工代码审查转向自动化监控、系统测试与 Evals（模型评测体系）。这不仅极大地减轻了工程负担，更重要的是为 AI Agent 构建了质量自愈的“闭环”——只要给 Agent 明确定义成功的测试标准，它们自身就能侦测失败并自动修复。
除了正规评测外，团队还在感知真实用户情绪上动了许多巧思。Lenny 笑着提到 Anthropic 内部流传的一个公开趣闻：团队设立了一个专门监控“脏话”（swear words / F-words）频率的大盘。Fiona 笑着证实了这一细节，回忆起去年 9 月她刚入职不久时，团队在内部使用中遭遇了一些卡点，一位工程师突发奇想提出统计大家爆粗口的频率，她当即觉得这是个天才创意。Evals 固然重要，但捕捉用户何时产生挫败感、怎样让体验更加令人愉悦同样不可忽视，“脏话看板”便成了量化挫败感最直观有趣的风向标。
---
### [48:22](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2902s) 赞助商插播：Mercury 银行与智能对话助手 Command
Lenny 插入了本期播客的赞助商 Mercury。这是一家深受超过 30 万名创业者喜爱的金融科技平台，Lenny 本人已深度使用超过 6 年，从未动过更换银行的念头。他认为 Mercury 最大的不同在于它是由懂产品的人打造的，而非传统的银行家，开发团队不仅为其配备了 API、原生终端 CLI，甚至还提供了支持 AI 的 MCP（Model Context Protocol）服务器。近期 Mercury 全新推出了对话式金融操作界面“Command”，用户可以直接用自然语言查询财务状况、调动资金、分析现金流。例如 Lenny 当天直接询问“过去一年中我从某赞助商处获得了多少收入”，系统在 10 秒内便给出了准确答案。
---
### [49:34](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2974s) 为什么 Anthropic 的所有管理者都必须从 IC（独立贡献者）做起
谈及团队的管理创新，Lenny 提到了 Anthropic 非常特别的一项管理制度：**所有管理人员入职时必须先作为一线 IC（Individual Contributor，独立贡献者）写代码，此后也必须保持一部分时间作为“半个 IC”，采取类似“球员兼教练”（player-coach）的工作模式。**
Fiona 深入剖析了这项制度的由来：
- **快速变化的时代背景**：当前 AI 研发环境日新月异，昨天奏效的管理方法明天可能就过时了，每个人都必须保有强烈的成长心态（growth mindset）。
- **倾听一线反馈的启示**：她刚加入 Anthropic 与团队进行倾听之旅（listening tours）时，许多工程师反馈虽然很享受团队赋予的高自主权，但在优先级排序上常常需要把关；同时大家极力排斥大公司那种繁复冗长、层层审批的代码审查机制。
- **先入局、后带人**：带人管理（supporting people）是一份沉甸甸的严肃责任。如果让新管理者一上来就背负繁重的人事责任，他们就失去了深入探索代码库和熟悉产品的沉浸时间（maker time）。因此，先以 IC 身份深潜到代码与产品流程中，不仅能让管理者真正看懂底层逻辑，更能让自己持续保持在编码与交付的心流（flow）状态中。
### [51:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3084s) 管理者躬身入局：通过日常狗粮与代码提交建立信任
Fiona 强调，作为团队管理者，即便自己提交 Pull Request（PR）去修复代码，重点也早已不是具体修复了什么 Bug，而是强迫自己每天真正使用团队打造的产品——Claude Code 与 Cowork。很多管理者往往沉迷于漂亮的数据指标看板，但在 Fiona 看来，如果你作为技术管理者不能每天“呼吸”自己的产品，就会彻底失去对产品细微体验与质感的感知。当新经理加入团队时，给予他们充分的时间去深入代码和产品细节，而不是一上来就迫不及待地打开“管理者工具箱”、摆弄各种管理套路，往往能在工程师群体中建立起极佳的声誉与互信。
这种“亲自使用产品”的习惯贯穿了 Fiona 的整个职业生涯。无论是在 Meta 负责 VR、智能眼镜、AR 眼镜，还是在 Instagram 掌舵基础设施和增长团队，每当她刚加入一个新团队，工程师们最常给出的正面反馈几乎都是：“太难得了，看到你真的在每天高频使用我们做的东西，并且能给出真实的用户反馈，感觉特别耳目一新。”这种身体力行的狗粮实践（Dogfooding），正是技术领导者感知团队劳动成果最真实、最直接的桥梁。
- **狗粮实践（Dogfooding）的双重价值**：不仅能第一时间把控产品质量的真实体感，还能作为管理者了解一线工程痛点与技术流的窗口。
- **管理者入职的新范式**：先放下管理架子，花时间像普通工程师一样熟悉代码库与工作流，能极快破除与团队之间的隔阂。
---
### [52:50](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3170s) 从掌管500人团队到重回 IC：借助 Claude Code 找回写代码的底气
Lenny 提到一个许多人未曾料到的反差事实：Fiona 在加入 Anthropic 之前，在 Meta 统管着一支拥有大约 500 人的庞大工程团队，而来到 Anthropic 时，她几乎是以一线工程师（IC）的身份重新起步。Fiona 回忆说，自己在从微软跳槽至 Meta 时也是如此——虽然是以管理岗面试录用，但前几个月她坚决选择担任纯 IC，因为她此前在微软深耕 11 年，熟悉的是微软的代码库与工具链，她必须亲身经历作为一名 Meta 工程师如何交付代码。
来到 Anthropic 后，让 Fiona 最为惊艳和感慨的正是 Claude Code。她坦言，在 Meta 时上一次将生产级代码交付上线可能还要追溯到 2017 年；多年不写生产代码的管理者往往心存恐惧，害怕改动引发故障、缺少正确的自动化验证，或者因为不熟悉最新的工具流而浪费团队其他人的排查时间。然而加入 Anthropic 的第一周，当她原本习惯性地想找工程师们约咖啡做 1-on-1 时，突然意识到“等等，我可以直接去问 Claude”。Claude 成为了极其出色的“入职导师（Onboarding Buddy）”，不仅带她剖析整个代码库架构，还帮她设计覆盖各种极端情况的手动与自动化测试用例，迅速赋予了她重新向主分支提交 PR 的信心。如今，很多做了多年管理岗的工程老友纷纷向她发来感慨：“因为有了 Claude，我终于又能重新交付代码了！”
```mermaid
flowchart TD
accTitle: Claude Code 赋能技术管理者的入职与编码循环
accDescr: 展现管理者如何通过 Claude Code 消除不写代码的恐惧并建立工程信心。
subgraph Traditional["传统管理者模式"]
A["脱离工程多年<br/>产生破损与提错恐惧"] --> B["入职依赖约人喝咖啡<br/>碎片化了解架构"]
end
subgraph ClaudeEmpowerment["Claude 协作流"]
B --> C["充当 AI 入职导师<br/>随问随答代码库机理"]
C --> D["自动生成测试用例<br/>设计手工验证矩阵"]
end
subgraph Shipping["重塑工程师底气"]
D --> E["安全提交生产级 PR<br/>找回亲自构建的纯粹乐趣"]
E --> F["亲历产品全链路体验<br/>以真实用户身份指导方向"]
end
Traditional -.-> ClaudeEmpowerment
ClaudeEmpowerment --> Shipping
```
---
### [55:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3324s) 技能萎缩隐忧与“深入一层”的理解法则
面对 Lenny 提出的尖锐问题——工程师由于不再亲手敲打每一行代码，传统编码技能是否会发生萎缩？这到底算不算一个严重的问题？Fiona 直言团队内部也经常热烈讨论这一话题。早期如 Boris Cherny（Claude Code 掌门人）之所以能举重若轻，是因为初期的每一行底层代码都是他亲自手写的，他对整个系统的神经末梢了如指掌。对于后来新加入团队的工程师，Fiona 始终提醒他们：即使 AI 代劳了具体的语法和打字，依然要花足精力去吃透系统架构与设计变更，这就是所谓的“信任，但必须验证（Trust, but verify）”。
Fiona 提出了一个至关重要的工程元认知原则——**永远对你的依赖项保持“双击展开”（Double clicking on your dependencies）的深度**。抽象层之下永远在发生变化，如果工程师完全变成盲目点击运行的旁观者，一旦底层依赖演进或出现异常，你将完全无法察觉，更无法利用最新底层特性的红利。因此，即便语法层面的机械肌肉记忆不再重要，对系统因果链与深层架构的审视力反而是越来越稀缺的核心能力。
- **信任但验证**：AI 交付的产物不能当做不可解释的黑盒，工程师对关键逻辑必须具备自上而下的逆向验证能力。
- **深挖依赖层级**：技术演进越快，越需要理解底层依赖运作机制，避免在依赖层升级时陷入被动或错失架构优化空间。
---
### [56:35](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3395s) AI 结对午餐与“并行游戏”：打破 AI 研发时代的孤岛感
伴随着每位工程师身旁都常驻着几十个全天候并发运转的 AI Agent，团队内悄然出现了一种意料之外的隐秘副作用——孤岛感与孤独感。过去软件工程是一项极具社交性的团队活动，前端、后端、移动端紧密围坐在一起联调协同；如今，每个人都在单方面与自己的 Claude 频繁交谈，面对屏幕不知不觉陷入隔绝。
为了化解这种异化状态，团队设立了“结对编程午餐（Pairwise Programming Lunch）”与定期的内部黑客松。他们发现，团队中每个人使用 Claude Code 和 Cowork 的具体习惯与工作流差异极大；坐在一块进行类似儿童成长中的“并行游戏（Parallel Play）”——各自在工位旁打造自己的系统，但彼此观察对方如何给 AI 发送指令、如何组合自动化流程——大家能够爆发式地学到许多全新的技巧与思路。面对 Lenny 关于团队是否会过度沉迷于微调工作流的调侃，Fiona 笑着表示大家更多是将精力放在提升系统可靠性与探索架构新边界上；在每天都在剧烈进化的工具链面前，根本不存在所谓“完美的固定工作流”，彼此观察与启发才是最高效的进化方式。
---
### [58:41](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3521s) 失去的“心流”与被重塑的工程师职业愉悦
谈及 AI 原生开发时代丢失的工程浪漫，Lenny 感慨自己曾经做过十年工程师，最难忘的莫过于独自坐在屏幕前，沉浸在深层心流（Flow）中，看着复杂的代码编译通过、系统跑通那一刻所带来的强烈成就感；而如今，工程师的常态往往是发出指令，然后坐在那里等待 Agent 集群的构建结果。
Fiona 坦言自己前几天刚和团队里的工程师聊过同样的话题。昔日的技术人员最熟悉的仪式感，莫过于遇到极其棘手的恶性 Bug 时，戴上隔音耳机、打开专属音乐歌单、彻底沉浸在心流之中，历经千难万险终于破局时发出的那一声“太棒了，终于搞定了！”的狂喜。不可否认，过去解决最硬核技术痛点所带来的纯粹挑战乐趣，在 AI 时代正在被部分稀释。但与此同时，工程乐趣的重心也在发生不可逆的转移——从以往抠细枝末节的语法陷阱，转向在极短时间内把产品构想从无到有端到端落地、推向真实用户的全局掌控感。这种心理转变正是每位身处时代剧变中的工程师正在经历的重塑。
### [01:00:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3603s) 职能边界的消融：PM 与数据分析师的角色巨变
在讨论了使用大量智能体可能带来的孤独感后，Lenny 转向了一个宏观问题：在 Anthropic 内部，研发工程无疑是当前被 AI 重塑得最彻底的角色，那么排在第二位的又是哪一个？距离几年前的变化幅度最大的是谁？
Fiona 指出，所有与“编写代码”相邻的职能角色正在全面发生位移。其中产品经理（PM）的变化尤为剧烈。过去，PM 手握产品构想却往往受限于研发排期，必须苦苦等待工程团队腾出带宽；如今这一最大瓶颈已被打破。在 Anthropic，PM 们甚至会亲自“卷起袖子”，在工程师抽不出空时直接借助 AI 编写并上线一些小功能。但这也给流程带来了全新挑战：当不同专业背景的人都能往代码库提交代码（check in）时，团队必须建立起极高的验证门槛，以确保每个人都拥有足够的上线信心。除了工程与产品，Fiona 认为接下来的自动化探索将延伸至设计和数据科学领域。
听到这里，Lenny 分享了自己一位数据科学家朋友的真实遭遇：现在很多业务同事会用 AI 跑出一些半生不熟的“劣质”数据分析，然后直接丢给数据科学家说：“瞧，这是我做的数据分析，你能帮我确认下对不对吗？”而现实是，这些分析结果往往有一半是错的。原本指望做深度研究的数据科学家，日常工作竟变成了永无止境的“AI 数据作业审查员”，让人哭笑不得。
```mermaid
flowchart TD
accTitle: 角色边界消融与跨职能赋能流
accDescr: 展现 AI 如何打破传统研发、产品与分析的边界
subgraph Traditional["传统协作模式（存在严重工程与分析瓶颈）"]
PM1["产品经理 (提需求/写 PRD)"] -->|漫长等待排期| Eng1["研发工程师 (实现代码)"]
Eng1 -->|提需求| DS1["数据分析师 (跑 SQL 与建模)"]
end
subgraph AINative["AI 原生协作模式（能力双向渗透）"]
PM2["产品经理<br/>借助 AI 直接切入编码与功能交付"]
Eng2["研发工程师<br/>借助 AI 增强产品感知与跨职能能力"]
DS2["数据科学/验证<br/>重心由基础产出转向高维审查与质量把关"]
PM2 <--> Eng2
Eng2 <--> DS2
end
```
---
### [01:02:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3720s) 工程管理的新基线与全员“工程师化”
面对这种全新范式，Lenny 询问工程管理者如今对团队的基线预期应该是什么——除了“交付更快”之外，衡量常态运作的标准变成了什么？
Fiona 强调，在当下的工程团队中，绝大多数代码提交（commits）都已经是 Claude 辅助生成的，这代表着工作习惯的底层迁移。更深层的变化在于产品意识的内化：工程团队会将各类 Slack 内部用户反馈渠道和实时监控仪表盘接入 Claude，让工程师能够随时与数据和用户心声对话，从而持续锻炼出极其敏锐的“产品肌肉”。以往工程师遇到非工程领域的琐碎障碍，通常只能停下来等待跨职能伙伴（如设计、运营或分析师）的支持；现在借助大模型的辅助能力，这类跨职能等待大幅减少。
Lenny 总结道，这种变化呈现出奇妙的“双向流动”：一方面，工程师正在变得越来越具有产品意识，要对产品的整体成败与体验质量负起全责；另一方面，非研发人员在 AI 加持下也在越来越深入地涉足工程。正如有人曾戏谑的那样：“在这个时代，所谓‘岗位’其实就是看你花最多时间在做的那项工作是什么——界限已经完全模糊了。”
---
### [01:03:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3820s) 极致的 Dogfooding：通过真实使用把握产品脉搏
Lenny 提到，在与 Fiona 的多位同事交流时，大家反复提到她身上最显著的特质：对“吃自己的狗粮”（dogfooding，即团队极度高频地亲自使用自身产品）有着近乎执着的迷恋，无论带什么团队都要求所有人沉浸在产品体验中。
Fiona 坦言，这几乎是她掌握产品呼吸脉搏的最核心手段。每一款产品诞生之初都承载着一个美好的愿景，而只有作为重度用户持续使用它，你才能看清产品与梦想之间的落差。早在微软做 Visual Studio 时她就培养了这种热爱，而后续的经历更反复验证了这一点：
- **Facebook Marketplace 的诈骗防线**：在离开 Marketplace 团队后，她有一次想处理掉一台旧的 MacBook Air，便挂到了 Marketplace 上。令她始料未及的是，信息刚发出去，立刻就遭遇了一名买家的欺诈套路，从而顺藤摸瓜发现了一种此前团队从未捕捉到的新型诈骗路径。
- **Meta VR/AR 的地面标高 Bug**：在负责 VR 和 AR 团队时，由于她个人特殊的设备摆放习惯和使用环境，总能在系统里稳定触发一些极其罕见的地面高度识别错误（floor height issues）。她戏称自己天然就是一个绝佳的“Bug 复现测试机”。
对于管理者而言，亲自深潜入产品体验还有一层独特的价值。当时在 Meta 负责底层操作系统时，出于对系统稳定性的敬畏，Fiona 并未直接往底层代码库提交代码。但她选择把大量精力投入到 dogfooding 中，以此审查团队各种微小打磨（polish）后的实际体验，成为了团队严守质量底线的关键一环。她动情地提到，除了冰冷的指标，团队成员最在乎的是自己的工作到底有没有意义；当管理者亲自高频使用产品时，团队能真切感受到领导是与他们同呼吸的，而不是高高在上地飘在 PPT 和数据大屏里。
- 沉溺于仪表盘往往会产生盲区，真实用户的离群个案和切身痛点才能还原产品的真实样貌。
- 研发工程师提升产品感最直接的途径，就是把自己变成产品的重度核心用户。
---
### [01:07:07](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4027s) 走出仪表盘与走进用户现实：智利的网络冷水
Lenny 指出，高频使用产品是工程师培养 PM 思维的绝佳路径。Fiona 对此深表赞同，并补充道：如果你负责的产品类型天然无法让自己高频体验（例如面向特定垂直领域的工具），那就必须逼自己走出去与客户面对面。每一次客户拜访，都能颠覆认知。
她分享了在 Facebook Marketplace 准备拓展拉美市场时的一个经典案例。当时团队选择智利作为测试市场，但在后台数据中，智利的增长指标明显落后于其他试点地区，各种线上常规优化均无济于事。于是，Fiona 组建了一个极精简的三人调研小组亲自飞赴智利。
落地之后，她拿出一批在本地采购的普通 Android 手机开始实测。当手机连上当地的 LTE 网络那一瞬间，真相大白了：智利当地的基础网络环境比团队在硅谷办公室里习惯的美国高速 LTE 慢得多，Marketplace 的图文瀑布流在这些廉价 Android 设备上甚至连首屏都加载不顺畅。原本在办公室被当作“用户需求不匹配”来分析的数据异动，走到现实里却是一个最基础的网络性能瓶颈。如果没有走出办公室亲历这种现实，坐在硅谷的团队无论看多少份分析报告也无法找到真正的增长阻碍。
### [01:08:18](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4098s) 组织架构新命题：平台专家、自动化审查与体验验证
当谈到用户反馈与定性体感时，Lenny 引用了杰夫·贝佐斯（Jeff Bezos）的名言：“如果你手里既有数据又有具体案例（anecdote），要相信案例，胜过相信数据。”在此基础上，Lenny 翻出了 Fiona 此前在演讲幻灯片末尾提出的三个悬而未决的核心疑问：随着研发范式的剧变，团队是否还需要按 iOS 和 Android 划分独立团队？全自动代码与设计审查究竟能推到多深？在岗位边界日益模糊的背景下，又该如何确保不同背景的成员具备同等的生产力？
针对移动端体系的分工，Fiona 指出平台深层专业能力（deep expertise）依然必不可少，团队仍然需要招募顶尖的 Android 和 iOS 专家。然而，由于工程师现在能够借助 AI 在不同技术栈之间自由跨界（flexing），公司已经不再需要以往那样规模庞大、各自为政的移动端组织，目前的挑战在于如何精准平衡“核心专家配额”与“全栈通用交付”。至于自动化审查，Fiona 坦言如何验证“什么是真正的好”（what good looks like）依然是一大瓶颈。虽然团队已经在推行内容设计审查等自动化链路，但单纯跑通准确率评测（eval cases）并不等同于把控住了端到端的用户体验，如何构建全链路体验的自动化校验体系，仍是当下最难啃的骨头。
```mermaid
flowchart TD
accTitle: AI时代研发治理的三大未解命题
accDescr: 展示组织分工、自动化审查与上下文负荷三大维度面临的重塑挑战
subgraph Org ["1. 团队架构重组"]
A["传统独立架构<br/>(iOS / Android 大团队)"] --> B["精简专家 + AI跨栈开发<br/>(深度专家把关底层，普通成员跨栈协作)"]
end
subgraph Review ["2. 审查与验证边界"]
C["传统人工审查"] --> D["自动化规则与评测"]
D --> E["未解挑战：端到端体验验证<br/>(超越准确率，度量整体体验感知)"]
end
subgraph Load ["3. 认知负荷管理"]
F["单任务深度心流"] --> G["并行派发多智能体"]
G --> H["未解挑战：高频上下文切换<br/>(需专门留出 Focus Time 处理任务回执)"]
end
```
### [01:11:10](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4270s) 多 Agent 并行下的“上下文切换”风暴
随着 Claude Routines（日常例程）以及大量异步智能体的引入，一种新型的管理与工作认知负荷正在悄然形成。Fiona 观察到，由于每个人都可以随时派发多项异步任务，人类大脑在不同上下文之间快速来回切换的负荷正呈现指数级上升。当工作流中充斥着并行任务时，协调和处理这些任务所耗费的精力反而在蚕食人类的时间。
Lenny 生动地还原了这一状态：如果你同时挂着 20 个后台运行的 Agent，就意味着你要永无休止地下场检查状态、审核产出，并且得拼命回忆“我刚才到底让这个智能体负责哪一块来着”。虽然 AI 能在每次交互时提供上下文摘要，让人免于重新阅读所有架构细节和代码，但传统程序员那种长达数小时不被打扰的沉浸式“心流”（flow state）确实被打碎了。Fiona 笑着分享了自己的实际体会——过去她会在日程表上划出专门的“专注时间”（focus time）用于闭关写代码；而如今，她依然要在日历上锁定大段专注时间，目的却变成了集中阅读和收拢自己派发出去的各种异步 Agent 的阶段性产出。面对如何彻底消除这种高频切换带来的精神内耗，她坦率地承认业内目前“还没有人真正破解这个难题”。
- **传统专注模式**：日历锁定半天至全天，全神贯注于单一代码仓库实现系统架构。
- **Agent 并行模式**：碎片化派发数十个异步 Routine，需定时切换上下文进行验收与指引。
- **认知双刃剑**：降低了重新进入代码库的门槛，却极大增加了全局任务管理的状态追踪负担。
### [01:12:48](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4368s) 新一代工程师的培养瓶颈与抽象层迁移
一个令人玩味的行业现状是：尽管 AI 正在接管越来越多的编码细节，Anthropic 和 OpenAI 却依然在以惊人的速度抢夺顶尖工程人才。面对工程角色的未来走向，Fiona 展现出了非常真诚而脆弱的一面。她坦言，自己最焦虑也是最无解的命题是“如何培养下一代建设者”。过去工程师的成长路径是通过无数个日夜亲手敲击代码，一步步在底层踩坑中建立起系统级直觉，学会对技术栈层层深入、“向下深挖到第 8 层”（double-click down to layer eight）；但如今高校毕业生一入行就能直接借助模型一键生成系统，基础训练的路径已被彻底改变。
Fiona 设想，未来的软件工程培养或许必须打破传统的 3 个月轻度项目实习，转向类似“研究员机制（fellowship）”或“深度学徒制（apprenticeship）”，以更有针对性的方式把老一辈工程师历经沧桑才悟出的系统直觉灌输给新人。Lenny 随之指出，如果年轻开发者不再亲历排查内存泄漏与底层架构调试，未来会不会像当年应对千禧危机一样，不得不把退休的打孔卡老程序员返聘回来问“到底还有谁懂底层怎么跑”。
对此，Fiona 分享了一则打动人心的往事：她以前的一位工程主管是从纸带打孔卡（punch cards）时代开始敲代码的泰斗级前辈。这位经历过数次计算范式变迁的前辈，最近正兴高采烈地不断向 Fiona 发私信，展示他如何熟练地使用 Claude Code 打造全新的软件产品。这种见证技术演进的历史纵深感表明，计算行业一直在不断抽象化——从打孔卡、汇编语言，到高级编译语言，再到今天的 Prompt 与大模型的思考链路。重要的基础知识形态虽然在发生结构性转移，但核心能力永远在于敏锐地识别“什么才是真正值得解决的系统问题”。
### [01:16:23](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4583s) 拥抱指数级变化与重新审视失败的自动化尝试
Lenny 和 Fiona 讨论了在 AI 时代年轻一代工程师与资深工程师之间的差异。Lenny 指出，年轻人往往更容易毫无包袱地拥抱全新的工作方式，而很多老牌工程师却容易被过去的习惯困住。因此，像 Fiona 这样拥有 25 年工程经验却依然完全张开双臂拥抱变革的资深领袖实属罕见。Lenny 调侃道，面对 AI 生成的代码，人们总是会担心：“我们是在制造一堆垃圾代码（slop），还是在构建真正管用的架构？”
Fiona 解释道，AI 工具的演进速度极其惊人，这也是许多传统工程师最初抗拒的原因之一。她回忆道，在 Claude 3.5 Sonnet 甚至 3.6 的早期阶段，她用模型尝试做一些 side project 时，模型依然会犯不少低级错误，当时她也会忍不住吐槽：“你到底在干嘛？”许多抗拒 AI 的工程师便会抓住这些失误借题发挥：“你看吧，它根本不行。”然而，这些人忽略了模型能力的“指数级提升”。Fiona 强调，自己在这个过程中也学到了重要的一课：**如果曾经尝试过让 Claude 自动化某项工作但失败了，绝不要就此放弃，而应随着新模型的发布持续重新审视**。因为随着底层能力的跨越式迭代，之前无法搞定的瓶颈往往会在下一代模型中迎刃而解。
Lenny 也深有同感地补充道，这也是播客中经常被提及的一条铁律：“去构建那些处于边缘、几乎快要跑通的东西；因为一旦新模型到位，你就会瞬间遥遥领先于所有人。”
---
### [01:17:59](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4679s) Fiona 的心头大患：高速扩张下的团队文化与“一个团队”精神
当 Lenny 问及“究竟是什么让你彻夜难眠”时，Fiona 坦言，最困扰她的并非产品或工程架构上的硬核技术难题——因为那些问题通常可以通过数据看板、理论验证或建立假设来逐步解决——真正让她时刻挂心的是**团队在急剧扩张过程中的文化延续**。
Fiona 掌管着 Claude Code 和 Cowork 团队，她认为文化绝不是“印在墙上的标语口号”，而是一个有生命的有机体（living breathing thing）。它会随着时间推移而演变，具体体现在团队成员如何彼此相处、如何在关键时刻互相支持。Fiona 特别珍视“一个团队（One Team）的心态”：
- **多元化视角与开诚布公的公开争论**：团队必须具备足够包容的环境，鼓励大家把分歧摆在台面上进行坦诚、健康的交锋；
- **终点线前回望**：在冲向终点线时，要懂得回头看看身后是否有队友需要援手，因为“我们是一个团队共同冲过终点的”。
Fiona 坦言，随着 Anthropic 经历前所未有的爆炸式增长，团队文化的纤维很容易发生偏离（drift）。她的担忧在于，当文化出现偏移苗头时，大家能否及时察觉并坐在一起坦诚沟通，确保团队文化始终朝着正确的方向共同生长。
---
### [01:19:49](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4789s) Lenny 的 Airbnb 经历：文化守护与 Sheryl Sandberg 的忠告
Lenny 分享了自己在 Airbnb 经历极速扩张时对于文化的观察。Airbnb 创始人对文化达到了痴迷（obsessed）的程度，每一次全员大会（All Hands）和核心会议都必定自上而下地反复强调文化与核心价值观。
```mermaid
flowchart TD
accTitle: 两种团队困境对比
accDescr: 对比高速增长带来的文化挑战与业务停滞带来的痛苦
subgraph Good["良性问题（Good Problem）"]
direction TB
G1["业务超高速增长与大规模招聘"]
G2["文化受到冲击与人员磨合压力"]
G3["意味着企业正在走向成功"]
G1 --> G2 --> G3
end
subgraph Bad["恶性困境（Worse Situation）"]
direction TB
B1["业务陷入停滞与零新增招聘"]
B2["原有文化一成不变、波澜不惊"]
B3["带来深重痛苦与衰退风险"]
B1 --> B2 --> B3
end
```
此外，Lenny 回忆起前 Meta 首席运营官 Sheryl Sandberg 曾来 Airbnb 参加炉边谈话。当时有员工焦虑地询问：“公司扩张这么快，新员工源源不断涌入，我们究竟该如何维持原有文化？”Sheryl 的回答让 Lenny 铭记至今：
> “这正是你们梦寐以求想要拥有的问题（the problem you want to have）。因为这说明你们正在高速成长并取得巨大成功。如果你业绩惨淡、毫无增长、招不到任何人，你的文化确实完全不会变，但那种处境要痛苦糟糕得多。”
---
### [01:21:32](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4892s) 管理者的噩梦：“一切都很好”与着火房间里的迷因狗
顺着 Sheryl 的观点，Fiona 进一步指出，在 Claude Code 和 Cowork 团队中，她对管理层（Managers）和个人贡献者（IC）提出了极高的透明度要求，尤其是管理者：**不仅要大声庆祝成功的战果，更要对进展不顺、陷入困境的部分开诚布公**。
Fiona 笑着表示，她作为总监最大的“噩梦场景”，就是找某位管理者询问“最近怎么样？”，对方却面带微笑回答：“一切都好（Everything's fine）。”
- Fiona 心里会瞬间警铃大作：“天呐，不可能一切都好，我明明知道到处都是硬骨头！”
- 这种场景就像那个著名的迷因（meme）——一只小狗坐在熊熊燃烧的房间里端着咖啡说“This is fine”。
- 她在每位管理者入职之初都会反复强调：必须把问题摆在明面上谈，只有敢于承认“这件事情进展不顺”，团队才能集思广益、合力破局。
Lenny 对此深表赞同。他提到，在光鲜亮丽的顶尖独角兽企业中，周围每个人表面上看起来都混得风生水起（killing it），这种同侪压力会让很多人产生冒充者综合征，不敢承认自己正在挣扎或掉队。
---
### [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) 明确授权废除陈旧流程：反思 6 个月路线图
在进入闪电问答环节之前，Lenny 询问 Fiona 是否还有想留给听众的核心建议。Fiona 给出的建议是：**团队文化中必须给予大家“明确的许可，去杀死那些不再带来价值的陈旧流程”（explicit permission to kill processes that no longer serve us）**。
她建议所有团队领导者和成员审视日常工作：
- 挑出一个你打心底抗拒去做的流程；
- 或者是一个充满极高噪音、极其消耗精力与成本、或者完全依赖沉重人工操作的流程；
- 认真反问自己：“它是否还在履行最初设立时的使命？”
Fiona 拿自己的亲身教训作为反例：刚接手 Claude Code 团队时，她曾依照以往大厂经验推行了一次“为期 6 个月的路线图规划方案”。尽管她当时刻意将其设计得极其轻量级，希望避免陷入繁复的官僚主义，但实践证明这仍然跟不上 AI 时代的节奏。路线图制定仅仅过了 3 个月，整个 AI 领域和业务需求已经天翻地覆，那份规划文档根本再无人翻阅。Fiona 迅速自我调整，果断废弃了这种中长期硬性规划。她提醒所有人，在日新月异的技术浪潮中，必须始终对新认知保持开放，勇于亲手砍掉自己曾经引入的机制。这立刻引发了 Lenny 的追问：那么在如今的 AI 原生团队中，究竟该如何做规划？
### [01:24:34](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5074s) 从半年路线图走向 JIT（即时）月度规划
谈到团队如何规划与确定工作路线，Fiona Fung 将其现在的运作方式总结为“JIT（Just-In-Time，即时）规划”。过去制定长达六个月的路线图周期过长，在如今瞬息万变的 AI 时代早已跟不上节奏；虽然部分大项目依然需要一个月以上的时间，但他们将规划周期彻底缩减为轻量级的月度规划。令人惊讶的是，这个规划过程甚至连正式的 PRD 文档都没有，仅仅是团队在一个简短的电子表格（Spreadsheet）上对当月最重要的事项达成共识。
为了保证对齐，团队正在尝试设定当月的核心优先级，并通过极简的周度例会进行快速核对与确认：“这是我们这个月的优先级吗？是的，很好，继续推进。”Fiona 还强调，即便是一个简单的表格，她也在思考“如何进一步用 AI 将其自动化”，因为绝不能让填写表格变成团队成员的负担（Tax）。对于传统的 PM（产品经理）思维来说，这种极简运作方式甚至简单到令人难以置信：只要把当月重点列出来，每周看一眼确保方向无误即可，表格上的条目少而精。
```mermaid
flowchart TD
accTitle: Anthropic 的 JIT 即时规划流程
accDescr: 展示从每半年主题到月度轻量表格规划，再到每周快速确认与自动化探索的即时规划循环
subgraph Macro["半年度宏观方向"]
A["每 6 个月全员大会"] --> B["确定宏观探索主题与工作方向"]
end
subgraph Monthly["JIT 月度即时规划"]
B --> C["轻量级电子表格 (极简条目/无冗长文档)"]
C --> D["对齐当月核心优先级"]
end
subgraph Weekly["日常跟踪与自动化"]
D --> E["每周快速 Check-in: 优先级是否改变？"]
E --> F["工程师自主认领与推动落地"]
F -.持续思考.-> G["利用 AI 自动化更新，消除流程负担"]
end
```
- **宏观主题驱动**：虽然不做六个月的死板路线图，但团队每半年会召集全员开会，确立接下来的大主题（Themes）；不过由于外部行业格局变化太快，这些主题也必须保持敏捷调整的弹性。
- **赋能团队自主性（Agency）**：领导层只负责明确最高优先级的目标，团队中的每个人依据自身判断来决定具体做什么项目来解决这些优先级问题。
---
### [01:27:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5223s) 闪电快问快答：书籍与启蒙动画
节目进入经典的“闪电快问快答”环节。当 Lenny 询问她最常推荐给别人的两到三本书籍时，Fiona 分享了两位深深影响她的小说作家：加拿大作家玛格丽特·阿特伍德（Margaret Atwood，Fiona 在加拿大长大，非常喜欢她那种具有推演性、探讨未来人类社会走向的科幻小说）以及村上春树（Haruki Murakami，钟爱其标志性的“魔幻现实主义”风格）。而在所有图书中，她建议每个人每年至少读一遍的书是圣埃克苏佩里的《小王子》（*The Little Prince*），因为这本书能持续提醒人们在喧嚣的生活中反思“什么才是真正重要的东西”。
在影视作品方面，Fiona 笑称自己平时几乎不看电视剧（Lenny 插话说这是 Anthropic 员工上节目的普遍共性），但她的手机里永远下载着三部珍爱的经典电影：
1. **《天使爱美丽》（*Amélie*）**：一部天马行空、极具奇幻色彩的法国电影。Fiona 提到自己 16 岁时曾怀揣成为视觉艺术家的梦想随高中班级去巴黎旅行，那段记忆刻骨铭心，而《天使爱美丽》精准还原了她当年在巴黎所感受到的那种魔力。
2. **《千与千寻》（*Spirited Away*）**：宫崎骏吉卜力工作室的代表作之一，是她最喜欢的动画电影，百看不厌。
3. **《风之谷》（*Nausicaä of the Valley of the Wind*）**：该片由宫崎骏的漫画改编。Fiona 大约在八九岁时就看过了这部电影，女主角娜乌西卡展现出的领袖气质与处事方式在她心中留下了极深的印记，甚至成为她成年后许多领导力原则（Leadership principles）的核心灵感源泉。Lenny 调侃道，市面上大家推崇的顶级管理书往往是安迪·格鲁夫（Andy Grove）的《高产出管理》（*High Output Management*），而 Fiona 的管理秘籍居然是《风之谷》里的娜乌西卡。
---
### [01:30:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5424s) 改变生活的产品推荐与全球巡回
在推荐近期特别喜爱或改善生活的产品时，Fiona 分享了一个十分私人且接地气的选择：来自华盛顿州惠德比岛（Whidbey Island）本土小企业制造的 **Sweet Sisters Bodycare** 有机洗发水与护肤品。她提到自己因为频繁出差，习惯轻装出行并直接使用酒店提供的洗发水。几年前她的鼻梁处突然出现严重红肿、发炎甚至流血的皮疹，尝试停用所有面部护肤品也无济于事；后来一位朋友提醒她这可能是身体对多年来使用的普通超市洗发水中的化学物质产生了迟发性过敏反应（洗头时水会流经面部与身体）。当她换上 Sweet Sisters 的全天然有机洗发水后，顽固的皮肤问题立刻痊愈。最近这趟出差中她连续用了一周酒店备品，皮肤过敏反应再度复发，让她再次确信这款产品的重要性，打算以后出行都随身带上分装瓶。
- **Code with Claude 全球活动**：Lenny 提及 Fiona 近期密集的国际差旅是在参加 Anthropic 举办的全球巡回开发者活动“Code with Claude”，此前已在旧金山、伦敦等地举办，而 Fiona 即将前往最后一站日本东京。
### [01:32:54](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5574s) 人生信条：保持简单与选择善良
在谈到为人处世与工作哲学时，Fiona 分享了两个深植于心的座右铭。在工作层面，她的原则是“保持简单”（Keep it simple）——人们往往容易陷入过度思考（overthinking），因此不断提醒团队和自己明确核心目标并聚焦于最关键的事情至关重要。而在生活层面，她的信条则是：“在任何可以选择的世界里，请选择善良”（In a world where you can be anything, be kind）。Lenny 对此深有共鸣，提到自己在一所蒙特梭利学校参观时，教室墙上也赫然贴着这句话。
Fiona 动情地回顾了新冠疫情期间一段刻骨铭心的经历，以此说明善良往往体现在极其微小的日常瞬间。当时所有人都在远程办公，会议排得满满当当。对 Fiona 而言，与下属的一对一（1-on-1）会议向来被置于极高的优先级，因为这是下属期待倾诉、交流心声的重要专属时间。然而当时身处加拿大的祖母病重住在养老院，由于疫情封控家人无法前往探视，全家只能偶尔在护工有空协助时进行难得的 FaceTime 视频通话。某天中午，姑姑突然发来紧急消息，称祖母在中午 12 点恰好有一个短暂的通话窗口。面对即将开始的 1-on-1，Fiona 怀着极其愧疚的心情临时向报告下属发消息请求调整时间。对方毫不犹豫且极其温和地回复：“没关系，完全不用担心。”虽然这在外人看来只是一次微不足道的时间调配，对方也没有大张旗鼓，但这份体谅与善意让 Fiona 得以在屏幕前与祖母见上一面，成为了长久温暖她的珍贵记忆。
---
### [01:34:55](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5695s) 编织与代码：开会的咔嗒声、编译逻辑与毛线店梦想
Lenny 抛出了一个来自 Boris Cherny 的趣味内幕：Boris 透露，在许多极其重要的公司高层会议中，大家经常能在背景音里清晰地听到 Fiona 织毛衣的“咔嗒”声（click-clack）。Fiona 闻言大笑，大方展示自己身上穿的上衣就是不久前亲手织出来的。Lenny 调侃道：“你自己给自己做衣服，这简直太 Meta 了，就像 Claude Code 自己写自己一样。”
```mermaid
flowchart LR
accTitle: 编织与计算机系统的概念映射
accDescr: 展示编织的基本针法与动作如何映射到计算机的二进制、数据结构及编译器生成可执行文件。
subgraph Knitting ["编织世界 (Knitting)"]
K1["平针 (Knit) 与反针 (Purl)"]
K2["线圈堆叠与出入规则"]
K3["逐行织造成衣"]
end
subgraph Computer ["计算世界 (Computing)"]
C1["二进制 0 与 1"]
C2["栈 (Stack) 与队列 (Queue)"]
C3["编译器编译出可执行文件"]
end
K1 <--> C1
K2 <--> C2
K3 <--> C3
```
Fiona 剖析了编织与编程之间奇妙的底层相通性：
- **二进制对应**：编织的核心只有两种基础针法——正针（knit）与反针（purl），本质上就是计算机世界里的 0 和 1。
- **数据结构与编译**：线圈的处理过程充满了栈（Stack）和队列（Queue）的逻辑，手中的毛衣针就像编译器，把毛线一行行翻译并最终“生成一件可运行的可执行文件”（generating an executable）。
编织技能源于她八岁时祖母带她去毛线店并手把手传授的手艺，因此每次动针她都会想起祖母。Fiona 本身极具多线程工作习惯（正如她在后台启动 20 个 AI Agent 同时跑任务），熟能生巧后双手完全可以盲打，编织对她而言就像某种高阶的“解压指尖陀螺”（fidget spinner）。只要坐定开会或思考，双手就会自发运转“生成织物”，借此还能稍微消耗家里大量囤积的毛线存货。
当被问及如果通用人工智能（AGI）到来人类无需再工作时会做什么，Boris 此前表示要去酿味噌（miso），而 Fiona 的终极梦想则是以祖母的名义开一家毛线店，建立一个充满温度的社区空间。Lenny 幽默地补刀：“到那时 Cowork 就可以帮你把所有繁杂事务全自动处理好。”Fiona 笑着附和：“完全正确，特别是把开发票（invoicing）全包揽掉。”
---
### [01:37:07](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5827s) 结语与听众互动呼吁：反馈、隐性需求与“牵手”赋能
Lenny 盛赞 Fiona 及其领导的团队正在深刻改变整个世界的软件构建方式，产品的高速增长就是实力最好的证明。Fiona 谦逊地表示，能与 Anthropic 这群兼具野心与才华的团队共事是自己巨大的幸运。
针对想要线上交流或为团队提供帮助的听众，Fiona 指出了几条具体路径：
- **渠道与反馈**：可以在 LinkedIn 上关注并联系她。她非常渴望获得关于 Claude Code 与 Cowork 的一线实操反馈，无论好评还是痛点吐槽。
- **挖掘隐性需求（Latent Demand）**：欢迎大家分享各种意料之外的创造性用法。她分享道，最近有位朋友私信告诉她，自己正使用 Claude 生成定制化的木工建造施工图，甚至真的依此建好了一座后院储物棚（shed），这种跨领域的落地令她感到兴奋不已。
- **主动跨界帮扶（Hold somebody's hand）**：对于已经深度“AI 化”（AI-pilled）的技术受众，Fiona 呼吁大家走出极客圈子，主动走向身边尚未接触 AI 的小微企业主（如喜欢的独立小店）或普通朋友，“牵着他们的手”（take time to hold somebody's hand），耐心演示 AI 到底能在日常工作与生活中为他们卸下多少重担。
## Notable quotes
> [00:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=0s) 编写代码已不再是整个流程的瓶颈，每个人能力的上限被彻底掀开了。 — Fiona Fung
> [00:00](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=0s) 有什么事情是让 AI 做比让我自己做更好的？ — Fiona Fung
> [10:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=603s) 去犯新错误（Make new mistakes）。 — Fiona Fung
> [17:02](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1022s) 信任但要验证（trust but verify）。 — Fiona Fung
> [19:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1180s) 过去成就你的经验，未来可能不再适用。 — Fiona Fung
> [19:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=1180s) 你害怕进入的洞穴，往往藏着你所追寻的宝藏（The cave you fear contains the treasure you seek）。 — Lenny Rachitsky
> [39:40](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2380s) Don't forsake motion for progress（切勿把忙碌的动作误当成实质的进展）。 — Fiona Fung
> [44:24](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=2664s) 当 Sad 体验不断堆叠时，就会彻底恶化成 Bad。 — Fiona Fung
> [01:08:18](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4098s) 如果你手里既有数据又有具体案例（anecdote），要相信案例，胜过相信数据。 — Jeff Bezos
> [01:16:23](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4583s) 如果曾经尝试过让 Claude 自动化某项工作但失败了，绝不要就此放弃，而应随着新模型的发布持续重新审视。 — Fiona Fung
> [01:19:49](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4789s) 这正是你们梦寐以求想要拥有的问题（the problem you want to have）。因为这说明你们正在高速成长并取得巨大成功。 — Sheryl Sandberg
> [01:23:03](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=4983s) 明确的许可，去杀死那些不再带来价值的陈旧流程（explicit permission to kill processes that no longer serve us）。 — Fiona Fung
> [01:32:54](https://www.youtube.com/watch?v=Ybrl4FYM57c&t=5574s) 在任何可以选择的世界里，请选择善良（In a world where you can be anything, be kind）。 — Fiona Fung
## Mentioned
Fiona Fung, Lenny Rachitsky, Boris Cherny, Kat Wu, Tyler Cowen, Joseph Campbell, Jeff Bezos, Sheryl Sandberg, Andy Grove, Margaret Atwood, Haruki Murakami, Anthropic, Claude, Claude Code, Cowork, Claude Routines, Claude for Small Business, Microsoft, Visual Studio, TypeScript, Meta, Facebook Marketplace, Instagram, IBM, IBM DB2, Mercury, Command, WorkOS, Sweet Sisters Bodycare, 《小王子》（The Little Prince）, 《天使爱美丽》（Amélie）, 《千与千寻》（Spirited Away）, 《风之谷》（Nausicaä of the Valley of the Wind）, 《高产出管理》（High Output Management）
## Video description
Fiona Fung leads the teams behind Claude Code and Cowork at Anthropic (overseeing Boris Cherny and the entire engineering and PM team). Before Anthropic, she spent 11 years at Microsoft building Visual Studio and TypeScript and then moved to Meta, where she started Facebook Marketplace (now generating over $100 billion in GMV annually), worked on Meta’s first smart glasses and AR glasses, and led infrastructure, growth, integrity, and safety teams at Instagram. She’s been an engineer for over 25 years and has a unique perspective on how the role of building software is changing.
*In our in-depth conversation, we discuss:*
1. What she’s learned about running a team that’s shipping 8x more code than before
2. Which roles AI will transform next
3. Specific ways her team uses AI
4. How Claude “routines” have changed how she operates as a manager
5. The context-switching problem no one has solved yet
6. The biggest unsolved problem in AI
7. What keeps her up at night
*Brought to you by:*
WorkOS—Make your app enterprise-ready, with SSO, SCIM, RBAC, and more: https://workos.com/lenny
Mercury—Radically different banking, now with Command: https://mercury.com/
*Episode transcript:* https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering
*Archive of all Lenny's Podcast transcripts:* https://www.dropbox.com/scl/fo/yxi4s2w998p1gvtpu4193/AMdNPR8AOw0lMklwtnC0TrQ?rlkey=j06x0nipoti519e0xgm23zsn9&st=ahz0fj11&dl=0
*Where to find Fiona Fung:*
• LinkedIn: linkedin.com/in/fionafung
*Where to find Lenny:*
• Newsletter: https://www.lennysnewsletter.com
• X: https://twitter.com/lennysan
• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/
*In this episode, we cover:*
(00:00) Introduction to Fiona Fung
(02:31) How the engineering role has transformed over 25 years
(09:28) What an AI-pilled software team looks like in 2026
(12:26) Using Claude to manage and review team output
(14:40) The evolution of code review and verification
(16:55) Who to hire: creative builders and deep systems experts
(18:18) The shift to ambitious thinking
(19:40) The growth mindset required to thrive in AI-native teams
(25:52) Helping small businesses adopt AI tools
(31:46) How Anthropic spots latent demand and builds for it
(35:08) The next frontier: asynchronous work with AI routines
(38:06) Agency and accountability in AI-native teams
(39:40) The vibe shift from token-maxing to ROI measurement
(44:24) The “bad vs. sad” quality framework
(49:34) Why all managers start as ICs at Anthropic
(55:24) Preventing skill atrophy
(58:43) Managing context switching with 20 AI agents running
(1:00:08) How PM and data science roles are transforming
(1:03:40) The importance of dogfooding and using your own product
(1:08:36) Outstanding questions
(1:12:48) The future of engineering jobs and education
(1:17:59) What keeps Fiona up at night: team culture at scale
(1:22:53) From six-month roadmaps to JIT (just-in-time) monthly planning
(1:27:03) Lightning round
*Referenced:*
• Running an AI-native engineering org: https://www.youtube.com/watch?v=igO8iyca2_g
• Head of Claude Code: What happens after coding is solved | Boris Cherny: https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens
• Today, Anthropic engineers on average ship 8x as much code per quarter as they did compared to 2021-2025: https://x.com/AnthropicAI/status/2062568864240836995
• Visual Studio: https://visualstudio.microsoft.com
• Joseph Campbell’s quote: https://www.goodreads.com/quotes/192665-the-cave-you-fear-to-enter-holds-the-treasure-you
• Life-changing Cowork use case: https://x.com/lennysan/status/2059664455001334124
• Introducing Claude for Small Business: https://www.anthropic.com/news/claude-for-small-business
• Conversations with Tyler podcast: https://conversationswithtyler.com
• Sheryl Sandberg on Facebook: https://www.facebook.com/sheryl#
• Amélie on Prime Video: https://www.amazon.com/Amelie-Jean-Pierre-Jeunet/dp/B0DQ4S3N45
• Spirited Away on HBO Max: https://www.hbomax.com/movies/spirited-away/3deab668-d0a4-4a8d-9bc8-0952a0ad836e
...References continued at: https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering
*Recommended books:*
• Margaret Atwood’s books: https://www.amazon.com/stores/author/B000AQTHI0?ccs_id=0027a474-cd59-4a3a-bcd7-9b173c27d530
• Haruki Murakami’s books: https://www.amazon.com/stores/Haruki-Murakami/author/B000AP7AFI
• The Little Prince: https://www.amazon.com/Little-Prince-Antoine-Saint-Exup%C3%A9ry/dp/0156012197
• Nausicaä of the Valley of the Wind: https://www.amazon.com/Nausica%C3%A4-Valley-Wind-Box-Set/dp/1421550644
• High Output Management: https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884
_Production and marketing by https://penname.co/._
_For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com._
Lenny may be an investor in the companies discussed.
[Source](https://www.youtube.com/watch?v=Ybrl4FYM57c)
Source quotes
[0:00] Fiona Fung: 编写代码已不再是整个流程的瓶颈，每个人能力的上限被彻底掀开了。
[0:00] Fiona Fung: 有什么事情是让 AI 做比让我自己做更好的？
[10:03] Fiona Fung: 去犯新错误（Make new mistakes）。
[17:02] Fiona Fung: 信任但要验证（trust but verify）。
[19:40] Fiona Fung: 过去成就你的经验，未来可能不再适用。
[19:40] Lenny Rachitsky: 你害怕进入的洞穴，往往藏着你所追寻的宝藏（The cave you fear contains the treasure you seek）。
[39:40] Fiona Fung: Don't forsake motion for progress（切勿把忙碌的动作误当成实质的进展）。
[44:24] Fiona Fung: 当 Sad 体验不断堆叠时，就会彻底恶化成 Bad。
[68:18] Jeff Bezos: 如果你手里既有数据又有具体案例（anecdote），要相信案例，胜过相信数据。
[76:23] Fiona Fung: 如果曾经尝试过让 Claude 自动化某项工作但失败了，绝不要就此放弃，而应随着新模型的发布持续重新审视。
[79:49] Sheryl Sandberg: 这正是你们梦寐以求想要拥有的问题（the problem you want to have）。因为这说明你们正在高速成长并取得巨大成功。
[83:03] Fiona Fung: 明确的许可，去杀死那些不再带来价值的陈旧流程（explicit permission to kill processes that no longer serve us）。
[92:54] Fiona Fung: 在任何可以选择的世界里，请选择善良（In a world where you can be anything, be kind）。
Source quotes
[39:38] Fiona Fung: Don't forsake motion for progress. Because if you're measuring like, you know, like tool user usage, then you're you're measuring the action, but is it really making whatever the end outcome of yours like important?
[71:08] Fiona Fung: I do see the context switching load increasing
[83:03] Fiona Fung: I call it JIT planning now, like just-in-time planning.
[92:45] Fiona Fung: I'm kind of like a compiler. I'm kind of like... generating an executable when I knit
Original transcript
[0:00] Anthropic engineers, on average, ship
[0:01] eight times as much code per quarter as
[0:03] they did compared to 2025. [music]
[0:05] >> Coding is no longer the bottleneck. It's
[0:07] lifted the ceiling of what anyone is
[0:09] able to do.
[0:10] >> Everything is now possible in theory.
[0:12] Now, it's about how ambitious [music]
[0:13] can you be?
[0:14] >> It's always something we ask ourselves,
[0:15] what's better than me doing it? Haven't
[0:17] thought, David.
[0:18] >> The people that seem to be doing best
[0:19] are taking the most initiative, getting
[0:20] the most proactive, have the most
[0:22] agency.
[0:22] >> We say with high agency is also high
[0:24] accountability. So, it's all about
[0:25] making sure folks have that freedom to
[0:27] code. But, then it's also like, okay,
[0:29] what's the accountability for it? What's
[0:30] the hypothesis of what you're trying to
[0:32] solve?
[0:33] >> I'm curious what is lost in this new
[0:34] world of software engineering.
[0:36] >> It can start being a lonely experience
[0:37] cuz we all started just working with our
[0:39] agent so much. And on the Claude Code
[0:40] team, recently, we started up pair-wise
[0:43] programming lunch.
[0:44] >> Something you think about is this gap
[0:45] forming [music] between people that are
[0:47] leaning into AI, killing it, and then
[0:48] people that are not, super frustrated,
[0:51] fighting, resisting.
[0:52] >> In terms of frustration, I think
[0:54] sometimes I also see a little bit of
[0:55] fear. For anything that there is a fear,
[0:58] my advice is lean in and ask, [music]
[0:59] "What can I do about it? What is within
[1:01] my control?"
[1:05] >> Today, my guest is Fiona Fung. Fiona
[1:07] leads the teams behind Claude Code and
[1:09] co-work at Anthropic. She oversees both
[1:12] Boris Cherney and Kat Wu, both of whom
[1:15] who have been on the podcast and whose
[1:16] episodes are in the top 10 most listened
[1:18] to episodes of all time. Before
[1:20] Anthropic, at Microsoft, Fiona ran the
[1:22] teams that built TypeScript and Visual
[1:24] Studio. After that, she went to
[1:26] Facebook, where she started the Facebook
[1:27] Marketplace team, which [music] she took
[1:30] from idea to launch. Today, Facebook
[1:32] Marketplace generates over 100 billion
[1:34] dollars in GMV every year. Also, while
[1:37] at Meta, she oversaw work on Meta's
[1:39] first smart glasses product, and then
[1:40] she helped build Orion, their first AR
[1:42] glasses product. Then, she went
[1:44] Instagram, where she led infrastructure,
[1:46] growth, integrity, and safety teams.
[1:49] While at Instagram and at Meta, she
[1:50] [music] oversaw an org of over 500
[1:52] people. Fiona has been an engineer for
[1:54] over 25 years and as a long-time
[1:58] engineering leader, especially now
[1:59] [music] at Anthropic, she has such a
[2:02] unique lens into where things are
[2:04] heading, what's worth paying attention
[2:06] to, and what teams should be thinking
[2:08] about right now as [music] AI transforms
[2:11] the world of building. A huge thank you
[2:13] to Kat Lo, Boris Cherney, and Mohammad
[2:15] [music] Hegazi for suggesting topics and
[2:17] questions for this conversation. Before
[2:19] we get into it, don't forget to check
[2:20] out Lenny's product pass.com
[2:22] >> [music]
[2:22] >> for a free year of the hottest and most
[2:24] well-crafted AI products in the world
[2:26] available exclusively to Lenny's
[2:28] newsletter subscribers. With that, I
[2:30] bring you Fiona Fung.
[2:34] >> [music]
[2:35] >> Fiona, thank you so much for being here
[2:38] and welcome to the podcast.
[2:39] >> Thanks so much for having me, Lenny.
[2:41] >> So, I was at the Claude uh Code with
[2:43] Claude event uh I don't know, a month
[2:45] ago at this point and I was and I went
[2:46] to your talk and I I was just like, holy
[2:49] I got to get Fiona on this
[2:50] podcast. She's thinking so far ahead of
[2:52] where everybody else is going and what
[2:54] where people are at with AI. So, you've
[2:56] been an engineer for 25 years. I was
[2:58] browsing your LinkedIn. Uh you started
[3:00] at IBM of all places. Such a different
[3:03] [laughter]
[3:04] place to be these days.
[3:06] And it's just insane how much the job of
[3:09] an engineer has changed over the past
[3:11] just like 2 years. It's like a
[3:13] completely different job. Like, people
[3:15] may forget 100% of code was written by
[3:17] humans not long ago.
[3:19] And now it's getting to 100% of code
[3:22] written by AI. Uh as Boris uh famously
[3:25] said, code coding is salt.
[3:27] Along these lines, there's just this
[3:28] tweet that you guys put out yesterday
[3:31] where you showed uh here's the tweet.
[3:33] Anthropic engineers on average ship
[3:34] eight times as much code per quarter as
[3:36] they did compared to 2021 to 2025. We'll
[3:39] show this chart on the screen. It's just
[3:41] like stable stable stable stable boom
[3:43] shooting off into the moon. So, it's
[3:45] just insane how much this role has
[3:46] changed. I'm curious about your kind of
[3:50] path as an engineer going living through
[3:52] this, having been an engineer for a long
[3:54] time, what have been kind of like the
[3:55] big moments along the way where it's
[3:57] shifted your
[3:58] way of thinking and operating that have
[4:00] led you to what you do now and how you
[4:02] operate now?
[4:03] >> Oh, I I I love this kind of look back in
[4:05] time. Yeah, like IBM, working on DB2,
[4:08] the operating system services team. Like
[4:10] back then I was thinking, oh, how can I
[4:13] how can I be like the like what's a hard
[4:15] area of the stack? And I really thought
[4:18] the lower level you go closer to the OS,
[4:20] then it's like more hardcore and you you
[4:22] learn more. So that was a I was really
[4:24] fortunate to gotten into the IBM
[4:25] internship. Um but the funny thing was I
[4:28] would I think there's even a big shift
[4:29] from IBM to Microsoft. So at IBM it was
[4:33] I think Vim. Like I didn't have an IDE
[4:35] that we used. I think there might have
[4:36] been
[4:37] an Eclipse license, but for some reasons
[4:39] most of us didn't use it. So I remember
[4:40] it it was mainly like Vim and and you
[4:43] know, like kind of terminal debugging.
[4:46] And then when I joined Microsoft, I mean
[4:48] this is how naive I was. I didn't even
[4:50] know about IDEs and such and and back
[4:52] then you didn't really get to pick
[4:53] teams. Like this was early 2000s.
[4:56] Actually first off I should say I was so
[4:57] grateful that I landed the internship
[5:00] and the role cuz to take us all the way
[5:02] back in time the dot com bubble burst in
[5:04] 2000.
[5:05] And so for my graduating class like a
[5:07] lot of the companies weren't hiring or
[5:09] or were having freezes. So I'm so
[5:10] fortunate when Microsoft extended me an
[5:12] offer.
[5:14] And so they're like you're going to work
[5:14] on Visual Studio. I did not even know
[5:17] what Visual Studio was cuz I came from
[5:19] like a Unix school. So I remember to
[5:20] asking, oh, this cuz I was thinking,
[5:22] well, the name Visual Studio, I'm like,
[5:23] oh, is this like a a better paint
[5:25] program? And I could tell the look of my
[5:27] manager's face like, what is going on?
[5:30] >> [laughter]
[5:31] >> But then it ended up becoming like the
[5:32] love of my life for the first, you know,
[5:34] 11 years of of my career. But that was
[5:36] the first time I used an IDE. So joining
[5:38] the Visual Studio team, seeing, oh, wow,
[5:41] like here's an IDE with like debuggers
[5:43] and you can set breakpoints and do
[5:45] multi-threaded debugging. Like that was
[5:47] also always mind-blowing for me to think
[5:49] about the the stepwise change. Um so
[5:51] yeah, like that was kind of the story
[5:53] going from I beam to Visual Studio. And
[5:56] then what I really loved actually about
[5:58] Visual Studio is I was on the Visual
[6:00] Studio editor team. So I use a VS editor
[6:03] to build the VS editor and that's where
[6:05] my whole love of dog feeding comes from.
[6:07] Like I I remembered I wanted to first
[6:09] and foremost create a delightful
[6:11] experience not only for myself, but for
[6:13] my teammates. Cuz also if we go back in
[6:15] that time, if you remember, I mean when
[6:17] did Twitter come out? Like was it two
[6:20] 2000 and six or something?
[6:22] >> it's been around my whole life.
[6:24] >> [laughter]
[6:24] >> But back then, like before social media,
[6:27] it was also harder for most engineers to
[6:30] um
[6:30] hear fast customer feedback. Like for
[6:33] sure there you would be user research
[6:34] sessions or we would have customers
[6:36] visit us.
[6:38] But you didn't get the rapid feedback
[6:39] that you you you you do nowadays. But
[6:42] back then I was so lucky because I was
[6:43] on VS. We ourselves gave each other so
[6:45] much rapid feedback cuz we were all
[6:47] heavy VS users on the team.
[6:49] >> This episode is brought to you by our
[6:51] season's presenting sponsor WorkOS. What
[6:54] do OpenAI, Anthropic, Cursor, Vercel,
[6:57] Replit, Sierra, Clay, and hundreds of
[7:00] other winning companies all have in
[7:01] common? They are all powered by WorkOS.
[7:04] If you're building a product for the
[7:06] enterprise, you've felt the pain of
[7:07] integrating single sign-on, SCIM, RBA,
[7:10] audit logs, and other features required
[7:12] by large companies. WorkOS turns those
[7:15] deal blockers into drop-in APIs with a
[7:17] modern developer platform built
[7:19] specifically for B2B SaaS. Literally
[7:22] every startup that I'm an investor in
[7:24] that starts to expand upmarket [music]
[7:26] ends up working with WorkOS. And that's
[7:28] because they are the best. Whether you
[7:30] are seed stage startup trying to land
[7:31] your first enterprise customer or
[7:33] unicorn expanding globally, WorkOS is
[7:36] the fastest path to becoming enterprise
[7:38] ready and unblocking growth. It's
[7:40] essentially Stripe for enterprise
[7:42] features. Visit workos.com to get
[7:44] started or just hit up their Slack where
[7:46] they have actual engineers waiting to
[7:48] answer your questions. WorkOS allows you
[7:50] to build faster with delightful APIs,
[7:52] comprehensive docs, and a smooth
[7:54] developer experience. Go to workos.com
[7:57] to make your app enterprise-ready today.
[7:59] >> People think about these milestones
[8:01] along the way of an engineer's journey
[8:02] and we forget there's also there's been
[8:03] like a lot of transformation over the
[8:05] years. Not quite what we're living
[8:06] through, but just like IDEs, Visual
[8:08] Studio. Uh so I love that I love that
[8:10] you're reminding us of these moments in
[8:12] uh the history of software engineering
[8:14] that that have changed the the work in a
[8:15] big way.
[8:16] >> Yeah, when I worked on Visual Studio
[8:17] back then we also shipped software on
[8:19] CDs.
[8:20] I mean [laughter] before like and and
[8:22] that's why there were really hard
[8:23] deadlines cuz you had to make sure the
[8:25] software is ready for us to give to
[8:27] manufacturing to then, you know, put on
[8:28] the CDs for us to then put on the
[8:30] shelves. And uh and then so once that
[8:33] was another shift when we actually
[8:34] started to be able to, you know, ship
[8:36] software online. And I think that's the
[8:38] interesting thing and I kind of
[8:39] mentioned this in my talk. It's before
[8:41] when you like engineering time was like
[8:44] like really precious resource. But you
[8:46] also have these really hard deadlines,
[8:48] for example, like printing
[8:49] [clears throat] software on CDs. And so
[8:50] back then you would do a lot more
[8:52] planning cuz you just wanted to make
[8:54] sure given the time you have, you you
[8:56] make the best of it. And that's the
[8:58] shift that, you know, like we're seeing
[8:59] with with uh Clockwork and Co-work is
[9:02] coding is no longer the bottleneck. And
[9:04] so now like, you know, you showed up you
[9:06] showed the the tweet and that graphic.
[9:08] So but now it's all about like where has
[9:10] that shift happened? Like now not only
[9:12] engineers but we also have designers,
[9:14] PMs, everybody on the Clockwork team
[9:15] checks in code. So like when not only
[9:18] more people checking in code but like
[9:20] kind of different disciplines, but also
[9:21] the throughput is so high. How do we
[9:23] think about verification? Like that's
[9:25] kind of this other shift that I'm
[9:26] seeing.
[9:27] >> Maybe just kind of set this theme that I
[9:29] want to have for this conversation. A
[9:31] lot of people are just wondering what is
[9:33] what is software engineering, managing
[9:34] software engineers, managing software
[9:37] and product teams look like in the
[9:39] future and you are living through that
[9:40] right now. So, you mentioned this um
[9:43] point about a more focus on
[9:45] verification, making sure the quality of
[9:47] the code being
[9:49] uh 8X is actually high and something uh
[9:52] that's that you know that will work. So,
[9:55] just like let me ask this broad question
[9:56] and let's kind of see where this
[9:57] conversation goes. What is a What does
[9:59] an AI-pilled software team look like in
[10:01] 2026?
[10:03] >> Because the roles are blowing, it's
[10:04] shifting more to this builder
[10:06] uh like everybody starts being a a a
[10:09] builder, I would say. The other shift
[10:11] that I've recently done is I actually
[10:13] have a cloud code remote session that I
[10:16] enlist in all of our repos. And so, this
[10:19] way I have full visibility into the work
[10:21] that everybody's doing. And this
[10:23] instance it also has access to all our
[10:24] Slack channels and and I'll I'll have
[10:26] access to like how how are the metrics
[10:28] of of everything we track. And so, every
[10:31] month like I when when like I have been
[10:33] like, "Hey, you know what's fun? Like
[10:34] let's let's take a look back." Like and
[10:36] so, we'll actually do it together. I'll
[10:37] share my, you know, like cloud code you
[10:39] know, I've shared my screen and we we we
[10:41] do a cloud code
[10:42] session. And it's just about, "Hey, what
[10:44] were the focus areas? Like what were
[10:46] some of the the products that got
[10:47] shipped? How did they do? Oh, what were
[10:49] the feedback channels?" And and so, I
[10:51] even though like before I would have
[10:52] just used these sessions to like
[10:53] generate PRs and bug fixes, I actually
[10:56] have these sessions to enable me to have
[10:58] conversations with folks that I support.
[11:00] >> Say more about that. So, this is this is
[11:03] like a management technique, let's say,
[11:05] to help people
[11:07] not just ship, but actually
[11:10] ship better understand if they're
[11:12] shipping things that have impact. Is
[11:13] that kind of the idea here? Just like
[11:14] use cloud to keep on top of all the
[11:17] things people are shipping and then make
[11:18] that a conversation with them.
[11:20] >> Exactly. So, like yeah, outside of just,
[11:22] you know, the action of shipping is how
[11:24] did it do in market? Or hey, did we
[11:25] have, you know, like did we cause some
[11:27] bugs? And it's okay to like I have this
[11:29] saying, "Make new mistakes." Like it's
[11:31] okay to make mistakes, just make new
[11:33] ones so that we're always learning cuz
[11:34] if you aim to make zero mistakes, like
[11:36] that probably means you're not, you
[11:37] know,
[11:38] moving fast enough or being a little bit
[11:40] too cautious. And so yeah, by by having
[11:43] Claude, like so then it can also look at
[11:45] like some like for example, actually,
[11:47] yeah, we were I was just looking at, oh,
[11:48] you know, given some of the, you know,
[11:50] incidents that we have, like let's look
[11:52] across all of this. Can we generate a
[11:53] theme? Like what's a good area
[11:54] investment for us not just especially
[11:56] when we think about like quality. Like
[11:58] are we seeing any hot spots of where
[12:00] there could be a gap? I think that used
[12:03] to be just a much more manual uh
[12:05] process, I would say. Like if I look
[12:06] back a year ago, I don't think I would
[12:08] have been able to, you know, have some
[12:10] of these insights with Claude.
[12:11] >> Yeah, well, partly is cuz like there's
[12:13] that and also people weren't shipping as
[12:15] much, so you could just make a little
[12:16] bullet list. Here's the things I shipped
[12:18] last quarter. This feature, that
[12:19] feature, this feature, that feature. So
[12:21] I think what I'm hearing here is this is
[12:23] like one of the only ways to stay on top
[12:24] of all the things that 8 mate is
[12:26] shipping.
[12:27] So this is a really cool thread of just
[12:28] like how you found ways to stay on top
[12:30] of this 8 X increase in code. What else
[12:33] has worked in helping you and your team
[12:35] stay on top of and maintain quality of
[12:37] all the stuff that y'all are shipping
[12:39] cuz that's obviously a challenge, a
[12:41] bigger challenge.
[12:42] >> Yeah, and so definitely like the
[12:44] feedback channels are really important
[12:45] to us, but then we also get a lot of
[12:47] feedback and like for example, even I
[12:49] myself usually what my my morning ritual
[12:52] would be, you know, I get my morning cup
[12:53] of coffee and then I look at the
[12:55] feedback channels and then I try to pick
[12:57] up what are, you know, if I have some
[12:58] maker time, what's something that maybe
[13:00] I would be able to help out or what I
[13:01] could like see some gaps. Like that just
[13:03] used to be something I would do every
[13:04] morning.
[13:05] And uh yeah, I think maybe a month or
[13:07] two ago we we launched routines. And
[13:09] that's also completely changed. Like now
[13:11] I just have a routine that automates all
[13:13] this for me and then there's also it's
[13:14] almost like before I would, you know, be
[13:16] able to kind of like,
[13:18] you know, generate some prompts, but now
[13:19] with routines, it's almost like I'm,
[13:22] you know, having an agent help me
[13:23] generate the like generate the prompts
[13:25] and the PR. So for example, one is,
[13:27] "Hey, keep a look on this feedback
[13:28] channel, you know, what are some of the
[13:30] themes?" And then like when I wake up,
[13:32] then you know, I have a really good
[13:33] summary of that. And then even some like
[13:35] PRs that I'll be able to take a look and
[13:37] review.
[13:38] >> And the feedback channel, where's that
[13:39] feedback coming from? Is that like
[13:41] like emails, Twitter's, or a combo of
[13:43] everything?
[13:45] >> [laughter]
[13:45] >> Our feedback channels are definitely
[13:47] like we have a lot from internal and but
[13:49] also like emails, channels. Actually,
[13:52] everybody like when we all get feedback
[13:54] on even like when friends ping us or on
[13:56] LinkedIn or socials, we'll all actually
[13:58] like post all of that in Slack as well.
[14:00] And so and and we also have like of
[14:02] course partnerships. And so we have
[14:04] different channels for for all the
[14:07] various sources. But but that's what I
[14:09] mean of I need Claude's help to help me
[14:10] stay on top because there's so much
[14:12] incoming feedback.
[14:14] >> Got it. Okay, so this is cool. So, this
[14:16] is a
[14:17] like a way of working that you've built
[14:20] to stay on top of all the stuff shipping
[14:21] which is this kind of daily ritual /
[14:23] routine where you as a manager look at
[14:27] what people are saying about the current
[14:29] state of
[14:30] Claude Code and Co-work and used to just
[14:32] like okay, someone go fix this, go fix
[14:34] that. Now it's like here's the PR that
[14:37] will fix this thing, check it out. We're
[14:38] ready to ship it if you want.
[14:40] >> That's right.
[14:41] >> Okay, like obviously a big challenge for
[14:42] people is also just code review. I
[14:44] imagine Claude is also doing a lot of
[14:46] its own code reviews. There anything
[14:48] there you've
[14:49] recently figured out that allows your
[14:50] teams to ship faster stuff that they are
[14:53] confident is great?
[14:54] >> Yeah, and honestly, it's crazy when you
[14:56] think we didn't even have Claude Code
[14:57] Reviews last year. And so speaking of
[15:00] bottlenecks, that that was a really
[15:01] really big bottleneck of, you know, the
[15:03] human reviewers. So, we definitely for
[15:05] the important like like areas that need
[15:07] deep subject matter expertise, we
[15:09] definitely want to make sure we have the
[15:10] proper you know, like human still
[15:12] reviewing. I would say what helps us
[15:14] though is the more that we can automate
[15:16] to almost check in the framework for
[15:18] what good looks like. Claude is very
[15:21] good when you give it a framework to
[15:23] validate against those frameworks. So, I
[15:25] had mentioned like you know our late you
[15:26] know like recently we just updated the
[15:28] content design to to have a scale in it.
[15:31] Like my like I and this is why like um I
[15:33] think if you have specs or like or like
[15:36] like check those into the repo and then
[15:38] make sure the spec also keeps up to date
[15:40] with the code like frequently. But
[15:42] that's what I found like works really
[15:43] well of any time you have like a
[15:45] statement of what good looks like, get
[15:47] that into the repo and then Claude code
[15:49] review can make sure it's still matching
[15:51] what you set up to do.
[15:52] >> Basically, it's like a the evolution of
[15:54] test-driven development.
[15:56] >> Yes, for TDD it's cuz I remember that
[15:58] was like a a big thing my gosh maybe
[16:01] like in the 2000s of write the test
[16:03] first and then and then you can like
[16:05] make sure the test fails then you do
[16:06] actually the code. In principle, it's
[16:08] really good but I think I know I
[16:10] remember that I myself struggling a bit
[16:11] because it was almost like you have to
[16:13] eat the broccoli first. That's why I'm
[16:14] like ah you have to write this test
[16:16] first and I just get so much thrill out
[16:17] of shipping and building product. So,
[16:20] that's funny. Actually, the first bug I
[16:22] fixed on Claude code I remember asking
[16:23] Claude, "Hey, I want to do test-driven
[16:25] development. Help me write the test
[16:27] first. Make sure it fails and then we'll
[16:29] actually, you know, do the fix and then
[16:31] and then now that test pass." And the
[16:33] fact that that used to be, you know,
[16:35] like that test generation used to just
[16:37] be this tax that I remember having to
[16:39] pay. Like the fact that that's now
[16:40] automated and you can even revisit all
[16:43] these principles that have been around
[16:44] for a while but now they actually might
[16:46] be even more efficient just because you
[16:48] have the models that can do more of the
[16:50] work for you.
[16:51] >> Yeah, like that's it's so unfair. It
[16:53] just writes the test for you first.
[16:55] >> [laughter]
[16:56] >> So, on this point of builders, one of my
[16:58] favorite slides from your talk that um I
[17:01] want to ask you about is
[17:02] who you are hiring and who what you look
[17:04] for in people. And so, I'll read what
[17:07] you said there and I want to hear more
[17:08] here. So, the two profiles that you now
[17:10] look for when you're hiring are creative
[17:13] builders with product sense and deep
[17:15] systems experts for the hard parts.
[17:18] >> Yeah, the deep subject matter expertise.
[17:20] Like for example, when I first joined
[17:21] Cloud Code, we had really great kind of
[17:23] like product generalists. And then I
[17:25] realized, oh, we were missing folks with
[17:28] systems background. And so, that was
[17:30] definitely an area that we we needed
[17:32] more folks with kind of like systems and
[17:34] distributed systems expertise.
[17:37] And so, I would say whatever are the
[17:38] parts that it's all about trust but
[17:40] verify. The models are really good, but
[17:42] there are definitely a lot of areas that
[17:44] still need verification. And so,
[17:47] wherever you need the deep subject
[17:49] matter expertise, I would say that's,
[17:50] you know, an area to definitely still
[17:52] invest in.
[17:54] And the other one is kind of like the
[17:55] the product the product sense works
[17:58] almost like the dreamers. Like these are
[18:00] folks that usually will be like, "Oh my
[18:01] gosh, I'm really passionate about a
[18:02] product." And they have an idea, they
[18:04] build it, and then it's always like
[18:06] looking at the feedback, and then
[18:07] iterating, and polishing, and making
[18:09] sure that the product is a delightful
[18:11] experience. Like owning that product
[18:13] end-to-end. Uh that's that's like
[18:16] another skill set that served us really
[18:18] well on Cloud Code.
[18:19] >> This super resonates. There's this word
[18:21] ambition. I don't know if you used it,
[18:23] but that's what I thought of as you were
[18:24] talking. That's been coming up a bunch
[18:26] recently in the podcast and in other
[18:29] work I've been doing. There's this 10X
[18:31] engineer I was talking to the other day,
[18:33] and he was just like, "I used to like I
[18:36] heard about a feature idea, like I have
[18:37] someone's like, 'Hey, we should build
[18:38] this.' And I was like, 'No, that's
[18:40] really hard and complicated.' And he's
[18:42] like, 'But now I'm like, no, no, that's
[18:44] so possible. I just ask Cloud Code to do
[18:46] it.' And it just does it. And it's this
[18:48] whole mindset shift. And he's just
[18:50] realizing now it's about how ambitious
[18:52] can you be? Like everything is now
[18:55] possible in theory. Now it's about how
[18:57] ambitious and how big can you think
[18:59] versus just like, 'Okay, it's all these
[19:01] stupid little features and things I have
[19:03] to unblock.' Does that Does that
[19:04] resonate? Is that something that you
[19:05] think about?
[19:06] >> Yeah, so actually I was just catching up
[19:07] with an engineer yesterday, and Um, uh,
[19:11] actually is not a mobile engineer by
[19:13] trade, but we really needed to, uh,
[19:15] update this feature to also have, uh, a
[19:17] mobile footprint. And it was just
[19:19] amazing. Like he's like, "You know
[19:20] what?" Cuz it it it and it's common cuz
[19:23] you might think, "Wait, but I don't I'm
[19:24] not like an Android expert." But now,
[19:27] thanks to Claude, actually I can
[19:28] actually have a partner and actually
[19:30] also do this on the mobile surfaces. And
[19:32] so that definitely resonates. It's like
[19:33] the it's lifted the ceiling of what and
[19:36] anyone is able to do.
[19:38] >> Let me follow that thread.
[19:40] As the role has transformed in such a
[19:43] crazy way,
[19:45] some people are thriving, some people
[19:47] super frustrated, unhappy, fighting,
[19:50] resisting.
[19:52] What do you see common across the people
[19:55] that are doing really well, the
[19:56] engineers that have adapted and are
[19:58] thriving, versus the engineers and, you
[20:00] know, even outside engineering that are
[20:02] just like frustrated and having a bad
[20:03] time?
[20:04] >> I would say that a growth mindset
[20:06] really, really helps. Like actually even
[20:08] before, um, AI tooling, I found that has
[20:11] been just so valuable. And I I learned
[20:13] that a lot. Actually it was the shift
[20:14] from that, um, Microsoft to Meta. That
[20:17] was where I first real That first year
[20:18] I'm like, "Oh, this is what having a
[20:20] growth mindset really means." It's
[20:22] really this concept of always be
[20:24] learning. Be also what served you to get
[20:27] you to this point may not uh, will serve
[20:29] you no longer. But it's really hard
[20:31] because, of course, everybody like we
[20:33] all, you know,
[20:35] we've all gotten to the state by acting
[20:38] or, you know, like operating in a
[20:40] certain way. And so sometimes it is a
[20:41] little bit scary to think, "Wait, you're
[20:43] ask like but I've been successful so
[20:44] far. You're asking me to change what has
[20:47] made me successful." And so I I would
[20:49] say like the growth mindset is is
[20:51] really, really has has really served me
[20:53] well and I think it's also served others
[20:56] well, um, that that I notice. Like
[20:58] always leaning in with curiosity and
[21:00] always being able to learn. Um,
[21:03] and then in terms of like the
[21:04] frustration, I think sometimes I also
[21:06] see a little bit of fear.
[21:08] And so my advice there is at least this
[21:11] is how just in life I
[21:13] cuz we all have and fear is of course an
[21:15] evolutionary like I I didn't study
[21:18] anthropology, but I think it you know,
[21:19] it makes sense, right? It helps us make
[21:21] sure we were able to survive and not get
[21:24] eaten and you know, by by larger
[21:26] predators.
[21:27] But for anything that you know, that
[21:30] that there is a fear my advice is kind
[21:32] of lean in and ask, "Okay, is there some
[21:34] what can I do about it? What is within
[21:36] my control?"
[21:37] Cuz sometimes the frustration comes from
[21:40] fear and feeling like but everything is
[21:42] outside of my control and so it's
[21:43] happening to me.
[21:45] And so if you think about, "Okay, what
[21:46] is in your control?" Um
[21:48] it instead of happening to you, is it
[21:50] happening for you? And then what's
[21:52] what's something that you might be able
[21:54] to kind of like do and change? Like I
[21:55] felt that's been helpful cuz if not it
[21:58] it it it is super frustrating to have
[22:00] the fear and then feeling like
[22:02] everything's outside of your control.
[22:04] Like I actually remembered um
[22:06] when I was in actually when I was in
[22:08] high It's funny when we were going back
[22:10] to IBM. When I was in high school, I
[22:12] actually didn't go into computer science
[22:15] or engineering. Like I really want to be
[22:17] a visual artist. And this is how far
[22:20] back we go. Back then computers were
[22:21] really expensive. I actually didn't even
[22:23] have access to a computer. My first
[22:25] computer with access to computer was
[22:28] grade nine I think in high school. I
[22:30] don't even know this happens in high
[22:32] school anymore. My high school had a
[22:33] typing class. You know, a typing class
[22:36] just to learn how to type on a keyboard
[22:38] and learn to be really proficient and
[22:40] that was my first time and then you
[22:41] know, the next class was maybe like some
[22:43] HTML programming. So anyways, it it it
[22:46] but the reason why I fell in love with
[22:47] it was while what I love about art is
[22:49] creating and being able if you have an
[22:51] idea, you can go ahead and create and
[22:53] tell story. And then I realized, "Oh,
[22:55] computers and programming, you know,
[22:57] that that's that's enables me to do
[22:59] that." So anyways, I I tried to really
[23:01] fast try to make up for all the, you
[23:03] know, science classes for me to get into
[23:05] university, but I had this fear of, "Oh,
[23:07] but how will I afford to get into an
[23:09] engineering school?"
[23:11] And it was this big unknown. I grew up
[23:13] in Ontario, so I was very grateful. I
[23:15] knew there was an Ontario, you know,
[23:17] school assistance program, OSAP, I think
[23:19] it's called, which I'm very grateful
[23:21] for, but I didn't know how much of that
[23:23] would cover my tuition or like expenses,
[23:25] and it was just this unknown, and it
[23:26] would be like a year a year out. And I
[23:29] remember thinking, "Okay, what can I
[23:31] what can I do about it?" And then as as
[23:33] luck would have it, the National Bank of
[23:35] Canada just posted this flyer in our
[23:37] high school saying, "Hey, we're hiring
[23:38] high school interns to be a bank
[23:40] teller."
[23:41] And I remembered, "Oh, that like I And
[23:44] of course it was going to be minimum
[23:45] wage, but I I I I thought that that
[23:47] could be a lifeline." But it was funny
[23:49] cuz the class I hated the most in high
[23:51] school was accounting, so I don't know
[23:52] if I'd be any good at it at all, but I
[23:54] signed up to be a bank teller, and that
[23:56] ended up being such a great decision cuz
[23:58] I worked all summer, saved up, and then
[24:01] then actually I was able to work as a
[24:02] bank teller on the weekends. So, like
[24:05] yeah, well I would went to I would go to
[24:06] school Monday to Friday, and then on
[24:08] Saturday I'd be a bank teller, and that
[24:09] ended up being this lifeline that
[24:10] enabled me to, you know, like pay for
[24:13] all my school expenses. Um and you know,
[24:15] we talked about the the year 2000 dot
[24:17] com crash, then when folks weren't
[24:19] hiring as much interns, actually I
[24:20] continued being a bank teller for for
[24:23] two two years. And And so, but
[24:26] but like that was the one action I
[24:28] thought I could take that was within my
[24:30] control to try to counter this fear I
[24:32] have of if I'm really going to go down
[24:34] this path, I don't even know if I could
[24:36] have afforded to go to school. So,
[24:37] that's probably my other advice of like
[24:39] growth mindset, and
[24:41] the source of, you know, frustration or
[24:43] anxiety, if it's coming from, you know,
[24:45] the like see is there some Is there one
[24:48] action that's within your control that
[24:50] you can take um to, you know, so it it
[24:53] it like cuz I think there's you you
[24:55] there there was a saying like do
[24:56] something What would you do if you're
[24:58] not afraid actually? Those were my two
[25:00] favorite sayings before like what would
[25:01] you do if you're not afraid and do
[25:02] something scary once in a while cuz
[25:04] that's also usually how we grow. Um I
[25:06] found that when you're when you're
[25:07] really good and professional at what you
[25:09] do, you're kind of at peak, you know,
[25:11] like maximum efficiency, but then how do
[25:13] you keep growing is you then do
[25:15] something scary that you might not have
[25:16] done before and yeah, you will cut have
[25:17] a dip because you need to learn.
[25:19] But that's kind of how you um keep
[25:21] pushing yourself to learn.
[25:22] >> The quote that I have probably used the
[25:24] most on this podcast of all quotes is
[25:27] the cave you fear contains the treasure
[25:29] you seek.
[25:30] >> Oh, I love that.
[25:32] >> Yeah, and it's so true. Just like like I
[25:35] forget who put this, but just the thing
[25:36] that is scariest is like that's a
[25:38] compass towards that's what you should
[25:39] be doing.
[25:41] >> Mhm. I'm going to I'm going to steal
[25:42] your quote.
[25:43] >> Yeah, then please do. Like, you know,
[25:45] there's like don't do all the scary
[25:46] things, like maybe don't jump off a
[25:48] cliff, but maybe in career in career
[25:50] moves it's probably a good a good
[25:52] choice.
[25:53] So, kind of following this path,
[25:54] something that
[25:56] I know that is important to you,
[25:58] something you think about that I also
[25:59] think about is this kind of gap that is
[26:02] forming between people that are just
[26:04] like leaning into AI, killing it, doing
[26:06] super well, and then people that are
[26:08] just like not. And this is like
[26:10] a scary time for people that may be left
[26:13] behind in this uh new world that is
[26:15] emerging. Uh I know you spend a lot of
[26:17] time with small businesses. That's a big
[26:18] passion of yours to help people learn
[26:20] how to use AI in their work. Talk about
[26:22] just like how you think about that and
[26:24] what maybe we should be thinking about
[26:26] to help folks, you know, stay not not
[26:29] fall behind basically.
[26:30] >> Oh, I I I love this. Yeah, it's one of
[26:32] my passion topics cuz uh I kind of
[26:35] mentioned, you know, like growing up in
[26:36] Canada. Um and I I moved there when I
[26:39] was a kid. Uh I was born in Hong Kong.
[26:42] So, I didn't speak any English and my
[26:43] parents had to work all the time. So, my
[26:45] grandma who is the best grandma that
[26:47] anyone could have ever asked for. I know
[26:49] everybody thinks their grandma's the
[26:50] best, but I really was so lucky. I had
[26:52] the best grandma. She moved with us uh
[26:55] just to take care of me while my parents
[26:56] were working. But neither of us spoke
[26:58] English, but I was able to learn how to
[27:01] speak English by you know going to
[27:02] school and speaking with classmates. And
[27:04] when I think about my grandma, it was a
[27:05] very alienating for her to be you know
[27:07] in the country new country where and you
[27:09] know back then it wasn't as walkable. Um
[27:12] but one summer I remembered we just
[27:14] happened to find this little yarn shop
[27:17] uh that was owned by a lady that also
[27:18] spoke Cantonese. And so that became
[27:21] every week to this yarn shop this summer
[27:23] and my grandma found her knitting circle
[27:25] and then I think I learned how to do
[27:26] like macrame.
[27:28] Uh which I think is having a comeback by
[27:30] the way. It's all it's always funny to
[27:31] see what's
[27:32] >> Macrame coming back?
[27:33] >> Macrame I think yeah. You heard it here
[27:35] first on Lenny's podcast. I think
[27:37] macrame's coming back.
[27:38] >> All right.
[27:39] >> Um but but that was probably where my
[27:41] love came from. I'm like oh wow this
[27:42] little small business created this
[27:43] wonderful sense of community. And I've
[27:45] been really fortunate to you know become
[27:47] friends with all the small businesses
[27:49] that that I love. So that that's kind of
[27:51] like where the passion comes from. And
[27:52] then um what how it happened was I was
[27:55] using Co-work for my own uh business uh
[27:58] expensing travel. I don't know what it
[28:00] is. I really don't like doing business
[28:02] expensing. And when I was using Co-work,
[28:04] it was magic. I'm like
[28:06] all these things that I don't like to do
[28:08] like Co-work is doing for me. And I'm
[28:09] like wait a minute all my friends and
[28:11] honestly small business owners they
[28:12] really bust their butt. Like they work
[28:14] incredibly hard um and they use you know
[28:17] like sometimes might be operating on
[28:18] really small margins.
[28:20] And so I thought if it's if Cloud
[28:22] Co-work is so good at helping me do my
[28:25] little you know business travel expense,
[28:27] this would be huge for it cuz I I see my
[28:29] friends sometimes sitting at the bar
[28:31] with stacks of bills and all they're
[28:32] doing is invoicing and expensing. And
[28:35] and I think nobody actually really likes
[28:36] to do it. So that's kind of uh where it
[28:39] came from. And then so yeah I remembered
[28:41] uh
[28:41] like helping uh a couple of them
[28:43] onboard. And and uh it was also very
[28:46] humbling to to see them go through our
[28:48] onboarding flow. Actually, it found some
[28:50] really good bugs. So, [snorts] it was
[28:52] really like a win-win, but it was also
[28:54] delightful for me cuz they also use Coda
[28:55] in in ways that I I wouldn't have
[28:57] thought about cuz I was all fixated on
[28:59] look at how it is amazing with PDFs and
[29:01] invoice. And then, um
[29:02] you know, one of my friends who who runs
[29:04] two restaurants, she's like, "Oh my
[29:06] gosh, this folder I have is like a junk
[29:08] drawer of like it it's basically our,
[29:11] you know, documents folder just becomes
[29:12] this junk drawer of every or downloads
[29:14] like just a you know, like junk drawer.
[29:17] And she's like, "I know I have a few
[29:18] menus in here and I can't find it." And
[29:20] I'm like, "Well, let's ask Coda." So, we
[29:22] gave Coda access to directory, found the
[29:23] menus. And then, she uses it in a really
[29:25] unique way. She goes like, "I want to
[29:26] make sure I keep my prices reasonable
[29:28] for locals and tourists." So, she goes,
[29:30] "Hey Claude, look across my style of
[29:32] cuisine in this area is a comparable."
[29:35] And it came back with really cool almost
[29:37] like market analysis. And she goes,
[29:39] "Hey, I actually just went to that
[29:40] restaurant in Seattle and that was
[29:41] pretty good." Um so, I learn something
[29:43] every time. And uh and yeah, they've
[29:46] been like giving me great feedback as
[29:47] well.
[29:48] >> So, the question then is just like how
[29:50] do we how do we spread this to
[29:51] everybody? Because as you see, you know,
[29:53] there's like like a lot of people are
[29:55] just like, "I don't have time for this."
[29:56] Or "I hate AI." It's just like I want to
[29:58] ignore it. Is it like talking is it just
[30:00] talking about this sharing examples?
[30:02] What do you think? How do it What's like
[30:04] a way to make a dent in this
[30:06] uh in this problem?
[30:07] >> For all of us as especially to your
[30:09] listeners are probably very AI pilled.
[30:11] If there's anyone either in their
[30:13] community or their family that that has
[30:16] like I would start with what has
[30:18] something that really you felt um
[30:21] has that you really have felt has made a
[30:23] meaningful life change uh for you with
[30:26] with the AI tools. And then, seeing if
[30:28] that is a conversation starter for cuz
[30:30] for me AI is a tool. Again, it's the
[30:31] whole light in the dark. I totally
[30:33] understand the frustrating part as well.
[30:35] But for me, I'm also felt like knowledge
[30:37] is power. Like have to learn how to use
[30:39] the tools because it could actually, you
[30:41] know, be the light part of that light
[30:42] and dark equation. So, I think that that
[30:45] would that's something that I would love
[30:47] everybody's help with of if there's
[30:48] whether it's a community member or even
[30:51] if there's a business you really like
[30:52] and think, "Hey, have you ever It's It's
[30:54] It's a little awkward to start." Like I
[30:56] remember when I first reached out to my
[30:57] friends, I'm like, cuz I don't talk
[30:58] about what I do
[31:00] with them a lot, but I'm like, "Hey, I
[31:02] kind of you know, work in AI. Can I Can
[31:04] I It sounds It's It's even unnatural for
[31:07] me to do cuz I'm you know, like, I'm
[31:08] like, "Hey, can I show you what you
[31:10] know, Codoxer is possible?" And and and
[31:12] then but it end up we end up having a
[31:14] lot of fun. So, yeah, I would love for
[31:16] like that conversation starter
[31:19] would be great of Yeah, cuz I just want
[31:21] to make sure we keep sharing the the
[31:23] knowledge and you know, making the tool
[31:24] equitable cuz if not, I'm
[31:26] concerned that the divide grows larger
[31:28] and larger.
[31:29] >> Me, too.
[31:30] I find that sharing use cases as you
[31:32] said is it's so powerful. I was just
[31:34] using Codoxer the other day to fill out
[31:35] my my son's camp forms. And just sharing
[31:39] that on Twitter just like a lot of
[31:40] people are like, "Oh, wow, I didn't
[31:41] think about that."
[31:43] Yeah, it's just like these little things
[31:44] you don't think about that Codoxer and
[31:45] Claude can do.
[31:47] Kind of along those lines, speaking of
[31:48] Codoxer,
[31:49] if you think about it, Anthropic has
[31:52] been super early on uncovering these
[31:55] really big opportunities ahead of
[31:58] everyone else. For example, coding. So
[32:01] far ahead. Like realizing this is a huge
[32:03] market. Whether it was intentional or
[32:04] not, uh it was just like, "Whoa, that's
[32:06] maybe the biggest
[32:08] new business opportunity in history." Uh
[32:10] and then Codoxer is a great example just
[32:12] leaning into knowledge work. Let's just
[32:15] make Let's just solve all the knowledge
[32:16] work. Why not?
[32:17] So far ahead of everyone else.
[32:19] Another element is it feels like a focus
[32:22] on the personality of the model,
[32:23] something you all were very early on
[32:25] just how important that is. Not just for
[32:27] the experience, but just also the
[32:28] intelligence and success of the model.
[32:31] What is it that you think Anthropic and
[32:33] the teams do
[32:35] differently that allows you to uncover
[32:38] these opportunities and then just go big
[32:40] on them before other labs, let's say.
[32:43] >> Well, I haven't worked in any other
[32:45] labs, so I'm not sure how other labs
[32:47] operate, but I I will share like yeah,
[32:49] with um
[32:50] and like actually on the Claude Code
[32:51] team as well and co-work like we also
[32:53] keep an eye on like latent demand. Now,
[32:56] we're very fortunate with coding as a
[32:57] use case because so many ants that we
[32:59] were, you know, like our our own first
[33:01] customers and we're able to do like
[33:02] really rapid feedback and and so I think
[33:05] um but latent demand has has been like a
[33:07] like for example, like co-work we
[33:09] noticed hey, a lot of folks that were
[33:10] not necessarily coders were were using
[33:12] Claude Code. Can we make that experience
[33:13] better? Um I think that's actually even
[33:16] outside of Anthropic that served me well
[33:18] in in all the different products I've
[33:20] worked on. Um but uh and and actually
[33:23] it's funny you mentioned like, you know,
[33:25] the the Claude's for uh you know, my
[33:27] passion with small business after I, you
[33:29] know, had had a few of these visits, we
[33:30] ended up now launching Claude for small
[33:32] business.
[33:33] Which is really cool cuz I and and it
[33:34] totally didn't come from me, so I'm not
[33:36] taking credit, but I noticed it too of
[33:37] like when I was working with and they
[33:39] because they were asking me, oh, does it
[33:40] have this plugin right this plugin? I'm
[33:42] like, I think it does and then we have
[33:43] to, you know, go and search for it. So,
[33:45] actually now Claude with small business
[33:46] bundles it all up, so inside co-work you
[33:48] just have this little toggle. And uh
[33:51] there were there were there was a
[33:52] wonderful team that's been kind of like
[33:53] uh
[33:54] you know, doing uh co-work sessions with
[33:56] small business that probably found hey,
[33:57] we could have like an efficiency gain
[33:59] here. Um
[34:00] or like make the experience better.
[34:02] And so I would I would say like always
[34:05] uh not only for products that you're on
[34:07] like making sure you're always
[34:08] you know, listening to feedback and
[34:10] always iterating, trying to make a
[34:12] delightful, reliable, high-quality
[34:14] experience, but then also keeping an eye
[34:16] out for oh, what are these other use
[34:17] cases that that are popping up and can
[34:20] we also make that experience better? Um
[34:23] it's it's interesting like after like,
[34:25] you know, in software I've learned that
[34:28] customers will use your product in ways
[34:30] that you did not intend for good or for
[34:32] bad. And so the the best way is really
[34:36] like it's all about the iteration learn
[34:37] and keep close to the feedback.
[34:40] >> Wait in demand. That's a that term's
[34:41] come up a bunch on this podcast.
[34:43] >> It's on there.
[34:44] >> Might be something there.
[34:45] >> So essentially it's just watching
[34:46] closely for
[34:48] behavior that you may not have expected
[34:50] or that is just kind of emerging.
[34:52] And then just going big on that
[34:54] essentially, exploring it, building
[34:55] something.
[34:56] >> Yeah.
[34:57] And having a hypothesis for hey, like
[35:00] because actually when you see people
[35:01] jumping through hoops to make something
[35:02] work,
[35:03] can you actually make that an even like
[35:06] a smoother and and better experience?
[35:08] >> Yeah.
[35:09] Coming back to the way that your teams
[35:11] operate,
[35:12] you guys are so at the edge of what's
[35:14] possible.
[35:16] And the role of just engineering has
[35:17] changed so much. I'm curious what you
[35:19] think is the next kind of frontier of
[35:21] how engineering in particular is going
[35:24] to change. Is it like I don't know,
[35:26] fleets of agents? Is it something else?
[35:29] Just like what's like the next big shift
[35:30] to how engineers operate that either
[35:32] you're already working on or
[35:34] implementing or just like it's starting
[35:35] to happen?
[35:36] >> I would say we're shifting more towards
[35:38] async, like asynchronous. And so to your
[35:40] point, the the fleets of agent, like
[35:42] that that's why routines is so
[35:43] interesting cuz almost like I used to be
[35:45] like you know, doing a prompt and
[35:47] synchronously. And then I would like
[35:49] maybe like kick off different prompts
[35:51] async asynchronously. But now I can
[35:53] actually have a routine that actually
[35:55] generates, you know, these these prompts
[35:57] for me. So it's almost like the level of
[35:59] abstraction keeps pulling up a little
[36:01] bit. And so I I would yeah, I
[36:04] wish I had a crystal ball to see what
[36:05] this is going to look like. It'll be fun
[36:07] actually for you and me to revisit a
[36:08] year from now.
[36:09] >> No, I I want to hear more about this.
[36:10] This is So help us understand what is
[36:12] what is routines and then what is what
[36:14] do you say asynchronous? You're
[36:16] writing a prompt and it just kind of
[36:18] goes off and is it writing it
[36:19] immediately? Talk about what this
[36:20] actually looks like.
[36:21] >> Uh yeah, so routines is like how you can
[36:24] like so if you remember I was talking
[36:25] about my what I used to do is always
[36:27] like you know, wake up with my morning
[36:29] cup of coffee and hey, look at through
[36:30] this slack channel for me. But then now
[36:33] like I have a routine that I set to run
[36:35] every morning at a certain time to say
[36:37] hey.
[36:38] >> Mhm, that's right. But then it's able to
[36:40] actually go and kick off agents on your
[36:42] behalf. And so that's cuz like that's
[36:44] what like you know, even you know,
[36:46] before it would be oh you you could like
[36:48] yeah, do a cron job to automate like but
[36:50] now it's hey, look at these feedback and
[36:52] then if you're seeing some of these bugs
[36:54] that what are some polish fixes that you
[36:55] might be able to to knock out and then
[36:57] it would like go kick off and then I
[36:58] wake up and I end up having PR's that I
[37:01] could review versus before which is
[37:02] still more of a kind of different agents
[37:04] that and then it's still I'm still
[37:06] thinking about okay, now what do I do
[37:07] with this information? So it's like that
[37:09] higher level abstraction of okay, now
[37:10] how can I actually write a routine that
[37:12] also basically does prompts for me for
[37:15] spawning different agents. So I think
[37:18] we'll we'll move more towards that kind
[37:20] of like asynchronous style of working.
[37:22] >> So interesting. So like in a sense as a
[37:24] manager, you have these kind of things
[37:26] you do daily and what you're saying here
[37:28] is you can set up these prompts that
[37:30] kind of check in every day on the things
[37:32] you would have be be doing like how are
[37:34] the projects going? What's falling
[37:35] behind? What should I unblock? Who is
[37:38] who's struggling?
[37:40] What's how do I fix some improve some
[37:42] some polish? And so the idea here what
[37:44] you're describing here is kind of write
[37:45] these things that you almost do as a
[37:46] manager daily and have Claude
[37:49] essentially do them for you and then
[37:50] show you here's what I'm doing here's
[37:52] what I here's what there's to review.
[37:53] >> And then it's it's even like then giving
[37:56] even more autonomy at some point of it.
[37:58] You know what like go for it. Like for
[37:59] example, if the verification is really
[38:01] good, go go [laughter] for it.
[38:02] >> see. So you give it like a little bit of
[38:04] freedom to do more of this.
[38:05] Yeah. That is so interesting. It reminds
[38:08] me speaking on this idea of go for it. I
[38:09] don't like I wasn't planning to talk
[38:11] about this, but I just watched Tyler
[38:13] Cowen had this awesome talk about just
[38:15] like what's happening. I don't know if
[38:16] you know Tyler Cowen is really smart
[38:18] dude economist has a podcast.
[38:21] And he just had like there's so much
[38:22] talk of
[38:24] the people that are doing best in this
[38:25] world,
[38:27] his term is initiative. They have
[38:29] initiative. Another term people use
[38:31] agency.
[38:33] Is that something just like you know
[38:35] people hear this a lot just like the
[38:36] people that seem to be doing best are
[38:38] taking the most initiative, getting the
[38:39] most proactive, have the most agency.
[38:41] Does that Does that kind of spark any
[38:43] thoughts to you just what people may
[38:45] need to I don't know think about or
[38:46] improve on?
[38:47] >> Actually that's agent it's that word
[38:50] agency. That's what we really hold
[38:51] important on the cloud code and code
[38:53] work team. But it's interesting I say
[38:55] along with high cuz it's like we really
[38:57] it's about like hey here's a problem and
[38:58] then it's really everybody on the team
[39:01] has ideas for how to address the
[39:02] problem. So it's really high agency and
[39:04] then we say with high agency is also
[39:06] high accountability. So it's all about
[39:08] like making sure folks have that freedom
[39:10] to cook. You know they and but then it's
[39:12] also like okay what's the accountability
[39:14] for it as well and that's where and
[39:17] again it goes back to like what's the
[39:18] hypothesis of what you're you know like
[39:20] trying to solve. So I think yeah the the
[39:21] balance like or you know almost like two
[39:24] sides of the same kind of agency and
[39:26] then accountability I think has served
[39:28] our team really well.
[39:29] >> Such an important element.
[39:31] Have a agency. Okay cool. Everyone's off
[39:33] doing stuff but okay what have you
[39:34] actually [laughter]
[39:35] what have you busted up?
[39:37] What have you done?
[39:38] So kind of along those lines
[39:40] it feels like there's this vibe shift
[39:41] recently from token maxing just go crazy
[39:44] spend as much as possible just see
[39:46] what's possible to like wait what are we
[39:48] actually getting out of this? How much
[39:50] is it costing? What's the ROI?
[39:52] Interestingly Boris was actually like
[39:53] head of product inch productivity at
[39:55] meta that was like his job is measuring
[39:58] inch productivity and uh
[40:00] and then also just this like tweet of
[40:02] lines per code like code ship like
[40:05] there's this like interesting discussion
[40:06] of just how do you actually measure
[40:08] productivity increase and ROI
[40:10] of
[40:12] AI tools in spend. How do you like you
[40:15] know you guys have the infinite
[40:15] advantage of getting free free tokens
[40:17] working at Anthropic.
[40:19] With that in mind,
[40:20] what what have you learned about just
[40:22] how to measure, say, ROI of engineers in
[40:26] today's world?
[40:27] >> This end productivity is such a
[40:29] fascinating topic. Um yeah, cuz I
[40:32] remember, you know, like like even for
[40:34] us mentioned, like you know, we'll first
[40:35] start with like lines of code. And then
[40:37] that's throughput and then I remembered
[40:38] once then there was a debate of, well,
[40:40] lines of code, this engineer had this
[40:41] crazy lines of code, but they just took
[40:43] some library and then just was porting
[40:45] it. So, they checked it in and then I
[40:46] was like, well, maybe it's significant
[40:48] lines of code. And then it's, well, but
[40:50] what if we're, you know, updating our
[40:51] frameworks and now we're generating less
[40:53] code, but like the output's still the
[40:55] same. So, now I'm like, okay, maybe it's
[40:56] it's like time to land PR. Like but but
[40:59] it's very interesting of it's always
[41:01] been whichever metric, it's it's um like
[41:05] if if you're really focused on the out
[41:07] like my advice here is
[41:10] one is output like is the output really
[41:13] going towards the outcome? Cuz yeah,
[41:15] like the the the the token maxing, it's
[41:17] kind of like a
[41:18] it's almost like the lines of code that
[41:20] we used to have, but I'm really much
[41:22] more about a um what is it that we're
[41:24] trying to to do? Like all all of this,
[41:27] you know, there there was another saying
[41:28] I really like, don't forsake motion for
[41:30] progress. Um because if you're measuring
[41:33] like, you know, like tool user usage,
[41:35] then you're you're measuring the action,
[41:37] but is it really making whatever the end
[41:39] outcome of yours like important?
[41:41] Um and so I I really uh try to zoom out
[41:45] and focus on what is the problem we're
[41:47] trying to solve? What's a good way to
[41:49] measure that? And then that's what we we
[41:51] focus mostly on versus kind of like the
[41:54] the the productivity measurement. Um
[41:57] I would say though, like outside of
[41:58] metrics, especially if on teams as
[42:01] you're having more people adopt AI
[42:03] tooling, I would say definitely go um on
[42:05] a listening tour for for the for the
[42:07] leaders listening to a podcast,
[42:08] especially, you know, um I I love to
[42:11] focus on the senior engineers as well.
[42:12] Like hear from them on what's working,
[42:14] what's not, how can we actually make it
[42:15] better cuz they will also help you
[42:17] multiply and scale that out across a
[42:19] full engineering team. And sometimes
[42:21] there's those conversations where you
[42:22] might get sparked an idea that comes up
[42:24] and also really good shared learning
[42:26] versus um, you know, like metric
[42:28] dashboards. It's very interesting. I've
[42:31] learned some good lessons from metrics.
[42:32] I'm all about like it's really great
[42:35] when you have a a metric that you can
[42:37] actually hill climb on, but always keep
[42:39] in mind that is you know, my whole
[42:41] growth mindset of is it still serving
[42:43] you? Always keep in mind like is that
[42:45] metric really uh, still serving the
[42:47] outcome that you were aiming for.
[42:49] Um, like a fun example I have with this
[42:51] is in the early
[42:53] Facebook Marketplace days, we were kind
[42:54] of like launching by region and we
[42:56] really want to make sure we're building
[42:57] a delightful product before we expand.
[43:00] And I remember in the early days what
[43:02] one thing we would keep an eye on is
[43:03] kind of like number of sellers. And I
[43:05] remembered after launching our first
[43:07] region, I'm like how in this area the
[43:09] number of sellers is low, but actually
[43:11] people are like people are finding items
[43:13] that they're looking for which is what
[43:15] we're aiming for like helping people
[43:16] find items that that they need. And then
[43:19] I realized in that region it wasn't uh,
[43:21] large number of sellers, but there were
[43:22] power sellers.
[43:24] But our first gate before we expand
[43:26] would have just been like you know,
[43:27] factoring heavily number of sellers and
[43:29] I remember that quick conversation of
[43:31] hey, and this goes back to that whole
[43:32] people will use things in ways you may
[43:33] not expect and ship better rate learn.
[43:36] And so so then we updated the the metric
[43:39] to go oh, you know, like it's not uh,
[43:41] number of seller cuz it didn't factor in
[43:42] power sellers. And so that's the advice
[43:45] I have to like whatever metric whether
[43:47] for productivity or even for product,
[43:49] always keep an eye and make sure that
[43:52] you're not just having blinders on
[43:53] that's blindly following a metric that
[43:55] used to make sense cuz sometimes the
[43:56] landscape can change so fast. Uh, even
[43:59] the metrics themselves might need to be
[44:00] adjusted.
[44:01] >> And this comes back to your
[44:03] uh, process that you shared of having
[44:06] Claude watch all the PRs shipping per
[44:09] engineer, let's say, and then not
[44:11] focusing on the metrics but focusing on
[44:13] that leading to a conversation about
[44:15] what impact this have, what was maybe
[44:17] some bugs that happened, and that being
[44:19] a really powerful way of understanding
[44:20] how what's going on with this engineer.
[44:23] >> Awesome.
[44:25] >> Let me come back to this just this
[44:26] question of speed and quality and just
[44:28] like
[44:29] impact. Uh is there anything else you've
[44:32] learned about just how to
[44:34] balance those things? Just like there's
[44:35] a crazy velocity of code that's being
[44:37] generated and just stay on top of
[44:40] quality and impact. Is there anything
[44:41] else there that might be helpful to
[44:43] other teams that are trying to wrangle
[44:44] all this all these PRs being shipped
[44:46] every day?
[44:47] >> I would say, and this is what honestly
[44:49] we we were we want to keep doing more of
[44:51] and and being better at it, too. Like
[44:53] the proactive quality, so especially for
[44:55] quality, making sure that what are the
[44:57] experiences that are key and making sure
[45:01] you actually is you actually speak of
[45:02] metric. Those are really good things
[45:04] that you you make sure you can look kind
[45:06] of like see trends over time.
[45:08] Um and so like on the quality front, we
[45:10] found like um
[45:11] and this is like the more proactive we
[45:14] can be of like making sure we can get an
[45:16] earlier detection into uh quality. And
[45:19] and so like um
[45:21] that's been one thing that we've been
[45:22] paying a lot of attention to. Like so
[45:25] like you know I I I started this, "Hey,
[45:26] let's have a concept of what's bad
[45:29] versus what's sad." And bad is like a
[45:31] very bad irrecoverable error. And sad is
[45:33] something that's kind of like a pain
[45:35] point recoverable, but it's interesting
[45:36] when you stack up sads, it could, you
[45:38] know, generally go to bad. But even
[45:40] having a like starting with a high-level
[45:42] framework like that and because of not
[45:43] like I think sometimes with dashboards
[45:45] you can have you know, like uh time to
[45:47] load or all these other, but when you're
[45:49] dealing with a lot of different product
[45:50] surfaces, it's harder to go, "Wait, is
[45:52] that a good number or not a good
[45:53] number?" And so one thing that's helped
[45:55] us is versus just raw, you know, like
[45:58] performance or uh uh, you know, like
[46:00] reliability numbers, also having some
[46:03] framework of what we think is, you know,
[46:05] like a a bad experience and making sure
[46:07] we're focused on addressing those and
[46:09] then also keeping an eye on where we
[46:11] seeing in terms of the sad. That That's
[46:13] helped us a little bit.
[46:14] >> I like the bad and sad. So, these are
[46:15] kind of like thresholds of this is bad.
[46:16] Okay, this is serious. And this is in
[46:18] terms of like performance or or or
[46:21] failures or what what what sort of
[46:22] things are you measuring here?
[46:23] >> Uh, so for example, like we we allow
[46:25] each team like speak of agency. So,
[46:27] knowing that bad is like a really bad
[46:29] irrecoverable error. We enable each team
[46:31] of further surface areas or it could be
[46:33] services that, you know, they lead. What
[46:35] What is like so for example, on CLI
[46:37] could be crash rates. Like a crash is
[46:39] pretty bad. You lost work.
[46:40] Um, and for example, a sad might be,
[46:42] "Hey, is it flickering?" Like it might
[46:44] be recoverable. But we have each team
[46:46] like and and that's why it's been
[46:47] interesting because before each because
[46:49] surface areas are different, like we
[46:51] would have all these dashboards of but
[46:52] it's it's harder to zoom out and go,
[46:54] "Okay, what's the overall theme of the
[46:56] experience?" So, to your point, we give
[46:58] high agency to each team what we think
[47:00] constitutes a bad and what's a sad and
[47:03] then what's the goal that um, each team
[47:05] wants to take.
[47:06] >> One of the like the main takeaway I'm
[47:07] hearing here is uh, one of the best
[47:09] tools for staying on top of quality is
[47:12] just uh, monitoring and tests versus
[47:16] spending more time reviewing, which
[47:18] makes sense because the speed is just
[47:20] impossible to stay on top of and it
[47:22] almost speaks to this idea of closing
[47:23] the loop for agents to be able to kind
[47:26] of figure things out themselves. They
[47:27] know what success looks like. Cool,
[47:28] we'll fix it ourselves. So, that's a
[47:30] really interesting takeaway is just
[47:31] invest more in the tests.
[47:33] Evals I imagine is part of this and then
[47:35] just like monitoring failures and speed
[47:37] and things like that.
[47:38] >> That's right.
[47:39] >> Something I think this is public. I I
[47:41] know that you guys have this dashboard
[47:42] that tracks just like F-words, like how
[47:44] often people are like
[47:45] >> [laughter]
[47:46] >> cuz they're so pissed and frustrated.
[47:47] There's like a funny term for it, I
[47:49] think. I forget what it's called.
[47:50] >> Yes. Actually, I remember yeah, that was
[47:52] last September cuz we were all we were
[47:54] all seeing some frustrations and uh,
[47:56] yeah, that was an engineer on the team
[47:57] of hey, we should maybe track swear
[47:59] words. I'm like, oh
[48:00] that's a great idea. I remember it. I
[48:02] had just, you know, joined and we were
[48:03] having that really fun conversation. Um
[48:05] yeah, so it's it's again like it it's
[48:07] very interesting to kind of like look at
[48:09] um and and that's why like Evals is hard
[48:11] too because it's
[48:13] going back to like that user experience
[48:14] and how we can make sure it's a
[48:16] delightful experience and less
[48:17] frustrating. But yeah, the the swear
[48:19] word dashboard is is a fun one.
[48:21] [laughter]
[48:22] >> This episode is brought to you by
[48:23] Mercury.
[48:24] >> Radically different banking loved by
[48:26] over 300,000 entrepreneurs and now with
[48:29] command. I've been a customer of
[48:31] Mercury's for over 6 years. I have never
[48:33] once thought about leaving. Mercury is
[48:35] basically what happens when banking is
[48:37] built by product people, not by bankers.
[48:40] [music] They make it so easy, dare I say
[48:42] fun, to send invoices, move money
[48:45] around, set up virtual cards for folks
[48:47] on my team. Does your bank have an API,
[48:50] a terminal native CLI, or an AI ready
[48:53] MCP server? I don't think so. And just
[48:56] recently they launched command, a
[48:58] conversational interface built directly
[49:00] into Mercury, which acts as your
[49:02] financial operator. I've been using
[49:04] command to transfer money around, to
[49:05] figure out what categories I've been
[49:07] spending the most money in, analyze my
[49:09] cash flows, and [music] just today I
[49:11] used it to find out how much I've made
[49:13] from a specific sponsor over the past
[49:15] year. I just asked, [music] "How much
[49:16] have I made from X over the past year?"
[49:19] 10 seconds later I have an answer.
[49:20] >> [music]
[49:20] >> It is so freaking cool. Visit
[49:22] mercury.com to learn more and apply
[49:25] online in minutes. Mercury is a fintech
[49:27] company, not an FDIC insured bank.
[49:29] Banking services provided through Choice
[49:31] Financial Group and Column N A, members
[49:33] FDIC.
[49:35] >> Kind of going back to the way you
[49:36] operate and ways that you've figured out
[49:37] to work in this crazy new world that
[49:39] we're in.
[49:39] Um I've heard about a couple things that
[49:41] you've implemented that are pretty
[49:42] unique, I think, to uh how teams operate
[49:45] and I think is something that has worked
[49:46] really well for you. One is making every
[49:49] manager start as an IC and then just
[49:52] every manager has to continue being an
[49:54] IC part-time kind of this player coach
[49:56] approach. Talk about that, why that's so
[49:58] important in today's world.
[50:00] >> Mhm, I love it. Um, it's funny when I
[50:02] first joined cuz I I and I have amazing
[50:05] recruiting partners and I I noticed we
[50:07] were you know this whole theme of um
[50:10] kind of growth mindset. It's just
[50:11] because the landscape is changing so
[50:12] fast. Like
[50:13] what worked well before like may not
[50:15] make sense and even what makes sense
[50:17] today may need to change tomorrow,
[50:18] right? Like that's what I have to keep
[50:20] reminding myself. So yeah, when I first
[50:22] joined recruiters like, "Okay, yeah, we
[50:23] have these um couple like manager
[50:25] postings." And I'm like, "You know, cuz
[50:27] actually how it came from like a
[50:28] listening tour I did with like all the
[50:30] all the um members on the team. Of and I
[50:33] heard a lot of these, "Hey, I really
[50:35] appreciate the agency, but how can I
[50:36] make sure prioritization?" And And so I
[50:38] kind of through that I I um I realized
[50:41] and then there was some really good
[50:42] feedback too of making sure that um it's
[50:44] not too many layers of reviews. Like
[50:47] there was good feedback. Some folks have
[50:49] might have drawn from like companies are
[50:50] like, "You know, and and then I'm like,
[50:51] "Hmm." When
[50:53] I actually think as a as a leader, if
[50:55] you actually start as IC first without a
[50:58] like worry of supporting people cuz
[51:00] that's a very heavy responsibility that,
[51:02] you know, I think like managers, but
[51:03] like that but before you have to take on
[51:05] that full responsibility, give yourself
[51:08] that maker time to actually type deep
[51:10] into the code and learn the code base
[51:13] and I I
[51:14] or or the product, like whatever it is.
[51:16] It doesn't have to like honestly the the
[51:18] PRs I do are like but it's more about
[51:20] for me it's important because it keeps
[51:21] me in the flow because we're making so
[51:24] many changes to co-work and code. So
[51:26] even me doing PRs it's less about what
[51:29] it is I'm fixing, it's more about me
[51:31] using the the product every day just to
[51:33] keep that touch cuz as amazing as
[51:34] metrics and everything are and I do look
[51:36] at those dashboards, if you as a leader
[51:39] if if you're not, you know, like living
[51:41] and breathing your your product every
[51:43] day you you sometimes kind of like lose
[51:44] touch of uh touch and feel of the
[51:46] product.
[51:47] But anyways, on the manager front, I
[51:49] think giving time for managers that join
[51:51] to be able to go deep into do that
[51:54] before supporting people. And then they
[51:56] actually like end up building really
[51:58] great rapport with the team. Like
[52:00] because if not, I I think sometimes as
[52:02] managers, you know, you might come and
[52:03] join a new team and you instantly think,
[52:05] "I have to manage. Let me dig into my
[52:07] manager toolbox and and do manager-y
[52:10] things." But if you actually give
[52:11] yourself time to not have to worry about
[52:13] that first and actually learn what it's
[52:14] like to be an engineer and teammate on
[52:16] the team. That also goes really far um
[52:19] to to building rapport. And and in and
[52:22] in terms of like using the product, I
[52:24] think that's that's it's it's
[52:25] interesting. Every team I've joined, one
[52:27] of the first actually across all the
[52:29] different products. It could be
[52:31] VR, it could be smart glasses, it was
[52:33] like Instagram. Usually when I first
[52:35] joined, one comment that comes back to
[52:36] me is, "Hey, you know what? I really
[52:38] love how you're actually using what we
[52:39] build. It's It's refreshing to see, you
[52:42] know, you giving user feedback." Like
[52:43] Like and and so I think as leaders too,
[52:45] it's also a way for us to experience
[52:47] that the work uh personally that the
[52:49] team does.
[52:50] >> Something that people may not realize,
[52:52] uh you were overseeing a an org of like
[52:54] 500 people at Meta before you moved to
[52:56] Anthropic, right?
[52:58] And you moved to IC IC engineer
[53:00] basically at Anthropic from that.
[53:03] >> I started out like it was for a very
[53:05] short short amount of time. But but um
[53:07] actually this was my journey between
[53:09] Microsoft and Meta. So at Meta, I
[53:11] interviewed as a manager, but I think at
[53:13] least for the first quarter, I was also
[53:15] an IC um because I really wanted to
[53:17] learn what it's like to be a Meta
[53:18] engineer because before then I was at
[53:21] Microsoft kind of like cut my teeth on
[53:22] engineering at Microsoft. So I knew all
[53:24] the code bases, the tools, the
[53:25] languages. And uh yeah, but it was so
[53:28] valuable to have the the those first
[53:31] months like actually learn what it's
[53:32] like to ship uh as a Meta engineer. Plus
[53:35] it was also fun. Like I think sometimes
[53:37] we forget if we like And but that's by
[53:39] the way what I love about Claude code.
[53:41] Because um the last time I shipped
[53:43] production software at Metal is probably
[53:46] 2017.
[53:48] And every year I might start like I do a
[53:50] lot of dog fooding and a lot of, you
[53:51] know, like I I also use dog fooding to
[53:54] help me like that the quality of of
[53:56] product as well.
[53:57] Um, but it's been a very long time since
[53:59] I shipped production software. It's
[54:01] because part of it is I don't I don't
[54:03] want to screw something up. Like I'm
[54:05] always I'm always so scared of what if I
[54:07] do something and then I cause a bug and
[54:09] then I'm not verifying properly or am I
[54:12] wasting someone's time? Because, you
[54:14] know, like also the the the tool flows
[54:16] would change. But I remember that first
[54:18] week on on Claude, I'm like at first I
[54:20] almost again went did my usual, let me
[54:22] go meet all the engineers and treat them
[54:23] to coffee and then I'm like, oh wait,
[54:26] wait, wait, let me ask Claude. Claude
[54:27] was this really good onboarding buddy of
[54:30] mine cuz I was like curious about the
[54:31] code base, asking it questions and and
[54:33] then it also really,
[54:35] you know, helped me like, you know, do
[54:37] the automated test, but I also want to
[54:38] still do some manual testing. And I I
[54:41] asked Claude, hey, help me come up with
[54:42] like what's a way for me to manually
[54:43] test this to make sure I cover all the
[54:45] case. But all that then gives me
[54:47] confidence that okay, I can ship peers
[54:49] again. And then I got like kind of more
[54:51] comfortable with it again. And and so
[54:54] I've actually had a lot of friends reach
[54:55] out to me that have been managers for a
[54:57] while that's like, hey, I'm shipping
[54:58] code again thanks to Claude. And so
[55:01] but in in general it's it's yeah, like
[55:03] it's it's just important to me as
[55:05] leaders to make sure you're kind of like
[55:07] using the product that your team builds.
[55:09] >> It's so interesting that you are
[55:11] overseeing the team as an angel leader
[55:14] that is most changing the role of an
[55:16] engineer. It's such a meta role. Like
[55:19] the work of an engineer is transforming
[55:22] because of the software that you're
[55:23] building.
[55:25] One question along these lines is just
[55:27] do you worry about
[55:29] engineers skills to code atrophying from
[55:32] not actually writing code anymore?
[55:34] And does it even matter? Is this like
[55:36] something you think about? Is it a big
[55:37] deal?
[55:38] >> It's It's interesting cuz we actually
[55:40] have this uh discussion on the team a
[55:42] bit. Like there Like are there things
[55:44] that we miss? Or like actually to your
[55:47] point, I'm always like thinking about
[55:48] like when someone's onboarding and
[55:50] ramping. Like you have Boris who hand
[55:51] wrote the code in the early days and of
[55:53] course not does anymore, but he gained
[55:54] that knowledge from before cuz he was in
[55:56] the code base. So for especially all the
[55:59] engineers that join, I'm also like make
[56:00] sure you're like taking the time to to
[56:02] all the work that you do still get the
[56:04] understanding of the architecture or the
[56:06] change because it goes back to that
[56:07] trust but verify. Maybe one day it won't
[56:10] matter anymore, but at the at the pace
[56:12] that we're going, I actually still think
[56:14] understand like it's always double
[56:15] clicking on that layer that you depend
[56:17] on. Like may maybe that to me is a metal
[56:19] like cuz
[56:20] um it's always take that time to learn
[56:22] about your dependencies cuz this way
[56:24] when your dependencies change, like
[56:26] you're kind of like more aware or you
[56:27] might not be taking advantage of changes
[56:29] to you know, dependencies. So I think
[56:31] it's always about kind of like uh
[56:33] doing that double click. But the other
[56:35] thing that we found interesting on the
[56:37] Cloud Code team is after a while we felt
[56:39] uh it could start being a lonely
[56:41] experience cuz we all started just
[56:42] working with our agent so much. So
[56:44] recently we started a maybe a like a
[56:47] pairwise programming lunch. And cuz what
[56:49] we also learned was on Cloud Code,
[56:51] everybody uses a Cloud Code co-work.
[56:53] Everybody uses a flow so differently.
[56:55] And so we found that wow, when we do
[56:57] pairwise programming, we actually learn
[57:00] so much from each other. Um and but and
[57:03] then the other thing too is we we make
[57:04] sure that like we also uh have them make
[57:07] your time together too. So like for
[57:08] example, hackathons is is another thing
[57:10] we really like to do just to make sure
[57:12] we're kind of like interacting together
[57:14] as a team.
[57:15] >> That is such a good point. Just like the
[57:17] loneliness that emerges because used to
[57:20] be inch teams building code together.
[57:22] Someone's doing back end, someone's
[57:24] doing front end, someone's doing iOS
[57:25] app. Probably a bunch of people, you
[57:27] know, on the back end. And I was like,
[57:30] you know, well if 10 clouds running in
[57:31] parallel doing all these things.
[57:33] That is such a good idea of just like
[57:35] finding ways to connect engineers. So,
[57:37] the idea here is like almost pair
[57:38] programming, but not. It's like parallel
[57:41] It's like parallel play when kids are
[57:42] growing up. Like, you're kind of working
[57:44] next to each other, but building your
[57:46] own things. But, even just watching how
[57:47] other people build is your finding is
[57:49] really valuable.
[57:51] >> Yeah, and it's because our our own tool
[57:53] chain is changing so fast as well. But,
[57:55] yeah, it's very interesting to me that
[57:56] like everybody on on our team just uses
[57:58] Claude code and and code work in
[58:00] different ways. And so, time I watch
[58:02] someone work, then I I learn something
[58:04] myself as well.
[58:05] >> How do you manage people getting over
[58:07] like obsessed with the optimizing their
[58:09] workflows? Is there anything you just
[58:10] say, "Okay, it's fine. Just
[58:12] Just keep [laughter] going."
[58:14] >> You know, I I haven't seen too many
[58:16] folks on our team like it's I think it's
[58:17] everybody is just really excited about,
[58:20] you know, either a like an architecture
[58:23] update that we think will be higher
[58:24] reliability or some product experience.
[58:27] So, most folks like that's what we we
[58:29] talked about a lot. Like, yeah, we we um
[58:31] we don't over It's fun lunchtime
[58:33] conversations, but I don't think we over
[58:35] optimize because there's no cuz there's
[58:37] no perfect answer actually.
[58:39] >> much to do.
[58:40] >> [laughter]
[58:41] >> Is there anything These are really
[58:42] interesting insights. Just like as the
[58:44] role transformed, things come, things
[58:46] go.
[58:47] So, I'm curious what else is kind of
[58:49] lost in this new world of software
[58:51] engineering. I used to be an engineer. I
[58:52] don't know if you know this. I was an
[58:53] engineer for 10 years.
[58:55] Uh and it was like so fun just to sit
[58:57] there in flow coding. You know this
[58:59] feeling. Just like, "Oh, wow, it's
[59:01] working. Look at it compile. It's
[59:02] amazing. I'm making progress." And now
[59:03] it's like you don't do that anymore. You
[59:05] just sit there and kind of wait for
[59:06] agents to build the thing. What else
[59:08] What else is kind of lost in this new
[59:10] world for engineers?
[59:12] >> Yeah, it's so funny. I just had that
[59:14] conversation with the engineer on the
[59:16] team of talk about flow. Like, remember
[59:18] the old days you have this really gnarly
[59:19] problem and you pop that music
[59:21] soundtrack in and then you're just in
[59:23] the in the zone. Um
[59:25] Uh so, yeah, there is a little and then
[59:27] there was always that big aha moment at
[59:28] the end. I would remember. Like is it
[59:30] Yeah, you remember you're like you
[59:31] finally cracked it. You know that yay.
[59:33] So we we do
[59:35] but it's like I think now we get a lot
[59:37] of joy from like the product but I do
[59:40] think there is cuz I hear from other
[59:42] engineers as well of it Well, I
[59:44] some of the hardest parts is what I used
[59:46] to enjoy.
[59:48] Like yeah, I heard that from another
[59:50] engineer as well. And so I think we're
[59:51] all just kind of like shifting um Uh,
[59:55] but I I I do see like the the thing most
[59:58] and that's why I was I I was talking
[59:59] about like the pair wise programming in
[60:01] the hackathon. That did recently come up
[60:03] more of folks were starting to feel like
[60:04] it's starting to be a lonely experience.
[60:07] >> So interesting.
[60:08] Within Anthropic I'm curious so
[60:10] engineering like the most transformed I
[60:13] think of any role right now. What other
[60:15] What's like the second most transformed
[60:17] role so far would you say within
[60:19] Anthropic that's most different from how
[60:21] it was like a couple years ago let's
[60:22] say?
[60:23] >> It's it's all the coding adjacent roles
[60:25] are shifting. Like PM is I know like you
[60:27] you were chatting with Kai. I think PM
[60:29] is also transformed quite a bit because
[60:31] PM bar no longer bottlenecked if if they
[60:33] have an idea waiting on engineering
[60:35] bandwidth. Um so that's kind of like the
[60:38] the next role I've seen shift. Like
[60:39] actually our PMs have also helped us
[60:41] roll up sleeves and help shift you know
[60:42] like some features when we when we were
[60:45] um you know like when when there wasn't
[60:47] uh when there was a you know something
[60:49] we wanted to do and an engineer wasn't
[60:51] able to. So I think um it's all the
[60:53] coding adjacent roles are starting to
[60:55] shift. Um but I think that's where again
[60:58] the verification is important cuz when
[61:00] you have more different disciplines
[61:02] checking in how do we make sure
[61:03] everybody has high confidence. I also
[61:05] think we need to do more to keep
[61:07] automating these other portions of the
[61:09] workflows. Like for sure we focus a lot
[61:10] on coding but next when you think about
[61:13] like design or data science like those
[61:15] are starting to be the next areas I
[61:16] think are good opportunities for us to
[61:19] see how we can yeah like um
[61:22] uh start and improving kind of like
[61:24] experiences there as well.
[61:26] >> Yeah, I have a speaking of data science,
[61:28] I have a data science friend and he was
[61:29] just saying how data science is so
[61:31] different now
[61:33] where
[61:34] now most of their job is people doing
[61:36] their own like not amazing data science
[61:38] work using AI and it and then just like
[61:41] showing it to the data scientist, "Here,
[61:43] here's the analysis I did. Can you just
[61:44] make sure it's right?" And half the time
[61:47] it's not right.
[61:48] And so the job is just like a whole
[61:49] different job now instead of doing the
[61:51] work that they thought they wanted to do
[61:52] and that's like, "All right, I'm just
[61:53] reviewing all this AI data science all
[61:55] the time. What the hell?"
[61:57] >> [laughter]
[61:58] >> Kind of along the lines, coming back to
[62:00] just how your team operates and how
[62:02] things are changing,
[62:03] let me see if something comes with this
[62:05] question. What should an engineering
[62:07] manager expect from their team now
[62:12] versus like a couple years ago? What's
[62:14] like a normal, I don't know, baseline
[62:15] expectation of how things should work?
[62:17] Is it other than just, you know, we're
[62:18] shipping faster? Is there anything else?
[62:20] >> Oh, interesting. Well, definitely I
[62:22] think most commits are cloud assisted
[62:25] and so that was a shift.
[62:27] Um
[62:29] I think
[62:31] you know, I kind of like mentioned we
[62:33] have like Slack channels with all the
[62:34] feedback and also our dashboards that we
[62:37] have
[62:38] get to cloud. I think having engineers
[62:41] building like keep building that
[62:42] stronger product sense muscle is I I
[62:44] think also like another and I think that
[62:46] in general helps kind of
[62:48] build these really strong minded product
[62:49] engineers. I would say more of these
[62:51] roles that were traditionally
[62:53] non-engineering,
[62:54] you do now see engineers being like and
[62:56] sometimes you're just blocked by, you
[62:58] know, waiting for you know, a
[63:00] cross-functional partner. I think
[63:02] there's there's less of those blocks now
[63:03] just because
[63:05] the models are able to augment
[63:07] additional capabilities that you may not
[63:09] have as an
[63:11] from as an engineer.
[63:12] >> So it's kind of interesting that it's
[63:13] both directions. Engineers becoming more
[63:16] product minded and responsible for the
[63:18] quality and success of a product and
[63:20] then everybody becoming an engineer more
[63:22] and more.
[63:23] >> Yeah, that's right. It's all blurring.
[63:25] >> Yeah.
[63:27] I forget who said this, but there's this
[63:28] like like what is a role anymore in this
[63:31] this guy said that it's like what's the
[63:34] average of what you do? What's like the
[63:36] highest percentage of what you and
[63:37] that's kind of your role now, whatever
[63:38] it is going to be. [laughter]
[63:40] >> Yeah.
[63:40] >> Oh man, I want to come back to your
[63:42] point about
[63:44] obsession with the the product living
[63:46] breathing the product dog fooding. I
[63:47] talked to a bunch of people that work
[63:48] with you about you and that's the thing
[63:51] that came up most just like your
[63:52] obsession with living and breathing the
[63:54] product using the product constantly,
[63:55] whatever it is you're building uh this
[63:57] idea of dog fooding.
[63:59] Talk about just like why
[64:01] that is so important, why that's
[64:02] something you instill within your teams
[64:04] and and and reports.
[64:06] >> Oh, I love it. Um yeah, I think it's
[64:08] it's really and and this has worked for
[64:10] me um it's just been a really good way
[64:12] for me to keep a pulse on
[64:15] you know, anytime you build product
[64:16] there's there's a dream. Like you're
[64:18] really hoping to enable an experience or
[64:21] make an experience better. So I think um
[64:23] being able like like that helps me keep
[64:26] really close to the pulse. I also think
[64:29] uh maybe and maybe something like for
[64:30] sure on Visual Studio that was like, you
[64:32] know, where I where I got this love of
[64:33] it um
[64:35] but it's interesting cuz even
[64:36] Marketplace, I remembered every time
[64:39] once in a while I'll do like even after
[64:41] I left the team actually. Um one time I
[64:43] had like a MacBook Air and I wanted to
[64:45] sell my old and you know, I haven't sold
[64:47] anything on Marketplace let let me and I
[64:49] could not believe it the minute I I put
[64:51] it up for sale a seller or buyer tried
[64:54] to scam me and it was an interesting
[64:56] like new scam vector I didn't detect and
[64:59] so but that goes to again like people
[65:01] will use uh your products in ways that
[65:03] that you may not expect and so
[65:05] especially as leaders or even like
[65:07] anyone on the team, we all have
[65:09] different like life like actually it's
[65:11] it's funny when it when I was a you
[65:12] know, supporting the VR and AR teams,
[65:15] somehow how I used VR, the setup, I
[65:18] would always be able to find these
[65:20] really weird floor height issues. So,
[65:22] that ended up being a I took a you know,
[65:24] like I'm going to help us you know, like
[65:26] cuz somehow I got a good repro
[65:28] environment. Um
[65:30] And so, I think it's number one like
[65:32] making that's how you keep your pulse on
[65:34] the product that you're building and
[65:35] don't get too lost in metrics and
[65:38] dashboards only or presentations.
[65:40] >> I think that's such an important point
[65:41] you're saying there that I just want to
[65:42] make sure people hear is just like like
[65:45] there's always this idea of anecdotal
[65:46] evidence and just like examples versus
[65:48] the data. And what you're saying here is
[65:50] as a product leader as an engine leader,
[65:52] there you found a lot of success in like
[65:54] the anecdotes, the specific uh little
[65:57] one-offs that you experience as a as a
[65:59] as a user versus like obsessing with the
[66:01] data only.
[66:02] >> Yeah. And and actually, sometimes it's
[66:04] also how I've been able to most
[66:05] effectively help the team. So, for
[66:07] example, the last team I was on I I was
[66:10] a you know, leading a VR team and
[66:13] you know, because like back then the
[66:14] like I I it it would have been I would I
[66:16] I was not I have not checked in any code
[66:18] into that code base just cuz I was
[66:20] really worried about like messing up the
[66:21] operating system. But what was a gap? We
[66:23] were doing a lot of polish fixes and I
[66:26] was I wanted to I'm like, "Hey, you know
[66:28] what? I'll use my dogfooding time to
[66:30] actually vet how the experience looks."
[66:32] And and so, that was also probably a way
[66:35] that I felt I could still meaningfully
[66:36] contribute to help hold the quality bar
[66:39] for the team. And and then like I say,
[66:42] like every team member usually always
[66:44] really appreciates cuz I I think um
[66:47] as a lead like you know, leader you're
[66:49] supporting folks on team that outside of
[66:51] metrics and everything, everybody really
[66:52] wants to make sure their work matters
[66:54] and yeah, just making sure that you
[66:58] know, leaders use your product. I think
[66:59] folks feel the the leaders um remain
[67:02] like really engaged and not too I'm
[67:05] >> And this connects a lot with your point
[67:07] that engineers need to become more
[67:09] product minded. That engineers need to
[67:11] become more PM-y, PMs need to become
[67:13] more But this is like as an engineer,
[67:15] this is one way to do it. Use the
[67:16] product constantly. And that'll help you
[67:18] understand what is missing in the
[67:19] product as a user cuz you're just using
[67:21] it.
[67:21] >> That's right. And And I would say if
[67:23] you're leading a team where it's really
[67:24] hard for you to use the product, then
[67:25] meet with customers. Like whatever the
[67:28] other avenue is that kind of um like I
[67:30] think that's also been really important
[67:32] to you. Every time I've done customer
[67:33] visits, I always learn something new.
[67:36] Like actually I remember that was uh
[67:38] Facebook Marketplace we're trying to
[67:39] launch to uh Latin America. And so we
[67:41] had you know, we were testing in Chile.
[67:44] And I remember that it it just wasn't
[67:45] doing as well as the other regions we'd
[67:47] done. And everything else we've we've
[67:49] tried. And then I remember I'm like we
[67:51] And we had a really small research trip
[67:53] where I went to Chile. I remember
[67:54] getting a whole bunch of Android phones
[67:56] for us. It was very small crew, like
[67:57] just three of us. And upon landing and
[68:00] upon me opening up these Android phones
[68:02] and I'm like, ah
[68:04] you know, the LTE connection was real
[68:06] was much slower than what we were used
[68:08] to in the US. And so I'm like, oh, the
[68:10] Marketplace feed didn't even load very
[68:12] well on these little LTE situations.
[68:14] What a What a growth blocker you know,
[68:16] you can't even load. But again, that's
[68:18] why it's so important to always uh you
[68:20] know, like um listen to customer
[68:22] feedback and and get that fast feedback
[68:24] loop.
[68:24] >> I think it was Jeff Bezos that said if
[68:26] you have the data and you have an
[68:28] anecdote, trust the anecdote over the
[68:31] data.
[68:32] Surprisingly. And that's a great
[68:33] example. Okay. Uh just a couple more
[68:35] questions.
[68:37] One is in your talk, you had this really
[68:39] interesting slide at the end of what
[68:41] questions you're kind of rethinking
[68:43] about right now that you haven't figured
[68:45] out how to solve
[68:46] with how much is changing. Uh I'm going
[68:49] to read the three. I'm curious just like
[68:50] if it's still these three, if there's
[68:51] anything else like current problems we
[68:53] need to figure out that we haven't
[68:54] solved in how we operate. What you
[68:56] shared in your talk was, do we still
[68:58] need separate iOS and Android orgs?
[69:01] How far do you push fully auto-
[69:03] automated reviews? And which role with
[69:06] role blurring, how do you ensure
[69:07] everyone's equally productive?
[69:10] Still problems? Is there anything else
[69:12] that you're thinking about like, okay,
[69:13] we need to crack this. We haven't
[69:14] figured this out.
[69:15] >> You know, the iOS Android one, like I
[69:17] think we're still actually it's funny
[69:19] cuz I speak of like the deep expertise.
[69:22] We definitely feel that it's really
[69:23] important like it's really important to
[69:25] still bring on folks with those
[69:26] expertise, but we probably don't need
[69:28] like as large because people are
[69:30] flexing. So it's again making sure we
[69:32] have
[69:33] you know, like the Android and iOS
[69:35] experts, but then less of a the larger
[69:38] kind of like a mobile org one per. And
[69:40] so but again, that's still a balance
[69:42] that we're trying to figure out of do we
[69:44] have the right and enough expertise? Um
[69:48] The the second one was Sorry, what was
[69:51] the second [laughter] one?
[69:52] >> Oh, yeah. It is how far do you push
[69:55] fully automated reviews?
[69:56] >> Ah. Yes. Actually, well, this is a a fun
[69:58] one like, you know, with the content
[69:59] design check. I think we're we're
[70:01] looking for across all of it like how do
[70:03] you actually get what good looks like?
[70:06] Um and so I have a like actually the
[70:08] verification is still one that we I
[70:10] think that's kind of like the second and
[70:12] the third that I think we there's more a
[70:14] lot more opportunities there for us. Um
[70:17] but the how far to push, I think looking
[70:19] at where we think that experts still
[70:21] matters and then also again have to keep
[70:23] asking ourselves, okay, is there a way
[70:24] to leverage our expertise to also
[70:26] automate? Like I think um
[70:30] like looking across the whole end-to-end
[70:31] experience, like making sure we're not
[70:33] missing in like I think we we come at it
[70:35] from like an engineering standpoint, but
[70:37] making sure um experiences how we think
[70:40] about those other areas. Um I I think
[70:42] there's definitely still more that we
[70:43] can do there.
[70:43] >> Basically, how do you solve how do you
[70:45] set up a verification that the
[70:47] experience is what you want it to be?
[70:49] >> Exactly. That and I think that one is
[70:51] still a hard one to crack cuz you kind
[70:53] of like mentioned the eval cases. It's
[70:55] Some of it for sure is accuracy, but
[70:56] it's also the experience. Um so that's
[70:59] something that's uh yeah, we're we're
[71:01] still kind of thinking through.
[71:03] >> Awesome. Is there anything else that's
[71:04] like uh this has changed recently we got
[71:06] to figure out how to rethink the way we
[71:08] operate or is this kind of the the big
[71:10] ones?
[71:10] >> You know, I think because with
[71:13] routines and everything being more
[71:15] async, I I I think there is starting to
[71:17] be a high load on our context switching.
[71:20] Cuz I even remember I myself was like,
[71:21] oh I I kicked like I kicked off like and
[71:24] and so I think that's probably another
[71:26] thing we have to think about of how do
[71:27] we uh you know, whether for our team
[71:29] members or our users like how can we
[71:31] actually make the experience better to
[71:33] reduce that load cuz I I do see the
[71:36] context switching load increasing.
[71:38] >> I can like if you have 20 agents running
[71:40] there's just endless checking in and
[71:43] reviewing and you have to remember what
[71:44] you're doing there. It's like such an
[71:46] interesting world where
[71:47] like the idea flow we talked about
[71:49] before like engineers and most people
[71:52] like there's less of the just hours of
[71:54] flow, but now the agents can kind of
[71:57] just remind you. Here's where you're at
[71:58] like the reset to switch almost is
[72:01] easier cuz you don't have to like
[72:02] relearn everything. You don't have to
[72:04] like re-understand the code base and the
[72:06] the architecture. You can kind of just
[72:08] like, okay, but here's what we're trying
[72:09] to do. It's kind of like both got
[72:11] better, got worse.
[72:12] >> Well, it's interesting cuz I used to do
[72:14] book out like focus time for like you
[72:15] know, the focus time for coding cuz you
[72:17] want that dedicated and then the whole
[72:19] context switching and then it's
[72:20] interesting now that because I can
[72:22] context switch more with more async
[72:23] agents, I'm noticing I do actually have
[72:25] to go back and block like a focus time
[72:28] for me to catch up on all the you know,
[72:30] different async work that I've kicked
[72:32] off.
[72:32] >> Yeah, do you have any thoughts on a
[72:33] solution there cuz that's hard. Just
[72:35] like there's like people just want to do
[72:37] more and more and just how do you do
[72:39] that without constantly context
[72:41] switching? It's really hard and
[72:42] annoying.
[72:43] >> Yes.
[72:43] I agree. Like definitely I haven't
[72:45] cracked it yet.
[72:46] >> [laughter]
[72:48] >> So interesting. Okay, there's a question
[72:49] I I of as we were talking that I I'm
[72:51] like so excited to hear your answer on
[72:53] that. I wasn't even planning to ask
[72:54] this, but it's so important these days,
[72:56] which is just like and jobs and hiring.
[72:59] So interesting that you would think AI
[73:01] would uh make engineers less necessary.
[73:04] On the other hand, it feels like you
[73:06] guys are hiring engineers like crazy.
[73:08] Open eyes hiring engineers like crazy.
[73:10] Just like there's so much demand for
[73:12] engineers.
[73:13] Where do you think this goes? What do
[73:14] you think about just the future of the
[73:15] end role? And this is a big question,
[73:17] but just
[73:18] >> [laughter]
[73:19] >> thoughts.
[73:20] >> I I'll I'll share I'll actually I'll
[73:21] I'll I'll share some vulnerability here.
[73:24] One, um speaking of like big open
[73:26] questions, I really do think how we
[73:29] grow the the next generation just
[73:31] because how you and me got to our
[73:34] engineering path is just so different.
[73:36] It's almost like, okay, now when you
[73:38] graduate from school, it's like how do
[73:40] you kind of fast-forward it? But but the
[73:42] important thing to me is that still
[73:43] understand kind of like, you know, that
[73:45] double-click I talked about to to the
[73:47] the layer of an eight. Um but that that
[73:49] is
[73:50] a big question I have, and I wish I have
[73:54] the answers, but I I wonder if it's um
[73:57] for software engineering, it's almost
[73:58] like you go more towards a fellowship or
[74:01] apprenticeship program.
[74:03] I know it's hard cuz technically we have
[74:04] like in internships that would but those
[74:06] were the kind of like 3 months and a
[74:08] little projects, but I I do wonder if um
[74:11] and I I wish I have a crystal ball here,
[74:13] but it's it's yeah, like how do you
[74:15] almost like cram in some of the
[74:18] And and maybe it won't matter, but you
[74:19] know, some of the life experiences that
[74:20] we all got, how do you actually enable
[74:23] um
[74:24] us to kind of like teach that to, you
[74:26] know, the next generation of builders?
[74:28] >> Right, like if you don't have to ever
[74:29] look at code,
[74:31] well, what's the incentive for a new
[74:33] software engineer to truly understand
[74:35] how
[74:36] infrastructure works and and memory
[74:39] allocation all these things that are
[74:40] like kind of foundational.
[74:42] >> And and it's interesting. Maybe the the
[74:44] models will get good enough that it it
[74:45] doesn't matter, but I do
[74:46] >> Yeah.
[74:47] >> You know, but I do think there's
[74:48] something about that that double click
[74:50] cuz I think that's where there might be
[74:52] an opportunity to improve the product or
[74:54] the system. But, figuring out how to
[74:57] learn that not necessarily by, you know,
[74:59] like year years of uh
[75:02] >> of typing code.
[75:03] >> Yeah.
[75:03] >> Yeah, like somebody's got to have to
[75:05] understand code at some level. Like,
[75:07] it's like some COBOL engineer they have
[75:08] to like pull out of retirement one day
[75:10] like, "Do you remember how to write
[75:12] Python?"
[75:13] >> You know what you was really fun? One of
[75:14] my
[75:15] you know, previous managers. I mean, he
[75:18] started software engineer when it was
[75:20] punch cards.
[75:22] And it's so fabulous. Like, he's been
[75:23] messaging me everything he's been
[75:25] building with cloud code. And I'm like,
[75:26] "Wow, what a career that you go from
[75:29] like he's really like he you know, he's
[75:31] really kind of like seen this whole
[75:33] change. So, maybe I think for us to
[75:34] think about it is like when I think
[75:35] about his career, how he got started
[75:37] with punch cards was also totally
[75:39] totally different than
[75:41] than now. And so, it it might be that um
[75:45] I I think it'll be interesting for us to
[75:46] see what remains important. And then
[75:49] what changes in terms of importance. And
[75:51] then it's like how do you um have gained
[75:53] the Like, I have a theory maybe maybe
[75:55] that's the the what is important will
[75:57] shift over time. And then how do you
[75:59] kind of uh
[76:00] kind of build the proficiency into it.
[76:02] >> Oh, yeah, just learn the things that
[76:04] really matter. Like, the argument that I
[76:06] I constantly hear is just like it's a
[76:07] new level of abstraction just like
[76:09] assembly and binary like it just keeps
[76:11] going up and up. And now, okay, we don't
[76:13] need to actually look at the code. It's
[76:14] like a new layer of abstraction prompts
[76:16] and
[76:17] and uh Claude's thinking uh you know,
[76:19] messages.
[76:20] >> Yeah, and it's maybe like, "Okay, what
[76:21] is a interesting problem? What's the
[76:23] prioritization for experience to build?"
[76:25] Like, it's it's interesting. Maybe we're
[76:27] kind of Yeah, and then when you build
[76:29] things, how do you know it's actually
[76:30] resonating? And and and uh it's kind of
[76:33] like doing what you intended.
[76:34] >> And is good, yeah. Like, is this going
[76:35] to are we just building a bunch of slop
[76:37] here or is this actually
[76:38] architecture [laughter]
[76:39] that will work? I think the advantage
[76:41] though for young people is they are so
[76:44] it's so much easier to just to lean in
[76:46] and work in this new way versus being
[76:48] stuck in the way that things used to be.
[76:50] It's like rare It's like amazing how
[76:51] many long-time engineers like yourself
[76:53] have adapted and embraced this. It's
[76:55] like so hard to just change everything.
[76:57] Okay, let's do it. Everything [laughter]
[76:59] >> Well, cuz the rate of change is also so
[77:01] fast. Actually, that that was the one
[77:03] thing of
[77:04] I remember the first time I It was
[77:06] probably Sonnet 3.5 or or 3.6 like and I
[77:09] I remembered it was still like making
[77:11] some mistakes when I was doing things on
[77:13] the side. I'm like, "What are you
[77:14] doing?" And and and then what I noticed
[77:15] was some of the engineers that were
[77:17] resisting AI tooling. They're like, "Ah,
[77:19] but see, it's you know, like look at all
[77:21] of these." But then I think it was hard
[77:23] to understand of how kind of like
[77:25] exponential rate of improvements. And so
[77:29] always And maybe that's another
[77:31] interesting thing that I myself am
[77:32] learning too. Like there might have been
[77:34] something I tried to automate that
[77:35] Claude wasn't quite good enough. And
[77:37] then actually in the next model, oh
[77:39] well, now it is good enough. So it's
[77:40] always also thinking about what may have
[77:44] not worked. Like it might be worth a
[77:45] time to revisit cuz you know, that now
[77:48] might be a new capability.
[77:49] >> Yeah, that comes up a lot in this
[77:51] podcast. Just build something that is
[77:53] almost working that is at the edge
[77:55] because once the model gets there,
[77:57] you'll be so far ahead of everybody
[77:58] else.
[77:59] Okay, final question. You may have
[78:01] already answered this with what you just
[78:03] said, but what keeps you up at at night?
[78:06] >> You know,
[78:07] the thing that keeps me up at night is
[78:08] probably um
[78:10] is how we So, you know, we talked about
[78:12] kind of like Claude code and co-work
[78:13] team culture. That's and the team
[78:15] culture is really important to me. Like
[78:17] it's the one team mentality and I I you
[78:20] know, I I share with folks. And and by
[78:23] the way, culture is like a living
[78:24] breathing thing. It's not just a poster
[78:25] you slap on a wall and it changes over
[78:27] time and it's it shows up in how we
[78:29] treat each other, how we how we're there
[78:31] for each other. And so, the culture of
[78:34] the team is important to me because we
[78:35] are we are growing and and
[78:38] and since the culture shifts like making
[78:39] sure that maintaining the things are
[78:41] important that we are we still really
[78:44] like it's really important for me to
[78:45] have like diverse perspectives so then
[78:47] we can have you know like good healthy
[78:49] open honest debates on in the open and
[78:52] we kind of like welcome those and kind
[78:54] of what I call that one team mentality
[78:56] that when you get close to the finish
[78:57] line look behind you and see is there
[78:59] some of our team to help cuz we kind of
[79:00] finish as a team.
[79:02] That's probably the thing that keeps me
[79:04] up at night and it's
[79:06] it's like you know there's so many other
[79:08] hard problems right but I think maybe a
[79:10] lot of the other ones are product or
[79:12] engineering challenges that yes we have
[79:15] you know like dashboards or theories or
[79:16] hypotheses like but the culture is like
[79:19] a human aspect that is
[79:22] um
[79:24] Like like I I think that's the one that
[79:26] I I always want to make sure that we're
[79:28] as we grow we're still kind of like
[79:30] maintain that culture cuz it is kind of
[79:32] like the fiber
[79:34] of the team and it like when it starts
[79:36] drifting it it's it I'm always worried
[79:39] of you know like if it if it drifts are
[79:41] we catching it and having conversations
[79:43] as a team together to to to make sure
[79:45] we're kind of all wanting the culture to
[79:48] grow in the right direction.
[79:49] >> Yeah, I imagine everybody is struggling
[79:51] with this considering the pace of change
[79:54] and the pace of hiring just like
[79:56] especially a company like Anthropic
[79:58] that's in this crazy like the most
[79:59] unprecedented growth trajectory in
[80:01] history. I could see how that could be
[80:04] some a challenge
[80:06] with so much change so
[80:08] it makes sense like even you know at
[80:09] Airbnb when I was there like that was
[80:11] quite a growth trajectory and that was
[80:13] nothing like what you guys are going
[80:14] through. And that was a constant topic
[80:17] of conversation how do we maintain the
[80:18] culture?
[80:19] >> Actually I'm curious what was your
[80:20] experience at Airbnb to maintain the
[80:23] culture as you were growing?
[80:24] >> things one is just the
[80:26] what worked well is the founders being
[80:28] obsessed with it like every every all
[80:30] hands every
[80:32] every big meeting is just like reminding
[80:34] of like the culture and the value of the
[80:36] culture and what the values are just the
[80:38] founders top-down being obsessed with it
[80:41] was a really big part of it. It just
[80:43] like couldn't have a meeting without
[80:44] that coming up as a as a thing.
[80:47] The other is a memory I always come back
[80:49] to is we had Sheryl Sandberg's became
[80:51] meta come to come do a fireside chat
[80:53] and somebody asked her just how do you
[80:55] maintain culture as you scale?
[80:58] Because we're just going so fast and
[81:00] it's so hard to mean deal with all this
[81:02] change and culture and all these new
[81:03] people and her advice was this is
[81:06] actually the what the problem you want
[81:08] to have because this means you're
[81:09] growing and doing well and this is
[81:12] normal versus you can
[81:15] nothing will change if you're doing
[81:16] badly like that's that's the that's so
[81:18] much worse situation when you're not
[81:19] growing and you're not hiring like
[81:21] crazy. That's a much worse situation
[81:24] that will cause even more even
[81:26] suffering. So this is what this is a
[81:28] good problem you're you're you're
[81:29] dealing with. is is her advice which has
[81:31] always stuck with me.
[81:32] >> Oh, that's great. Like it's interesting
[81:34] like here you talk I think one of the
[81:35] important things to kind of cloud code
[81:37] and co-work team is
[81:38] um whether uh ICs or managers but this
[81:42] is a thing I especially ask for managers
[81:44] on the team is really important that we
[81:46] all talk about for sure what's going out
[81:48] but also just be open about what's not
[81:49] going well.
[81:51] Because then if we can actually have a
[81:52] conversation what's not going well
[81:53] that's how we can actually go ahead and
[81:55] address it. Like my my my speaking of
[81:58] what keeps me up at night my nightmare
[82:00] is especially if someone's in a manager
[82:02] position and and I'm like hey how are
[82:04] things going? Everything's fine. I'm
[82:05] like oh my gosh I'm not doing [laughter]
[82:07] fine. I know this things are and like
[82:09] like it's that that whole like you know
[82:11] how there was this meme of the doctor
[82:12] cat cup of coffee in a room that's on
[82:14] fire. This is like that that is my my
[82:16] nightmare. So that's actually
[82:18] a discussion I have with a lot of folks
[82:21] on the team especially managers of when
[82:22] they first joined up hey let's always
[82:24] have these open conversations so that we
[82:26] can solve problems together.
[82:28] >> I imagine there's something a lot of
[82:29] people struggle with seeing so many
[82:31] people around them doing super well, at
[82:33] least seemingly doing well. Everything's
[82:35] going great. I'm growing this this
[82:37] awesome company or like just like
[82:39] everything it's hard to like hard to
[82:41] actually be honest and say it's not
[82:43] going great. I'm struggling here. I'm
[82:45] falling behind cuz everyone around you
[82:47] is just like on the surface feeling like
[82:49] they're killing it.
[82:50] >> Mhm.
[82:51] >> Yeah.
[82:53] Before we get to our very exciting
[82:55] lightning round, is there anything else
[82:56] that you either want to leave listeners
[82:58] with, anything else that we didn't
[83:00] cover, anything else that's important
[83:01] that you wanted to share?
[83:03] >> Maybe one thing is like just a
[83:05] suggestion cuz you know we talked about
[83:07] how how can Cloud do like automate like
[83:10] one other thing that's really big on
[83:12] Cloud Code and Core team culture is
[83:15] explicit permission to kill processes
[83:17] that no longer serve us. And so maybe a
[83:20] suggestion is for you know any anyone
[83:22] you know like on our work and our team
[83:24] or leading teams
[83:25] like take your like what's one process
[83:27] that you either dread doing
[83:29] or is really highly noisy or is like
[83:32] really expensive in terms of like just a
[83:34] lot of like it it might
[83:36] or is something that's just very manual.
[83:38] Like pick one thing and first ask is it
[83:40] still having its purpose? Like for
[83:42] example
[83:44] one like even our planning like
[83:46] Actually that was my own big first
[83:48] learning when I first joined Cloud Code.
[83:49] I'm like hey maybe we should you know do
[83:51] a six-month road map doc and and but
[83:54] we're going to do it super lightweight
[83:55] cuz I don't want to waste a lot of time
[83:56] planning and I I felt we did a really
[83:58] lightweight process. But that was such a
[83:59] good learning for me cuz the exercise
[84:01] was good to kickstart conversations and
[84:04] ensure we're aligned but like three
[84:05] months into it I'm like wait have we
[84:07] still referenced
[84:08] because so much has changed and that was
[84:10] also something I like and so that was
[84:12] also something I changed to that I
[84:14] myself brought in thinking hey maybe
[84:15] this will this will help. So always be
[84:17] open to learning and always ask yourself
[84:19] whatever process you have is it still
[84:22] serving its purpose? Just because the
[84:24] field is changing so fast.
[84:25] >> I love that advice. I got to follow up
[84:27] on this real quick. So, what is it? How
[84:28] do you think about planning now? Do you
[84:30] do any planning? Is it just like a
[84:32] month-long road map? What's kind of like
[84:34] the simple way to explain where you're
[84:35] at with that?
[84:36] >> Yeah, I
[84:37] I call it JIT planning now, like
[84:39] just-in-time planning. So, it it is like
[84:41] around like cuz yeah, I think 6 months
[84:42] was too long. So, now for sure some
[84:44] projects will take more than a month,
[84:46] but we try to do like a a month of
[84:49] planning, like really lightweight.
[84:50] Actually, there's not even docs. It's
[84:51] really just us aligning on a on a little
[84:54] spreadsheet of what we think is
[84:55] important. But even that one, I'm I'm
[84:57] kind of thinking through, "Hey, like
[84:59] every week we should probably still keep
[85:00] a like what we're trying is here are the
[85:03] the month's priorities."
[85:04] And we're going to try it out, but I
[85:05] have a feeling like every week we'll
[85:07] probably want to do really quick like,
[85:08] "Hey, just to check. Yep, this is the
[85:10] still this month's priorities. Good." Um
[85:13] but yeah, like but now we we've shrunk
[85:15] it to JIT monthly planning.
[85:17] >> So, it's monthly meaning for the next
[85:19] month, here's a little
[85:20] uh sheet/Excel spreadsheet of what we're
[85:23] planning to do for the next month. And
[85:25] then every week check in, is this still
[85:27] what we're planning to do for the next
[85:28] month?
[85:28] >> Yeah, it's it's yeah, like like very
[85:31] very we But even that one, I'm also
[85:33] still feeling, "How can we even
[85:35] automate this more?" Cuz I don't I never
[85:37] want it to be feeling like a tax when
[85:38] someone has to, you know, up update the
[85:40] spreadsheet. So, this is actually yeah,
[85:42] like just yesterday we're chatting,
[85:43] "Hey, how can we actually uh automate
[85:45] this?" Well, it's getting to that
[85:47] question, always ask yourselves, "Can we
[85:48] actually automate this better?"
[85:50] >> Like my PM brain is like, that's so like
[85:52] how could you not do something like
[85:53] that?
[85:54] >> [laughter]
[85:54] >> Okay, here's what we're thinking for the
[85:55] next month. Let's just check it once a
[85:57] week. Let's make sure this is like it's
[85:59] hard to imagine that not happening. Um
[86:01] and you don't have a lot of items on the
[86:03] spreadsheet is what I'm hearing also.
[86:05] >> Yeah, but like we really try focus. So,
[86:07] like we will will share out like here's
[86:09] what we think are the highest
[86:09] priorities. And again, for that agency
[86:11] of given the priorities, then like
[86:14] everybody's like their kind of like item
[86:16] for how they think uh addresses those
[86:18] priorities.
[86:19] >> Is there anything that's like here's for
[86:20] the next like 6 months bigger bets kind
[86:22] of stuff or is it just like let's just
[86:24] think 1 month ahead?
[86:26] >> I like so we'll usually definitely
[86:28] there's themes of where we think the the
[86:30] work and so we'll we'll definitely like
[86:31] um and actually the the whole team will
[86:33] bring everyone together
[86:35] uh like every every 6 months. So there
[86:37] we'll usually kick off like some themes
[86:39] but then it's really the
[86:41] making sure we keep the pulse of what
[86:43] because again like even though themes
[86:45] change you know so fast when uh the
[86:47] landscape changes.
[86:49] >> All right, let's pull up the spreadsheet
[86:50] and let's take a look.
[86:51] >> [laughter]
[86:54] >> Oh man. Man, this this whole podcast
[86:56] could have been just talking about this
[86:57] planning stuff they do. Okay, I'm going
[86:58] to have to find someone else to talk
[86:59] about this cuz this is so interesting
[87:01] just how y'all plan. Uh yeah, okay.
[87:04] Well, Fiona, with that we reached our
[87:06] very exciting lightning round. I've got
[87:08] five questions for you. Are you ready?
[87:10] >> Ready.
[87:11] >> Okay, first question. What are two or
[87:13] three books that you find yourself
[87:15] recommending most to other people?
[87:17] >> Ooh, I will say for fiction
[87:21] uh actually two authors I recommend to
[87:22] everyone, Margaret Atwood and uh
[87:26] Haruki Murakami.
[87:28] Um those are just two like like I mean I
[87:32] grew up in Canada so so I I read a lot a
[87:34] lot of Atwood growing up but her books
[87:36] are fascinating cuz it's almost like
[87:38] speculative fiction of
[87:41] you can kind of squint and say okay
[87:43] could this actually you know like happen
[87:45] to to a society. So so I love her take
[87:47] on speculative fiction and Murakami I
[87:50] love his um magical realism style.
[87:54] It's it's um but then the one book so
[87:57] there are authors but the one book I
[87:59] always recommend to everyone to read at
[88:01] least once a year or you know um The
[88:04] Little Prince.
[88:05] I like I I think I'm I'm sure we
[88:07] probably all read it at at some point in
[88:09] our lives but I think it's a I I read it
[88:11] at least once a year. It just you know,
[88:13] to to remind me to to think about like
[88:15] kind of like what's truly important.
[88:17] >> Wow. That doesn't come up a bunch. Okay.
[88:20] I love it. Uh favorite recent movie or
[88:23] TV show you have really enjoyed?
[88:25] >> I haven't watched TV [laughter] shows.
[88:27] >> That's very common across Anthropic
[88:28] people I have on the podcast.
[88:30] Common theme.
[88:32] >> But I will share with you what I always
[88:33] have downloaded on my phone so that if
[88:35] I'm on on the airplane um
[88:38] So there's three movies I I always have
[88:41] on my phone cuz I I think they're just
[88:42] so so fun to to to watch if I have time.
[88:46] One is Amelie.
[88:47] It's this uh French movie that oh my
[88:49] gosh, all of these movies are going to
[88:51] be very old by the way. It's going to be
[88:52] like vintage movies. But I I I loved
[88:54] Amelie. Super whimsical. So really
[88:57] highly recommend it to um anyone that
[88:59] haven't seen it. It's uh you know, if I
[89:02] if you remember I told you I was you
[89:03] know, going on a I thought I was going
[89:05] to be a visual artist. So when I was 16,
[89:07] my high school we took a a trip a high
[89:10] school trip to Paris and that that just
[89:12] I I've so many memories of that and
[89:14] Amelie really captures the magic I felt
[89:16] at Paris. And the other two are are
[89:19] Ghibli films. Uh I love Spirited Away.
[89:21] That's um it's just such a
[89:24] like just such a
[89:25] I just love that story. I I I love the
[89:29] yeah, like I I just love every
[89:30] everything about Spirited Away. It's
[89:32] probably one of my favorite Ghibli
[89:33] films. And then the third was another
[89:35] Ghibli film um Nausicaa Valley of the
[89:38] Wind. And uh I I think about this one
[89:41] quite a bit because if anyone asked me,
[89:43] "Hey, how did you kind of think about
[89:45] you know, all these leadership traits?"
[89:47] I think what I watched that movie
[89:48] probably when I was eight or nine.
[89:50] And the the heroine Nausicaa and how she
[89:54] seeing how she leads just left such a
[89:57] like um just left such a footprint in my
[90:00] heart I guess you could say that
[90:02] probably Nausicaa has inspired me to a
[90:05] lot and a lot of my different leadership
[90:07] principles.
[90:08] >> Wow, what what is that book called
[90:09] again?
[90:10] >> Uh the the movie's called like Nausicaä
[90:12] of the Valley of the Wind, but it was
[90:13] actually based on a on a manga.
[90:15] >> Valley of the Wind. So, it's like High
[90:16] Output Management Andy Grove, Valley of
[90:18] the Wind Nausicaä.
[90:20] >> [laughter]
[90:20] >> That's right.
[90:21] >> Two top management books. So cool. Okay.
[90:24] Uh do you have a favorite product you
[90:26] recently discovered that you really
[90:28] love? Could be an app, could be
[90:30] clothing, could be a gadget, could be
[90:31] kitchen equipment. Uh
[90:32] >> I'll I'll share the product that I was
[90:35] reminded of how much has made a
[90:36] difference in my life recently. Uh cuz
[90:38] I've been just traveling a little bit
[90:41] and so I don't I and I like to travel
[90:43] really light. So, I I use whatever
[90:45] shampoo and conditioner, you know, that
[90:47] the hotel gives. And I forgot that um so
[90:51] the the the product that I I actually
[90:53] have one of their hand I promise this is
[90:55] not an infomercial. But
[90:58] Sweet Sisters Bodycare. It's, you know,
[91:01] a
[91:01] a local business on on Whidbey Island.
[91:04] Um but the reason why their product has
[91:06] made such a big difference in my life uh
[91:08] it's a full line of organic hair, body,
[91:11] skin care. But a few years ago I started
[91:14] getting this rash on my nose right here
[91:15] that was really painful, like actually
[91:17] bleeding. And I could not for the life
[91:19] of me figure out how to stop it. Like I
[91:21] tried not using any lotions. Like I cut
[91:24] everything out on my face and it was
[91:25] still really hurting and then somebody
[91:27] says, "What's the shampoo you're using?"
[91:29] I'm like, "It's the same shampoo I've
[91:30] used since I was, you know, like a
[91:32] teenager." And they're like, "Maybe your
[91:34] body has now um and it's, you know, like
[91:36] generic, you know, brown shampoo that
[91:38] you get anywhere." And they said, "Maybe
[91:39] your body's just started developing an
[91:41] allergy to to it because of the
[91:43] chemicals uh in it that I like it."
[91:45] >> Wow.
[91:46] >> I'm like, "What?" And so anyways, this
[91:48] was an organic shampoo that I found. Lo
[91:51] and behold, I use their shampoo and then
[91:53] cuz I you don't think that when you wash
[91:55] your hair, it actually then, you know,
[91:57] like goes goes over to the to the rest
[91:59] of your body. But so since then I've
[92:00] switched everything that I used to be
[92:03] Sweet Sisters. Um but I'm recently
[92:05] reminded of how important this is cuz
[92:07] after a week of uh yeah, hotel shampoo,
[92:10] I I actually started having some skin
[92:12] reactions again. I'm like, "Ah, maybe I
[92:14] should get like travel-size bottles that
[92:17] I can bring with me."
[92:18] >> This is an awesome pick. I love local
[92:20] local business picks, even big bonus
[92:22] points for that. Uh and by the way, this
[92:24] travel you're doing just for folks that
[92:25] may not know this, there's a there's
[92:27] these Code with Claude events that are
[92:28] happening all over the world. I went to
[92:30] the one in SF. There was one in London.
[92:32] You're going to one in Tokyo. Is that
[92:34] the end of it or is there more after
[92:35] that?
[92:36] >> Uh Tokyo is So, yeah, that's next week
[92:38] and that's the last leg of of the trip.
[92:40] >> And then probably probably more in the
[92:42] future. Uh
[92:43] >> [laughter]
[92:43] >> so cool. I love that that's happening.
[92:45] Okay, two more questions. Do you have a
[92:47] favorite life motto that you find
[92:48] yourself coming back to often in work or
[92:50] in life?
[92:51] >> Ooh. Um so, in work, I really love to
[92:54] remind folks keep it simple. Like, what
[92:56] is the the thing that you're really
[92:58] trying to do well and and focus on that?
[93:00] Do you know, like keep it simple cuz I
[93:01] think sometimes we could overthink. Uh
[93:03] so, it's always a good mantra to think
[93:05] about that. Uh and then in life, um you
[93:08] know, probably in a world where you can
[93:10] be anything, be kind.
[93:11] >> Yeah. I love that one. I We were at a
[93:14] at a Montessori school uh tour and
[93:17] that's what the teacher had up on the
[93:18] wall.
[93:19] >> Aw. Like, it's you know, we have we have
[93:22] so many things going on that you never
[93:24] know what's going on in someone else's
[93:25] life and that one small act of of
[93:27] kindness can make the biggest
[93:29] difference. Like, um
[93:31] >> Yeah.
[93:31] >> For for me, actually, that was what
[93:33] Remember Do you remember COVID? We were
[93:35] all like working from home during, you
[93:37] know, the COVID days.
[93:39] >> Um I it it just always really stuck
[93:41] struck with me cuz I was in these, you
[93:43] know, back-to-back meetings and I and I
[93:45] always one-on-ones are really important
[93:46] to me because, you know, that I actually
[93:49] that time is usually also really
[93:50] important for the other person. It's
[93:51] something that, you know, they've been
[93:52] looking to. They might have things they
[93:54] discuss. So, I always try it, I always
[93:56] really prioritize one-on-ones. Uh but
[93:58] during that time I my grandmother wasn't
[94:01] doing well and she was in a home in
[94:03] Canada and because of COVID I couldn't
[94:05] go visit and actually even my aunt uh
[94:08] you know, aunt and mom couldn't go
[94:09] visit. And it was this very rare of if
[94:13] if they have a helper that can help we
[94:15] could do FaceTime. But you never know
[94:17] what time that is going to be because
[94:19] you know, there's so many people to take
[94:21] care and all of a sudden I got a message
[94:22] from my aunt going, "Grandma can
[94:24] FaceTime at like 12:00 p.m. today." I'm
[94:26] like, "Oh no, there's this one-on-one
[94:28] that I I've been meaning to have and I I
[94:29] just messaged uh you know, my report to
[94:32] say, "I'm really really sorry. It's so
[94:34] last minute. Is it okay to and I know it
[94:36] now it's when I say it it doesn't seem
[94:38] like it's a big thing cuz it's like but
[94:40] to me it's always really important to
[94:42] keep but he was like, "Yeah, totally. No
[94:43] problem at all." And for me that was
[94:45] just a small act of kindness. He doesn't
[94:47] and he totally didn't make it into a big
[94:48] deal but that made the biggest
[94:49] difference to me that I got to you know,
[94:51] say hi to my grandmother on FaceTime.
[94:53] >> I love that.
[94:54] >> [laughter]
[94:55] >> Okay. Uh final question. Uh so Boris
[94:58] Cherny, when I asked him about you, when
[95:00] he had this interesting insight where he
[95:03] said, "In very important meetings you
[95:04] can often hear Fiona you can hear the
[95:06] click-clack of Fiona knitting
[95:08] in the background."
[95:10] >> [laughter]
[95:11] >> Uh
[95:12] maybe talk about just what's going on
[95:14] there and what's [laughter] what are a
[95:16] couple things you knitted recently?
[95:18] Oh my gosh. Well, I I knitted this top
[95:21] recently.
[95:22] >> You make your own clothing. Unreal. This
[95:24] is [laughter] very meta for Cloud Code
[95:27] building itself.
[95:28] >> You know, we're always building our
[95:29] clothing.
[95:30] >> [laughter]
[95:30] >> Yeah, actually actually this is whole
[95:32] fun thing I I think between knitting and
[95:34] programming cuz it's kind of like two
[95:36] stitches, knit and a purl, so it's zero
[95:38] and one. And anyway, so many concepts of
[95:40] stocks and queues you actually could
[95:42] Like I'm kind of like a compiler. I'm
[95:43] kind of like you know, generating a an
[95:45] executable when I knit. Um but I don't
[95:48] [laughter] know about that. Yeah,
[95:49] actually it was my my grandma that
[95:50] taught me to to knit when I was eight. I
[95:52] kind of mentioned her and I um going to
[95:54] that yarn shop and so every time I I I
[95:57] knit I think of her. Um but I I always
[96:00] like to multitask as you can see. Like
[96:01] yeah, I kick off multiple agents and so
[96:03] anytime I'm sitting and because um I
[96:06] practice enough and got proficient I
[96:07] have to I don't have to look at at what
[96:09] I'm doing. So it's almost almost like
[96:11] how you know sometimes people have like
[96:12] fidget spinners and such. Uh knitting is
[96:14] just so anytime I'm sitting still I'm
[96:16] like, oh this is time to you know like
[96:18] generate more knitting. It's cute. Well,
[96:21] cuz I got so much yarn that if I don't
[96:22] do this yeah, my my yarn
[96:25] I'm I might have a slight yarn addiction
[96:27] problem.
[96:28] >> I love this. When I when I asked Boris
[96:30] what he would do when AGI hits when we
[96:32] don't have to work he said he's going to
[96:34] make me so I'm guessing your answer
[96:35] would be just knit and make beautiful
[96:36] clothing. [laughter]
[96:37] >> Oh my gosh, my dream is to actually open
[96:39] up a a yarn store in my grandmother's
[96:41] name and and create that community.
[96:44] >> And then co-work would help out you
[96:45] automate everything.
[96:46] >> That's right. Especially invoicing.
[96:49] >> [laughter]
[96:50] >> Oh my god. Fiona, you're awesome.
[96:52] It's just incredible the work that you
[96:54] and your team are doing just changing
[96:56] the world in such profound ways
[96:58] and there's no it's clear why it's
[97:01] growing so fast.
[97:03] So good job. Good job over there.
[97:05] Thank you for making time for this.
[97:07] >> Well, I'm just really honestly lucky and
[97:09] humble that I get to work with such an
[97:11] amazing team. Like I know how lucky and
[97:13] I am I am and I'm so grateful. But
[97:16] thanks a lot for having me on the
[97:17] podcast as well. This was a lot of fun.
[97:19] >> Uh to follow up on questions, where can
[97:20] folks find you online if you are online
[97:22] if they want to follow up on anything
[97:24] and how can listeners be useful to you?
[97:26] >> Ooh, uh so definitely I'm on LinkedIn
[97:29] and I'm sure most people have shared
[97:30] this already but would love feedback of
[97:32] what's going well, what's not going
[97:34] well. Um also any latent demand that you
[97:37] are all using that might be interesting
[97:39] use cases. You know, I had a friend
[97:40] message me recently to go, oh I'm using
[97:43] Claude to help me generate uh
[97:45] a building plan for my shed and he
[97:47] actually showed me his his shed, which
[97:49] was cool. So would would love to hear
[97:51] about that. And then yeah, maybe also,
[97:54] you know, we talked about reaching out
[97:56] across over there's someone whether a
[97:57] small business that you love or or
[97:59] someone that you feel like hasn't
[98:01] you know, as some of the listeners are
[98:03] super AI pill. Yeah, maybe take a time
[98:05] to hold somebody's hand to show what's
[98:09] AI might be able to help them with.
[98:11] >> Such a good one. That is such a good
[98:12] answer to this question. Especially
[98:14] coming from you, Fiona. This was
[98:16] awesome. Thank you so much for being
[98:18] here.
[98:18] >> Thanks so much for having me, Lenny.
[98:20] >> Bye everyone.
[98:22] Thank you so much for listening. If you
[98:23] found this valuable, you can subscribe
[98:25] to the show on Apple Podcasts, Spotify,
[98:27] or your favorite podcast app.
[98:30] Also, please consider giving us a rating
[98:32] or leaving a review as [music] that
[98:33] really helps other listeners find the
[98:35] podcast. You can find all past episodes
[98:37] or learn more about the show at
[98:39] lennyspodcast.com. [music]
[98:41] See you in the next episode.
