Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)
In a Nutshell
Fiona Fung describes how Anthropic's engineering teams now ship 8x more code because AI has removed coding as the bottleneck, shifting focus to ambition, verification, and quality. The most effective engineers demonstrate high agency paired with high accountability, while non-engineers like PMs and designers now write production code directly. Teams combat isolation and skill gaps through deliberate rituals like pairwise programming lunches, automated feedback routines, and maintaining "trust but verify" practices even as agents handle most implementation work.
These notes were generated by AI and may contain inaccuracies.
Anthropic engineers on average ship eight times as much code per quarter as they did compared to 2021 to 2025. Coding is no longer the bottleneck. It has lifted the ceiling of what anyone is able to do. Everything is now possible in theory. Now it is about how ambitious you can be. The people that seem to be doing best are taking the most initiative, getting the most proactive, and have the most agency. High agency comes with high accountability. The focus is on ensuring folks have the freedom to code while also maintaining accountability for outcomes and the hypothesis of what they are trying to solve.
Working extensively with AI agents can start being a lonely experience. On the Claude Code team, pairwise programming lunch was recently started. A gap is forming between people that are leaning into AI and excelling versus people that are not, who are super frustrated, fighting, and resisting. In terms of frustration, there is sometimes a little bit of fear. The advice for fear is to lean in and ask, "What can I do about it? What is within my control?"
Fiona Fung leads the teams behind Claude Code and Co-work at Anthropic. She oversees Boris Cherney and Kat Wu. Before Anthropic, at Microsoft she ran the teams that built TypeScript and Visual Studio. At Facebook she started the Facebook Marketplace team, which she took from idea to launch. Facebook Marketplace now generates over 100 billion dollars in GMV every year. While at Meta she oversaw work on Meta's first smart glasses product and helped build Orion, their first AR glasses product. At Instagram she led infrastructure, growth, integrity, and safety teams and oversaw an org of over 500 people. Fiona has been an engineer for over 25 years.
Fiona started at IBM on the DB2 operating system services team. At IBM, work was done primarily in Vim with terminal debugging and limited use of IDEs like Eclipse. Joining Microsoft and the Visual Studio team was the first exposure to a full IDE with debuggers, breakpoints, and multi-threaded debugging. Working on the Visual Studio editor team meant using VS editor to build the VS editor, which developed a strong emphasis on dogfooding. Before social media, rapid customer feedback was harder to obtain, but the team gave each other rapid feedback because they were all heavy VS users.
Software used to be shipped on CDs, which created hard deadlines for manufacturing. There was more planning because engineering time was a precious resource with fixed release windows. Once shipping moved online, the constraints changed. Now coding is no longer the bottleneck. On the Claude Code team, not only engineers but also designers and PMs check in code. Throughput is so high that the focus has shifted to verification and quality.
Roles are shifting so that everybody becomes a builder. Fiona maintains a Claude Code remote session enlisted in all repos for full visibility into everyone's work. This instance also has access to all Slack channels and metrics. Every month the team reviews focus areas, products shipped, performance, and feedback channels together using Claude Code. These sessions enable conversations with supported team members beyond just generating PRs and bug fixes.
Claude sessions are used to review not just shipping activity but also market performance and whether bugs were caused. The principle is to "make new mistakes" because aiming for zero mistakes likely means moving too cautiously. Claude can analyze incidents across the organization to generate themes and identify quality investment areas. This level of insight was not possible a year ago when shipping volume was lower.
A morning ritual involves getting coffee and reviewing feedback channels to identify gaps or areas to help. Recently, routines were launched that automate feedback monitoring. Routines generate summaries of feedback themes and even PRs for review upon waking. Feedback comes from internal sources, emails, Slack channels, friends, LinkedIn, social media, and partnerships. All feedback is posted in Slack. Claude is essential for staying on top of the volume of incoming feedback.
Claude Code Reviews did not exist last year and previously represented a major human-review bottleneck. For areas requiring deep subject matter expertise, human review is still used. For everything else, frameworks defining "what good looks like" are checked into the repo. Claude validates against these frameworks during code review. Specs are checked into the repo and kept up to date with the code. Any statement of what good looks like should be added to the repo so Claude Code Review can validate against it.
Test-driven development used to feel like paying a tax because tests had to be written before the thrill of shipping. The first bug fixed on Claude Code involved asking Claude to write the failing test first, then implement the fix until the test passed. Test generation is now automated. Principles that were previously inefficient are now more practical because models handle more of the work.
Two profiles are prioritized when hiring: creative builders with product sense and deep systems experts for the hard parts. When Fiona first joined Claude Code, the team had strong product generalists but was missing systems and distributed systems expertise. Deep subject matter expertise remains necessary in areas requiring verification because models still need trust but verify. Creative builders are dreamers who are passionate about a product, build it, gather feedback, iterate, and own the end-to-end experience.
The shift enables anyone to tackle areas outside their primary expertise. An engineer who is not a mobile specialist was able to add a mobile footprint to a feature because Claude served as a partner. The ceiling of what anyone is able to do has been lifted. It is no longer about whether something is hard and complicated but about how ambitious one can be.
A growth mindset is highly valuable. The concept is to always be learning and recognize that what served success previously may no longer serve in the new environment. It can be scary to change the behaviors that led to past success. People who are thriving lean in with curiosity and are always learning. Frustration sometimes stems from fear. The advice is to lean in and ask what can be done and what is within one's control. Instead of feeling that change is happening to you, reframe it as happening for you and identify actions that can be taken.
Fiona Fung initially wanted to be a visual artist rather than pursue computer science or engineering. She grew up without access to computers until grade nine in high school in Ontario, Canada. Her first exposure to computers was through a typing class, followed by an HTML programming class. She fell in love with programming because it enabled her to create and tell stories, similar to her love for art.
She faced significant financial uncertainty about affording engineering school. The Ontario Student Assistance Program (OSAP) existed but the coverage amount was unknown. As a solution within her control, she took a minimum wage position as a bank teller at National Bank of Canada after seeing a flyer at her high school. Despite hating her high school accounting class, she worked through the summer and continued on weekends during school. This income covered her school expenses. After the year 2000 dot-com crash reduced internship opportunities, she continued working as a bank teller for two years.
Fung shares two favorite sayings that guided her: "What would you do if you're not afraid" and "Do something scary once in a while." She explains that when professionals reach peak efficiency, growth requires doing something new that feels scary, which involves a temporary learning dip. The host shares the quote "The cave you fear contains the treasure you seek," noting that what feels scariest often points toward what should be pursued. Fung agrees and notes this applies to career moves, though not necessarily extreme actions like jumping off cliffs.
A gap is forming between people leaning into AI and those being left behind. Fung's passion for helping small businesses with AI stems from her childhood experience moving from Hong Kong to Canada. Her grandmother, who didn't speak English, found community through a local yarn shop owned by a Cantonese speaker, where she joined a knitting circle. This experience showed Fung how small businesses create community.
Fung discovered Coda's capabilities while using it for her own business expense tracking and realized it could help her small business owner friends who work hard on thin margins. She helped several onboard, which revealed unexpected use cases. One friend running two restaurants used Coda to search a documents folder for menus and to perform market analysis comparing cuisine prices in the area between locals and tourists.
Fung recommends that AI-fluent listeners start conversations by sharing specific AI tools that have made meaningful life changes for them. She frames AI as a tool that provides knowledge and power. She acknowledges the awkwardness of reaching out to friends about AI but found these conversations enjoyable. Her goal is ensuring equitable access to tools to prevent the divide from growing larger.
The host shares an example of using Coda to fill out his son's camp forms and posting about it on Twitter, which helped others discover new use cases.
Anthropic identified coding as a major market opportunity early. Coda represents another early move into knowledge work. The company also focused early on model personality and its importance for both user experience and model performance.
Fung explains the approach involves watching for latent demand - unexpected user behaviors. With Claude Code, the team noticed non-coders using it and worked to improve that experience. After helping small businesses, the team launched Claude for Small Business, which bundles relevant plugins and features into a toggle within Coda. This came from observing small business owners asking about specific plugins and from team members running Coda sessions with small businesses.
Fung emphasizes iterating based on customer feedback and accepting that customers will use products in unintended ways. The best approach is staying close to feedback and iterating continuously.
Engineering work is shifting toward asynchronous patterns. Routines allow setting up recurring prompts that run automatically. For example, a routine can run every morning to review a Slack channel, identify bugs, and kick off agents to generate potential fixes. The user wakes up to review pull requests rather than manually initiating each step.
This represents a higher level of abstraction where routines generate prompts that spawn agents. Managers can set up daily routines for checking project status, identifying blockers, and suggesting improvements. If verification is strong, the system can be given autonomy to execute changes.
Tyler Cowen's concept of initiative (also called agency) resonates with Fung. On the Claude Code and Coda teams, high agency paired with high accountability is valued. Team members have freedom to address problems with their own ideas while maintaining accountability for outcomes. The balance between agency and accountability has served the team well.
Productivity measurement has evolved from tracking lines of code to questioning what that actually measures. One engineer generated high lines of code by porting a library, while framework updates might reduce code volume while maintaining output. Time to land PRs was considered as an alternative metric.
Fung advises focusing on whether output serves the intended outcome rather than measuring motion over progress. When adopting AI tooling across teams, she recommends leaders conduct listening tours, especially with senior engineers, to understand what's working and scale learnings. Metrics are useful for hill climbing but should be evaluated for whether they still serve the original outcome.
She shares an example from early Facebook Marketplace days where number of sellers was tracked as a metric. After launching in one region, seller numbers were low but power sellers existed and buyers were finding items - the actual goal. The metric was updated based on this insight.
Metrics can quickly become outdated when the landscape changes rapidly. Fiona shared an example where tracking the number of sellers failed to account for power sellers, requiring the metric to be updated. The key lesson is to continually reassess whether a metric still captures what matters, rather than following it blindly.
Claude watches all PRs shipping per engineer. Rather than focusing purely on metrics, the system triggers conversations about impact, bugs encountered, and overall contribution. This approach provides richer insight into an engineer's work than raw numbers alone.
With dramatically increased code velocity, proactive quality measures become essential. Teams should identify key experiences and track trends over time rather than relying solely on raw performance or reliability numbers.
Fiona introduced a simple classification system: bad refers to very bad, irrecoverable errors, while sad refers to recoverable pain points. Stacking multiple "sads" can eventually lead to "bad" outcomes. This high-level framework helps teams make sense of quality across diverse product surfaces where traditional dashboard metrics may be ambiguous.
Each team defines what constitutes a "bad" or "sad" experience for their specific surface areas or services. For example, on CLI, crash rates count as bad because work is lost, while flickering might count as sad. This agency allows teams to set appropriate goals while maintaining a shared language for discussing quality.
Given the impossibility of manual review at current speeds, teams should invest more heavily in tests, evals, and automated monitoring. The goal is to close the loop so agents can detect issues and fix them autonomously.
An engineer proposed tracking swear words as a proxy for user frustration. The resulting dashboard became a lighthearted but useful signal for identifying painful experiences that traditional metrics might miss.
Every manager at Anthropic starts as an individual contributor and continues contributing part-time. This structure emerged from a listening tour where engineers requested better prioritization support and fewer review layers. Starting as an IC gives new managers time to deeply learn the codebase and product before taking on people-management responsibilities.
The model builds stronger rapport because managers first experience what it is like to be an engineer on the team rather than immediately applying management frameworks. It also keeps leaders in direct contact with the product. Fiona continues shipping PRs herself, not primarily for the code changes but to maintain tactile understanding of how the product is evolving.
Across multiple companies (Instagram, VR, smart glasses, Meta), Fiona consistently received feedback that her active use of the product stood out. Dogfooding surfaces unexpected usage patterns and edge cases that metrics and dashboards often miss. It also provides personal, visceral feedback on the team's work.
Fiona previously oversaw an organization of roughly 500 people at Meta. Upon joining Anthropic she began as an IC for a short period to learn the codebase and tools. She had followed a similar pattern when moving from Microsoft to Meta, spending her first quarter as an IC to understand what it felt like to ship as a Meta engineer.
When Fiona first joined, Claude served as an effective onboarding buddy. She used it to explore the codebase, generate automated tests, and create manual test plans. This gave her confidence to ship production code again after years away from day-to-day engineering. Several former managers have reached out to her noting they are shipping code again thanks to Claude.
The team has discussed whether engineers' coding skills might atrophy. Fiona emphasizes the continued importance of understanding architecture and dependencies even when agents generate most of the code. The principle of "trust but verify" remains relevant; double-clicking into layers you depend on helps engineers stay aware when those dependencies change.
Heavy agent usage created a lonely experience for some engineers. The team introduced pairwise programming lunches where engineers work side-by-side. Because everyone uses Claude Code and Code Work differently, watching others work reveals new workflows and techniques. Hackathons serve a similar purpose by ensuring engineers interact as a team.
Fiona has not observed excessive optimization of individual workflows. Team conversations tend to focus on architecture improvements and product experience rather than perfecting prompts or processes, partly because no single optimal answer exists.
Engineers report missing the deep flow state associated with tackling a difficult problem alone and experiencing the "aha" moment upon solving it. While product impact still brings joy, some of the hardest and most satisfying parts of the job have shifted. The pairwise programming and hackathon initiatives were partly responses to this emerging sense of isolation.
After engineering, product management has changed significantly. PMs are no longer bottlenecked by engineering bandwidth; they can implement features themselves when needed. All coding-adjacent roles are shifting. Data science is also transforming, with data scientists increasingly reviewing AI-generated analyses rather than performing the work themselves.
Most commits are now Claude-assisted. Engineers are expected to develop stronger product sense and take greater ownership of quality and success. Cross-functional blocks have decreased because models can augment capabilities engineers previously lacked.
The distinction between roles is blurring. Engineers are becoming more product-minded, while non-engineers are performing more engineering work. One framing is that a person's role is increasingly defined by the highest-percentage activity they perform.
Dogfooding keeps leaders close to the actual user experience rather than relying solely on metrics, dashboards, or presentations. Real usage often reveals unexpected behaviors and edge cases. Fiona recounted discovering new scam vectors on Marketplace by personally trying to sell an item, and identifying floor-height issues in VR through her own usage patterns.
Product leaders and engineering leaders have found significant success by valuing specific user anecdotes and one-off experiences alongside data analysis rather than obsessing over data alone. This approach has helped leaders effectively support their teams beyond metrics.
One leader shared their experience leading a VR team where they avoided checking code into the codebase due to concerns about potentially breaking the operating system. Instead, they used their dogfooding time to vet how the experience actually felt for users. This approach helped maintain the quality bar for the team during a period focused on polish fixes. Team members generally appreciate when leaders use their own products, as it demonstrates genuine engagement beyond metrics.
Engineers can develop product intuition by constantly using their own products, which naturally reveals what's missing from the user perspective. When it's difficult for leaders to directly use their product, meeting with customers provides an alternative avenue for gaining insights.
Customer visits consistently yield new learnings. During a Facebook Marketplace expansion to Latin America, a small research trip to Chile revealed a critical issue: the LTE connection was significantly slower than in the US, causing the Marketplace feed to load poorly. This infrastructure constraint was a major growth blocker that wouldn't have been apparent without on-the-ground observation.
Jeff Bezos has stated that when you have both data and an anecdote, trust the anecdote. This principle was illustrated by the Chile Marketplace example where direct observation revealed issues invisible in aggregate data.
Several structural questions remain unresolved as AI capabilities evolve rapidly. First, whether separate iOS and Android organizations are still necessary. Second, how far to push fully automated reviews. Third, with increasing role blurring, how to ensure everyone remains equally productive.
While deep platform expertise remains important, organizations likely don't need as large dedicated mobile teams because engineers are increasingly flexing across platforms. The balance involves maintaining enough expertise without oversized platform-specific organizations.
The challenge extends beyond accuracy to defining what good looks like across automated systems. Verification remains a key area with significant opportunities, particularly ensuring experiences meet intended quality standards beyond just functional correctness.
Setting up verification that confirms the experience matches intended outcomes remains difficult to solve. This involves both accuracy metrics and experiential quality, making it harder to fully automate than purely technical evaluations.
With increased async work and routines, there's a growing context switching burden. When managing twenty agents, constant checking, reviewing, and tracking multiple workstreams increases cognitive load. The need to remember context across multiple in-progress agent tasks creates friction.
Traditional hours of deep flow are being replaced by more fragmented work patterns. However, agents can reduce the cost of context switching by reminding engineers of current state, eliminating the need to relearn codebases and architectures when returning to tasks. This creates a mixed outcome where some aspects improve while others degrade.
Leaders who previously blocked focus time for coding now find they need to block time specifically to catch up on async work initiated across multiple agents. The increased ability to context switch creates a corresponding need for dedicated time to process accumulated async outputs.
Despite AI capabilities, demand for engineers remains extremely high at companies like Anthropic and OpenAI. The question of how the engineering role evolves remains open, particularly regarding how new engineers will develop deep technical understanding.
Traditional paths to engineering expertise may no longer apply. The concern is how new graduates can develop the ability to double-click into technical layers without years of hands-on coding experience. There's speculation that software engineering education might shift toward fellowship or apprenticeship models rather than short three-month internships with limited projects.
If engineers never need to examine code directly, the incentive to understand infrastructure, memory allocation, and other foundational concepts diminishes. The question remains whether models will improve to the point where this knowledge becomes unnecessary, or whether there will always be value in understanding underlying systems.
Engineers who began with punch cards have successfully adapted to modern AI-assisted development, demonstrating that career-long adaptation to new paradigms is possible. The key question is identifying what remains important versus what changes in importance as abstraction layers evolve.
The progression from assembly and binary to higher-level languages continues upward. Prompts and model thinking messages represent another abstraction layer. The challenge becomes determining which problems are interesting and how to build proficiency in the new paradigm.
As abstraction increases, determining whether built artifacts are resonating with users and whether they're architecturally sound becomes harder. The risk is building significant amounts of low-quality output versus creating durable, functional systems.
Engineers who initially resisted AI tooling pointed to current model limitations, but underestimated the exponential rate of improvement. Tasks that couldn't be automated with earlier models become viable with subsequent releases, requiring ongoing reassessment of what capabilities have newly become accessible.
The primary concern is preserving team culture—the one-team mentality where people look behind them near project completion to ensure everyone finishes together. Culture is a living, breathing element that manifests in how team members treat and support each other, not a static poster. As teams grow rapidly, maintaining diverse perspectives, enabling healthy open debate, and catching cultural drift becomes critical.
At Airbnb during its growth phase, founder obsession with culture—repeatedly emphasizing values in all-hands meetings and major gatherings—was essential. Sheryl Sandberg advised that struggling with culture during rapid growth is actually the problem you want to have, as it indicates the company is succeeding. The alternative of not growing and not hiring is significantly worse.
Managers are explicitly encouraged to discuss both successes and failures openly. The nightmare scenario is a manager reporting that everything is fine while significant problems exist. Creating space for honest conversations about what's not working enables collective problem-solving.
Teams should have explicit permission to eliminate processes that no longer serve their purpose. This includes processes that are dreaded, highly noisy, expensive, or excessively manual. The question to ask is whether a process still serves its intended purpose, especially given the rapid pace of change in the field.
A six-month roadmap document was replaced with JIT (just-in-time) monthly planning using lightweight spreadsheets rather than formal documents. The focus is on aligning on highest priorities for the upcoming month, with weekly check-ins to verify priorities remain relevant. The entire team comes together every six months to establish broader themes, but detailed planning stays at the monthly level due to rapid landscape changes.
Margaret Atwood is recommended for her speculative fiction that invites readers to consider how imagined scenarios could plausibly manifest in society. Haruki Murakami is recommended for his magical realism style.
Fiona recommends reading The Little Prince at least once a year as a reminder of what is truly important.
Fiona does not watch TV shows. She keeps three movies downloaded on her phone for airplane travel:
- Amelie - a French movie she loves for its whimsical quality. She connects it to a high school trip to Paris at age 16 when she thought she would become a visual artist. The film captures the magic she felt in Paris.
- Spirited Away - her favorite Studio Ghibli film.
- Nausicaä of the Valley of the Wind - another Ghibli film. She watched it at age eight or nine, and the heroine Nausicaä's leadership style left a deep impression that inspired many of her own leadership principles.
The manga Nausicaä of the Valley of the Wind is referenced alongside High Output Management by Andy Grove as two top management books.
Fiona recommends Sweet Sisters Bodycare, a local organic hair, body, and skincare business on Whidbey Island. A few years ago she developed a painful, bleeding rash on her nose that would not resolve despite eliminating lotions. Someone suggested checking her shampoo. She had used the same generic brown shampoo since her teenage years and discovered she had developed an allergy to the chemicals. Switching to Sweet Sisters organic shampoo resolved the issue. She now uses their full line because shampoo residue contacts the rest of the body during rinsing. Recent travel reminded her of its importance after a week of hotel shampoo caused skin reactions again. She plans to get travel-size bottles.
Fiona mentions the Code with Claude events happening worldwide. She attended or is attending the Tokyo event, which is the final leg of the current tour. More events are planned in the future.
In work, Fiona's motto is "keep it simple" - focus on the core thing you are trying to do well and avoid overthinking.
In life, her motto is: "In a world where you can be anything, be kind."
She shares that one small act of kindness can make the biggest difference because you never know what someone else is going through. During COVID, while working from home with back-to-back meetings, her grandmother in Canada was unwell and could not receive visitors. Fiona received a last-minute message that her grandmother could FaceTime at noon. She messaged her direct report to reschedule their one-on-one. The report responded "Yeah, totally. No problem at all," allowing Fiona to connect with her grandmother. She emphasizes that one-on-ones are important to her and that this small kindness made a significant difference.
Boris Cherny noted that in important meetings, the click-clack of Fiona knitting can often be heard. Fiona knits her own clothing and recently completed a top. She compares knitting to programming: both involve two basic actions (knit and purl, analogous to zero and one), and concepts like stacks and queues apply. She describes herself as a compiler generating an executable when knitting.
Her grandmother taught her to knit at age eight. Every time she knits she thinks of her grandmother. She knits while sitting still because she has become proficient enough to knit without looking, similar to a fidget spinner. She has accumulated so much yarn that she jokes about having a slight yarn addiction. When asked what she would do when AGI arrives and work is no longer necessary, she says her dream is to open a yarn store in her grandmother's name and create that community. She notes that co-work could help automate everything, especially invoicing.
Fiona expresses feeling lucky and humble to work with an amazing team and is grateful for the opportunity.
She can be found on LinkedIn. She welcomes feedback on what is going well and what is not, as well as any latent demand or interesting use cases for Claude. She shares an example of a friend using Claude to generate a building plan for a shed. She also encourages listeners to reach out to small businesses or people who may not yet be using AI and take time to show them what AI might help with.
The episode closes with thanks to Fiona and listeners, subscription and review requests, and a reference to lennyspodcast.com.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
