AI-Native Team Practices: How Anthropic Engineers Achieved an 8x Productivity Boost

Article

Over the past two years, the job of a software engineer has undergone a near-total transformation. Official data from Anthropic shows that per-engineer quarterly code delivery has increased 8x compared to the previous baseline—the chart essentially flatlines for a long period before rocketing straight to the moon. Behind this number lies a qualitative shift in large language models (LLMs) for code generation: AI coding tools like Claude Code are no longer just "smart autocomplete" offering single-line suggestions. They can now understand entire codebase context, auto-debug, refactor across files, and even independently handle complete tasks—what academia calls the paradigm shift from "tool" to "agent."

The technical foundation of this leap rests on two key LLM breakthroughs in recent years. First, context windows expanded from thousands of tokens to hundreds of thousands, enabling models to "see" entire codebases rather than single file fragments. Second, function calling/tool use capabilities matured, allowing models to proactively execute terminal commands, read and write files, run tests, and form a complete "generate-execute-feedback-correct" loop—corresponding to the engineering implementation of the ReAct (Reasoning + Acting) paradigm. When "programming is no longer the bottleneck" becomes reality, how exactly should an AI-native team operate?

Anthropic's Fiona Fung may be the best person to answer this question. She leads both the Claude Code and Cowork product teams, bringing over 25 years of engineering experience: she previously led the TypeScript and Visual Studio teams at Microsoft (TypeScript was introduced by Anders Hejlsberg's team in 2012 as a strongly-typed superset of JavaScript, with a core design philosophy of "maintaining engineering quality in large-scale codebases through static type systems"—directly aligned with her emphasis on framework-based verification today), built Facebook Marketplace from scratch into what is now a platform with over $100 billion in annual GMV (its success largely depended on Facebook's existing social graph, where buyers and sellers often had mutual friends, dramatically reducing trust costs), and contributed to the development of Meta's first smart glasses and AR glasses Orion (Orion is Meta's decade-long, multi-billion-dollar augmented reality project requiring optical waveguide displays on ultra-thin lenses—an engineering challenge of extreme complexity that gave her deep understanding of "perception-level bugs that only heavy users can discover"). In this episode of Lenny's Podcast, she shared extensive frontline management and engineering insights.

Programming Is No Longer the Bottleneck: AI Tools Have Raised the Ceiling

Fiona repeatedly emphasized one core thesis: AI has raised the ceiling of what each person can accomplish. "In theory, everything becomes possible. The question now becomes—how ambitious can you be?"

She gave a vivid example: an engineer on the team who didn't come from a mobile background needed to build out mobile support for a feature. In the past, he would have instinctively refused—"that's too hard"—but now he simply told Claude "help me implement this on mobile too," and it actually did it. This mindset shift is spreading across the entire industry—what was once "this feature is too complex to build" has become "this is totally doable, just hand it to Claude Code."

Interestingly, this change isn't limited to engineers. On the Claude Code team, designers, PMs, and essentially everyone is submitting code. "Everyone is becoming a builder." When different roles can all write code and throughput is this high, a fundamentally new challenge emerges: verification. With code volume multiplied by 8x, how do you ensure quality remains solid and everything actually works? This has become one of the core challenges for AI-native teams.

Using Claude to Manage Claude: The AI-Native Team's New Workflow

Fiona shared a management methodology she practices firsthand. She deploys a Claude Code remote session instance across all code repositories, with access to all code, every Slack channel, and all the metrics the team tracks.

Each month, she opens this Claude session with her team to review together: What were this month's priorities? What products shipped? How are they performing? What are the feedback channels saying? "I used to only use these sessions to generate PRs and fix bugs. Now I use them to support deep conversations with team members."

Her daily morning workflow has also been completely automated. She used to sip coffee while scrolling through feedback channels one by one, manually picking out areas for improvement. Now, through routines, she sets up tasks that run on a daily schedule: "Monitor this feedback channel for me, summarize the themes, have a digest ready when I wake up, and even generate some PRs I can review."

The key here is that the abstraction layer keeps moving upward—from "I write a prompt and execute synchronously," to "I asynchronously kick off multiple agents," to "I write a routine that has an agent generate prompts and automatically spawn multiple agents." This is the latest evolution in AI application architecture: single LLM calls were the first-generation paradigm, agents with tool use were the second generation, and Multi-Agent Systems are the arriving third generation.

In engineering terms, multi-agent systems typically include an "orchestrator" and multiple specialized "executors": the orchestrator handles task decomposition and scheduling, while executors focus on specific sub-domains like code generation, test writing, and documentation. Multiple parallel LLM instances coordinate through message passing, with the core engineering challenges being "context passing" and "result consistency"—among the most active areas of exploration in current AI system design. This architecture elevates human engineers from task executors to task architects. Fiona believes this is the next frontier of engineering evolution: asynchronous operations (async) and fleets of agents.

Embracers vs. Resisters: Growth Mindset Is the True Dividing Line

As roles undergo dramatic change, a chasm is forming: some people fully embrace AI and thrive, while others feel frustrated, resistant, or even fearful. Fiona observed that the people who do best share one common trait—growth mindset.

This concept originates from Stanford psychologist Carol Dweck's research. In her book Mindset, Dweck proposed that fixed-mindset individuals believe abilities are innately fixed, while growth-mindset individuals believe abilities can be developed through effort. In the context of AI reshaping how we work, this framework is especially relevant—engineers who think "programming ability is my core identity" tend to have more difficulty accepting AI involvement, while those who believe "solving problems is the goal" more easily view AI as leverage rather than a threat.

"The way that made you successful in the past may not continue to support you." She acknowledged this is hard, because everyone has achieved success through some established approach, and being asked to change naturally triggers fear. Frustration often stems precisely from fear and the helplessness of feeling "nothing is within my control."

Her advice is direct: lean in, and ask yourself "what is within my control? What can I do?" She cited economist Tyler Cowen's perspective—the highest performers all have exceptionally strong "initiative" or "agency." Cowen, a professor of economics at George Mason University, found that the people who perform best in the AI era possess exceptional agency—the ability to define problems without waiting for instructions and proactively seek solutions. This echoes research by MIT economist Daron Acemoglu and others: the jobs least impacted by AI automation tend to be those requiring proactive judgment and flexible responses to unstructured situations. On the Claude Code and Cowork teams, Fiona distills this into a dialectical relationship: high agency paired with high accountability. Give the team full freedom to "swing for the fences," while requiring them to have clear hypotheses for every attempt and take ownership of the results.

She also quoted a saying—"The cave you fear to enter holds the treasure you seek"—encouraging people to "occasionally do things that scare you" in their careers, because that's often exactly where growth happens.

Quality Gatekeeping: From Manual Review to Framework-Based Verification

When code delivery volume surges, traditional manual code review becomes an enormous bottleneck. Fiona's solution is to explicitly codify "what good looks like" into the repository.

"Claude performs extremely well when you give it a framework to validate against." She recommends checking specifications (specs), content design guidelines, and similar standards into the repository as skills, keeping them updated in sync with the code. This way, Claude Code review can continuously ensure output meets established standards. She draws an analogy to an evolution of Test-Driven Development (TDD)—TDD was systematized by extreme programming pioneer Kent Beck in the early 2000s, with the core workflow being "write the test first, then the implementation, then refactor."

TDD's historical adoption has been fraught with challenges, with the core resistance always being "the time cost of writing tests"—industry surveys show that even among Silicon Valley teams that champion engineering quality, actual test coverage consistently falls short of the ideal 80% target. AI coding tools are fundamentally changing this economic equation: Claude Code can generate boundary condition tests, mock objects, and integration test scaffolding simultaneously with business logic, at virtually zero additional time cost. Fiona's deeper insight is incorporating "product specifications" themselves into this system—once specs are in the repository, AI can continuously verify whether generated output aligns with product intent, creating a new quality loop of "product spec as test case." This means quality standards that were historically compromised due to labor costs could be fully revived with AI assistance.

For quality monitoring, the team established a "bad vs. sad" framework: bad refers to severe, unrecoverable errors (like CLI crashes or lost work), while sad refers to recoverable pain points (like UI flickering). Interestingly, accumulated sad issues can evolve into bad ones. Based on the "high agency" principle, each team defines their own bad and sad standards for their respective surface areas. The team even once shipped a dashboard tracking users' "profanity frequency"—when people are frequently swearing, it usually means the experience has a serious problem.

The core takeaway: in an era where human capacity can't keep pace with speed, monitoring and evals are the most reliable tools for maintaining quality, not investing more time in manual review.

What AI Has Changed—and What It Has Taken Away

This transformation comes with both gains and losses. Fiona spoke honestly about what is disappearing.

The flow state that engineers used to cherish most—putting on headphones, playing a focus playlist, and experiencing the peak moment of "I finally got it" after conquering a hard problem—is becoming less common. Even more concerning is the loneliness. Software engineering has always been a collaborative endeavor, with some people doing backend, others doing frontend, others doing iOS. Now it might be "10 Claude instances running in parallel doing everything."

To address this, the Claude Code team implemented two human-centered initiatives: first, they started pairwise programming lunches, because everyone uses Claude Code so differently that watching each other yields tremendous learning; second, they maintained hackathons and similar formats to create shared "maker time" for the team. This is a new form of collaboration resembling children's "parallel play"—everyone builds their own thing, but side by side, observing and learning from each other.

Regarding whether engineers will experience skill atrophy from no longer writing code, Fiona's stance is: maintain "trust but verify" and always invest time in understanding the architecture and every layer you depend on ("always double click on the layer beneath"). This concern is not unfounded—cognitive science research on "skill rust" shows that prolonged absence from direct practice of a skill leads to degradation of underlying cognitive models, well-documented in the context of pilots experiencing decreased operational capability after relying on autopilot. As for training the next generation of engineers, she admits this is one of the open questions that keeps her up at night—perhaps the future will move toward something like fellowship or apprenticeship models.

From Six-Month Roadmaps to JIT Planning

Fiona shared a counterintuitive but extremely pragmatic management philosophy: explicitly empower the team to "kill" processes that no longer serve their goals.

When she first joined Claude Code, she tried to create a lightweight six-month roadmap document. Three months later, she realized that because the field was changing so rapidly, nobody was referencing it anymore. So she shifted to what she calls JIT planning (just-in-time planning): make only one-month plans that are extremely lightweight (even just a simple table listing the few things the team considers most important), then quickly check each week—"are these still the things we should be doing?" Meanwhile, she retains a full-team directional alignment session every six months.

The "JIT" naming borrows from the "just-in-time production" concept in lean manufacturing—developed and refined by Toyota industrial engineer Taiichi Ohno after World War II, with the core goal of eliminating seven types of waste. "Inventory" maps to knowledge work as "unexecuted plans" and "outdated documentation." This philosophy entered software engineering most notably when the 2001 Agile Manifesto listed "responding to change over following a plan" as a core principle. Fiona's practice pushes this principle to a more radical extreme: in VUCA environments (Volatility, Uncertainty, Complexity, Ambiguity), the more turbulent the domain, the more you need to shorten planning cycles and strengthen feedback loops. Traditional annual OKR frameworks have become nearly meaningless under AI-accelerated iteration rhythms.

She's even thinking about how to automate this weekly update process, preventing anyone from feeling burdened by "having to update a spreadsheet." The meta-principle behind this: in a field changing this fast, always ask yourself—is this process still serving its purpose?

Conclusion: The Dogfooding Spirit and the Team Culture That Keeps Her Up at Night

A recurring high-frequency term throughout the conversation was dogfooding. The term originated from a 1988 email by Microsoft executive Paul Maritz to employees, urging teams to internally use the products they developed. It has since become a universal cultural term in the tech industry.

The deeper value of dogfooding is rooted in the cognitive science concept of "tacit knowledge"—philosopher Michael Polanyi's core thesis is "we know more than we can tell." Users often cannot accurately describe their pain points but can perceive them the instant they occur during an experience. Relying on feedback forms to discover product issues involves systematic information loss, whereas product teams using the product firsthand gain direct access to this hard-to-verbalize experiential information. Psychological research on the "empathy gap" further shows that when people don't personally experience a certain state, they tend to dramatically underestimate the intensity of feelings in that state—which is precisely why Fiona's firsthand experience with scam flows while selling a MacBook on Facebook Marketplace, or consistently discovering bizarre ground-height bugs on the VR team, yielded insights that internal testing alone could never replicate.

From a management perspective, dogfooding's core value lies in shortening the feedback loop—product team members, as high-density users, can more quickly discover experience issues that ordinary users encounter but struggle to articulate. Her statement that "users will use your product in ways you never expected" is a straightforward footnote to this principle. To quote Bezos: when data and anecdotes conflict, trust the anecdote. Quantitative data reveals "what happened," while firsthand experience explains "why"—combining both points to the true root of the problem.

What truly keeps Fiona up at night isn't product or engineering challenges—it's team culture. "Culture is a living, breathing thing, not a poster on the wall." At a company like Anthropic, riding the steepest growth curve in history, how do you maintain that "one-team mentality" (when you're approaching the finish line, look back to see if any teammates need help—maybe you should cross it together as a team) amid rapid expansion and constant hiring? That's her deepest concern.

For those who feel left behind by the times, Fiona's advice is simple yet powerful: lean in proactively, and ask yourself "what is within my control?" Knowledge is power, and AI tools are the lamp that can illuminate the road ahead.