Code with Claude 2026 · Talk Deep Dive

Running an AI-Native Engineering Org

When writing code is no longer the bottleneck, every process built around old cost assumptions must be rewritten.

Fiona Fung Dir. of Eng, Claude Code 2026-05-06 · SF 28:38 Watch Original Video →
Speaker

Fiona Fung

Leads engineering and product for Claude Code and Cowork, working closely with Boris Cherny (Claude Code lead) and Cat Wu (product lead). Since joining, she has been writing production code using Claude Code — "the first time in a long time I've personally shipped production-grade software."

2000s
IBMSoftware Dev
2005
MicrosoftVS 2005 · TypeScript 1.0
2015
MetaMarketplace · Quest 2 · Horizon OS
2025
AnthropicClaude Code & Cowork
Core Thesis

The Bottleneck Has Shifted

She compares AI's impact on software engineering to the 2000s shift from CD-ROM physical distribution to internet delivery: it's not just a new tool — the cost structure has changed. When the cost structure changes, every process must be rewritten.

She lived through the VS 2005 era of "racing to hit the disc-stamping deadline." That era's waterfall, design docs, and 10:1 manager ratios were all built around the premise that "engineering capacity is expensive."

Past: Engineering capacity was the bottleneck
Coding
85%
Other
15%
Now: The bottleneck has shifted
Coding
10%
Verification
30%
Review
25%
Cross-functional
20%
Maintenance
15%
Processes rarely kill themselves. We tend to just layer more and more processes on.Fiona Fung
Team Norms

Seven Norms That Must Be Rewritten

01JIT Planning
Drastically reduce upfront planning; no more long-cycle roadmaps

Before

6-month roadmaps, design doc before every line of code, extensive product reviews.

When she first joined, she built a 6-month roadmap. Three months later it was already obsolete.

Now

  • Discover idea → prototype → internal dogfood → collect feedback → ship publicly
  • "Design doc before every code" largely eliminated
  • Most discussions happen on PRs or prototypes
  • Design docs still needed for async discussions and specific scenarios
02Code Wins Arguments
Replace whiteboard debates with generated code

When she first joined and wanted to do an API refactor, she and Boris had a technical disagreement. Her instinct was to pull Boris into a meeting room and draw on whiteboards — then she stopped herself. She had Claude generate 3 competing PRs. The key benefit wasn't just seeing different implementations, but seeing each approach's impact on all API callers.

"When building is cheap, arguing is expensive."

Cultural safeguard: Cheap code actually demands better team alignment culture. "What totally won't fly is the last person who checks in wins. I'm going to stay up at 3 a.m. to submit this PR."

03Code Review — Human-AI Layering
Claude handles mechanical review; humans focus on judgment

Claude Handles

  • Style checks, lint
  • PR feedback requests
  • Catching and fixing small bugs before commit
  • Writing supplementary tests
  • "Babysitting PRs" — continuous oversight

Humans Retain

  • Legal review
  • Trust boundaries and security-sensitive code
  • Product intuition and aesthetic judgment

She asked Claude to turn the terminal mascot into a snowman. A designer looked at it and said: "You turned Claude into the Mr. Peanut character." Aesthetic judgment still requires humans.

"I would love for me to find bugs before any of you find it." — Shift Left verification
04Code Ownership — Double-Click to Dig Deeper
Stop fixating on "who wrote it" — ask about the real intent behind the question

All PRs are Claude-assisted, so "who wrote it" becomes blurry. What's more useful is double-clicking to ask:

  • Are you trying to find who introduced this regression?
  • Are you looking for a domain expert to answer a customer question?
  • Are you trying to get context about a piece of code?

She used to manually open the feedback channel every morning for Claude to summarize. Now it's automated with Routines — when she made this slide deck (about a month ago), Routines didn't even exist. That's the pace of change.

05Team Composition — Product Sense + Systems Experts
No longer selecting people based on raw engineering output

Two Key Profiles

  • Creative builders with product sense — highly curious, see a problem and immediately want to prototype
  • Deep systems expertise — distributed systems, infrastructure (when she joined, they lacked hard-part experts)

No longer heavily indexing on: raw throughput

Role Blurring Is Already Happening

  • PMs writing code (Cat Wu directly submits PRs)
  • Designers submitting PRs
  • Engineering managers using Claude as a content design partner
"But now Claude has really helped me augment that role."
06Org Structure — Flat + Managers Start as ICs
Rejecting the classic layered management hierarchy

The recruiting team planned with 10:1 ratios and nested hierarchies. Fung rejected that, requiring every manager to start as an IC upon joining. Recruiters said: "No manager would be interested in that." Her response: "Well, this is what dogfooding on the Claude Code team's about. If someone's not interested, it's better for us to do earlier separation."

At Meta she still tried to do one PR per year, but internal tools kept changing — now with Claude you don't need to remember git commands.

Org principles: As flat as possible, entire team shares one mission, pods have high autonomy.

07Knowledge Sharing — Code Is the Source of Truth
Code replaces documentation as the single authority
"On our team on Claude Code, the code is the source of truth."

When answering customer questions, she queries the codebase directly using local Claude Code. If a team has a good spec, she recommends checking it into the repo so Claude can validate against it — rather than treating spec and code as two separate sources of truth.

When building is cheap, arguing is expensive.Fiona Fung
Non-Negotiable

Three Team Principles

1

Every team member uses Claude Code

Not just engineers — PMs, designers, all cross-functional partners. Also heavy use of Cowork.

2

Claudify everything you can

Any manual step is an automation candidate. For every task, ask "can Claude help me do this?"

3

Explicit permission to kill old processes

Old processes don't kill themselves. Teams must be explicitly empowered to eliminate them.

Case — 50-person weekly meeting

A large room where everyone sat staring at laptops, only looking up when it was their turn to report. Fung asked one question — "Why are we having it?" — everyone nodded, and the meeting was cancelled.

Case — Stand-up evolution

From stand-up meetings → shared spreadsheet → stand-up Skill (a markdown file that tells Claude its role). Runs automatically; everyone stays informed at all times.

"Forcing function makes adoption non-negotiable. Room to adapt makes adoption sustainable." — Chris Ebert's notes
Measurement

Key Metrics

0
% Claude-Assisted Commits
Not a single non-Claude-assisted commit in the past 4 months
Continuously rising
New Hire Ramp-up Time
Engineers, designers, and PMs start contributing effectively faster
Significantly reduced
PR Cycle Time
If not decreasing, CI/infrastructure can't keep up with code volume
Should decrease
"I think throughput is great, but really think about how you measure what it is that you're actually really trying to solve."
Unresolved Questions

Questions Fung Doesn't Have Answers To Yet

1 Do iOS/Android teams still need to be separate?
"When engineers can now more efficiently flex across different mobile platforms, does a more traditional way of having an iOS team and an Android team still make sense?"
2 How far do you push automated review?
Where's the balance point for "trust but verify"? Model capabilities keep improving. "Even if you might need to do more verify than trust for a certain section of work, that might also change with the next model."
3 As roles blur, how do you ensure everyone feels equally productive?
Designers writing code, PMs running tests, engineers writing survey questionnaires — it's fun when it's fun, but it needs a deliberate cultural contract to sustain.
Call to Action
"Pick your noisiest workflow."

The most expensive one, the one you dread most, the one your team looks forward to least — ask whether it still serves its original purpose. If it can be automated, Claudify it. If it's no longer needed, kill it outright.

External Observations

Supplementary Data from Fellow Attendees

Noah Zweben
500 → 1,150

Weekly PR merges doubled within three months. Docs team is one person, using agentic routines for overnight auto-updates.

Jarred Sumner · Robobun
Surpassed the creator

Autonomous Claude Code agent Robobun now commits more to the Bun codebase than Jarred himself.

Conference consensus
Writing code → Orchestrating agents

Software engineering is shifting from "write code + review" to "define tasks → dispatch agents → review results."

Daisy Hollman · Anthropic MTS
Run agents overnight

Opus 4.7 in auto mode can run autonomously for hours. Six months ago this would have sounded like science fiction.

Data source: Chris Ebert (software engineer) conference notes

References

Sources