Fiona Fung on Running Claude Code and Cowork When Coding Is No Longer the Bottleneck
Lenny's Podcast
Fiona Fung leads the teams behind Claude Code and Cowork at Anthropic, overseeing Boris Cherny and Kat Wu. Before Anthropic she spent 11 years at Microsoft on Visual Studio and TypeScript. At Facebook she started the Marketplace team and took it from idea to launch, worked on Meta's first smart glasses and the Orion AR glasses, and led infrastructure, growth, integrity and safety teams at Instagram, in an org of over 500 people. In this conversation with Lenny Rachitsky, the central question is what building software and managing software teams looks like once code is no longer the scarce resource. Her answer: the bottleneck has moved to verification, judgment, product sense and culture. She is candid that several of the resulting problems are still unsolved on her own team.
The backdrop is a figure Anthropic published the day before the recording. Anthropic engineers, on average, now ship eight times as much code per quarter as they did over 2021–2025. Lenny described the chart as flat for years and then shooting up.
Earlier step changes: from Vim at IBM to Visual Studio
Asked about turning points in her 25-year career, Fung started with her IBM internship on DB2, working with the operating system services team. At the time she believed that the lower in the stack you worked, the more hardcore it was and the more you learned. Development there mostly meant Vim and terminal debugging. There may have been an Eclipse license, but most people didn't use it.
She joined Microsoft in the early 2000s, just after the dot-com crash had frozen hiring for much of her graduating class, and felt lucky to get an offer at all. She was assigned to Visual Studio without knowing what it was; coming from a Unix-oriented school, she guessed from the name that it might be a better paint program. It became, in her words, the love of her life for the next 11 years. It was also her first IDE, and she remembers being amazed by breakpoints and multi-threaded debugging.
Her lifelong commitment to dogfooding comes from that period. She worked on the Visual Studio editor team, using the VS editor to build the VS editor. Before social media, engineers rarely got fast customer feedback beyond user research sessions or customer visits. The VS team could give each other rapid feedback because everyone was a heavy user of the product.
She also described shipping software on CDs. Discs had to go to manufacturing and then onto store shelves, so deadlines were hard. Engineering time was precious, and teams did extensive planning to make the best use of it. Her point is that this assumption has now flipped. With Claude Code and Cowork, "coding is no longer the bottleneck." Designers, PMs and everyone else on the team check in code, and throughput is high. The shift she sees is toward the question of how to verify all of it.
Using a Claude Code session as a management instrument
When Lenny asked what an "AI-pilled" software team looks like in 2026, Fung said roles are blurring and everyone becomes a builder. She then described one of her own practices. She runs a Claude Code remote session enlisted in all of the team's repos. It also has access to the team's Slack channels and the metrics they track, which gives her visibility into everyone's work.
She uses this session less to generate PRs and more as a basis for conversations with the people she supports. Every month she does a look-back with people, sharing her screen and running the Claude Code session together. They ask what the focus areas were, what shipped, how it did in market, which feedback channels lit up, and whether anything caused bugs. She said she tells people to "make new mistakes." Mistakes are fine as long as they are new ones, because aiming for zero mistakes probably means moving too slowly or being too cautious.
She also uses the session for cross-cutting analysis. For example, she asks it to look across recent incidents, generate themes, and find quality "hot spots" that suggest where to invest. She said this used to be a much more manual process, and she doesn't think she could have gotten these insights with Claude a year earlier. Lenny suggested this may be one of the only ways to keep up with an 8x increase in output. When people shipped less, a bullet list of last quarter's features was enough.
Routines: automating the morning feedback ritual
Fung's morning used to follow a set pattern. She would get coffee, read the feedback channels, and look for gaps she could fix in her own maker time. The team receives feedback from many sources. Internal users, emails, partnerships, and messages people get from friends, on LinkedIn or on social media all get posted into Slack, with separate channels per source. She said she needs Claude's help simply to keep up with the volume.
A month or two before the recording, the team launched routines, and she said they completely changed this ritual. She now has a routine scheduled every morning that watches the feedback channels, summarizes themes, and kicks off agents to attempt polish fixes for the bugs it sees. She wakes up to a summary and to PRs she can review. The difference from earlier workflows, she explained, is a level of abstraction. Before, she wrote prompts herself, synchronously or as several async jobs, and then still had to decide what to do with the output. A cron job could automate a fixed task, but a routine can generate the prompts that spawn agents. Lenny summarized it as a manager encoding their daily check-ins, such as what's falling behind, what needs unblocking and what polish is needed, into prompts that Claude runs and then reports back on for review. Fung added that when verification is strong enough, you can eventually give it more autonomy to "go for it."
Code review: put "what good looks like" into the repo
Fung pointed out that Claude Code Review didn't exist the previous year, and human review had been a major bottleneck. For areas that need deep subject-matter expertise, the team still wants human reviewers. Beyond that, her approach is to automate as much as possible by checking the definition of "good" into the repository. Claude is very good at validating work against a framework when it's given one. As an example, she said the team recently updated its content design guidance and put it into the repo. More generally, specs should live in the repo and be kept current alongside the code, so Claude's code review can check that changes still match what the team set out to do.
Lenny called this an evolution of test-driven development. Fung agreed and recalled TDD as a 2000s movement that she found hard to practice. Writing tests first felt like eating your broccoli before the fun part of shipping. The first bug she fixed on Claude Code, she asked Claude to help her write a failing test first, then make the fix and get the test passing. What used to feel like a tax is now automated, and she suggested that older engineering principles may be worth revisiting because models can do more of the work.
Who to hire: systems experts and product-minded builders
In her Code with Claude talk, Fung described two hiring profiles: creative builders with product sense, and deep systems experts for the hard parts. She explained that when she joined Claude Code, the team had strong product generalists but lacked people with systems and distributed-systems backgrounds, so she hired for that gap. Her principle is "trust but verify." Models are very good, but many areas still need verification, and wherever deep expertise is required, it's still worth investing.
She called the other profile "the dreamers." These are people passionate about a product, who have an idea, build it, watch the feedback, and keep iterating and polishing until it's delightful, owning it end to end.
Lenny raised a theme from other conversations: ambition. Once almost everything is possible in theory, the question becomes how big you're willing to think. Fung gave an example from the day before. An engineer who is not a mobile engineer by trade needed to give a feature a mobile footprint. Instead of feeling blocked by not being an Android expert, the engineer used Claude as a partner and built it. In her words, AI has "lifted the ceiling of what anyone is able to do."
Growth mindset, fear, and what is within your control
Asked what separates engineers who are thriving from those who are frustrated or resisting, Fung pointed to a growth mindset. She said she only really understood the term during her first year after moving from Microsoft to Meta. The core idea is that what got you here may no longer serve you. She acknowledged that this is uncomfortable, since people are being asked to change the very habits that made them successful.
She said she often sees fear underneath the frustration. Her advice is to lean into the fear and ask what is within your control. Frustration often comes from feeling that everything is happening to you. Reframing it as happening for you, and finding one action you can take, helps.
She illustrated this with her own story. In high school she wanted to be a visual artist. She had no computer at home, and her first exposure was a grade-nine typing class, followed by some HTML. She fell in love with programming because, like art, it let her create and tell stories. She scrambled to make up science credits for university, but feared she couldn't afford engineering school. Ontario's student assistance program existed, but she didn't know how much it would cover. Then the National Bank of Canada posted a flyer at her school recruiting high-school interns as bank tellers. Although accounting was her least favorite class, she signed up. She worked full-time that summer and on Saturdays during the school year, which paid her school expenses. When internships dried up after the 2000 crash, she kept working as a teller for two years. That was the one action within her control against the fear.
Two sayings she has relied on are "What would you do if you weren't afraid?" and "Do something scary once in a while." When you're at peak proficiency you stop growing, and doing something new means accepting a dip while you learn. Lenny offered his most-quoted line, Joseph Campbell's "the cave you fear to enter holds the treasure you seek," and she said she'd adopt it.
The widening AI gap and small businesses
Lenny asked about the growing gap between people leaning into AI and those who aren't. Fung called this a passion topic and traced it to her childhood. She was born in Hong Kong and moved to Canada as a child without speaking English. Her parents worked constantly, and her grandmother moved with them to care for her. Her grandmother, who also didn't speak English, found life isolating until the two of them discovered a small yarn shop owned by a Cantonese-speaking woman. It became a weekly ritual. Her grandmother found a knitting circle, and Fung learned macramé. She said that is where her appreciation for how small businesses create community began.
The connection to AI came through Cowork. She was using it to handle her business travel expenses, a task she dislikes, and found it "magic." She thought of friends who run small businesses on thin margins and spend evenings at the bar with stacks of bills doing invoicing and expensing. She helped several of them onboard. Watching them go through the onboarding flow was humbling, and they found real bugs. They also used Cowork in ways she hadn't anticipated. One friend who runs two restaurants had a downloads folder that had become a junk drawer. Cowork found her lost menus in it. She then asked Claude to compare her prices against comparable restaurants with her style of cuisine in the area, because she wanted to stay reasonable for both locals and tourists. It returned something like a market analysis.
As for how to spread adoption, Fung asked AI-fluent listeners to start with something that has made a meaningful difference in their own lives and use it as a conversation starter with family, community members or businesses they love. She admitted it felt awkward at first, since she rarely talked about her work with those friends, but they ended up having fun. She sees AI as a tool with light and dark sides. She understands the frustration, but believes knowledge is power, and she worries that if the knowledge isn't shared equitably, "the divide grows larger and larger." Lenny mentioned using Cowork to fill out his son's camp forms and seeing how many people hadn't thought of that kind of use.
Latent demand and Claude for Small Business
Lenny asked what lets Anthropic spot opportunities like coding, knowledge work and model personality ahead of other labs. Fung said she hasn't worked at other labs and can't compare. What her teams do is watch for latent demand. Coding was a fortunate use case because Anthropic employees were their own first customers and could give rapid feedback. Cowork came from noticing that many people who weren't coders were using Claude Code, and asking whether that experience could be made better.
She tied this back to small businesses. After her visits, Anthropic launched Claude for Small Business, which bundles the relevant plugins behind a toggle in Cowork. She was explicit that it didn't come from her. She credited a team that had been running Cowork sessions with small businesses, though she had noticed the same friction herself, with friends asking whether a plugin existed and then having to search for it. Her general lesson is that customers will use your product in ways you didn't intend, for good or bad. When you see people "jumping through hoops" to make something work, form a hypothesis about how to make that path smoother.
Toward asynchronous work, with agency and accountability
On what comes next for engineering, Fung said work is shifting toward the asynchronous. Routines are an early sign, with the level of abstraction rising from writing prompts to writing routines that write prompts. She said she wished she had a crystal ball and suggested they revisit the question in a year.
Lenny brought up Tyler Cowen's argument that the people doing best now are those with initiative and agency. Fung said agency is central to the Claude Code and Cowork team, where everyone is expected to have ideas about how to address a problem. But she pairs it with accountability. People get freedom to "cook," but they are expected to have a hypothesis about what they're trying to solve and to own the results. She described the two as sides of the same coin.
Measuring productivity: output versus outcomes
Lenny noted a shift in mood from "token-maxing" to asking about ROI. Fung walked through the familiar problems with productivity metrics. Lines of code can be inflated by porting a library. "Significant" lines of code break down when a framework update means less code for the same output. Time to land a PR has its own issues. Her view is that token consumption is essentially the new lines-of-code metric. She quoted a saying she likes, "don't mistake motion for progress." Measuring tool usage measures activity, not whether the outcome that matters is improving. She tries to zoom out, define the problem being solved, and measure that.
For leaders rolling out AI tooling, she recommended a listening tour, especially with senior engineers, who can tell you what's working and help spread practices across the team. She said such conversations often produce ideas and shared learning that dashboards don't.
She values metrics you can hill-climb, but warned against following an outdated one blindly. Her example came from the early days of Facebook Marketplace, which launched region by region. One gate for expansion was the number of sellers. In the first region, seller counts were low, yet buyers were finding what they needed. The region was served by a small number of power sellers. The team changed the metric, and she took it as a lesson that the landscape can change quickly enough that the metrics themselves need updating.
"Bad versus sad": a framework for quality at speed
On balancing velocity with quality, Fung said the team wants to get better at proactive quality, meaning earlier detection and trend-tracking for key experiences. She introduced a distinction between "bad" and "sad." Bad is a severe, irrecoverable error. Sad is a recoverable pain point, although many sads stacked together can amount to bad.
The framework exists because raw numbers such as load times and reliability are hard to interpret across many different product surfaces, and you can't easily tell whether a given number is good. Each team defines bad and sad for its own surfaces or services and sets its own goals, which is agency again. For the CLI, a crash is bad because users lose work, and flickering might be sad. Lenny summarized the takeaway as investing in monitoring, tests and evals so agents can close the loop themselves, rather than relying on more human review. Fung agreed.
Lenny also asked about the team's dashboard tracking swear words from frustrated users. Fung said it started around the previous September, when an engineer suggested it during a period of visible user frustration, shortly after she joined. She said it illustrates why evals are hard. Accuracy is only part of it, and the real target is an experience that is delightful and less frustrating.
Managers start as ICs, and leaders use the product
One practice Fung introduced at Anthropic is that new managers start as individual contributors before taking on people. The idea came from a listening tour. People valued their agency but wanted help with prioritization, and some cautioned against too many review layers. She reasoned that starting as an IC lets new leaders go deep into the code base and product before carrying the weight of supporting people. It also builds rapport, and it keeps new managers from immediately reaching for their "manager toolbox." She did the same when she moved to Meta, where she was hired as a manager but spent roughly her first quarter as an IC to learn Meta's tools and code bases after a career at Microsoft.
She also said she hadn't shipped production software since around 2017. Part of the reason was fear of causing a bug, verifying poorly, or wasting colleagues' time. In her first week on Claude Code, she started to follow her usual routine of buying engineers coffee, then asked Claude instead. It became her onboarding buddy. She asked it questions about the code base, used it for automated tests, and asked it to design manual test plans covering the edge cases. That gave her the confidence to ship PRs again. She said several longtime managers have told her they're shipping code again thanks to Claude. For her, the PRs matter less for what they fix than for keeping her using the product every day while it changes quickly.
Dogfooding came up repeatedly, and Lenny said colleagues named it as her defining trait. After leaving Marketplace, she tried selling an old MacBook Air on it and was immediately targeted by a scam that used a vector the team hadn't detected. On the VR teams, something about her physical setup reliably reproduced odd floor-height bugs, so she became a useful repro environment. On a VR team where she avoided committing code for fear of breaking the operating system, she used dogfooding time to vet polish fixes and help hold the quality bar. She said teams consistently tell her they appreciate a leader who actually uses what they build.
When using the product is impractical, she recommends meeting customers. When Marketplace underperformed in Chile during a Latin America launch, she and two colleagues went on a small research trip with a batch of Android phones. On landing, they found that LTE connections were much slower than in the US and the Marketplace feed barely loaded. That was a growth blocker the data hadn't revealed. Lenny connected this to the saying he attributed to Jeff Bezos: when anecdote and data disagree, trust the anecdote.
Skill atrophy, lost flow, and loneliness
Asked whether engineers' coding skills will atrophy, Fung said the team discusses it. Boris wrote Claude Code by hand in the early days and absorbed its architecture that way, but he no longer does. For new engineers, she asks them to take time to understand the architecture and the changes they make, again in the spirit of "trust but verify." She conceded that "maybe one day it won't matter anymore," but at the current pace she thinks it still does. Her broader principle is to "double-click" on the layers you depend on, so you notice when dependencies change and can take advantage of those changes.
A less expected cost is loneliness. After a while, the Claude Code team felt the work was becoming isolating because everyone spent so much time with their own agent. They recently started pair-programming lunches. People turned out to use Claude Code and Cowork in very different ways, so watching each other work teaches everyone something. Hackathons serve a similar purpose. Lenny compared it to children's parallel play. Asked whether engineers over-optimize their workflows, she said she hasn't seen much of that. It makes for fun lunch conversation, but there's no perfect answer, and people are more excited about architecture and product work.
On lost flow, she recalled the old experience of tackling a gnarly problem with music on and the big "aha" when it cracked. People now get a lot of joy from the product, but she has heard engineers say that some of the hardest parts were what they used to enjoy most.
How other roles are changing
Fung said all coding-adjacent roles are shifting. PMs are no longer bottlenecked on engineering bandwidth, and PMs on her team have shipped features when no engineer was available. That puts more pressure on verification, since people from many disciplines are now checking in code. She sees design and data science as the next areas where workflows could be better automated. Lenny added an anecdote from a data scientist friend who now spends much of their time checking colleagues' AI-generated analyses, about half of which are wrong.
On what managers should now expect, Fung said most commits are Claude-assisted. Engineers are expected to build stronger product sense, with feedback channels and dashboards piped into Claude. Engineers are also less often blocked waiting on cross-functional partners, because models supply capabilities they lack. Lenny described the blurring as going both ways, and she agreed.
Open questions the team hasn't solved
Lenny revisited three open questions from her talk. On separate iOS and Android orgs, Fung said deep platform expertise still matters, but the team probably needs smaller mobile groups because people flex across platforms. Finding the right balance is still in progress. On how far to push fully automated review, she pointed back to encoding "what good looks like," as with the content design check. She said verification, and especially verifying the experience rather than just correctness, is still hard to crack. The third question, how to keep everyone equally productive as roles blur, she grouped with verification as an area with much more room for improvement.
She added a new problem: context switching. As work becomes more asynchronous, the load of checking on many agents keeps rising. She used to block focus time for coding. Now she finds she needs to block focus time just to catch up on all the async work she has kicked off. Asked whether she has a solution, she said plainly that she hasn't cracked it yet.
The future of engineering jobs and training the next generation
On jobs, Fung "shared some vulnerability." Her biggest open question is how to develop the next generation of engineers, whose path will look nothing like hers. She wondered whether software engineering might move toward something like a fellowship or apprenticeship, longer than a three-month internship. The challenge is how to compress some of the experience her generation gained over years of typing code. That experience is where the "double-click" understanding comes from, and she thinks it is where opportunities to improve a product or system are found. She acknowledged models may eventually make this moot.
She mentioned a former manager who began programming on punch cards and now regularly messages her things he has built with Claude Code. That career spans a transformation just as large. Her working theory is that what matters will shift over time, and the task is figuring out how to build proficiency in whatever still matters.
She also urged revisiting failures. When she first tried roughly Sonnet 3.5 or 3.6, it made mistakes, and some resistant engineers pointed to those errors without appreciating how quickly models were improving. She said she has tried to automate things Claude couldn't yet handle, then found the next model could. Anything that didn't work before may be worth trying again.
What keeps her up at night: culture at scale
Her main worry is team culture as the team grows quickly. She calls culture "a living, breathing thing," not a poster on the wall. It shows up in how people treat each other. She values diverse perspectives, open and honest debate, and a "one team" mentality. When you near the finish line, you look back to see who needs help, because the team finishes together. Product and engineering problems have dashboards and hypotheses, she said, but culture is a human problem, and she worries about noticing drift early.
Lenny shared two lessons from his time at Airbnb. The founders were obsessive about culture, and Sheryl Sandberg once told the company that struggling to preserve culture during hypergrowth is the problem you want to have. Fung described her own safeguard: she asks everyone, especially managers, to talk openly about what isn't going well. Her nightmare is asking a manager how things are and hearing "everything's fine" while she knows otherwise, like the meme of the dog drinking coffee in a burning room.
Killing processes and "just-in-time" planning
Her parting suggestion was the team's explicit permission to kill processes that no longer serve them. She encouraged listeners to pick one process they dread, one that's noisy, expensive or manual, and ask whether it still serves its purpose. She gave her own mistake as an example. On joining Claude Code, she introduced a deliberately lightweight six-month roadmap. The exercise helped with alignment, but three months in she realized nobody was referencing it because so much had changed.
She now calls the approach "JIT planning." The team aligns monthly on a small spreadsheet of priorities, with no docs. She is considering quick weekly check-ins to confirm the month's priorities still hold. Within those priorities, individuals decide how to address them. The whole team gathers every six months to set broad themes, though she noted that themes also change fast. Even the monthly spreadsheet is on her list for more automation, because she doesn't want updating it to feel like a tax. The team discussed automating it the day before the recording.
Lightning round
For books, she recommended Margaret Atwood for speculative fiction, Haruki Murakami for magical realism, and The Little Prince, which she rereads every year. The films she keeps downloaded for flights are Amélie, which captures the magic she felt on a high-school trip to Paris at 16, Spirited Away, and Nausicaä of the Valley of the Wind. She said she saw Nausicaä at eight or nine and that its heroine shaped many of her leadership principles. Her product pick was Sweet Sisters Bodycare, a small business on Whidbey Island. She switched to it after a painful rash on her nose turned out to be a possible reaction to a shampoo she'd used since her teens, and a week of hotel shampoo on tour brought the reactions back.
Her mottos are "keep it simple" at work and "in a world where you can be anything, be kind" in life. For the second, she told a story from COVID. Her grandmother was in a care home in Canada, and the family could only FaceTime when a helper was available. One day she got a last-minute window at noon that clashed with a one-on-one she considered important. Her report agreed to move it without fuss, and she said that small kindness made a huge difference to her.
On knitting through meetings, which Boris had mentioned, she said her grandmother taught her at eight. She compared knit and purl stitches to zeros and ones, and joked that she is a kind of compiler. Knitting is her fidget spinner while agents run. Her dream is to open a yarn store in her grandmother's name and recreate that community.
She asked listeners for feedback on Claude Code and Cowork, including examples of latent demand. A friend recently showed her a shed built from plans Claude helped create. Her final request echoed her concern about the AI divide: find a small business you love, or someone who hasn't yet seen what AI can do for them, and take the time to show them.
Anthropic engineers, on average, ship eight times as much code per quarter as they did compared to 2025.
Coding is no longer the bottleneck. It's lifted the ceiling of what anyone is able to do.
Everything is now possible in theory. Now, it's about how ambitious can you be?
It's always something we ask ourselves, what's better than me doing it? Haven't thought, David.
The people that seem to be doing best are taking the most initiative, getting the most proactive, have the most agency.
We say with high agency is also high accountability. So, it's all about making sure folks have that freedom to code. But, then it's also like, okay, what's the accountability for it? What's the hypothesis of what you're trying to solve?
I'm curious what is lost in this new world of software engineering.
It can start being a lonely experience cuz we all started just working with our agent so much. And on the Claude Code team, recently, we started up pair-wise programming lunch.
Something you think about is this gap forming between people that are leaning into AI, killing it, and then people that are not, super frustrated, fighting, resisting.
In terms of frustration, I think sometimes I also see a little bit of fear. For anything that there is a fear, my advice is lean in and ask, "What can I do about it? What is within my control?"
Today, my guest is Fiona Fung. Fiona leads the teams behind Claude Code and Cowork at Anthropic. She oversees both Boris Cherny and Kat Wu, both of whom have been on the podcast and whose episodes are in the top 10 most listened to episodes of all time. Before Anthropic, at Microsoft, Fiona ran the teams that built TypeScript and Visual Studio. After that, she went to Facebook, where she started the Facebook Marketplace team, which she took from idea to launch. Today, Facebook Marketplace generates over 100 billion dollars in GMV every year. Also, while at Meta, she oversaw work on Meta's first smart glasses product, and then she helped build Orion, their first AR glasses product. Then, she went to Instagram, where she led infrastructure, growth, integrity, and safety teams. While at Instagram and at Meta, she oversaw an org of over 500 people. Fiona has been an engineer for over 25 years and as a long-time engineering leader, especially now at Anthropic, she has such a unique lens into where things are heading, what's worth paying attention to, and what teams should be thinking about right now as AI transforms the world of building.
A huge thank you to Kat Wu, Boris Cherny, and Mohammad Hegazi for suggesting topics and questions for this conversation. Before we get into it, don't forget to check out LennysProductPass.com for a free year of the hottest and most well-crafted AI products in the world available exclusively to Lenny's newsletter subscribers. With that, I bring you Fiona Fung.
Fiona, thank you so much for being here and welcome to the podcast.
Thanks so much for having me, Lenny.
So, I was at the Code with Claude event, I don't know, a month ago at this point, and I went to your talk and I was just like, holy, I got to get Fiona on this podcast. She's thinking so far ahead of where everybody else is going and where people are at with AI. So, you've been an engineer for 25 years. I was browsing your LinkedIn. You started at IBM of all places. Such a different place to be these days. And it's just insane how much the job of an engineer has changed over the past just like 2 years. It's like a completely different job. Like, people may forget 100% of code was written by humans not long ago. And now it's getting to 100% of code written by AI. As Boris famously said, coding is solved.
Along these lines, there's just this tweet that you guys put out yesterday where you showed, here's the tweet: Anthropic engineers on average ship eight times as much code per quarter as they did compared to 2021 to 2025. We'll show this chart on the screen. It's just like stable, stable, stable, stable, boom, shooting off into the moon. So, it's just insane how much this role has changed. I'm curious about your kind of path as an engineer living through this, having been an engineer for a long time, what have been kind of like the big moments along the way where it's shifted your way of thinking and operating that have led you to what you do now and how you operate now?
Oh, I love this kind of look back in time. Yeah, like IBM, working on DB2, the operating system services team. Like back then I was thinking, oh, how can I be like, what's a hard area of the stack? And I really thought the lower level you go closer to the OS, then it's like more hardcore and you learn more. So I was really fortunate to have gotten into the IBM internship.
But the funny thing was I think there's even a big shift from IBM to Microsoft. So at IBM it was I think Vim. Like I didn't have an IDE that we used. I think there might have been an Eclipse license, but for some reason most of us didn't use it. So I remember it was mainly like Vim and, you know, like kind of terminal debugging. And then when I joined Microsoft, I mean this is how naive I was, I didn't even know about IDEs and such, and back then you didn't really get to pick teams. Like this was early 2000s.
Actually first off I should say I was so grateful that I landed the internship and the role cuz to take us all the way back in time the dot com bubble burst in 2000. And so for my graduating class like a lot of the companies weren't hiring or were having freezes. So I'm so fortunate when Microsoft extended me an offer.
And so they're like, you're going to work on Visual Studio. I did not even know what Visual Studio was cuz I came from like a Unix school. So I remember asking, cuz I was thinking, well, the name Visual Studio, I'm like, oh, is this like a better paint program? And I could tell by the look on my manager's face, like, what is going on?
But then it ended up becoming like the love of my life for the first, you know, 11 years of my career. But that was the first time I used an IDE. So joining the Visual Studio team, seeing, oh, wow, like here's an IDE with like debuggers and you can set breakpoints and do multi-threaded debugging. Like that was also always mind-blowing for me to think about the stepwise change. So yeah, that was kind of the story going from IBM to Visual Studio.
And then what I really loved actually about Visual Studio is I was on the Visual Studio editor team. So I used the VS editor to build the VS editor and that's where my whole love of dogfooding comes from. Like I remember I wanted to first and foremost create a delightful experience not only for myself, but for my teammates. Cuz also if we go back in that time, if you remember, I mean when did Twitter come out? Like was it 2006 or something?
It's been around my whole life.
But back then, like before social media, it was also harder for most engineers to hear fast customer feedback. Like for sure there would be user research sessions or we would have customers visit us. But you didn't get the rapid feedback that you do nowadays. But back then I was so lucky because I was on VS. We ourselves gave each other so much rapid feedback cuz we were all heavy VS users on the team.
This episode is brought to you by our season's presenting sponsor WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise-ready today.
People think about these milestones along the way of an engineer's journey and we forget there's also been like a lot of transformation over the years. Not quite what we're living through, but just like IDEs, Visual Studio. So I love that you're reminding us of these moments in the history of software engineering that have changed the work in a big way.
Yeah, when I worked on Visual Studio back then we also shipped software on CDs. I mean before, and that's why there were really hard deadlines cuz you had to make sure the software is ready for us to give to manufacturing to then, you know, put on the CDs for us to then put on the shelves. And then that was another shift when we actually started to be able to, you know, ship software online.
And I think that's the interesting thing and I kind of mentioned this in my talk. Before, engineering time was like a really precious resource. But you also have these really hard deadlines, for example, like printing software on CDs. And so back then you would do a lot more planning cuz you just wanted to make sure given the time you have, you make the best of it. And that's the shift that, you know, we're seeing with Claude Code and Cowork, is coding is no longer the bottleneck. And so now, you know, you showed the tweet and that graphic. So now it's all about like where has that shift happened? Like now not only engineers but we also have designers, PMs, everybody on the Claude Code team checks in code. So not only more people checking in code, like kind of different disciplines, but also the throughput is so high. How do we think about verification? Like that's kind of this other shift that I'm seeing.
Maybe just kind of set this theme that I want to have for this conversation. A lot of people are just wondering what software engineering, managing software engineers, managing software and product teams look like in the future and you are living through that right now. So, you mentioned this point about more focus on verification, making sure the quality of the code being 8x is actually high and something that you know will work. So, let me ask this broad question and let's kind of see where this conversation goes. What does an AI-pilled software team look like in 2026?
Because the roles are blurring, it's shifting more to this builder, like everybody starts being a builder, I would say.
The other shift that I've recently done is I actually have a Claude Code remote session that I enlist in all of our repos. And so, this way I have full visibility into the work that everybody's doing. And this instance also has access to all our Slack channels and I'll have access to like how are the metrics of everything we track.
And so, every month I've been like, "Hey, you know what's fun? Let's take a look back." And so, we'll actually do it together. I'll share my Claude Code, you know, I've shared my screen and we do a Claude Code session. And it's just about, "Hey, what were the focus areas? What were some of the products that got shipped? How did they do? Oh, what were the feedback channels?" And so, even though before I would have just used these sessions to generate PRs and bug fixes, I actually have these sessions to enable me to have conversations with folks that I support.
Say more about that. So, this is like a management technique, let's say, to help people not just ship, but actually better understand if they're shipping things that have impact. Is that kind of the idea here? Just like use Claude to keep on top of all the things people are shipping and then make that a conversation with them.
Exactly. So, yeah, outside of just, you know, the action of shipping is how did it do in market? Or hey, did we cause some bugs? And it's okay to, like, I have this saying, "Make new mistakes." Like it's okay to make mistakes, just make new ones so that we're always learning, cuz if you aim to make zero mistakes, that probably means you're not, you know, moving fast enough or being a little bit too cautious. And so yeah, by having Claude, it can also look at, for example, actually, yeah, I was just looking at, oh, you know, given some of the incidents that we have, let's look across all of this. Can we generate a theme? Like what's a good area of investment for us, especially when we think about quality. Like are we seeing any hot spots of where there could be a gap? I think that used to be just a much more manual process, I would say. Like if I look back a year ago, I don't think I would have been able to, you know, have some of these insights with Claude.
Yeah, well, partly it's cuz there's that and also people weren't shipping as much, so you could just make a little bullet list. Here's the things I shipped last quarter. This feature, that feature, this feature, that feature. So I think what I'm hearing here is this is like one of the only ways to stay on top of all the things that 8x is shipping. So this is a really cool thread of just like how you found ways to stay on top of this 8x increase in code. What else has worked in helping you and your team stay on top of and maintain quality of all the stuff that y'all are shipping, cuz that's obviously a challenge, a bigger challenge.
Yeah, and so definitely the feedback channels are really important to us, but then we also get a lot of feedback, and for example, even I myself, usually my morning ritual would be, you know, I get my morning cup of coffee and then I look at the feedback channels and then I try to pick up, you know, if I have some maker time, what's something that maybe I would be able to help out with, or I could see some gaps. Like that just used to be something I would do every morning.
And yeah, I think maybe a month or two ago we launched routines. And that's also completely changed. Like now I just have a routine that automates all this for me. It's almost like before I would, you know, be able to kind of generate some prompts, but now with routines, it's almost like I'm having an agent help me generate the prompts and the PR. So for example, one is, "Hey, keep a look on this feedback channel, you know, what are some of the themes?" And then when I wake up, I have a really good summary of that. And then even some PRs that I'll be able to take a look at and review.
And the feedback channel, where's that feedback coming from? Is that like emails, Twitter, or a combo of everything?
Our feedback channels, we definitely have a lot from internal, but also like emails, channels. Actually, when we all get feedback, even like when friends ping us or on LinkedIn or socials, we'll all actually post all of that in Slack as well. And we also have, of course, partnerships. And so we have different channels for all the various sources. But that's what I mean, I need Claude's help to help me stay on top because there's so much incoming feedback.
Got it. Okay, so this is cool. So, this is like a way of working that you've built to stay on top of all the stuff shipping
which is this kind of daily ritual / routine where you as a manager look at what people are saying about the current state of Claude Code and Cowork and used to just like okay, someone go fix this, go fix that. Now it's like here's the PR that will fix this thing, check it out. We're ready to ship it if you want.
That's right.
Okay, like obviously a big challenge for people is also just code review. I imagine Claude is also doing a lot of its own code reviews. Is there anything there you've recently figured out that allows your teams to ship faster stuff that they are confident is great?
Yeah, and honestly, it's crazy when you think we didn't even have Claude Code Reviews last year. And so speaking of bottlenecks, that was a really, really big bottleneck of, you know, the human reviewers. So, we definitely for the important areas that need deep subject matter expertise, we definitely want to make sure we have the proper, you know, like human still reviewing. I would say what helps us though is the more that we can automate to almost check in the framework for what good looks like. Claude is very good when you give it a framework to validate against those frameworks. So, I had mentioned like, you know, recently we just updated the content design to have a skill in it. And this is why I think if you have specs, check those into the repo and then make sure the spec also keeps up to date with the code frequently. But that's what I found works really well: any time you have a statement of what good looks like, get that into the repo and then Claude Code Review can make sure it's still matching what you set out to do.
Basically, it's like the evolution of test-driven development.
Yes, for TDD, because I remember that was a big thing, my gosh, maybe in the 2000s, of write the test first and then you can make sure the test fails, then you actually do the code. In principle, it's really good, but I remember myself struggling a bit because it was almost like you have to eat the broccoli first. That's why I'm like, ah, you have to write this test first, and I just get so much thrill out of shipping and building product. So, that's funny. Actually, the first bug I fixed on Claude Code, I remember asking Claude, "Hey, I want to do test-driven development. Help me write the test first. Make sure it fails and then we'll actually, you know, do the fix and then now that test passes." And the fact that that test generation used to just be this tax that I remember having to pay, the fact that that's now automated, and you can even revisit all these principles that have been around for a while, but now they actually might be even more efficient just because you have the models that can do more of the work for you.
Yeah, it's so unfair. It just writes the test for you first.
So, on this point of builders, one of my favorite slides from your talk that I want to ask you about is who you are hiring and what you look for in people. And so, I'll read what you said there and I want to hear more here. So, the two profiles that you now look for when you're hiring are creative builders with product sense and deep systems experts for the hard parts.
Yeah, the deep subject matter expertise. Like for example, when I first joined Claude Code, we had really great kind of product generalists. And then I realized, oh, we were missing folks with systems background. And so, that was definitely an area where we needed more folks with kind of systems and distributed systems expertise. And so, I would say whatever are the parts, it's all about trust but verify. The models are really good, but there are definitely a lot of areas that still need verification. And so, wherever you need the deep subject matter expertise, I would say that's, you know, an area to definitely still invest in.
And the other one is kind of the product sense folks, almost like the dreamers. These are folks that usually will be like, "Oh my gosh, I'm really passionate about a product." And they have an idea, they build it, and then it's always looking at the feedback, and then iterating, and polishing, and making sure that the product is a delightful experience. Like owning that product end-to-end. That's another skill set that served us really well on Claude Code.
This super resonates. There's this word ambition. I don't know if you used it, but that's what I thought of as you were talking. That's been coming up a bunch recently in the podcast and in other work I've been doing. There's this 10X engineer I was talking to the other day, and he was just like, "I heard about a feature idea, like someone's like, 'Hey, we should build this.' And I was like, 'No, that's really hard and complicated.'" And he's like, "But now I'm like, no, no, that's so possible. I just ask Claude Code to do it." And it just does it. And it's this whole mindset shift. And he's just realizing now it's about how ambitious can you be? Like everything is now possible in theory. Now it's about how ambitious and how big can you think versus just like, 'Okay, it's all these stupid little features and things I have to unblock.' Does that resonate? Is that something that you think about?
Yeah, so actually I was just catching up with an engineer yesterday who actually is not a mobile engineer by trade, but we really needed to update this feature to also have a mobile footprint. And it was just amazing. He's like, "You know what?" Because it's common, because you might think, "Wait, but I'm not an Android expert." But now, thanks to Claude, I can actually have a partner and actually also do this on the mobile surfaces. And so that definitely resonates. It's lifted the ceiling of what anyone is able to do.
Let me follow that thread. As the role has transformed in such a crazy way, some people are thriving, some people are super frustrated, unhappy, fighting, resisting. What do you see common across the people that are doing really well, the engineers that have adapted and are thriving, versus the engineers and, you know, even outside engineering, that are just frustrated and having a bad time?
I would say that a growth mindset really, really helps. Actually, even before AI tooling, I found that has been just so valuable. And I learned that a lot. Actually, it was the shift from Microsoft to Meta. That first year I'm like, "Oh, this is what having a growth mindset really means." It's really this concept of always be learning. Also, what served you to get you to this point will serve you no longer. But it's really hard because, of course, we've all gotten to this state by acting or, you know, operating in a certain way. And so sometimes it is a little bit scary to think, "Wait, but I've been successful so far. You're asking me to change what has made me successful." And so I would say the growth mindset has really served me well, and I think it's also served others well that I notice. Always leaning in with curiosity and always being able to learn.
And then in terms of the frustration, I think sometimes I also see a little bit of fear. And so my advice there, at least this is how I approach it just in life, because we all have fear, and fear is of course evolutionary. I didn't study anthropology, but I think it makes sense, right? It helps us make sure we were able to survive and not get eaten by larger predators. But for anything where there is a fear, my advice is kind of lean in and ask, "Okay, what can I do about it? What is within my control?" Because sometimes the frustration comes from fear and feeling like everything is outside of my control, and so it's happening to me. And so if you think about, "Okay, what is in your control?" Instead of happening to you, is it happening for you? And then what's something that you might be able to do and change? I felt that's been helpful, because if not, it is super frustrating to have the fear and then feel like everything's outside of your control.
Like I actually remember, it's funny, we were going back to IBM. When I was in high school, I actually didn't go into computer science or engineering. I really wanted to be a visual artist. And this is how far back we go: back then computers were really expensive. I actually didn't even have access to a computer. My first access to a computer was grade nine, I think, in high school. I don't even know if this happens in high school anymore. My high school had a typing class. You know, a typing class just to learn how to type on a keyboard and learn to be really proficient, and that was my first time, and then, you know, the next class was maybe some HTML programming. So anyways, the reason why I fell in love with it was, what I love about art is creating: if you have an idea, you can go ahead and create and tell a story. And then I realized, "Oh, computers and programming, that enables me to do that." So anyways, I tried to really fast make up for all the science classes for me to get into university, but I had this fear of, "Oh, but how will I afford to get into an engineering school?"
And it was this big unknown. I grew up in Ontario, so I was very grateful. I knew there was an Ontario school assistance program, OSAP, I think it's called, which I'm very grateful for, but I didn't know how much of that would cover my tuition or expenses, and it was just this unknown, and it would be like a year out. And I remember thinking, "Okay, what can I do about it?" And then as luck would have it, the National Bank of Canada just posted this flyer in our high school saying, "Hey, we're hiring high school interns to be a bank teller." And of course it was going to be minimum wage, but I thought that could be a lifeline. But it was funny, because the class I hated the most in high school was accounting, so I didn't know if I'd be any good at it at all, but I signed up to be a bank teller, and that ended up being such a great decision, because I worked all summer, saved up, and then I was able to work as a bank teller on the weekends. So I would go to school Monday to Friday, and then on Saturday I'd be a bank teller, and that ended up being this lifeline that enabled me to, you know, pay for all my school expenses. And, you know, we talked about the year 2000 dot-com crash; when folks weren't hiring as many interns, I continued being a bank teller for two years.
But that was the one action I thought I could take that was within my control to try to counter this fear I had of, if I'm really going to go down this path, I don't even know if I could afford to go to school. So, that's probably my other advice: growth mindset, and if the source of frustration or anxiety is coming from fear, see, is there one action that's within your control that you can take? Because there was a saying, what would you do if you're not afraid? Actually, those were my two favorite sayings before: what would you do if you're not afraid, and do something scary once in a while, because that's also usually how we grow. I found that when you're really good and professional at what you do, you're kind of at peak, you know, maximum efficiency, but then how you keep growing is you do something scary that you might not have done before, and yeah, you will have a dip because you need to learn. But that's kind of how you keep pushing yourself to learn.
The quote that I have probably used the most on this podcast of all quotes is the cave you fear contains the treasure you seek.
Oh, I love that.
Yeah, and it's so true. I forget who put it this way, but the thing that is scariest is a compass toward what you should be doing.
Mhm. I'm going to steal your quote.
Yeah, please do. You know, don't do all the scary things, like maybe don't jump off a cliff, but in career moves it's probably a good choice.
So, kind of following this path, something that I know is important to you, something you think about that I also think about, is this kind of gap that is forming between people that are just leaning into AI, killing it, doing super well, and then people that are just not. And this is a scary time for people that may be left behind in this new world that is emerging. I know you spend a lot of time with small businesses. That's a big passion of yours, to help people learn how to use AI in their work. Talk about just how you think about that and what maybe we should be thinking about to help folks, you know, not fall behind, basically.
Oh, I love this. Yeah, it's one of my passion topics, because I kind of mentioned, you know, growing up in Canada. I moved there when I was a kid. I was born in Hong Kong. So, I didn't speak any English and my parents had to work all the time. So, my grandma, who is the best grandma that anyone could have ever asked for, I know everybody thinks their grandma's the best, but I really was so lucky, I had the best grandma. She moved with us just to take care of me while my parents were working. But neither of us spoke English. I was able to learn how to speak English by going to school and speaking with classmates. And when I think about my grandma, it was very alienating for her to be in a new country, and, you know, back then it wasn't as walkable.
But one summer, I remember, we just happened to find this little yarn shop that was owned by a lady that also spoke Cantonese. And so that became every week to this yarn shop that summer, and my grandma found her knitting circle, and then I think I learned how to do macrame. Which I think is having a comeback, by the way. It's always funny to see what's
Macrame coming back?
Macrame, I think, yeah. You heard it here first on Lenny's Podcast. I think macrame's coming back.
All right.
But that was probably where my love came from. I'm like, oh wow, this little small business created this wonderful sense of community. And I've been really fortunate to become friends with all the small businesses that I love. So that's kind of where the passion comes from.
And then how it happened was I was using Cowork for my own business travel expensing. I don't know what it is, I really don't like doing business expensing. And when I was using Cowork, it was magic. I'm like, all these things that I don't like to do, Cowork is doing for me. And I'm like, wait a minute, all my friends, and honestly small business owners, they really bust their butt. They work incredibly hard, and sometimes they might be operating on really small margins. And so I thought if Claude Cowork is so good at helping me do my little business travel expense, this would be huge for them, because I see my friends sometimes sitting at the bar with stacks of bills and all they're doing is invoicing and expensing. And I think nobody actually really likes to do it. So that's kind of where it came from. And then, yeah, I remember helping a couple of them onboard. And it was also very humbling to see them go through our onboarding flow. Actually, it found some really good bugs. So, it was really a win-win, but it was also
delightful for me because they also use Cowork in ways that I wouldn't have thought about, because I was all fixated on look at how it is amazing with PDFs and invoices. And then, you know, one of my friends who runs two restaurants, she's like, "Oh my gosh, this folder I have is like a junk drawer of like, it's basically our, you know, documents folder just becomes this junk drawer of every, or downloads, like just a, you know, like junk drawer." And she's like, "I know I have a few menus in here and I can't find it." And I'm like, "Well, let's ask Cowork." So, we gave Cowork access to the directory, found the menus. And then, she uses it in a really unique way. She goes like, "I want to make sure I keep my prices reasonable for locals and tourists." So, she goes, "Hey Claude, look across my style of cuisine in this area, is it comparable." And it came back with really cool, almost like market analysis. And she goes, "Hey, I actually just went to that restaurant in Seattle and that was pretty good." So, I learn something every time. And yeah, they've been giving me great feedback as well.
So, the question then is just like how do we spread this to everybody? Because as you see, you know, there's like a lot of people are just like, "I don't have time for this." Or "I hate AI." It's just like I want to ignore it. Is it just talking about this, sharing examples? What do you think? What's a way to make a dent in this problem?
For all of us, especially your listeners, who are probably very AI-pilled, if there's anyone either in their community or their family that has, like, I would start with something that you really have felt has made a meaningful life change for you with the AI tools. And then seeing if that is a conversation starter, because for me AI is a tool. Again, it's the whole light and the dark. I totally understand the frustrating part as well. But for me, I've also felt like knowledge is power. Like, we have to learn how to use the tools because it could actually, you know, be the light part of that light and dark equation. So, I think that's something that I would love everybody's help with, of, whether it's a community member or even if there's a business you really like and think, "Hey, have you ever..." It's a little awkward to start. Like I remember when I first reached out to my friends, because I don't talk about what I do with them a lot, but I'm like, "Hey, I kind of, you know, work in AI. Can I..." It's even unnatural for me to do, because I'm like, "Hey, can I show you what, you know, Cowork, is possible?" And then we ended up having a lot of fun. So, yeah, I would love for that conversation starter, that would be great. Because I just want to make sure we keep sharing the knowledge and, you know, making the tool equitable, because if not, I'm concerned that the divide grows larger and larger.
Me, too. I find that sharing use cases, as you said, is so powerful. I was just using Cowork the other day to fill out my son's camp forms. And just sharing that on Twitter, a lot of people are like, "Oh, wow, I didn't think about that." Yeah, it's just like these little things you don't think about that Cowork and Claude can do.
Kind of along those lines, speaking of Cowork, if you think about it, Anthropic has been super early on uncovering these really big opportunities ahead of everyone else. For example, coding. So far ahead. Like realizing this is a huge market. Whether it was intentional or not, it was just like, "Whoa, that's maybe the biggest new business opportunity in history." And then Cowork is a great example, just leaning into knowledge work. Let's just solve all the knowledge work. Why not? So far ahead of everyone else. Another element is it feels like a focus on the personality of the model, something you all were very early on, just how important that is. Not just for the experience, but also the intelligence and success of the model. What is it that you think Anthropic and the teams do differently that allows you to uncover these opportunities and then just go big on them before other labs, let's say?
Well, I haven't worked in any other labs, so I'm not sure how other labs operate, but I will share, like, yeah, actually on the Claude Code team as well and Cowork, we also keep an eye on latent demand. Now, we're very fortunate with coding as a use case because so many Ants, we were, you know, our own first customers and we're able to do really rapid feedback. But latent demand has been, like for example, with Cowork we noticed, hey, a lot of folks that were not necessarily coders were using Claude Code. Can we make that experience better? I think that's actually, even outside of Anthropic, served me well in all the different products I've worked on.
And actually it's funny you mentioned, you know, my passion with small business. After I had a few of these visits, we ended up now launching Claude for Small Business. Which is really cool, and it totally didn't come from me, so I'm not taking credit, but I noticed it too, when I was working with them, because they were asking me, oh, does it have this plugin, that plugin? I'm like, I think it does, and then we have to, you know, go and search for it. So, actually now Claude for Small Business bundles it all up, so inside Cowork you just have this little toggle. And there was a wonderful team that's been, you know, doing Cowork sessions with small businesses that probably found, hey, we could have an efficiency gain here, or make the experience better.
And so I would say, not only for products that you're on, making sure you're always, you know, listening to feedback and always iterating, trying to make a delightful, reliable, high-quality experience, but then also keeping an eye out for, oh, what are these other use cases that are popping up and can we also make that experience better? It's interesting, in software I've learned that customers will use your product in ways that you did not intend, for good or for bad. And so the best way is really, it's all about the iteration: learn and keep close to the feedback.
Latent demand. That term's come up a bunch on this podcast.
It's on there.
Might be something there. So essentially it's just watching closely for behavior that you may not have expected or that is just kind of emerging. And then just going big on that essentially, exploring it, building something.
Yeah. And having a hypothesis for, hey, because actually when you see people jumping through hoops to make something work, can you actually make that an even smoother and better experience?
Yeah. Coming back to the way that your teams operate, you guys are so at the edge of what's possible. And the role of engineering has changed so much. I'm curious what you think is the next frontier of how engineering in particular is going to change. Is it, I don't know, fleets of agents? Is it something else? Just, what's the next big shift to how engineers operate that either you're already working on or implementing, or it's just starting to happen?
I would say we're shifting more towards async, like asynchronous. And so to your point, the fleets of agents, that's why routines is so interesting, because I used to be, you know, doing a prompt synchronously. And then I would maybe kick off different prompts asynchronously. But now I can actually have a routine that generates, you know, these prompts for me. So it's almost like the level of abstraction keeps pulling up a little bit. And so, yeah, I wish I had a crystal ball to see what this is going to look like. It'll be fun actually for you and me to revisit a year from now.
No, I want to hear more about this. So help us understand, what is routines, and then what do you mean by asynchronous? You're writing a prompt and it just kind of goes off, and is it writing it immediately? Talk about what this actually looks like.
Yeah, so routines is how you can, so if you remember I was talking about what I used to do is always, you know, wake up with my morning cup of coffee and, hey, look through this Slack channel for me. But now I have a routine that I set to run every morning at a certain time to say, hey...
Mhm, that's right. But then it's able to actually go and kick off agents on your behalf. And that's, you know, before it would be, oh, you could do a cron job to automate, but now it's, hey, look at this feedback and then, if you're seeing some of these bugs, what are some polish fixes that you might be able to knock out? And then it would go kick off, and I wake up and I end up having PRs that I could review. Versus before, which is still more of kind of different agents, and I'm still thinking about, okay, now what do I do with this information? So it's that higher level of abstraction of, okay, now how can I actually write a routine that also basically does prompts for me for spawning different agents? So I think we'll move more towards that kind of asynchronous style of working.
So interesting. So in a sense, as a manager, you have these kind of things you do daily, and what you're saying here is you can set up these prompts that check in every day on the things you would be doing, like how are the projects going? What's falling behind? What should I unblock? Who's struggling? How do I improve some polish? And so the idea here, what you're describing, is write these things that you almost do as a manager daily and have Claude essentially do them for you and then show you, here's what I'm doing, here's what there is to review.
And then it's even giving even more autonomy at some point, of, you know what, go for it. For example, if the verification is really good, go for it. [laughter]
I see. So you give it a little bit of freedom to do more of this. Yeah. That is so interesting. It reminds me, speaking on this idea of go for it, I wasn't planning to talk about this, but I just watched Tyler Cowen, he had this awesome talk about what's happening. I don't know if you know Tyler Cowen, he's a really smart economist, has a podcast. And there's so much talk of the people that are doing best in this world; his term is initiative. They have initiative. Another term people use is agency. People hear this a lot, that the people that seem to be doing best are taking the most initiative, being the most proactive, having the most agency. Does that spark any thoughts for you on what people may need to, I don't know, think about or improve on?
Actually, it's that word agency. That's what we really hold important on the Claude Code and Cowork team. But it's interesting, I say it along with high, because it's really about, hey, here's a problem, and then everybody on the team has ideas for how to address the problem. So it's really high agency, and then we say with high agency is also high accountability. So it's all about making sure folks have that freedom to cook, you know, but then it's also, okay, what's the accountability for it as well? And again it goes back to, what's the hypothesis of what you're trying to solve? So I think the balance, almost like two sides of the same coin, of agency and then accountability, has served our team really well.
Such an important element. Have agency. Okay, cool. Everyone's off doing stuff, but okay, what have you actually [laughter] shipped? What have you done?
So kind of along those lines, it feels like there's this vibe shift recently from token-maxing, just go crazy, spend as much as possible, just see what's possible, to, wait, what are we actually getting out of this? How much is it costing? What's the ROI? Interestingly, Boris was actually head of eng productivity at Meta; his job was measuring eng productivity. And then also just this tweet of lines of code shipped. There's this interesting discussion of how do you actually measure productivity increase and ROI of AI tools and spend. You guys have the infinite advantage of getting free tokens working at Anthropic. With that in mind, what have you learned about how to measure, say, ROI of engineers in today's world?
This eng productivity is such a fascinating topic. Yeah, because I remember, you know, we'd first start with lines of code. And that's throughput, and then I remembered once there was a debate of, well, lines of code, this engineer had this crazy lines of code, but they just took some library and were porting it, so they checked it in. And then I was like, well, maybe it's significant lines of code. And then it's, well, but what if we're, you know, updating our frameworks and now we're generating less code, but the output's still the same? So now I'm like, okay, maybe it's time to land PR. But it's very interesting, it's always been, whichever metric, if you're really focused on the out... like, my advice here is, one is output: is the output really going towards the outcome? Because, yeah, the token-maxing, it's almost like the lines of code that we used to have, but I'm really much more about what is it that we're trying to do? There was another saying I really like: don't mistake motion for progress. Because if you're measuring, you know, tool usage, then you're measuring the action, but is it really making whatever the end outcome of yours is important? And so I really try to zoom out and focus on what is the problem we're trying to solve? What's a good way to measure that? And then that's what we focus mostly on, versus the productivity measurement.
I would say though, outside of metrics, especially on teams as you're having more people adopt AI tooling, I would say definitely go on a listening tour, for the leaders listening to the podcast especially. I love to focus on the senior engineers as well. Hear from them on what's working, what's not, how can we actually make it better, because they will also help you multiply and scale that out across a full engineering team. And sometimes there are those conversations where you might get an idea sparked, and also really good shared learning, versus, you know, metric dashboards. It's very interesting. I've learned some good lessons from metrics. It's really great when you have a metric that you can actually hill climb on, but always keep in mind, you know, my whole growth mindset of, is it still serving you? Always keep in mind, is that metric really still serving the outcome that you were aiming for?
A fun example I have with this is, in the early Facebook Marketplace days, we were kind of launching by region, and we really wanted to make sure we were building a delightful product before we expanded. And I remember in the early days, one thing we would keep an eye on is number of sellers. And I remembered after launching our first region, I'm like, huh, in this area the number of sellers is low, but actually people are finding items
that they're looking for, which is what we're aiming for, like helping people find items that they need. And then I realized in that region it wasn't a large number of sellers, but there were power sellers. But our first gate before we expand would have just been, you know, factoring heavily number of sellers, and I remember that quick conversation of, hey, and this goes back to that whole people will use things in ways you may not expect, and ship, iterate, learn. And so then we updated the metric to go, oh, you know, it's not number of sellers, because it didn't factor in power sellers. And so that's the advice I have: whatever metric, whether for productivity or even for product, always keep an eye and make sure that you're not just having blinders on, blindly following a metric that used to make sense, because sometimes the landscape can change so fast. Even the metrics themselves might need to be adjusted.
And this comes back to your process that you shared of having Claude watch all the PRs shipping per engineer, let's say, and then not focusing on the metrics but focusing on that leading to a conversation about what impact this had, what were maybe some bugs that happened, and that being a really powerful way of understanding what's going on with this engineer.
Awesome.
Let me come back to this question of speed and quality and impact. Is there anything else you've learned about how to balance those things? There's a crazy velocity of code that's being generated, and just staying on top of quality and impact. Is there anything else there that might be helpful to other teams that are trying to wrangle all these PRs being shipped every day?
I would say, and this is what honestly we want to keep doing more of and being better at, too, the proactive quality. So especially for quality, making sure: what are the experiences that are key, and making sure you actually, speaking of metrics, those are really good things that you make sure you can look at, kind of see trends over time. And so on the quality front, we found, and this is the more proactive we can be of making sure we can get an earlier detection into quality. And so that's been one thing that we've been paying a lot of attention to.
So, you know, I started this: "Hey, let's have a concept of what's bad versus what's sad." And bad is a very bad, irrecoverable error. And sad is something that's kind of a pain point, recoverable, but it's interesting, when you stack up sads, it could, you know, generally go to bad. But even starting with a high-level framework like that, because I think sometimes with dashboards you can have, you know, time to load or all these others, but when you're dealing with a lot of different product surfaces, it's harder to go, "Wait, is that a good number or not a good number?" And so one thing that's helped us is, versus just raw performance or reliability numbers, also having some framework of what we think is a bad experience and making sure we're focused on addressing those, and then also keeping an eye on where we're seeing in terms of the sad. That's helped us a little bit.
I like the bad and sad. So these are kind of thresholds of: this is bad, okay, this is serious. And is this in terms of performance or failures, or what sort of things are you measuring here?
So for example, we allow each team, speaking of agency... knowing that bad is a really bad irrecoverable error, we enable each team, for their surface areas, or it could be services that they lead, to define what that is. So for example, on CLI it could be crash rates. A crash is pretty bad. You lost work. And for example, a sad might be, "Hey, is it flickering?" It might be recoverable. And that's why it's been interesting, because before, since surface areas are different, we would have all these dashboards, but it's harder to zoom out and go, "Okay, what's the overall theme of the experience?" So, to your point, we give high agency to each team on what we think constitutes a bad and what's a sad, and then what's the goal that each team wants to take.
The main takeaway I'm hearing here is one of the best tools for staying on top of quality is just monitoring and tests versus spending more time reviewing, which makes sense because the speed is just impossible to stay on top of, and it almost speaks to this idea of closing the loop for agents to be able to figure things out themselves. They know what success looks like. Cool, we'll fix it ourselves. So that's a really interesting takeaway: just invest more in the tests. Evals, I imagine, is part of this, and then just monitoring failures and speed and things like that.
That's right.
Something, I think this is public. I know that you guys have this dashboard that tracks F-words, like how often people are... because they're so pissed and frustrated. There's a funny term for it, I think. I forget what it's called.
Yes. Actually, I remember, that was last September, because we were all seeing some frustrations and, yeah, that was an engineer on the team: hey, we should maybe track swear words. I'm like, oh, that's a great idea. I remember it. I had just, you know, joined and we were having that really fun conversation. So again, it's very interesting to kind of look at, and that's why evals are hard too, because it's going back to that user experience and how we can make sure it's a delightful experience and less frustrating. But yeah, the swear word dashboard is a fun one.
This episode is brought to you by Mercury. Radically different banking loved by over 300,000 entrepreneurs and now with Command. I've been a customer of Mercury's for over 6 years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal-native CLI, or an AI-ready MCP server? I don't think so.
And just recently they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, to figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a specific sponsor over the past year. I just asked, "How much have I made from X over the past year?" 10 seconds later I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., members FDIC.
Kind of going back to the way you operate and ways that you've figured out to work in this crazy new world that we're in. I've heard about a couple things that you've implemented that are pretty unique, I think, to how teams operate, and I think something that has worked really well for you. One is making every manager start as an IC, and then every manager has to continue being an IC part-time, kind of this player-coach approach. Talk about that, why that's so important in today's world.
I love it. It's funny, when I first joined, because I have amazing recruiting partners, and I noticed we were, you know, this whole theme of growth mindset. It's just because the landscape is changing so fast. What worked well before may not make sense, and even what makes sense today may need to change tomorrow, right? That's what I have to keep reminding myself. So yeah, when I first joined, recruiters were like, "Okay, yeah, we have these couple of manager postings." And I'm like, "You know..." because actually how it came from was a listening tour I did with all the members on the team, and I heard a lot of these: "Hey, I really appreciate the agency, but how can I make sure of prioritization?" And so through that I realized, and then there was some really good feedback too of making sure that it's not too many layers of reviews. There was good feedback. Some folks might have drawn from other companies, and then I'm like, "Hmm."
I actually think, as a leader, if you actually start as an IC first without the worry of supporting people, because that's a very heavy responsibility that, you know, I think managers have, before you have to take on that full responsibility, give yourself that maker time to actually dive deep into the code and learn the code base, or the product, whatever it is. Honestly, the PRs I do are... but for me it's important because it keeps me in the flow, because we're making so many changes to Cowork and Code. So even me doing PRs, it's less about what it is I'm fixing, it's more about me using the product every day just to keep that touch, because as amazing as metrics and everything are, and I do look at those dashboards, if you as a leader are not, you know, living and breathing your product every day, you sometimes kind of lose touch and feel of the product.
But anyways, on the manager front, I think giving time for managers that join to be able to go deep and do that before supporting people. And then they actually end up building really great rapport with the team. Because if not, I think sometimes as managers, you know, you might come and join a new team and you instantly think, "I have to manage. Let me dig into my manager toolbox and do manager-y things." But if you actually give yourself time to not have to worry about that first and actually learn what it's like to be an engineer and teammate on the team, that also goes really far to building rapport. And in terms of using the product, it's interesting. Every team I've joined, actually across all the different products, it could be VR, it could be smart glasses, it was Instagram, usually when I first joined, one comment that comes back to me is, "Hey, you know what? I really love how you're actually using what we build. It's refreshing to see, you know, you giving user feedback." And so I think as leaders too, it's also a way for us to experience personally the work that the team does.
Something that people may not realize: you were overseeing an org of like 500 people at Meta before you moved to Anthropic, right? And you moved to IC engineer basically at Anthropic from that.
I started out, like, it was for a very short amount of time. But actually this was my journey between Microsoft and Meta. So at Meta, I interviewed as a manager, but I think at least for the first quarter I was also an IC, because I really wanted to learn what it's like to be a Meta engineer, because before then I was at Microsoft, kind of cut my teeth on engineering at Microsoft. So I knew all the code bases, the tools, the languages. And yeah, it was so valuable to have those first months actually learn what it's like to ship as a Meta engineer. Plus it was also fun. I think sometimes we forget. And that's, by the way, what I love about Claude Code.
Because the last time I shipped production software at Meta is probably 2017. And every year I might start, like, I do a lot of dogfooding, and I also use dogfooding to help me with the quality of the product as well. But it's been a very long time since I shipped production software. Part of it is I don't want to screw something up. I'm always so scared of: what if I do something and then I cause a bug and then I'm not verifying properly, or am I wasting someone's time? Because, you know, the tool flows would change too. But I remember that first week on Claude, at first I almost again did my usual, let me go meet all the engineers and treat them to coffee, and then I'm like, oh wait, wait, wait, let me ask Claude. Claude was this really good onboarding buddy of mine, because I was curious about the code base, asking it questions, and then it also really helped me do the automated tests, but I also wanted to still do some manual testing. And I asked Claude, hey, help me come up with a way for me to manually test this to make sure I cover all the cases. But all that then gives me confidence that, okay, I can ship PRs again. And then I got more comfortable with it again. And so I've actually had a lot of friends reach out to me that have been managers for a while that are like, hey, I'm shipping code again thanks to Claude. But in general, it's just important to me as leaders to make sure you're using the product that your team builds.
It's so interesting that you are overseeing, as an eng leader, the team that is most changing the role of an engineer. It's such a meta role. The work of an engineer is transforming because of the software that you're building. One question along these lines is just: do you worry about engineers' skills to code atrophying from not actually writing code anymore? And does it even matter? Is this something you think about? Is it a big deal?
It's interesting because we actually have this discussion on the team a bit. Are there things that we miss? Or actually, to your point, I'm always thinking about when someone's onboarding and ramping. You have Boris, who handwrote the code in the early days and of course doesn't anymore, but he gained that knowledge from before because he was in the code base. So especially for all the engineers that join, I'm also like, make sure you're taking the time, for all the work that you do, to still get the understanding of the architecture or the change, because it goes back to that trust but verify. Maybe one day it won't matter anymore, but at the pace that we're going, I actually still think understanding... it's always double-clicking on that layer that you depend on. Maybe that to me is a meta... because it's always take that time to learn about your dependencies, because this way when your dependencies change, you're more aware, or you might not be taking advantage of changes to dependencies. So I think it's always about doing that double click.
But the other thing that we found interesting on the Claude Code team is after a while we felt it could start being a lonely experience, because we all started just working with our agent so much. So recently we started maybe a pairwise programming lunch. Because what we also learned was on Claude Code, everybody uses Claude Code and Cowork, everybody uses a flow so differently. And so we found that, wow, when we do pairwise programming, we actually learn so much from each other. And then the other thing too is we make sure that we also have maker time together too. So for example, hackathons are another thing we really like to do, just to make sure we're interacting together as a team.
That is such a good point, the loneliness that emerges, because it used to be eng teams building code together. Someone's doing back end, someone's doing front end, someone's doing the iOS app. Probably a bunch of people, you know, on the back end. And I was like, you know, well, it's 10 Claudes running in parallel doing all these things. That is such a good idea of finding ways to connect engineers. So,
The idea here is like almost pair programming, but not. It's like parallel play when kids are growing up. Like, you're kind of working next to each other, but building your own things. But even just watching how other people build, you're finding, is really valuable.
Yeah, and it's because our own tool chain is changing so fast as well. But yeah, it's very interesting to me that everybody on our team just uses Claude Code and Cowork in different ways. And so, every time I watch someone work, I learn something myself as well.
How do you manage people getting over-obsessed with optimizing their workflows? Is there anything you just say, "Okay, it's fine. Just keep going"?
You know, I haven't seen too many folks on our team like that. I think everybody is just really excited about, you know, either an architecture update that we think will be higher reliability or some product experience. So, for most folks, that's what we talked about a lot. Like, yeah, we don't over... It's fun lunchtime conversations, but I don't think we over-optimize, because there's no perfect answer actually.
Much to do.
Is there anything... These are really interesting insights. Just like as the role transformed, things come, things go. So, I'm curious what else is kind of lost in this new world of software engineering. I used to be an engineer. I don't know if you know this. I was an engineer for 10 years. And it was so fun just to sit there in flow coding. You know this feeling. Just like, "Oh, wow, it's working. Look at it compile. It's amazing. I'm making progress." And now it's like you don't do that anymore. You just sit there and kind of wait for agents to build the thing. What else is kind of lost in this new world for engineers?
Yeah, it's so funny. I just had that conversation with an engineer on the team, to talk about flow. Like, remember the old days, you have this really gnarly problem and you pop that music soundtrack in and then you're just in the zone. So, yeah, there is a little... And then there was always that big aha moment at the end. I would remember. Like, yeah, you remember you're like, you finally cracked it. You know, that yay. So we do, but I think now we get a lot of joy from the product. But I do think there is, cuz I hear from other engineers as well of, well, some of the hardest parts is what I used to enjoy. Like, yeah, I heard that from another engineer as well. And so I think we're all just kind of shifting.
But I do see the thing most, and that's why I was talking about the pairwise programming in the hackathon. That did recently come up more, of folks starting to feel like it's starting to be a lonely experience.
So interesting. Within Anthropic, I'm curious, so engineering is like the most transformed, I think, of any role right now. What's like the second most transformed role so far, would you say, within Anthropic that's most different from how it was a couple years ago, let's say?
All the coding-adjacent roles are shifting. Like PM, I know you were chatting with Kai. I think PM is also transformed quite a bit, because PMs are no longer bottlenecked, if they have an idea, waiting on engineering bandwidth. So that's kind of the next role I've seen shift. Actually, our PMs have also helped us roll up sleeves and help ship some features when there was something we wanted to do and an engineer wasn't able to. So I think all the coding-adjacent roles are starting to shift.
But I think that's where, again, the verification is important, cuz when you have more different disciplines checking in, how do we make sure everybody has high confidence? I also think we need to do more to keep automating these other portions of the workflows. For sure we focus a lot on coding, but next, when you think about design or data science, those are starting to be the next areas I think are good opportunities for us to see how we can start improving experiences there as well.
Yeah, speaking of data science, I have a data science friend and he was just saying how data science is so different now, where now most of their job is people doing their own not-amazing data science work using AI and then just showing it to the data scientist: "Here, here's the analysis I did. Can you just make sure it's right?" And half the time it's not right. And so the job is just a whole different job now. Instead of doing the work that they thought they wanted to do, it's like, "All right, I'm just reviewing all this AI data science all the time. What the hell?"
Kind of along the lines, coming back to just how your team operates and how things are changing, let me see if something comes with this question. What should an engineering manager expect from their team now versus a couple years ago? What's like a normal, I don't know, baseline expectation of how things should work? Is there, other than just, you know, we're shipping faster, anything else?
Oh, interesting. Well, definitely I think most commits are Claude-assisted, and so that was a shift. I think, you know, I kind of mentioned we have Slack channels with all the feedback and also our dashboards that we have get to Claude. I think having engineers keep building that stronger product sense muscle is also another, and I think that in general helps build these really strong-minded product engineers. I would say more of these roles that were traditionally non-engineering, you do now see engineers being like... And sometimes you're just blocked by, you know, waiting for a cross-functional partner. I think there's less of those blocks now, just because the models are able to augment additional capabilities that you may not have as an engineer.
So it's kind of interesting that it's both directions. Engineers becoming more product-minded and responsible for the quality and success of a product, and then everybody becoming an engineer more and more.
Yeah, that's right. It's all blurring.
Yeah. I forget who said this, but there's this, like, what is a role anymore? This guy said that it's like, what's the average of what you do? What's the highest percentage of what you do? And that's kind of your role now, whatever it is going to be.
Yeah.
Oh man, I want to come back to your point about obsession with the product, living and breathing the product, dogfooding. I talked to a bunch of people that work with you about you, and that's the thing that came up most, just your obsession with living and breathing the product, using the product constantly, whatever it is you're building, this idea of dogfooding. Talk about just why that is so important, why that's something you instill within your teams and reports.
Oh, I love it. Yeah, I think it's really... and this has worked for me. It's just been a really good way for me to keep a pulse on, you know, anytime you build product, there's a dream. Like, you're really hoping to enable an experience or make an experience better. So I think that helps me keep really close to the pulse. I also think maybe, for sure, on Visual Studio that was where I got this love of it.
But it's interesting, cuz even Marketplace, I remembered, once in a while I'll do it, even after I left the team, actually. One time I had a MacBook Air and I wanted to sell my old one, and, you know, I hadn't sold anything on Marketplace, let me... And I could not believe it: the minute I put it up for sale, a seller or buyer tried to scam me, and it was an interesting new scam vector I didn't detect. And so that goes to, again, people will use your products in ways that you may not expect. And so, especially as leaders, or even anyone on the team, we all have different lives. Actually, it's funny, when I was, you know, supporting the VR and AR teams, somehow, how I used VR, the setup, I would always be able to find these really weird floor height issues. So, that ended up being, I took a, you know, I'm going to help us, cuz somehow I got a good repro environment.
And so, I think it's number one: that's how you keep your pulse on the product that you're building and don't get too lost in metrics and dashboards only, or presentations.
I think that's such an important point you're saying there that I just want to make sure people hear. There's always this idea of anecdotal evidence and just examples versus the data. And what you're saying here is, as a product leader, as an engineering leader, you found a lot of success in the anecdotes, the specific little one-offs that you experience as a user, versus obsessing with the data only.
Yeah. And actually, sometimes it's also how I've been able to most effectively help the team. So, for example, the last team I was on, I was, you know, leading a VR team, and back then I had not checked in any code into that code base, just cuz I was really worried about messing up the operating system. But what was a gap? We were doing a lot of polish fixes, and I was like, "Hey, you know what? I'll use my dogfooding time to actually vet how the experience looks." And so, that was also probably a way that I felt I could still meaningfully contribute to help hold the quality bar for the team. And then, like I say, every team member usually really appreciates it, cuz I think as a leader, you're supporting folks on the team, and outside of metrics and everything, everybody really wants to make sure their work matters. And yeah, just making sure that, you know, leaders use your product. I think folks feel the leaders remain really engaged and not too...
And this connects a lot with your point that engineers need to become more product-minded. That engineers need to become more PM-y, PMs need to become more... But this is, as an engineer, one way to do it. Use the product constantly. And that'll help you understand what is missing in the product as a user, cuz you're just using it.
That's right. And I would say if you're leading a team where it's really hard for you to use the product, then meet with customers. Whatever the other avenue is. I think that's also been really important to me. Every time I've done customer visits, I always learn something new.
Actually, I remember that was Facebook Marketplace; we were trying to launch to Latin America. And so we were testing in Chile. And I remember that it just wasn't doing as well as the other regions we'd done, and everything else we'd tried. And we had a really small research trip where I went to Chile. I remember getting a whole bunch of Android phones for us. It was a very small crew, like just three of us. And upon landing and upon me opening up these Android phones, I'm like, ah, you know, the LTE connection was much slower than what we were used to in the US. And so I'm like, oh, the Marketplace feed didn't even load very well in these little LTE situations. What a growth blocker, you know, you can't even load. But again, that's why it's so important to always listen to customer feedback and get that fast feedback loop.
I think it was Jeff Bezos that said if you have the data and you have an anecdote, trust the anecdote over the data. Surprisingly. And that's a great example. Okay. Just a couple more questions.
One is, in your talk, you had this really interesting slide at the end of what questions you're kind of rethinking right now that you haven't figured out how to solve, with how much is changing. I'm going to read the three. I'm curious if it's still these three, if there's anything else, like current problems we need to figure out that we haven't solved in how we operate. What you shared in your talk was: do we still need separate iOS and Android orgs? How far do you push fully automated reviews? And with role blurring, how do you ensure everyone's equally productive? Still problems? Is there anything else that you're thinking about, like, okay, we need to crack this, we haven't figured this out?
You know, the iOS and Android one, I think we're still... Actually, it's funny, cuz I speak of the deep expertise. We definitely feel that it's really important to still bring on folks with those expertise, but we probably don't need as large, because people are flexing. So it's again making sure we have, you know, the Android and iOS experts, but then less of the larger kind of mobile org, one per. And so, but again, that's still a balance that we're trying to figure out, of do we have the right and enough expertise? The second one was... Sorry, what was the second one?
Oh, yeah. It is how far do you push fully automated reviews?
Ah. Yes. Actually, well, this is a fun one, like, you know, with the content design check. I think we're looking across all of it at how do you actually get what good looks like? And so, actually, the verification is still one... I think that's kind of the second and the third, where I think there's a lot more opportunities for us. But the how far to push, I think, is looking at where we think that experts still matter, and then also, again, we have to keep asking ourselves, okay, is there a way to leverage our expertise to also automate? Like, I think looking across the whole end-to-end experience, making sure we're not missing... I think we come at it from an engineering standpoint, but making sure of how we think about those other areas. I think there's definitely still more that we can do there.
Basically, how do you set up a verification that the experience is what you want it to be?
Exactly. That, and I think that one is still a hard one to crack, cuz you kind of mentioned the eval cases. Some of it for sure is accuracy, but it's also the experience. So that's something that, yeah, we're still kind of thinking through.
Awesome. Is there anything else that's like, this has changed recently, we've got to figure out how to rethink the way we operate? Or is this kind of the big ones?
You know, I think because of routines and everything being more async, I think there is starting to be a high load on our context switching. Cuz I even remember I myself was like, oh, I kicked off... And so I think that's probably another thing we have to think about, of how, whether for our team members or our users, we can actually make the experience better to reduce that load, cuz I do see the context switching load increasing.
I can... Like, if you have 20 agents running, there's just endless checking in and reviewing, and you have to remember what you're doing there. It's such an interesting world where, like the idea of flow we talked about before, for engineers and most people there's less of the just hours of flow, but now the agents can kind of just remind you, here's where you're at. The reset to switch almost is easier, cuz you don't have to relearn everything. You don't have to re-understand the code base and the architecture. You can kind of just say, okay, but here's what we're trying to do. It's kind of like it both got better and got worse.
Well, it's interesting, cuz I used to book out focus time, like, you know, the focus time for coding, cuz you want that dedicated, and then the whole
context switching, and then it's interesting now that because I can context switch more with more async agents, I'm noticing I do actually have to go back and block, like, a focus time for me to catch up on all the, you know, different async work that I've kicked off.
Yeah, do you have any thoughts on a solution there, cuz that's hard. Just like, people just want to do more and more, and just how do you do that without constantly context switching? It's really hard and annoying.
Yes. I agree. Like, definitely I haven't cracked it yet.
So interesting. Okay, there's a question I thought of as we were talking that I'm so excited to hear your answer on. I wasn't even planning to ask this, but it's so important these days, which is jobs and hiring. So interesting that you would think AI would make engineers less necessary. On the other hand, it feels like you guys are hiring engineers like crazy. OpenAI's hiring engineers like crazy. Just like, there's so much demand for engineers. Where do you think this goes? What do you think about just the future of the eng role? And this is a big question, but just thoughts.
I'll share, I'll actually share some vulnerability here. One, speaking of big open questions, I really do think how we grow the next generation, just because how you and me got to our engineering path is just so different. It's almost like, okay, now when you graduate from school, it's like how do you kind of fast-forward it? But the important thing to me is that you still understand, you know, that double-click I talked about to the layer of an eight. But that is a big question I have, and I wish I had the answers.
But I wonder if for software engineering, it's almost like you go more towards a fellowship or apprenticeship program. I know it's hard cuz technically we have internships, but those were kind of like 3 months and little projects. But I do wonder, and I wish I had a crystal ball here, but yeah, how do you almost cram in some of the... And maybe it won't matter, but you know, some of the life experiences that we all got, how do you actually enable us to teach that to, you know, the next generation of builders?
Right, like if you don't ever have to look at code, well, what's the incentive for a new software engineer to truly understand how infrastructure works, and memory allocation, all these things that are kind of foundational?
And it's interesting. Maybe the models will get good enough that it doesn't matter, but, you know, I do think there's something about that double-click, cuz I think that's where there might be an opportunity to improve the product or the system. But figuring out how to learn that not necessarily by, you know, years and years of...
Of typing code.
Yeah.
Yeah, like somebody's going to have to understand code at some level. It's like some COBOL engineer they have to pull out of retirement one day, like, "Do you remember how to write Python?"
You know what was really fun? One of my previous managers, I mean, he started as a software engineer when it was punch cards. And it's so fabulous. He's been messaging me everything he's been building with Claude Code. And I'm like, "Wow, what a career," that you go from... he's really kind of seen this whole change.
So maybe for us to think about it, when I think about his career, how he got started with punch cards was also totally, totally different than now. And so it might be that, I think it'll be interesting for us to see what remains important, and then what changes in terms of importance. And then it's like, how do you gain the... Like, I have a theory, maybe, that what is important will shift over time. And then how do you kind of build the proficiency into it.
Oh, yeah, just learn the things that really matter. Like, the argument that I constantly hear is just, it's a new level of abstraction, just like assembly and binary. It just keeps going up and up. And now, okay, we don't need to actually look at the code. It's like a new layer of abstraction: prompts and Claude's thinking, you know, messages.
Yeah, and it's maybe like, "Okay, what is an interesting problem? What's the prioritization for experiences to build?" It's interesting. And then when you build things, how do you know it's actually resonating and it's doing what you intended?
And is good, yeah. Like, are we just building a bunch of slop here, or is this actually architecture that will work? I think the advantage, though, for young people is it's so much easier for them to just lean in and work in this new way versus being stuck in the way that things used to be. It's amazing how many long-time engineers like yourself have adapted and embraced this. It's so hard to just change everything. Okay, let's do it. Everything.
Well, cuz the rate of change is also so fast. Actually, that was the one thing. I remember the first time, it was probably Sonnet 3.5 or 3.6, and I remember it was still making some mistakes when I was doing things on the side. I'm like, "What are you doing?" And then what I noticed was some of the engineers that were resisting AI tooling, they're like, "Ah, but see, look at all of these." But then I think it was hard to understand the kind of exponential rate of improvements.
And maybe that's another interesting thing that I myself am learning too. There might have been something I tried to automate that Claude wasn't quite good enough at. And then actually in the next model, oh well, now it is good enough. So it's always also thinking about what may have not worked. It might be worth the time to revisit, cuz, you know, that now might be a new capability.
Yeah, that comes up a lot on this podcast. Just 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.
Okay, final question. You may have already answered this with what you just said, but what keeps you up at night?
You know, the thing that keeps me up at night is probably how we... So, you know, we talked about the Claude Code and Cowork team culture, and the team culture is really important to me. It's the one team mentality, and I share with folks... And by the way, culture is a living, breathing thing. It's not just a poster you slap on a wall, and it changes over time, and it shows up in how we treat each other, how we're there for each other.
And so the culture of the team is important to me because we are growing, and since the culture shifts, making sure that we maintain the things that are important. It's really important for me to have diverse perspectives, so then we can have good, healthy, open, honest debates in the open, and we welcome those. And kind of what I call that one team mentality: when you get close to the finish line, look behind you and see if there's someone on our team to help, cuz we finish as a team.
That's probably the thing that keeps me up at night. There are so many other hard problems, right? But I think a lot of the other ones are product or engineering challenges that, yes, we have, you know, dashboards or theories or hypotheses for. But the culture is a human aspect that is...
I think that's the one that I always want to make sure that, as we grow, we still maintain, cuz it is kind of the fiber of the team. And when it starts drifting, I'm always worried, you know, if it drifts, are we catching it and having conversations as a team together to make sure we all want the culture to grow in the right direction?
Yeah, I imagine everybody is struggling with this, considering the pace of change and the pace of hiring, especially at a company like Anthropic that's on this crazy, the most unprecedented growth trajectory in history. I could see how that could be a challenge with so much change. It makes sense. Even at Airbnb when I was there, that was quite a growth trajectory, and that was nothing like what you guys are going through. And that was a constant topic of conversation: how do we maintain the culture?
Actually, I'm curious, what was your experience at Airbnb to maintain the culture as you were growing?
Two things. One is, what worked well is the founders being obsessed with it. Every all-hands, every big meeting, is just reminding everyone of the culture and the value of the culture and what the values are. Just the founders, top-down, being obsessed with it was a really big part of it. You just couldn't have a meeting without that coming up as a thing.
The other is a memory I always come back to. We had Sheryl Sandberg, from what became Meta, come do a fireside chat, and somebody asked her just how do you maintain culture as you scale? Because we're just going so fast, and it's so hard to deal with all this change and culture and all these new people. And her advice was, this is actually the problem you want to have, because this means you're growing and doing well, and this is normal. Nothing will change if you're doing badly. That's so much worse, a situation when you're not growing and you're not hiring like crazy. That's a much worse situation that will cause even more suffering. So this is a good problem you're dealing with. That was her advice, which has always stuck with me.
Oh, that's great. It's interesting. I think one of the important things on the Claude Code and Cowork team, whether ICs or managers, but this is a thing I especially ask of managers on the team, is it's really important that we all talk about, for sure, what's going well, but also just be open about what's not going well. Because then if we can actually have a conversation about what's not going well, that's how we can actually go ahead and address it.
Speaking of what keeps me up at night, my nightmare is, especially if someone's in a manager position, and I'm like, "Hey, how are things going?" "Everything's fine." And I'm like, oh my gosh, I know things are not fine. It's that whole, you know, there was this meme of the dog with a cup of coffee in a room that's on fire. That is my nightmare. So that's actually a discussion I have with a lot of folks on the team, especially managers, when they first join: "Hey, let's always have these open conversations so that we can solve problems together."
I imagine that's something a lot of people struggle with, seeing so many people around them doing super well, at least seemingly doing well. "Everything's going great. I'm growing this awesome company." It's hard to actually be honest and say, "It's not going great. I'm struggling here. I'm falling behind," cuz everyone around you, on the surface, feels like they're killing it.
Mhm.
Yeah. Before we get to our very exciting lightning round, is there anything else that you want to leave listeners with, anything else that we didn't cover, anything else that's important that you wanted to share?
Maybe one thing is just a suggestion, cuz, you know, we talked about how Claude can automate. One other thing that's really big in the Claude Code and Cowork team culture is explicit permission to kill processes that no longer serve us. And so maybe a suggestion for anyone, you know, in our work, on our teams, or leading teams: what's one process that you either dread doing, or is really noisy, or is really expensive in terms of just a lot of effort, or is something that's just very manual? Pick one thing and first ask, is it still serving its purpose?
For example, even our planning. Actually, that was my own big first learning when I first joined Claude Code. I'm like, "Hey, maybe we should do a six-month roadmap doc, but we're going to do it super lightweight, cuz I don't want to waste a lot of time planning." And I felt we did a really lightweight process. But that was such a good learning for me, cuz the exercise was good to kickstart conversations and ensure we're aligned, but three months into it, I'm like, wait, have we still referenced it? Because so much has changed. And so that was also something I changed, that I myself brought in thinking, "Hey, maybe this will help."
So always be open to learning, and always ask yourself, whatever process you have, is it still serving its purpose? Just because the field is changing so fast.
I love that advice. I've got to follow up on this real quick. So how do you think about planning now? Do you do any planning? Is it just a month-long roadmap? What's the simple way to explain where you're at with that?
Yeah, I call it JIT planning now, just-in-time planning. I think 6 months was too long. So now, for sure, some projects will take more than a month, but we try to do a month of planning, really lightweight. Actually, there aren't even docs. It's really just us aligning on a little spreadsheet of what we think is important. But even that one, I'm kind of thinking through, "Hey, every week we should probably still keep..." What we're trying is, here are the month's priorities. And we're going to try it out, but I have a feeling that every week we'll probably want to do a really quick, "Hey, just to check. Yep, these are still this month's priorities. Good." But yeah, now we've shrunk it to JIT monthly planning.
So it's monthly, meaning for the next month, here's a little sheet, Excel spreadsheet, of what we're planning to do for the next month. And then every week, check in: is this still what we're planning to do for the next month?
Yeah, very much. But even with that one, I'm also still thinking, "How can we automate this even more?" Cuz I never want it to feel like a tax when someone has to, you know, update the spreadsheet. So actually, just yesterday we were chatting, "Hey, how can we actually automate this?" It's getting to that question: always ask yourselves, "Can we actually automate this better?"
My PM brain is like, how could you not do something like that? Okay, here's what we're thinking for the next month. Let's just check it once a week. Let's make sure this is... It's hard to imagine that not happening. And you don't have a lot of items on the spreadsheet, is what I'm hearing also.
Yeah, we really try to focus. So we'll share out, here's what we think are the highest priorities. And again, for that agency, given the priorities, everybody has their own items for how they think they address those priorities.
Is there anything that's like, here's the next 6 months, bigger bets kind of stuff, or is it just, let's think 1 month ahead?
So usually there are definitely themes of where we think the work is going. And actually, we'll bring the whole team together every 6 months. So there we'll usually kick off some themes, but then it's really about making sure we keep the pulse, because again, even the themes change so fast when the landscape changes.
All right, let's pull up the spreadsheet and let's take a look.
Oh man. Man, this whole podcast could have been just talking about this planning stuff you do. Okay, I'm going to have to find someone else to talk about this, because this is so interesting, just how y'all plan. Yeah, okay. Well, Fiona, with that we reached our very exciting lightning round. I've got five questions for you. Are you ready?
Ready.
Okay, first question. What are two or three books that you find yourself recommending most to other people?
Ooh, I will say for fiction, actually two authors I recommend to everyone: Margaret Atwood and Haruki Murakami. Those are just two, like, I mean, I grew up in Canada, so I read a lot of Atwood growing up, but her books are fascinating because it's almost like speculative fiction of, you can kind of squint and say, okay, could this actually happen to a society? So I love her take on speculative fiction. And Murakami, I love his magical realism style.
But then the one book, so those are authors, but the one book I always recommend to everyone to read at least once a year is The Little Prince. I'm sure we probably all read it at some point in our lives, but I read it at least once a year, just to remind me to think about what's truly important.
Wow. That doesn't come up a bunch. Okay. I love it. Favorite recent movie or TV show you have really enjoyed?
I haven't watched TV shows.
That's very common across Anthropic people I have on the podcast. Common theme.
But I will share with you what I always have downloaded on my phone so that if I'm on the airplane. So there's three movies I always have on my phone because I think they're just so fun to watch if I have time.
One is Amélie. It's this French movie. Oh my gosh, all of these movies are going to be very old, by the way. It's going to be like vintage movies. But I loved Amélie. Super whimsical. So I really highly recommend it to anyone that hasn't seen it. If you remember, I told you I thought I was going to be a visual artist. So when I was 16, my high school took a trip to Paris, and I have so many memories of that, and Amélie really captures the magic I felt in Paris.
And the other two are Ghibli films. I love Spirited Away. I just love that story. I just love everything about Spirited Away. It's probably one of my favorite Ghibli films.
And then the third was another Ghibli film, Nausicaä of the Valley of the Wind. And I think about this one quite a bit, because if anyone asked me, "Hey, how did you think about all these leadership traits?" I think I watched that movie probably when I was eight or nine. And the heroine Nausicaä, seeing how she leads, just left such a footprint in my heart, I guess you could say, that probably Nausicaä has inspired a lot of my different leadership principles.
Wow, what is that book called again?
The movie's called Nausicaä of the Valley of the Wind, but it was actually based on a manga.
Valley of the Wind. So, it's like High Output Management, Andy Grove; Valley of the Wind, Nausicaä.
That's right.
Two top management books. So cool. Okay. Do you have a favorite product you recently discovered that you really love? Could be an app, could be clothing, could be a gadget, could be kitchen equipment.
I'll share the product that I was reminded of how much it has made a difference in my life recently. Because I've been traveling a little bit, and I like to travel really light, so I use whatever shampoo and conditioner the hotel gives. And I forgot that. So the product, I actually have one of their hand... I promise this is not an infomercial. But Sweet Sisters Bodycare. It's a local business on Whidbey Island.
But the reason why their product has made such a big difference in my life: it's a full line of organic hair, body, skin care. A few years ago I started getting this rash on my nose right here that was really painful, like actually bleeding. And I could not for the life of me figure out how to stop it. I tried not using any lotions. I cut everything out on my face and it was still really hurting. And then somebody says, "What's the shampoo you're using?" I'm like, "It's the same shampoo I've used since I was a teenager." And it's a generic brown shampoo that you get anywhere. And they said, "Maybe your body's just started developing an allergy to it because of the chemicals in it."
Wow.
I'm like, "What?" And so anyways, this was an organic shampoo that I found. Lo and behold, I use their shampoo, and then, because you don't think that when you wash your hair, it actually goes over to the rest of your body. But since then I've switched everything that I use to be Sweet Sisters. But I was recently reminded of how important this is, because after a week of hotel shampoo, I actually started having some skin reactions again. I'm like, "Ah, maybe I should get travel-size bottles that I can bring with me."
This is an awesome pick. I love local business picks, even big bonus points for that. And by the way, this travel you're doing, just for folks that may not know this, there are these Code with Claude events that are happening all over the world. I went to the one in SF. There was one in London. You're going to one in Tokyo. Is that the end of it or is there more after that?
Tokyo is next week, and that's the last leg of the trip. And then probably more in the future.
So cool. I love that that's happening. Okay, two more questions. Do you have a favorite life motto that you find yourself coming back to often in work or in life?
Ooh. So, in work, I really love to remind folks: keep it simple. What is the thing that you're really trying to do well, and focus on that. Keep it simple, because I think sometimes we can overthink. So it's always a good mantra to think about. And then in life, probably: in a world where you can be anything, be kind.
Yeah. I love that one. We were at a Montessori school tour and that's what the teacher had up on the wall.
Aw. We have so many things going on that you never know what's going on in someone else's life, and that one small act of kindness can make the biggest difference.
Yeah.
For me, actually, do you remember COVID? We were all working from home during the COVID days. It always really struck with me, because I was in these back-to-back meetings, and one-on-ones are really important to me, because that time is usually also really important for the other person. It's something they've been looking to. They might have things to discuss. So I always really prioritize one-on-ones.
But during that time, my grandmother wasn't doing well, and she was in a home in Canada, and because of COVID I couldn't go visit, and actually even my aunt and mom couldn't go visit. And it was this very rare thing: if they have a helper that can help, we could do FaceTime. But you never know what time that is going to be, because there are so many people to take care of. And all of a sudden I got a message from my aunt going, "Grandma can FaceTime at like 12:00 p.m. today." I'm like, "Oh no, there's this one-on-one that I've been meaning to have."
And I just messaged my report to say, "I'm really, really sorry. It's so last minute. Is it okay to..." And I know now, when I say it, it doesn't seem like a big thing, but to me it's always really important to keep. But he was like, "Yeah, totally. No problem at all." And for me that was just a small act of kindness. He totally didn't make it into a big deal, but that made the biggest difference to me, that I got to say hi to my grandmother on FaceTime.
I love that.
Okay. Final question. So Boris Cherny, when I asked him about you, had this interesting insight where he said, "In very important meetings, you can often hear the click-clack of Fiona knitting in the background." Maybe talk about just what's going on there, and what are a couple things you knitted recently?
Oh my gosh. Well, I knitted this top recently.
You make your own clothing. Unreal. This is very meta for Claude Code building itself.
You know, we're always building our clothing.
Yeah, actually, this is a whole fun thing I think between knitting and programming, because it's kind of like two stitches, knit and purl, so it's zero and one. And anyway, so many concepts of stacks and queues. I'm kind of like a compiler. I'm kind of generating an executable when I knit. But I don't know about that.
Actually, it was my grandma that taught me to knit when I was eight. I kind of mentioned her and I going to that yarn shop, and so every time I knit I think of her. But I always like to multitask, as you can see. I kick off multiple agents. And so anytime I'm sitting, because I practiced enough and got proficient, I don't have to look at what I'm doing. So it's almost like how sometimes people have fidget spinners and such. Knitting is just, anytime I'm sitting still, I'm like, oh, this is time to generate more knitting.
It's cute.
Well, because I've got so much yarn that if I don't do this... I might have a slight yarn addiction problem.
I love this. When I asked Boris what he would do when AGI hits, when we don't have to work, he said he's going to make me... So I'm guessing your answer would be just knit and make beautiful clothing.
Oh my gosh, my dream is to actually open up a yarn store in my grandmother's name and create that community.
And then Cowork would help you automate everything.
That's right. Especially invoicing.
Oh my god. Fiona, you're awesome. It's just incredible, the work that you and your team are doing, just changing the world in such profound ways, and it's clear why it's growing so fast. So good job. Good job over there. Thank you for making time for this.
Well, I'm just really honestly lucky and humbled that I get to work with such an amazing team. I know how lucky I am, and I'm so grateful. But thanks a lot for having me on the podcast as well. This was a lot of fun.
To follow up on questions, where can folks find you online, if you are online, if they want to follow up on anything, and how can listeners be useful to you?
Ooh, so definitely I'm on LinkedIn, and I'm sure most people have shared this already, but I would love feedback on what's going well, what's not going well. Also any latent demand, things you are all using that might be interesting use cases. I had a friend message me recently to go, "Oh, I'm using Claude to help me generate a building plan for my shed," and he actually showed me his shed, which was cool. So I would love to hear about that.
And then maybe also, we talked about reaching out across. If there's someone, whether a small business that you love, or someone that you feel like hasn't... as some of the listeners are super AI-pilled, maybe take the time to hold somebody's hand to show what AI might be able to help them with.
Such a good one. That is such a good answer to this question, especially coming from you. Fiona, this was awesome. Thank you so much for being here.
Thanks so much for having me, Lenny.
Bye, everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated