Building AI-Native Teams: What Anthropic's Claude Team Teaches Us About Leading in the Agent Era

TL;DR

• AI-native teams require fundamentally different structures than AI-assisted ones: The distinction isn't about using AI tools—it's about designing workflows where AI agents are first-class team members, not productivity boosters.
• Role clarity becomes paradoxically more important as AI blurs boundaries: When agents can write code, design interfaces, and analyze data, human roles must be defined by judgment, context-setting, and strategic direction rather than execution tasks.
• The "AI-pilled" mindset is a competitive moat: Teams that deeply internalize AI capabilities—building muscle memory for when to delegate to agents versus when to intervene—ship faster and iterate more boldly than those treating AI as optional tooling.
• Leadership in AI-native orgs means curating agent-human handoffs: The new management skill is designing the interfaces between human judgment and agent execution, not just managing human-to-human collaboration.

---

We're in the middle of a quiet revolution in how engineering teams operate, and most product leaders are still preparing for the last war. They're asking "how do we get our team to use AI tools?" when the real question is "how do we structure teams when AI agents are doing half the work?"

Fiona Fung, who manages the Claude Code and Cowork teams at Anthropic, is building what she calls "the most AI-pilled engineering team in the world." In her conversation with Lenny Rachitsky, she offers a rare glimpse into what it actually looks like to lead teams at the frontier of AI-native work. This isn't theoretical—these are the people building the tools that millions of developers now use daily, and they're eating their own dog food in ways that reveal the future of product development.

What strikes me most about Fiona's approach isn't the specific tools or processes—it's the underlying philosophy about what teams are for in an age of capable AI agents. Let's unpack what product builders can learn from Anthropic's experiment in AI-native team structure.

The AI-Assisted vs. AI-Native Divide

Most teams today are "AI-assisted." Engineers use Copilot to autocomplete functions. Product managers use ChatGPT to draft PRDs. Designers use Midjourney for mood boards. This is table stakes now—if your team isn't doing this, you're already behind.

But AI-native is different. It's not about individuals using AI to do their jobs faster. It's about restructuring the job itself around what AI can reliably do versus what requires human judgment.

Fiona describes how her team at Anthropic uses Claude not just as a coding assistant but as a reasoning partner for architectural decisions, a first-pass reviewer for code quality, and a documentation generator that maintains consistency across the codebase. The key insight: they've identified which parts of the software development lifecycle can be delegated to AI versus merely accelerated by it.

This distinction matters enormously for how you structure teams. In an AI-assisted world, you still need roughly the same roles doing roughly the same things, just faster. In an AI-native world, you need to rethink what humans are uniquely good at and staff for those capabilities specifically.

What Human Roles Look Like When Agents Join the Team

Here's where it gets interesting for product builders: when AI agents can handle substantial chunks of implementation, testing, and even some design work, what exactly are human team members doing?

Fiona's teams have converged on a few core human responsibilities:

Context-setting and strategic direction. AI agents are phenomenal at executing within a well-defined problem space, but they can't tell you which problems are worth solving or how a feature fits into a three-year product vision. Humans need to become better at articulating context—not just "build this feature" but "here's why this matters, here's what success looks like, here's what we're willing to trade off."

Judgment calls at decision points. Code can be written by AI, but deciding whether to refactor a core system versus patch it requires understanding of technical debt, team capacity, and business priorities that agents don't have. The human role increasingly is showing up at branch points in the decision tree and making calls that shape the path forward.

Quality bar calibration. When Claude generates a first draft of code or documentation, someone needs to evaluate whether it meets the bar. This isn't just catching bugs—it's asking whether the solution is elegant, maintainable, and aligned with team conventions. Fiona emphasizes that her team has developed strong opinions about what "good" looks like, and they use that judgment to iterate with AI rather than accepting first outputs.

Cross-functional translation. As AI handles more specialized tasks, the ability to translate between domains becomes more valuable. Someone who understands both the technical architecture and the user experience can guide AI to build solutions that work across the stack. Generalists with strong judgment become more valuable, not less.

My take: This is where a lot of product leaders are getting it wrong. They're trying to preserve existing role definitions and just make people more productive with AI. But the actual opportunity is to completely reimagine roles around these higher-order functions—context, judgment, quality, translation—and accept that much of what we used to call "the work" will be done by agents. That's uncomfortable, but it's where the competitive advantage lies.

The "AI-Pilled" Mindset as Competitive Moat

Fiona uses the term "AI-pilled" to describe teams that have deeply internalized what AI can do and built reflexes around using it. This isn't about enthusiasm or belief in AI's potential—it's about muscle memory.

When an AI-pilled engineer encounters a bug, their first instinct is to ask Claude to analyze the stack trace and suggest fixes, then evaluate those suggestions with their domain knowledge. When they need to refactor a module, they prompt the AI to generate three different architectural approaches, then choose based on maintainability and team context.

This might sound like basic AI usage, but the key is the reflexive nature of it. Non-AI-pilled teams still default to doing things themselves and occasionally remember to try AI. AI-pilled teams default to agent-first workflows and intervene when their judgment says the agent needs guidance.

The competitive implication is significant. Fiona's teams ship features in days that might take weeks elsewhere—not because they're smarter or work harder, but because they've eliminated entire categories of grunt work and focused human time on the highest-leverage decisions.

For product builders, this suggests a critical hiring and culture question: Are you selecting for people who can build AI-native workflows, or just people who are good at traditional execution? The former is increasingly the differentiator.

Leadership Challenges in the Agent Era

Managing AI-native teams requires different skills than managing traditional engineering teams. Fiona highlights several leadership challenges that product builders should anticipate:

Designing agent-human handoffs. The new core management skill is figuring out where in a workflow to hand off to AI and where to bring humans back in. This requires deep understanding of both what AI can reliably do and where your specific team members add unique value. It's less about task assignment and more about workflow architecture.

Maintaining quality without micromanagement. When AI generates substantial portions of the output, how do you ensure quality without reviewing every line? Fiona's approach is to be extremely clear about principles and patterns, then trust the team to evaluate AI outputs against those standards. This requires more upfront investment in shared understanding and less ongoing oversight.

Preventing skill atrophy. If junior engineers are using AI to write most of their code, are they actually learning the fundamentals? Fiona acknowledges this tension and suggests that teams need deliberate practice in areas where AI might otherwise do the work. The trick is identifying which fundamentals still matter (system design, debugging, architecture) versus which are becoming less critical (syntax memorization, boilerplate generation).

Setting the pace of AI adoption. Not everyone on a team will embrace AI tools at the same rate. Some will be power users immediately; others will be skeptical. Fiona emphasizes meeting people where they are while creating clear incentives for AI adoption—showing, not telling, how AI-native workflows produce better outcomes.

I think this last point is especially important for product leaders. You can't mandate that a team becomes AI-native through policy. It happens through demonstration, through early adopters showing concrete wins, and through gradually raising the bar for what counts as good work. If your team sees that AI-native approaches ship faster and with fewer bugs, adoption follows naturally.

Practical Implications for Product Builders

So what does this mean if you're building a product team today? A few concrete takeaways:

1. Audit your workflows for AI-delegable tasks. Go through your typical product development cycle and identify which steps could be fully delegated to AI agents versus merely accelerated. Writing first-draft PRDs? Generating test cases? Creating API documentation? These are candidates for full delegation. Making prioritization decisions? Evaluating design trade-offs? These stay human.

2. Hire for judgment over execution speed. In an AI-native world, the ability to quickly evaluate options and make sound decisions matters more than the ability to personally execute every task. Look for people who can articulate why one approach is better than another, not just people who can ship fast.

3. Invest in context documentation. AI agents are only as good as the context they receive. Teams that maintain clear documentation of principles, patterns, and priorities will get better outputs from AI. This isn't busywork—it's the foundation of effective agent collaboration.

4. Create feedback loops for AI output quality. Don't just accept what AI generates. Build team norms around evaluating, iterating, and improving AI outputs. This is where the judgment and quality calibration skills come in. The teams that get best results from AI are the ones that treat it as a collaborative partner, not a vending machine.

5. Experiment with role definitions. Don't be afraid to create roles that don't fit traditional categories. "AI workflow designer," "context architect," "agent-human interface specialist"—these might sound weird now, but they reflect real needs in AI-native teams. The teams that invent the right roles first will have an advantage.

The Broader Shift in Team Dynamics

What Fiona describes at Anthropic is a preview of where all product teams are heading. The timeline might vary—some teams will be AI-native within a year, others will take five—but the direction is clear.

The teams that thrive will be those that embrace the fundamental restructuring of roles and workflows rather than trying to preserve existing structures with AI bolted on. This requires courage from leadership, because it means acknowledging that much of what we've traditionally valued in team members (speed of execution, breadth of technical skills) matters less than we thought, while other qualities (judgment, context-setting, quality calibration) matter more.

It also requires humility. None of us really know what the optimal AI-native team structure looks like yet. Fiona and her team at Anthropic are figuring it out in real-time, and even they're constantly iterating. The advantage goes to teams that experiment, measure, and adapt quickly.

For product builders, the opportunity is enormous. AI-native teams can ship faster, iterate more boldly, and tackle more ambitious problems than traditional teams. But capturing that opportunity requires rethinking almost everything about how we structure, lead, and evaluate teams.

The question isn't whether your team will become AI-native. It's whether you'll lead that transition deliberately or have it happen to you reactively. Fiona's work at Anthropic shows what the former looks like—and why it's worth the discomfort of reimagining team structure from first principles.

The Meta-Challenge: Building While the Ground Shifts

Here's the part that keeps me up at night as someone building AI products: we're trying to figure out optimal team structures while the capabilities of AI agents are changing every few months. What works today might be obsolete in six months when the next generation of models arrives.

Fiona's teams have an advantage here—they're building the tools themselves, so they see capabilities emerge before the rest of us. But even they can't fully predict what team structures will make sense when agents can handle even more of the development lifecycle.

The answer, I think, is to build teams that are structurally adaptable. Focus on the human capabilities that are unlikely to be automated soon (strategic judgment, cross-functional synthesis, quality taste) while staying loose on exactly how those capabilities get applied. The specific workflows will change; the underlying human value-add will remain.

This is uncharted territory for all of us. But the teams that treat it as an opportunity to reimagine team structure rather than a threat to existing roles will be the ones building the products that define the next decade.

---

What's your experience building AI-native workflows in your team? I'm especially curious about the unexpected challenges and the moments where AI-native approaches have unlocked capabilities you didn't expect. Let's figure this out together.