How to Manage an Engineering Team in the Age of AI

Fiona Fung spoke for 28 minutes at an Anthropic conference, discussing how to manage an engineering team in the age of AI.

When she prepared these slides, Anthropic had not yet released the “Routines” feature.

Three weeks later, Routines went live. This is a feature that allows Claude Code to run tasks automatically in the cloud on a schedule, without needing to keep a terminal open locally. By the time she actually took the stage at the Code with Claude 2026 conference, several of her slides were already outdated.

Fiona Fung is the Engineering and Product Lead for the Claude Code and Cowork product lines at Anthropic. Prior to this, she spent 12 years at Microsoft (starting with Visual Studio), then moved to Meta to lead engineering teams for Facebook Marketplace and Instagram, joining Anthropic in September 2025. Although her talk was under 30 minutes and the topic sounded ordinary—“How to manage an engineering team in the age of AI”—she focused entirely on the pitfalls encountered by the Claude Code team over the past year, the broken old rules, and the unresolved real-world challenges, avoiding abstract platitudes.

Original video link: https://www.youtube.com/watch?v=igO8iyca2_g

Key Takeaways

• The bottleneck in software engineering has shifted from “slow coding” to verification, review, cross-functional collaboration, and security. Past processes were designed based on the assumption that “writing code is expensive.” Now that “writing code is nearly free,” processes must be entirely restructured.

• Processes rarely die out naturally; organizations tend to layer on SLAs, regulations, and reviews. The first step in transforming an engineering team with AI is to explicitly allow people to cut outdated processes.

• The way technical debates are conducted has changed. In the past, you’d pull people into a whiteboard room to draw architecture diagrams. Now, you have Claude generate three PRs simultaneously and discuss the code alongside the actual impact on APIs.

• In the Claude Code team, Claude is involved in every PR. The question “Who exactly wrote this code?” is gradually losing its meaning.

• Managers must start as first-line Individual Contributors (ICs). Fiona held firmly to this principle when hiring; recruiters initially couldn’t understand it: “Who would want a manager to go back to writing code first?” Her response was blunt: “If they’re not willing, it’s better to part ways early.”

• The organization strives to be flat, with all sub-teams sharing a single team mission. The reasoning is simple: when goals change, more hierarchy leads to greater alignment loss; flatness means agility.

• Code is the only “source of truth,” not design documents. If specs must be retained, commit them into the codebase and let Claude verify consistency between the code and the documentation.

• Measure effectiveness using three metrics: onboarding time for new hires, PR lifecycle, and the ratio of commits assisted by Claude. However, she warned: do not obsess over “how much code is written by AI”—that is a vanity metric. The key is product quality and reliability.

[1] The Industry Has Been Reshaped Twice in Twenty Years

At the start of her talk, Fiona pulled the timeline back to the early 2000s. She was working on Visual Studio 2005 at Microsoft—one of the world’s mainstream development tools. Back then, software was distributed via CDs (or floppy disks, even earlier). Because software had to go through a manufacturing line for disc pressing, packaging, and retail distribution, every version had a rigid release mainline.

Then the internet arrived, shifting distribution from CDs to online delivery, disrupting the engineering rhythm. Now it’s AI’s turn, but this time, it’s not just the release rhythm changing—it’s the act of “writing code” itself.

What served you in the past may no longer serve you.

She returned to this point repeatedly. For years, engineering rhythms were built around an assumption: writing code is expensive, writing tests is expensive, refactoring is expensive. From Waterfall to Agile, every methodology was about allocating this scarce resource.

Last year, she was still complaining about “vibe coding” (programming by feel, a term popularized by OpenAI co-founder Andrej Karpathy in early 2025): “Why are there so many hardcoded constants? Engineering practices are poor.” A year later, models have become capable of much more. This breakthrough goes far beyond simple “speedup”; it represents an order-of-magnitude jump in overall throughput.

[2] When Coding Is No Longer the Bottleneck, Where Are the New Bottlenecks?

The current bottlenecks for the Claude Code team are verification, review, cross-functional collaboration, and security.

As code volume increased, the most common question she received from other engineering leaders was: “How can humans possibly review all this code?” She also wondered how to calculate maintenance costs. The cost of generating code is nearly zero, but maintenance costs do not drop to zero alongside it.

Note: The phrase “building Claude Code with Claude Code” mentioned in the talk is an open practice at Anthropic. Boris Cherny has previously discussed in multiple interviews how he used Claude Code to build Cowork, a desktop agent for non-technical users, in 10 days. This is an engineering reality, not a rhetorical device.

She listed a set of old processes that are “quietly becoming obsolete”: six-month product roadmaps, cumbersome scheduling meetings, strict ownership of code, marathon code review meetings, traditional step-by-step team structures, knowledge base sharing, and lengthy onboarding training. These were all historical artifacts forced upon teams because “development costs were too high” in the past.

Processes rarely kill themselves. We tend to just layer more and more processes on top.

She gave a painful example: In a previous team, there were so many SLAs (Service Level Agreements) that a large spreadsheet was needed to force-prioritize items, just so engineers could figure out which issues to respond to first. She had long felt this excessive layering needed cleaning up, but she didn’t truly commit to acting on it until joining Anthropic.

[3] Do Less: Six-Month Roadmaps, Design Docs, Product Reviews

When she first joined Claude Code, she asked, “Don’t we need a six-month roadmap?”

They wrote one. It was useful for the first three months, but by the time the New Year passed, it was half-obsolete. She now uses the term JIT planning (Just-In-Time planning), borrowing from the just-in-time compilation concept in programming: figure out what to do only when it’s needed. Since the cost of prototyping has approached zero, the leverage of “planning ahead” has disappeared.

Design documents have also been drastically reduced. The default medium of discussion in the Claude Code team shifted from “write a doc first” to “open a PR first.” If you have an idea, build it directly. Product review meetings are also held less frequently, because the product form changes too quickly. Instead of reviewing mocks, they push internal builds to all Anthropic employees (she calls this “ant-fooding,” a pun on the company name Anthropic containing “ant”) and then to external users to see how they use it.

[4] Do More: Verification, Shifting Quality Assurance Left

She wants the team to double down on verification, a concept known as shift left. In a traditional software pipeline, “left” is the source and “right” is delivery. This means shifting quality assurance from manual testing near the delivery end toward automation near the source.

Why is this becoming more important? Because role boundaries are blurring. Her designer colleagues are now submitting code. Fiona shared a small, real anxiety: Once she fixed a bug related to job resumes, and the next day, scanning Boris’s message feed, she saw someone in a group chat @-mentioning him to report a new bug. She described her feeling as “missing a heartbeat,” fearing she had caused the issue.

No one wants to take down a service because of their commit. In this high-throughput environment, this is a very real psychological burden. Traditional manual QA simply cannot keep up with such high code output rates, so quality assurance must rely earlier on automated mechanisms.

[5] The Way Technical Debates Are Conducted Has Changed: From Whiteboards to Three PRs

When she first joined the Claude Code team, she wanted to do a refactor to familiarize herself with the codebase. She had a technical disagreement with Boris and almost habitually said, “Come on, let’s go to the whiteboard room and draw it out.”

In the next second, she realized that she could instead have Claude generate three versions of the PR simultaneously, allowing direct comparison of the complete code implementations, even pulling up the impact on all callers. You can’t draw such an intuitive global perspective on a whiteboard, but code can provide it.

When building is cheap, arguing is expensive.

Her tone was particularly serious when making this judgment. She then reminded the audience: precisely because the cost of generating code approaches zero, team culture and baseline consensus have become even more critical.

It must never devolve into “whoever makes the last commit wins.” For example, someone staying up until 3 AM to sneak in code, or setting a scheduled task to cut it close to the release deadline—this is absolutely unacceptable. Precisely because code is no longer precious, horizontal alignment within the team requires clearer bottom lines.

[6] Code Review: What Claude Takes, What Humans Keep

Cat Wu had already discussed Claude’s ability to automatically review PRs in the keynote earlier in the day. Fiona’s perspective here is more specific: what to hand off to Claude, and what to keep for humans.

Note: Cat Wu is the Product Lead for Claude Code, co-leading the product direction alongside Boris Cherny.

Hand off to Claude: Style checks, lint deduplication, responding to code review comments, catching common bugs, and completing unit tests. She said Claude is now very good at “managing” PRs, usually finishing most of the grunt work before humans need to step in.

Three categories still require human intervention: Legal and compliance reviews, due to risk tolerance; boundary confirmation for security-sensitive code, because the cost of vulnerabilities is too high; and product experience “sense” (intuition) and taste, which remains a difficult threshold for current large models to cross.

She gave a lighthearted example for the third category. She has a small hobby of decorating Claude’s terminal avatar for holidays. For Christmas, she wanted to turn Claude into a snowman using ASCII art. She sent the result to a designer colleague for feedback, and their one-sentence response was: “You drew him as Mr. Peanut.”

Note: Mr. Peanut is the mascot for the American snack brand Planters, wearing a top hat and monocle, with a silhouette somewhat similar to a snowman.

She ultimately went with a simple solution: Ice blue + snowflakes. She used this story to illustrate the significance of product sense: abstract judgment is hard to automate.

[7] Code Boundaries Are Blurring, Role Division Is Being Reshuffled

In the Claude Code team, Claude is involved in almost every PR. The question “Who exactly wrote this code?” is becoming absurd, or even meaningless.

Fiona suggests not dwelling on this superficiality, but digging deeper into what you truly want to understand: Whose changes triggered the bug? Who has enough background context to explain technical details to customers? Who understands the ins and outs of this code module better? If you ask these more specific questions, you’ll often find better automated paths to answer them. For instance, she used to have a habit of brewing coffee every morning and using Claude Code to connect to customer feedback channels to generate summary digests. Now, this action has been orchestrated into a Routines automated task, saving even the manual command typing.

Note: Routines is a feature of Claude Code that allows setting up scheduled or triggered automated tasks. During the month Fiona prepared this talk, this feature had just launched, requiring updates even to her own slide content.

This blurring of roles is bidirectional. On one hand, non-technical staff are rolling up their sleeves to write code; the PMs in the Claude Code team are submitting real PRs. On the other hand, engineers are being encouraged to step out of their silos and take on tasks traditionally belonging to other roles. Fiona used herself as an example: She originally wanted to optimize user survey questions for Claude Code but couldn’t find a content designer. In the past, she might have spent time nitpicking wording with the content team. Now, she uses Claude directly as a copywriting partner. She self-deprecatingly noted that as a typical engineer, “I’m a mess when it comes to refining copy.”

In hiring, the Claude Code team focuses on two types of people. One is creative builders with a product sense: curious, eager to build products to solve problems, and willing to iterate on experience. The other is deep system experts: when building Claude Code Remote, they realized a lack of people with distributed systems experience. What she no longer prioritizes is raw coding throughput, as models have leveled that playing field.

[8] Organizational Structure: As Flat as Possible, Managers Start as ICs

When Anthropic hired her for Claude Code, the default structure was “10 ICs per 1 manager, nested downward.” Fiona didn’t want that.

She wants it as flat as possible. The Claude Code and Cowork lines share only one team mission, rather than letting each subgroup set its own. The reason is practical: when missions change, multiple layers take a long time to align downward; flatness equals agility.

She also insists on one thing: All managers in the Claude Code team must start as ICs (Individual Contributors, i.e., frontline engineers).

Recruiters’ initial reaction was “You’re crazy,” implying no manager would want to start as an IC.

I expect every manager on the Claude Code team to start as an IC. This is what dogfooding on the team is about. This is my expectation. If someone isn’t interested, it’s better for us to separate early.

This applied to her as well. Her last push to production was in 2017; she only started writing code again after joining Anthropic. She said she tried to submit a PR once a year while at Meta, but internal tools changed so fast that a command she learned one year was obsolete the next.

Nowadays I don’t even remember git commands; I just always ask Claude to help me out with all of that.

[9] Step Back from Docs, Let Code Be the “Single Source of Truth”

The Claude Code team now treats code as the ultimate source of truth. For example, how does Fiona handle technical customer complaints now? She launches desktop Claude Code, mounts the local repo, and lets the large model find the logic directly in the code to answer. This approach completely eliminates a millennia-old legacy problem in the software industry: development documentation never staying in sync with code.

However, she specifically clarified that this experience is not universally applicable. If your team’s business requires complete requirement documentation, then logically, commit the specs into the codebase and let Claude cross-check whether the final running code matches the documentation.

When implementing these changes, Fiona distinguished between “must-unify” and “leave-to-subgroups.” Core principles that must be unified: Every team member must use Claude Code (including cross-functional partners, including Cowork); automate as much work as possible with Claude (internally called “claudify everything”); and explicitly allow killing old processes that no longer serve people.

For the last point, she gave a specific example. The Claude Code team used to have stand-up meetings, which changed to filling out weekly progress in a shared spreadsheet as the team grew. One day, looking at this huge table, she felt bored: because the information was already available where Claude could read it. Why not have Claude write a summary script and post it, allowing anyone to pull up status summaries for others at any time? This is infinitely better than chasing people to fill out forms.

However, the space left for subgroups to decide is also clear: Bug triage mechanisms, scheduling rhythms, on-call rotations, and which workflows have higher priority to be automated with Claude are all left for subgroups to decide.

[10] Three Observable Metrics, and One Warning

She didn’t reveal specific numbers, but highlighted three directions:

New hire ramp-up time has dropped significantly. Engineers, designers, and PMs in the new team are producing effective output much faster.

The PR lifecycle has shortened noticeably. She mentioned in passing that this is a metric worth digging into, because its changes reflect not only the team’s acceptance of AI tools, but sometimes also expose shortcomings in downstream infrastructure, such as CI (Continuous Integration) pipelines or product infrastructure environments that simply cannot handle the engineers’ current surge in commit rates.

The coverage ratio of commits involving Claude is increasing. In the atmosphere of the Claude Code team, having Claude assist with every commit is the default normal operation:

I don’t think I’ve seen a non-Claude-assisted commit in the last four months or so.

However, she explicitly added a warning in the metrics section: Do not just look at “how much code is generated by AI.” Press releases from various companies boast higher and higher percentages, but throughput itself is not the goal. You need to look back at what problems you are solving, and whether product quality and reliability are maintained.

[11] Three Things She Still Hasn’t Figured Out

At the end of her talk, Fiona admitted that there are three questions for which she still has no answers:

First, whether the traditional division of “iOS Team + Android Team” still makes sense after engineers can work cross-platform.

Second, how far automated review should go. The boundary of “trust but verify” will shift again with model upgrades. She referenced a talk earlier that day about model capabilities, meaning that how much review is handed off to Claude is not a one-time decision.

Third, how to ensure everyone feels a sense of contribution after roles blur. When engineers can create content, PMs can write code, and designers can fix bugs, traditional attribution of output becomes blurred, and designing for a sense of fairness is a new challenge.

Her final advice to the audience was actually very simple and direct:

Pick your noisiest workflow… and ask if it’s still really serving its purpose.

She used her own experience as a counterexample. When leading a previous team, there was an immovable weekly meeting with over 50 people squeezed into a large room. But upon closer inspection, Fiona found that besides those called on to report status (who would pretend to look up), everyone else was silently typing on their keyboards. She simply asked one question: “What are we even getting out of this meeting?” and it was unanimously agreed to cancel it on the spot.

Original video link: https://www.youtube.com/watch?v=igO8iyca2_g