Learn how Anthropic's Fiona Fung is transforming engineering with AI. Discover strategies for 8x productivity gains, building high-agency teams, and adapting...
Building AI-Powered Engineering Teams: The Future of Software Development
Engineering is undergoing one of the most profound transformations in its history. Anthropic engineers are now shipping eight times as much code per quarter compared to 2021-2025. Coding has stopped being the bottleneck—it has lifted the ceiling of what anyone is able to do. Everything is now theoretically possible, and the real question becomes: how ambitious can you be?
Fiona Fung, who leads Claude Code and Cowork teams at Anthropic, brings a unique perspective to this transformation. With over 25 years of engineering experience and leadership roles at Microsoft, Meta, and Instagram, Fiona has witnessed every major shift in how software engineers work. From her early days using Vim at IBM to pioneering IDE development at Microsoft, from building Facebook Marketplace to leading 500+ person organizations at Meta, she understands what it takes to build elite engineering teams in the AI era.
This comprehensive guide explores the critical insights from Fiona's work and experience, offering practical strategies for engineering leaders, individual contributors, and anyone navigating the dramatic changes reshaping the software engineering profession.
The Eight-Fold Increase: Understanding the AI Productivity Revolution
The statistics are striking: Anthropic engineers ship 8x as much code per quarter as they did just a few years ago. This isn't just incremental improvement—it represents a fundamental shift in what engineering work means.
Why This Shift Matters
For most of software engineering's history, coding capacity was the primary limiting factor. Engineers spent countless hours writing, debugging, and refining code. IDE improvements, better programming languages, and frameworks all aimed at making coding faster and more efficient. But these improvements were relatively marginal—perhaps 10-20% gains at best.
AI fundamentally changes this equation. When you have Claude or similar AI models handling the mechanical act of writing code, the bottleneck shifts entirely. Coding, the thing that consumed 60-70% of an engineer's time, is now automated. The constraint moves upstream to the thinking, design, and verification phases.
The New Bottleneck: Ambition and Vision
With coding no longer the limiting factor, the question engineers now face is: what's worth building? How ambitious can I be with my vision? This represents a seismic shift in engineering culture. Previously, ambitious engineers were constrained by the time required to implement their ideas. Now, if you can clearly articulate what you want to build, Claude can help you build it.
This creates a new hierarchy of engineering capabilities. The engineers thriving in this environment are those with the highest ambition levels and the clearest product sense. It's no longer about who can code fastest or who knows the most obscure language features. It's about who has the biggest ideas and the agency to pursue them.
Practical Implications for Engineering Teams
The 8x productivity increase has immediate organizational consequences. If your team is shipping eight times as much code, you need different structures for code review, quality assurance, and verification. Traditional code review processes that worked for 2021-era productivity levels become bottlenecks. This is why Anthropic has invested heavily in Claude-assisted code reviews and automated verification frameworks.
Similarly, planning processes need to evolve. If your team could ship 10 features per quarter in 2021, and can now ship 80 features per quarter, your quarterly planning becomes obsolete within weeks. Fiona addresses this through "JIT planning"—just-in-time planning with lightweight monthly check-ins rather than heavy six-month roadmaps.
The 8x increase also raises profound questions about team composition. Do you need the same number of engineers? Different types? What's the right ratio of builders to reviewers? These questions don't have settled answers yet, but they're critical for engineering leaders to think through.
Building High-Agency, High-Accountability Engineering Teams
One of Fiona's core principles for her teams is the concept of "high agency, high accountability." This isn't just a catchy phrase—it represents a fundamental approach to organizational design in the AI era.
Understanding Agency and Accountability
Agency means giving engineers freedom and trust to make decisions, prioritize their work, and pursue their ideas. It means not requiring approval from three levels of management before shipping code. It means engineers have skin in the game and can set their own direction within the team's broader goals.
But high agency without accountability leads to chaos. If everyone can do whatever they want without consequences or consideration for the team's actual outcomes, you end up with fragmented work, wasted effort, and a lack of coherence.
The balance Fiona strikes is: you have complete agency in how you solve problems and pursue your goals, but you're also accountable for the results. Did the feature you shipped actually improve the product? Did it introduce bugs or quality issues? What's the hypothesis you're testing, and did you validate it?
How to Implement High Agency in Practice
Fiona's approach involves several concrete practices:
First, every manager on her team starts as an individual contributor. This isn't a brief onboarding phase—it's ongoing. Managers continue to do engineering work, ship PRs to production, and stay deeply involved in the technical work. This serves multiple purposes: it keeps managers grounded in the actual problems engineers face, it demonstrates that management is a complement to engineering rather than a separation from it, and it ensures managers have credibility when discussing technical decisions.
Second, she emphasizes what she calls "the hypothesis of what you're trying to solve." Engineers aren't just told to implement features. They're asked: what problem are we solving? What's our hypothesis about how users will behave? How will we measure success? This transforms engineering from task execution into problem-solving.
Third, Fiona maintains extremely accessible feedback channels. She has Slack channels dedicated to customer feedback, product feedback, and team feedback. Every morning, as part of her routine, she reviews these channels and looks for opportunities to help unblock issues or identify patterns. With Claude's help through routines, she can now automate much of this pattern-finding work.
The Role of Growth Mindset
Fiona repeatedly emphasizes growth mindset as essential for thriving in the AI-transformed engineering world. This isn't about being positive or optimistic. It's about understanding that what made you successful in the past may not serve you going forward.
For example, many experienced engineers built their reputations on deep expertise in specific domains: "I'm the database optimization expert" or "I'm the systems programmer who understands lock-free algorithms." AI doesn't eliminate the value of this knowledge, but it does change how it's applied. The engineer who insists on manually optimizing database queries before trying an AI-generated solution may waste weeks of work. The engineer who approaches AI tools with curiosity—"What can I learn here? How can I combine this with what I know?"—opens up new possibilities.
Growth mindset also helps engineers navigate the fear that AI creates. Many engineers worry about job security or feel threatened by AI coding capabilities. Fiona's advice is direct: lean into the fear and ask, "What's within my control?" You can't control whether AI gets more powerful. You can control whether you learn to use these tools, whether you stay curious, and whether you adapt your approach.
Managing Fear and Resistance in the AI Transition
Not every engineer is thriving in this new world. Fiona observes a clear bifurcation: engineers embracing AI are excelling and experiencing remarkable productivity gains, while engineers resisting or fighting AI are frustrated, overwhelmed, and struggling.
Understanding the Root of Resistance
The resistance often stems from fear, though it's not always consciously acknowledged. Fear takes several forms:
Fear of job security—if AI can write code, why do we need engineers? Fear of skill erosion—if I'm not writing code, am I still a "real" engineer? Fear of irrelevance—I spent 20 years becoming expert in X, and now that seems less important. Fear of the unknown—I don't understand these AI tools, and I feel like I'm losing control.
These fears aren't irrational. There's real uncertainty about how the engineering profession will evolve. The job market is volatile. The rate of change is unprecedented.
Fiona's Framework for Managing Fear
Her advice: identify what's within your control and take action there. You can't control the pace of AI development. You can't control whether your company adopts Claude Code. But you can control your response.
What's within your control:
- Learning the tools that exist
- Practicing with AI coding assistants
- Staying curious about how they work
- Finding specific problems they solve well
- Identifying areas where you still add essential value
- Building relationships with teammates
- Focusing on outcomes rather than process
She shares a powerful personal example: as a high school student in Canada planning to study engineering, she faced financial uncertainty. She couldn't control whether she could afford university. But she could control whether she took a job as a bank teller to save money. That one action—entirely within her control—resolved the core problem.
The "Cave You Fear Contains the Treasure You Seek"
Fiona references a quote that encapsulates this approach: the thing that scares you most is usually pointing you toward the biggest opportunity for growth. The engineer who's most frightened of AI is sitting on a goldmine of opportunity if they lean in rather than resist.
She emphasizes that this doesn't mean recklessly pursuing every scary thing. You don't jump off a cliff. But in career development, in learning, in professional growth, the scary direction is usually the direction of greatest opportunity.
The Future of the Engineering Role: Builders, Verification Experts, and Verification Frameworks
As coding becomes increasingly automated, the engineering role is splitting into distinct profiles. Fiona has shifted her hiring approach based on these emerging specializations.
The Two Profiles of AI-Era Engineers
Profile 1: Creative Builders with Product Sense
These are engineers who combine technical capability with strong product intuition. They understand users. They have ideas about what should be built. They iterate based on feedback. They care deeply about whether the product delights people.
Product sense is critical because, with AI handling the mechanical coding, the bottleneck is now "what should we build?" Engineers with strong product sense can drive their own features from idea to launch. They don't wait for product managers to specify requirements. They observe user behavior, identify gaps, propose solutions, and iterate based on feedback.
In the Claude Code and Cowork environment, these are the engineers shipping high-impact features. They might not be the deepest systems experts, but they have the vision and iteration capability to drive product development.
Profile 2: Deep Systems Experts
The other critical profile is deep subject matter expertise in hard problems. These are engineers who understand distributed systems, infrastructure, security, performance, or domain-specific complexity. These are the areas where AI still needs human guidance, verification, and expertise.
When Fiona joined the Claude Code team, she initially saw an abundance of product generalists but realized they were missing people with deep systems backgrounds. This became a focus area. Because coding is no longer the bottleneck, you can have fewer people working on hard infrastructure problems—but they need to be genuinely expert.
The key phrase Fiona uses is "trust but verify." Claude can generate plausible-looking code for infrastructure changes. But you need expert humans who can review it, understand the implications, catch subtle bugs that might cause data loss or security issues, and ensure the approach is sound.
The Blurring of Roles
Something else is happening: roles are blurring. Product managers are increasingly writing code with Claude. Designers are implementing design features. Engineers are handling product strategy and user research. The boundary between roles isn't disappearing, but it's becoming much more fluid.
This creates opportunities but also challenges. When everyone can code, how do you maintain code quality? When engineers are making product decisions, how do you ensure coherence? This is where frameworks become essential.
Verification Frameworks: The New Quality Gatekeeper
As everyone becomes capable of writing code through AI, verification becomes the critical quality control mechanism.
From Preventative to Verification-Based Quality
Traditional software development emphasized preventative approaches: code review before merging, design review before building, specifications before implementation. These approaches assume that preventing bad code from being written is more efficient than finding and fixing bad code later.
With AI-generated code at scale, this assumption flips. You can't review everything deeply. Instead, you need frameworks that specify what "good" looks like, and then verify that the code meets those specifications.
How Specification-Based Verification Works
Fiona's approach involves several layers:
First, write specifications or standards. This might be "all database queries must use prepared statements," or "all user-facing text must be run through i18n," or "all API endpoints must document their error cases."
Second, store these specifications in the repository. They're living documents that the team maintains.
Third, use Claude to review code against these specifications. Claude is very good at taking a specification and checking whether code conforms to it. With a clear framework, Claude can catch violations that would slip through in casual code review.
This is the evolution of test-driven development. In traditional TDD, you write tests first, then code. With AI, Claude can write tests for you. Fiona describes the joy of saying, "Help me write a test first, make sure it fails, then fix the code," and having Claude automate what used to be tedious work.
The Quality Verification Dashboard
Fiona has implemented a monthly review process where her team looks at all the code shipped, analyzes it through Claude for patterns and issues, and identifies themes. They categorize issues as "bad" (severe, unrecoverable errors) or "sad" (less critical but frustrating). This categorization helps them understand whether they're seeing systemic issues or isolated incidents.
They also maintain feedback channels that aggregate customer feedback from all sources: emails, social media, customer messages, team members' personal conversations. Claude reviews these channels and surfaces themes and patterns.
The combination of specification verification + code review verification + customer feedback analysis creates a robust quality system that can scale with the 8x productivity increase.
The Rise of Asynchronous, Agent-Based Work: Routines and the Future
One of the most interesting technical innovations Fiona discusses is the evolution toward asynchronous work through routines.
From Synchronous Prompting to Automated Routines
Traditionally, AI agents work synchronously: you write a prompt, the agent responds, you write another prompt based on the response. This is interactive and immediate but requires constant human attention.
Fiona is shifting her work toward "routines"—essentially cron jobs that run autonomously. For example, a routine might:
- Run every morning at 5 AM
- Check Slack feedback channels for new messages
- Analyze them for themes
- Identify bugs or issues mentioned
- Generate candidate fixes
- Create pull requests with those fixes
- Alert the manager
The manager then wakes up and sees: "Here are 5 candidate fixes based on customer feedback. Here are the PRs. Review and merge if they look good."
This is profoundly different from traditional work. Previously, managers would manually scan feedback channels, think about what to do, and then assign work. Now the routine does that thinking and even the implementation, and the manager does final verification and approval.
The Implications of Async Work
This shift toward asynchronous agent work has several implications:
First, context switching increases paradoxically. As a manager you're no longer in the flow state of deep work or synchronous problem-solving. Instead, you're constantly handling async notifications and reviewing work from multiple agents. This creates cognitive load around context switching.
Second, the nature of management changes. Rather than directing engineers what to do, managers set up frameworks and routines, then verify and guide the autonomous agents. It's less about telling people what to do and more about designing systems that make good decisions.
Third, the human elements of work—collaboration, brainstorming, creative problem-solving—become more valuable precisely because they're less common. If everything were fully autonomous agents, you'd lose the serendipitous insights from human collaboration.
Fiona recognizes this and has implemented "pair-wise programming lunches" where engineers work together, watching each other's approaches, learning different workflows, and maintaining human connection despite spending most of their time working with AI agents.
The Long-Term Evolution
Looking forward, Fiona expects this async agent approach to expand. Not just manager routines, but routines for all kinds of work. Teams might have standing routines for:
- Monitoring product health metrics
- Analyzing crash reports and identifying patterns
- Generating candidate solutions for known issue categories
- Automating routine maintenance work
- Identifying and flagging edge cases
The engineering team increasingly becomes a combination of human judgment (What's important? Is this right?) and AI execution (Let me implement that at scale).
Building Product-Minded Engineers and the Dogfooding Advantage
Fiona repeatedly emphasizes product obsession as perhaps the most important trait of her best engineers. This isn't about being a cheerleader for the product. It's about deeply understanding how users experience it and using that understanding to drive improvements.
The Power of Dogfooding
Dogfooding—using the product you build—is not new. But Fiona takes it further than most leaders. She explicitly allocates time to actually use Claude Code and Cowork in her workflow. She catches bugs, experiences friction, and provides feedback directly.
She shares an example: when working on Facebook Marketplace, she listed a MacBook Air for sale on the product. Within minutes, she encountered a scam vector she'd never thought about. This real experience was more valuable than pages of user research reports.
Similarly, when supporting VR and AR teams, she would personally set up and use the hardware at specific floor heights, which led to discovering obscure but reproducible bugs that became priorities for the team to fix.
Why Product Obsession Matters in the AI Era
As everything becomes possible through AI, product sense becomes even more critical. The question "Should we build this?" becomes more important than "Can we build this?" without strong product intuition, you can end up shipping enormous amounts of code that doesn't meaningfully improve user experience.
Product-minded engineers:
- Spend time in customer conversations
- Actively use the product
- Notice friction points and subtle UX issues
- Think about the entire user journey, not just the feature they're implementing
- Iterate based on feedback
- Care about whether their work actually matters
Fiona's Approach to Building Product Sense
For Fiona's team, this involves several practices:
First, make product obsession explicit. It's not optional or nice-to-have. Understanding your product is core to your job.
Second, create structured feedback channels. Slack channels dedicated to various feedback sources. Daily review of feedback. It becomes a routine part of the workday.
Third, encourage participation in user conversations. Help engineers interact with customers, see how they use the product, understand their pain points.
Fourth, use data, but don't worship it. Fiona emphasizes that anecdotal evidence and personal experience often trump dashboards. When metrics showed Facebook Marketplace wasn't performing in Chile, the real answer came from visiting and discovering that local LTE speeds were too slow to load the feed. Metrics alone wouldn't have surfaced that.
The Role Transformation Beyond Engineering
While engineering has changed most dramatically, adjacent roles are also transforming.
Product Management Transformation
Product managers are no longer bottlenecked by engineering capacity. A PM can now write code directly using Claude. This removes a major source of friction in product development: the communication gap between product vision and engineering implementation.
Fiona's PMs now roll up their sleeves and implement features when engineering is busy with other priorities. This changes the PM role from "request + wait" to "vision + execute."
Design and Verification as Emerging Opportunities
Fiona identifies design and data science as the next frontiers for AI-enabled productivity. Design work is increasingly being augmented by AI. Data science is already transforming—many analyses are now generated by AI, and the specialist's role is increasingly verification and interpretation rather than analysis generation.
This suggests a broader pattern: every role adjacent to engineering is moving through the same transition. First, AI does the mechanical work. Then, the specialist's role becomes judgment, verification, and interpretation. The role doesn't disappear; it transforms.
Growing the Business Without Destroying Culture
Anthropic is hiring engineers aggressively. The Claude Code and Cowork teams are growing rapidly. This creates a challenge that keeps Fiona up at night: how do you maintain culture and connection as you scale?
The Non-Negotiable: One Team Mentality
Fiona describes her team culture with a specific principle: "one team." This means:
- When approaching the finish line on a goal, you look back to see if anyone from your team needs help
- Finish together, not individually
- Diverse perspectives are valued
- Open, honest debates are encouraged
As you grow from 20 people to 100 people to 500 people, maintaining this "one team" mentality becomes harder. New people don't inherit the culture; they create new micro-cultures. Silos form. The natural human tendency is for subgroups to develop.
Intentional Culture Practices
Fiona's approach involves several intentional practices:
First, regular all-hands or team meetings where culture is explicitly discussed, not just product metrics. Culture is a living thing that requires attention.
Second, listening sessions with team members, especially senior engineers and long-tenured people who remember earlier versions of the culture and can spot drift.
Third, permissioning people to "make new mistakes" rather than repeating old processes. She asks regularly: does this process still serve its purpose? If not, can we eliminate it?
Fourth, one-on-one meetings with direct reports are sacred. She prioritizes them even when it means juggling other obligations. These conversations are where she learns what's really going on and what people need.
The Healthy Problem Perspective
Fiona references advice from Sheryl Sandberg: scaling culture is a problem you want to have. It means you're growing and succeeding. The alternative—not growing, having nothing worth protecting—is worse.
This doesn't make the challenge easier, but it provides perspective. The work of maintaining culture through rapid growth is worth doing because it means the organization is valuable.
The Hiring Paradox: Why Engineering Demand is Skyrocketing
One might expect that as AI coding becomes more powerful, demand for engineers would decline. The opposite is happening. Anthropic, OpenAI, and other AI companies are hiring engineers at unprecedented rates. Why?
The Verification and Trust Problem
The core reason: someone still needs to ensure the AI-generated code is correct. As coding becomes cheaper and faster, the bottleneck shifts to verification, oversight, and ensuring quality at scale. This actually increases demand for experienced engineers, especially those with deep systems knowledge.
The Opportunity Expansion Effect
Additionally, as coding becomes cheaper, the opportunity space expands. More ambitious projects become feasible. Teams that previously couldn't afford to build certain things now can, because the execution cost dropped from "would take 6 months and a team of 5" to "would take 2 weeks and a team of 2."
This is similar to historical precedent: the PC revolution didn't kill computer science; it exploded the number of programs being written and the people writing them. The democratization of computing created vastly more demand, not less.
The Skills Question: Training the Next Generation
The one area Fiona expresses genuine uncertainty is how to train the next generation of engineers. Engineering education evolved around the assumption that you learn by writing a lot of code. You practice. You struggle. You gradually internalize patterns and principles.
But if AI is doing much of the coding, how do junior engineers gain the foundational understanding they need? How do they develop intuition about performance, about architecture, about what works and what doesn't?
Fiona speculates about apprenticeship or fellowship models rather than traditional bootcamps or university education. She emphasizes the importance of "double-clicking" on dependencies—understanding the layer beneath what you're working on, not just taking it for granted.
She references a manager who started their career with punch cards and is now happily building with Claude Code. The fact that someone could learn across that full spectrum suggests that new engineers might learn differently than they currently do, but the fundamental principles might remain.
Personal Philosophy: From Art to Code to Leadership
Fiona's path into engineering reveals something important about how she approaches problems and people.
The Artist's Perspective
She initially wanted to be a visual artist. She loved the creative expression, the ability to have an idea and bring it to life. She discovered that programming offered the same joy at a different scale. With art, you can create a drawing or sculpture. With code, you can create experiences for millions of people.
This artistic sensibility shows up throughout her leadership approach. She thinks about delightful experiences. She notices beauty and craft. She uses metaphors like "compiler" and "executable" when discussing knitting, because she sees the underlying structure and logic in creative pursuits.
The Immigrant Perspective
Growing up in Ontario after immigrating from Hong Kong, not speaking English initially, gave her perspective on what it means to face barriers and adapt. Her grandmother learned English through immersion and community (a yarn shop that became a knitting circle). Fiona learned similar lessons.
This shapes her approach to helping others adopt AI. She doesn't think everyone should be forced to learn these tools or feel bad about struggling. She thinks about finding the right community, the right use case, the right person to learn from. Meeting people where they are, showing them something that works for their specific situation.
Growth Through Scary Challenges
Fiona has repeatedly taken on scary challenges: learning entirely new platforms at Microsoft and Meta, building entirely new business lines (Marketplace, then AR glasses), switching to Anthropic as an IC despite being a very senior leader. Each time, she's leaned into the fear rather than avoiding it.
Her philosophy: the thing that scares you most is usually pointing you toward the biggest growth opportunity. Do something scary once in a while. Learn by doing things that stretch you beyond your current competence.
Practical Advice for Engineering Teams Today
Based on Fiona's experience and philosophy, several concrete recommendations emerge for engineering teams navigating the AI transition:
For Individual Engineers:
Embrace the tools. Don't resist Claude Code or similar tools. Use them. Get proficient. Notice how they work best. Where do they generate good code? Where do you need to verify carefully?
Develop product sense. Use the product you're building. Notice friction. Talk to customers. Understand what delights people and what frustrates them. This becomes your primary value add as AI automates coding.
Double-click on dependencies. When AI generates code that depends on X, take time to understand X. What assumptions is it making? What could break it? This understanding becomes more valuable as mechanical coding becomes automated.
Lean into fear. If AI makes you nervous, that's where your growth is. Take an hour to learn Claude Code. Build something small. Realize that you can still add value. Approach it with curiosity rather than defensiveness.
Keep learning. The tools change fast. The capabilities expand rapidly. What doesn't work today might work next month. Update your assumptions frequently.
For Engineering Managers:
Shift to high agency, high accountability. Give engineers freedom to pursue ideas and make decisions. Hold them accountable for outcomes. Stop managing process; start managing results.
Be an IC part-time. Keep shipping code. Keep using the tools. Stay grounded in what engineers actually experience. This keeps your advice grounded and credible.
Build feedback loops. Create channels for customer feedback, product feedback, and team feedback. Review this feedback regularly. Use it to spot patterns and identify opportunities.
Implement verification frameworks. Rather than trying to prevent bad code through review, create specifications for what good looks like and verify against them. This scales better.
Focus on outcomes, not motion. Measure whether code shipped actually improves product outcomes. Don't mistake metrics like "PRs opened" or "lines of code" for actual value. "Don't mistake motion for progress."
Invest in product sense. Hire for it. Develop it in your team. Create time and space for engineers to use the product, talk to customers, and think about user experience.
For Engineering Leaders:
Hire the right profiles. You need creative builders with product sense and deep systems experts for hard problems. Don't try to hire everyone for everything.
Watch for skill bottlenecks. As coding scales, where is real constraint? For most teams, it's moving to verification, architecture review, and decision-making about what to build.
Maintain culture intentionally. Culture doesn't scale automatically. As you grow, be explicit about values and principles. Create space for people to connect.
Listen deeply. One-on-ones with direct reports matter. Listening sessions with broader teams matter. What you hear in these conversations usually matters more than metrics.
Stay close to the product. Use it. Notice friction. Participate in customer conversations. This keeps you grounded in what's real versus what dashboards claim.
Help people navigate fear. Many people are frightened by the pace of change. Help them understand that fear is pointing toward opportunity. Help them take action on what's within their control.
The Future: Unanswered Questions and Opportunities
Despite her experience and insight, Fiona acknowledges significant open questions about the future of engineering:
How do we train the next generation? Traditional programming education assumes lots of manual coding. What does learning look like when that assumption is gone?
How do we maintain culture at scale? Anthropic is growing incredibly fast. How do you preserve what makes the team special?
How do we balance speed and quality? With 8x productivity, how do we ensure we're not shipping sloppy work?
How do we handle context switching? As async work increases, context switching becomes more of a burden. How do we mitigate this?
What skills will still matter? As capabilities improve, what uniquely human skills become more valuable?
How do we bring people along? There's a growing gap between people embracing AI and thriving vs. people resisting and struggling. How do we help people make the transition?
These questions don't have settled answers. The field is still figuring them out. But thinking deeply about these questions is how you stay ahead of the transformation.
Conclusion
The engineering profession is undergoing transformation comparable to the introduction of IDEs, the internet, or the shift to cloud computing. But this transformation is accelerating faster than any previous one. Within a single year, the role has changed so dramatically that engineers from different cohorts sometimes don't recognize the role they share.
Fiona Fung's perspective, drawn from 25+ years of engineering and leadership across Microsoft, Meta, and now Anthropic, offers crucial guidance through this transition. Her core insights repeat in different forms:
Lean into what scares you. The thing you're most afraid of—that AI will make your skills irrelevant, that you'll lose the satisfaction of flow state, that the future is uncertain—is pointing you toward the biggest opportunity for growth. Face it with curiosity rather than defensiveness.
Build high agency, high accountability. Give people freedom to pursue their vision. Hold them responsible for outcomes. This unleashes ambition while maintaining quality and coherence.
Keep the human elements. Pair programming lunches, one-on-ones, customer conversations, the joy of delightful design—these become more valuable, not less valuable, in the AI era. Protect them intentionally.
Stay close to the product. Use what you build. Notice friction. Talk to people who use it. Let that ground your decisions in reality rather than in metrics or theory.
Help people adapt. There will be people in your organization, your family, your network who are struggling with these changes. Help them understand what's within their control. Show them use cases that matter for them. Meet them where they are with kindness.
The engineers who will thrive in the next era are those who see AI not as a threat to engineering but as a liberation from the bottleneck of coding. They see it as an expansion of what's possible and a transformation of what makes an engineer valuable. They combine technical depth with product sense, creativity with accountability, ambitious vision with rigorous verification.
Building these kinds of teams—teams with high agency, high accountability, strong product sense, and deep technical capability—is the work of engineering leadership in the AI era. Fiona Fung's experience and philosophy offer a roadmap for how to do it.
Original source: Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)
powered by osmu.app