How Anthropic runs an AI-native engineering org

In Brief

The first thing Fiona Fung noticed when she joined Anthropic to lead engineering on Claude Code wasn't that people were shipping code faster. It was that the old habits were in the way. Her talk at Anthropic's developer conference Code with Claude is a quick tour of what "quietly stopped working" once coding stopped being the expensive part. It isn't a recipe. It's a checklist for any team still organized as if writing code were the bottleneck.

---

The bottleneck that disappeared

For years, software engineering has been organized around one scarcity: engineering bandwidth. That's how much code a team can actually produce. This scarcity is what explains waterfall and agile, design docs before every line of code, "code ownership" questions about who wrote what, and rigid hiring formulas like ten engineers per manager. The whole apparatus was built because writing code was expensive.

That's not the case anymore, Fung says. On the Claude Code team, coding is rarely the slow part. The volume has exploded. People aren't producing a little more code; they're producing a lot more. And when a bottleneck disappears in one place, it pops up in another. The new bottlenecks on her team are verification (is this code actually correct?), code review (who has time to read it all?), cross-functional partners (legal, design, security), and the maintenance burden of an ever-growing codebase.

Fung takes a quick historical detour. She started her career in the early 2000s at Microsoft, shipping Visual Studio 2005. Back then, the deadline was everything. The code had to be ready in time for the factory to burn it onto CD-ROMs and put it into boxes. When internet distribution took over, the entire delivery model changed. She sees the AI shift the same way: not as a new tool, but as a change in what costs time and money. And changes in the cost structure force new processes.

What quietly stops working

Her favorite phrase in the talk is that old processes rarely kill themselves. They quietly stop working, without anyone noticing. We pile rule on rule, SLA on SLA (service-level agreements that set time limits), ritual on ritual. Only when someone dares to ask "does this still serve us?" does it become obvious how much has survived long past its expiration date.

She gives an example from an earlier team: so many overlapping SLAs that they had to rank which SLA mattered most when more than one was broken at the same time. That's the moment to ask whether the system makes sense at all. She asks the same question of her Claude Code team every few months: are our principles still right, or are we just clinging to them out of habit?

The six norms that had to be rewritten

1. Planning. Fung calls what they do JIT planning ("just-in-time," like JIT compilation): make just enough plan at just the right time. When she joined, the team made a six-month roadmap. It was good for three months, and then the situation had shifted so much they had to start over. Today they make smaller plans more often and spend the time prototyping rather than arguing on paper.

2. Technical debates. The temptation is still to take the discussion to a whiteboard. Fung tells the story of nearly doing this with Boris Cherny, who leads Claude Code, when they were deciding how to refactor an API. She stopped herself and let Claude generate three competing PRs (pull requests, the proposed code changes that wait for review). The debate got better. They didn't only see different implementations; they also saw how each one affected the code that called the API. "When building is cheap, arguing is expensive," she sums up.

3. Code review. This is where the philosophy gets concrete. Claude handles what Cat Wu, the team's product manager, presented in the morning keynote: styling, lint (automated style checking), feedback on the PR itself, small bugs, and adding tests. Humans are kept for what still needs expertise and taste: legal review, security-sensitive code, and product judgment. Fung shares a small funny story: she once asked Claude to give the terminal mascot a holiday theme, and her design partner laughed and said "you turned him into Mr. Peanut, not a snowman." That exact judgment ("does it look right?") is not something AI is finished with yet.

4. Hiring. Her recruiters wanted to use the classic 10:1 formula: ten engineers per manager, with many layers of management above. Fung said no. She wanted a flat organization, and she required every manager to start as an IC (individual contributor, an engineer who actually writes code). The recruiters thought she was crazy: "No manager wants a job where they have to write code first." Her answer: if no manager is willing to do it, it's better to find that out early. The reasoning is practical. Without being inside the codebase herself, she would never have understood what the team was building.

5. Team composition. Now that Claude does the raw coding volume, she no longer indexes on raw throughput. Two profiles get most of the space: creative builders with product sense (the ones who see a problem and just have to prototype the solution) and people with deep systems expertise (distributed systems, infrastructure). The latter group was thin on the ground when she joined. Generalists were plentiful, but "the hard part" needed reinforcement. At the same time, roles are getting more fluid: her designers and PMs now write code, and she herself asks Claude to help draft short survey questions when she lacks a content designer.

6. Source of truth. On the Claude Code team, the code is the source of truth, not the specs. She checks customer questions against the codebase by opening Claude Code locally and asking. That removes the classic gap where the documentation says one thing and the code does another. If a team has good specs, she suggests checking them into the same repo and using them as a reference Claude can compare the code against, not as a separate truth.

The three principles they live by

She closes with three rules that aren't up for negotiation on the team:

• Everyone uses Claude Code. Not just the engineers but also product managers, designers, and every cross-functional partner. They also use Claude Cowork, Anthropic's other product for cross-functional AI collaboration.
• Claudify everything you can. Every manual step is a candidate for automation. Fung's morning routine used to be manually opening the customer-feedback channel and asking Claude to summarize. When Anthropic launched Routines (an April 2026 feature that lets Claude Code jobs run on a schedule in the cloud without your laptop being on), that routine became automatic. She now wakes up to a finished summary every morning.
• Explicit permission to kill old processes. She tells the story of a team that held a weekly status meeting with 50 people in a large room, where everyone sat on their laptops except when it was their turn to give an update. She simply asked, "Why are we having this?" The whole room nodded. The meeting was canceled.

On Claude Code, the team swapped a weekly status spreadsheet for a Skill (a markdown file that tells Claude what role to take). It runs automatically and keeps everyone informed at the same time.

The numbers that actually changed

Fung can't give specific numbers from Anthropic, but she points to three metrics any team should watch when making these changes:

• Onboarding ramp-up time. How quickly a new engineer, designer, or PM starts contributing meaningfully. It has dropped dramatically.
• PR cycle time. How long a pull request takes from start to merge. If it doesn't shrink, the bottleneck may be somewhere else: for example, the infrastructure or the automated test pipeline can't keep up with the code volume.
• Share of Claude-assisted commits. On her team it's 100 percent. She hasn't seen a single non-Claude-assisted commit in the last four months.

She warns against making that last number the goal itself. Many companies announce that X percent of their code is AI-generated. That's nice, but the real question is whether users get a better product and whether quality holds. She and her team pay particular attention to reliability and quality. That's where the new scarcity sits.

What she still doesn't know

Fung ends with three open questions she carries with her:

When Claude lets engineers move smoothly between iOS and Android at low cost, does it still make sense to have separate iOS and Android teams? She doesn't know yet.

How far should you push automated review? "Trust but verify" is the rule, but how much verification is really needed? She points back to Daniela Amodei's keynote earlier the same day (Daniela is Anthropic's president and co-founder), which highlighted that the models keep getting better. The line between "safe to trust" and "must be checked" keeps moving.

And when roles are more fluid than before, how do you make sure everyone on the team feels equally productive? Designers who code, PMs who write tests, engineers who draft content surveys. It's fun when it works, but it takes a deliberate cultural contract.

What to take away

A single word: reconsider. Fung sends her audience home with a task. Pick your noisiest workflow (that meeting, that report, that ritual you yourself dread) and ask whether it still serves its original purpose. If the answer is no, you have two options: can you automate it with Claude, or can you just cut it?

It's tempting to read her talk as a celebration that AI has made coding cheap. But that's not the point. The point is that cheap coding is a consequence. The interesting part is that it frees up time and attention you now have to reallocate deliberately. If you don't do it yourself, that time just gets eaten by processes that have quietly stopped working.

---

Glossary

---

Sources and resources