How to Manage an Engineering Team in the AI EraAI 时代到底该怎么管一个工程团队

Fiona Fung spoke for 28 minutes at an Anthropic conference about how to run an engineering team in the AI era.

When she built these slides, Anthropic hadn't yet launched the Routines feature.

Three weeks later, Routines shipped. It's a feature that lets Claude Code run tasks automatically on a schedule in the cloud, without needing a terminal open locally the whole time. By the time she actually took the stage at Code with Claude 2026, several of her slides were already out of date.

Fiona Fung leads engineering and product for Anthropic's Claude Code and Cowork product lines. She previously spent twelve years at Microsoft (starting on Visual Studio), then went to Meta where she led engineering teams for Facebook Marketplace and Instagram, before joining Anthropic in September 2025. Her talk ran under thirty minutes and had a fairly ordinary-sounding title — "How to run an engineering team in the AI era" — but what she actually covered were the pitfalls the Claude Code team hit this past year, the old rules they broke, and the real challenges they still haven't figured out. No abstract platitudes.

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

Key takeaways

The bottleneck in software engineering used to be "writing code is slow"; now it has shifted to verification, review, cross-functional collaboration, and security. Old processes were all designed around the assumption that "writing code is expensive" — now that "writing code is nearly free," the processes all need to be rebuilt.

Processes almost never die on their own; organizations just keep stacking SLAs, rules, and reviews on top of each other. The first step in transforming an engineering team with AI is explicitly giving people permission to cut stale processes.

The way technical debates happen has changed. It used to mean pulling people into a whiteboard room to sketch architecture diagrams; now it means having Claude churn out three PRs at once, and discussing the code together with its actual blast radius on the API.

On the Claude Code team, Claude has a hand in every single PR. The question "who actually wrote this code?" has increasingly lost its meaning.

Managers must have come up through the ranks as individual contributors (ICs). Fiona held firm on this in hiring — the recruiter initially couldn't quite understand it: "which manager these days wants to go back to writing code?" Her response was blunt: "if you don't want to, let's part ways amicably now."

Keep the org as flat as possible, with all subteams sharing one team mission. The reasoning is simple: when the mission shifts, more layers mean more alignment loss — flat means agile.

Code is the single source of truth, not design docs. If you insist on keeping specs, commit the spec into the codebase and have Claude verify that the code and the docs actually match.

Effectiveness is measured on three metrics: time for a new hire to ramp up, the lifecycle of a PR, and the share of commits assisted by Claude. But she warned: don't fixate on "how much code was written by AI" — that's a vanity metric. What matters is product quality and reliability.

In twenty years, the industry has been reshaped twice

Fiona opened by rewinding to the early 2000s. Back then she was working on Visual Studio 2005 at Microsoft — one of the world's leading development tools. Software still shipped on CDs then (floppy disks before that). Because software had to go through a pipeline to be burned onto discs, boxed, and shipped to stores, every release had a fixed, unmovable release train.

Then the internet arrived, shifting distribution from CDs to online delivery, and upending engineering rhythms. Now it's AI's turn — but this time it's not just the release cadence that's changing, it's the act of writing code itself.

What worked before may no longer serve you now. ("What served you prior may not serve you any longer.")

She kept returning to this line throughout the talk. For years, engineering rhythms were built around one assumption: writing code is expensive, writing tests is expensive, refactoring is expensive. From waterfall to agile, every methodology was really about allocating that scarce resource.

Last year she was still complaining about vibe coding (coding by feel, a term coined by OpenAI co-founder Andrej Karpathy in early 2025): "why are magic constants everywhere, the engineering practices aren't good." A year later, models have become far more capable. This breakthrough goes well beyond simple "speedup" — overall throughput has jumped by an entire order of magnitude.

When coding is no longer the bottleneck, where are the new choke points

The Claude Code team's bottlenecks now are verification, review, cross-functional collaboration, and security.

With code volume up, the question other engineering leaders ask her most is: "how can anyone possibly review all this code?" She wonders about maintenance cost too. Generating code is now nearly free, but maintenance cost doesn't drop to zero along with it.

Note: the talk's mention of "building Claude Code using Claude Code" is a publicly stated practice at the company level at Anthropic. Boris Cherny has said in several interviews that he built Cowork — a desktop agent aimed at non-technical users — using Claude Code in 10 days. That's an engineering reality, not a figure of speech.

She listed a set of old processes that are quietly breaking down: six-month product roadmaps, tedious scheduling meetings, dividing up code ownership, marathon code review meetings, rigid traditional team structures, knowledge-base sharing, and lengthy new-hire onboarding. All of these were historical artifacts forced into existence by the fact that development used to be expensive.

Processes almost never kill themselves. What we're used to doing is just piling more and more processes on top. ("Rarely do processes kill themselves, we tend to just layer more and more and more processes on.")

She gave a painful example: at a previous team, there were so many SLAs (service-level agreements) that they needed a giant spreadsheet to rank them, just so engineers could figure out which one to prioritize. She'd long felt this kind of over-accumulation needed cleaning up, but it wasn't until she got to Anthropic that she actually did something about it.

Do less of: six-month roadmaps, design docs, product reviews

When she first joined Claude Code, she still asked: "don't we need a six-month roadmap?"

They wrote one. It was still useful for the first three months; by the new year, most of it had already changed. She now uses a term: jit planning (just-in-time planning), borrowing from the just-in-time compilation concept in programming — plan what you need only when you need it, because prototyping cost has gone to near zero, so the leverage of "planning ahead" has disappeared.

Design docs have also been cut way back. The default medium for discussion on the Claude Code team shifted from "write a doc first" to "send a PR first" — if you have an idea, just build it. Product reviews are held less often too, because the product shape changes too fast; rather than reviewing mockups, they'd rather push an internal build out to all of Anthropic (she calls this "ant-fooding," playing on the "ant" in Anthropic) and then to external users, and listen to how they actually use it.

Do more of: verification, pushing quality assurance upstream to the source

She wants the team to double down on verification — what she calls "shift left." In a traditional software pipeline, left is the source and right is delivery; the idea is to push quality assurance from manual testing near delivery back toward automation near the source.

Why does this matter now? Because role boundaries are blurring. Her designer colleagues are now also submitting code. Fiona shared a small, genuine moment of anxiety: she once fixed a bug related to job-application resumes, and the next day glanced at Boris's message feed and saw someone @-mentioning him to report a new bug. She said her heart skipped a beat, worried she was the one who'd broken it.

Nobody wants to be the one whose commit takes down the service. In this high-throughput environment, that's a very real psychological burden. Traditional manual QA simply can't keep up with this rate of code output, so quality assurance has to rely more heavily on automation earlier in the pipeline.

The way technical debates happen has changed: from the whiteboard to three PRs

When she first joined the Claude Code team, she wanted to do a refactor to get familiar with the codebase. She and Boris disagreed on the technical approach, and she almost reflexively said, "let's go hash it out on the whiteboard."

In the next instant she realized she could just have Claude churn out three versions of a PR at once, and compare the full implementations directly — even pull out the impact on every caller. A whiteboard can't give you that kind of concrete, global view, but code can.

When building is cheap, arguing is expensive. ("When building is cheap, arguing is expensive.")

Her tone turned notably serious as she made this point. She immediately reminded the audience: precisely because the cost of generating code trends toward zero, team culture and shared baseline norms matter more than ever.

It absolutely cannot devolve into "whoever commits last wins." For example, someone sneaking in a commit at 3am, or setting up a scheduled job to slip changes in right before a release deadline — that's completely unacceptable. Precisely because code is now cheap, the team needs even clearer shared boundaries to stay aligned.

Code review: what goes to Claude, what stays with humans

Cat Wu already covered Claude's automated PR-review capability in the morning keynote. Fiona's angle here is more concrete: what gets handed to Claude, and what still stays with humans.

Note: Cat Wu is the product lead for Claude Code, working alongside Boris Cherny to steer the product direction of Claude Code.

What gets handed to Claude: style checks, deduplicating lint issues, responding to code review comments, catching routine bugs, and filling in unit tests. She said Claude is now very good at "grooming" a PR, usually clearing out most of the grunt work before a human even picks it up.

Three kinds of work still need a human: legal and compliance review, since it involves risk exposure; boundary checks on security-sensitive code, because the cost of a vulnerability is too high; and product-experience sense and taste, which remains a threshold that's quite hard for current large models to clear.

For that third category she gave a lighthearted example. She has a small hobby: decorating Claude's terminal persona for holidays. For Christmas she wanted to turn Claude into a snowman, having Claude draw it in ASCII art. She sent the result to a designer colleague for feedback, who said simply: "you turned it into Mr. Peanut."

Note: Mr. Peanut is the mascot of the well-known American snack brand Planters, wearing a top hat and monocle, whose silhouette bears some resemblance to a snowman.

She ended up going with a simple approach: ice blue plus snowflakes. She used this story to illustrate the meaning of product sense: abstract judgment is hard to automate.

Code boundaries keep blurring, and roles are being reshuffled too

On the Claude Code team, Claude has a hand in nearly every PR. The question "who actually wrote this code?" is becoming absurd, even meaningless.

Fiona suggests not getting hung up on that surface-level question, and instead digging into what you actually want to know: whose change triggered the bug? Who has enough context to explain the technical details to a customer? Who understands the history and background of this code module best? If you ask these more specific follow-up questions, you'll usually find there are better automated paths to answering them. For instance, she used to have a habit: brew a cup of coffee each morning and use Claude Code to run a summary pass over the customer-feedback channel; now that's been folded into an automated Routines task, so she doesn't even have to type a command by hand anymore.

Note: Routines is a Claude Code feature that lets you set up scheduled or triggered automated tasks. It only launched about a month before Fiona prepared this talk, which meant even her own slide content needed updating because of it.

This blurring of roles is happening in both directions. On one side, people without a technical background are rolling up their sleeves and writing code — the PM on the Claude Code team genuinely submits PRs. On the other side, engineers are being pushed to step outside their own lane and pick up work traditionally owned by other roles. Fiona used herself as an example: she wanted to improve the Claude Code user survey but couldn't find a content designer. In the past she might have had to go back and forth endlessly with the content team over word choice; now she just uses Claude as her copywriting partner. She joked that, as a typical engineer, she is "an absolute mess when it comes to writing tight copy."

In hiring, the Claude Code team focuses on two types of people. One is the creative builder with product sense: intensely curious, sees a problem and wants to build a product to solve it, and keeps polishing the experience. The other is the deep systems expert: when the team was building Claude Code Remote, they found they lacked someone with distributed-systems experience. What she no longer weighs heavily is raw coding throughput — models have already leveled that playing field.

Org shape: as flat as possible, managers come up through IC roles

When Anthropic recruited her for Claude Code, they defaulted to a structure of "10 ICs per manager, nested downward from there." Fiona didn't want that.

What she wanted was as flat as possible. Claude Code and Cowork share a single team mission, rather than letting each subteam set its own. The reasoning is practical: when the mission changes, more layers means more time spent realigning everyone down the chain — flat means agile.

She also insisted on one rule: every manager on the Claude Code team had to first work as an IC (individual contributor, a frontline engineer).

Recruiters' initial reaction was "you're crazy" — meaning no manager would want to start as an IC first.

I want every manager on the Claude Code team to start out as an IC — that's what I expect from the team, and if someone isn't willing to accept that, it's better for us to part ways early. ("This is what dogfooding on the Claude Code team's about, this is what I expect and if someone's not interested it's better for us to do earlier separation.")

This rule applied to herself too. Her last time pushing code to production was in 2017, and she only started writing code again after joining Anthropic. She said that at Meta she still tried to submit one PR a year, but the internal tooling changed so fast that a command she learned one year would be obsolete the next.

Nowadays I don't even remember git commands — I just always ask Claude to help me out with all of that. ("Nowadays I don't even remember git commands, I just always ask Claude to help me out with all of that.")

Stepping documentation back and letting code become the "single source of truth"

The Claude Code team now treats code as the ultimate source of truth. For example, how does Fiona now respond to technical customer complaints? She directly launches the desktop version of Claude Code, mounts the local repo, and has the model find the logic straight from the code to answer. This approach completely eliminates a millennia-old problem in the software industry: development docs that are never in sync with the code.

But she specifically noted that this lesson isn't universally applicable. If your team's business requires complete requirements documentation, then it naturally makes sense to bring the spec into the codebase too, so Claude can cross-check whether the code that ends up running actually matches what the docs say.

In driving these changes, Fiona distinguished between what "must be unified" and what's "left to the team." A few core principles that must be unified: every team member uses Claude Code (including cross-functional partners, and Cowork too); automate as much work as possible with Claude (internally called "claudify everything"); explicitly allow killing off old processes that no longer serve people.

For the last point, she gave a concrete example. The Claude Code team used to hold standups, and as the team grew, switched to filling in weekly progress in a shared spreadsheet. One day, looking at this big spreadsheet, she found it utterly dull: since the information was already sitting somewhere Claude could read it, having Claude write a summary script and drop it there so anyone could pull anyone else's status summary at any time was, frankly, far better than nagging people to fill in a form.

That said, the room left for teams to decide for themselves is also very clear: things like bug triage mechanisms, scheduling cadence, who's on call and how, and even which workflows are high priority enough to adopt Claude first — all of that is left entirely up to each team.

Three observable metrics, and one warning

She didn't disclose specific numbers, but pointed to three directions:

New-hire ramp-up time has dropped significantly. Engineers, designers, and PMs produce meaningful output on new teams noticeably faster.

The time needed per PR has clearly shortened. She added in passing that this is actually a metric worth digging into, because its change doesn't just reflect how much your team has embraced AI tools — sometimes it also exposes weaknesses in downstream infrastructure, such as a CI (continuous integration) pipeline or product infrastructure environment that simply can't keep up with engineers' current surge in commit rate.

The proportion of commits involving Claude keeps rising. In the Claude Code team's culture, having every commit come with Claude involvement is now the default norm:

I don't think I've seen a non-Claude-assisted commit in probably the last four months or so. ("I don't think I've seen a non-Cloud assisted commit probably in the last four months or so.")

But in this section on metrics she explicitly added a warning: don't just look at "how much of the code was AI-generated." Every company's press releases keep pushing that percentage higher and higher, but throughput itself isn't the goal — you have to look back at what problem you're actually solving, and whether product quality and reliability are still being upheld.

Three things she hasn't figured out herself either

At the end of her talk, Fiona admitted there are three questions she still doesn't have answers to:

First, now that engineers can move across platforms, does the traditional split into "iOS team + Android team" still make sense?

Second, how far should automated review be pushed. Where's the boundary of "trust but verify" — and that boundary will keep shifting as models are upgraded. She mentioned an earlier talk that day about model capabilities, meaning how much review gets handed off to Claude isn't a decision you make once and for all.

Third, once roles become blurred, how do you make everyone feel an equal sense of accomplishment. 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 piece of advice to the audience was actually very plain and direct:

Pick out the workflow that's the most maddening, the most long-winded, and take a fresh look at who it's actually still serving. ("Pick your noisiest workflow … is it still really serving, what's the purpose of there.")

She used her own experience as a counterexample. When she used to lead a certain team, there was an unshakeable weekly meeting that packed more than fifty people into one big room. But looking closely, Fiona noticed that aside from the person called on to report status pretending to look up for a moment, everyone else was, without exception, heads-down typing on their keyboards. Later she simply asked one question — "what exactly are we even getting out of still holding this godforsaken meeting" — and it was unanimously approved on the spot to just cancel it right then and there.

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