Video summary

Running an AI-native engineering org

Main summary

Key takeaways

Business

High-level context

Fiona Fung (engineering/product leader at Claude Code / Cowie) shares operating lessons for building and scaling an AI-native engineering org. The core emphasis: as AI increases coding throughput, the org must redesign team norms, verification, and planning/coordination habits because bottlenecks move.

Core theme: “The bottlenecks have moved”

Key idea

When AI makes coding cheaper/faster, previously “expensive” bottlenecks (typing, refactoring, test-writing) shift toward verification, review, security, and cross-functional coordination.

What used to be bottlenecks (now less dominant)

  • Engineering bandwidth / coding throughput
  • Refactoring/test time as “scheduled work”
  • Long planning horizons (e.g., 6-month roadmaps) because implementation was slower
  • Traditional division of ownership and roles (clear engineer-only boundaries)

New bottlenecks and failure modes

  • Verification & review
    • “Is this code correct?”
    • “Who reviews this code?”
  • Security / legal / trust boundaries
    • Human experts still required in sensitive areas
  • Maintenance cost & regression risk
    • Faster generation can break things elsewhere
  • Cross-functional gaps
    • Roles blur (designers and PMs contributing code; engineers needing help on copy/content)

Playbook implication

  • Treat AI-driven throughput as a change to the whole pipeline, not just “more output.”
  • Continuously ask: “What part of the process is now limiting speed/quality?”

Team norms & processes to rewrite (Claude Code)

Fung lists specific norms that evolved as AI made production faster.

1) Code review: human judgment + AI delegation

Claude handles “babysitting” PRs, including:

  • styling/lint feedback
  • bug-catching and fixes before full commit
  • adding/assisting tests

Humans retain responsibility for:

  • expertise & risk tolerance
  • legal review
  • security-sensitive boundaries

“Trust but verify” remains explicit.

2) Planning: from long roadmap + design docs → JIT planning + PR/prototypes

What was reduced:

  • design docs before every code ritual (kept for certain scenarios)
  • product reviews (because the landscape changes quickly)
  • heavy upfront planning cycles

What increased:

  • JIT planning (“JIT compiling” metaphor)
  • early prototyping: “find an idea, go prototype”
  • coordination in PR discussions rather than separate docs

3) Technical debates: “code wins,” but with broader impact analysis

With AI generating multiple options quickly, debates shift from “who can draft code” toward:

  • implementation tradeoffs and
  • impact to callers/consumers

Example:

  • Instead of debating an API change on a whiteboard, AI helped generate three PR variants, enabling discussion of downstream effects.

4) Team culture/rituals: prevent “last word wins”

Fung highlights a cultural anti-pattern:

  • don’t let speed/AI-generated convenience create a “whoever ships last wins” dynamic

Need norms that support:

  • open technical debate
  • alignment routines
  • predictable collaboration habits

5) Knowledge share + onboarding changes (roles blurring)

Onboarding, ownership questions, and knowledge transfer evolve because:

  • more roles can write/ship code
  • engineers and non-engineers contribute more directly

Verification strategy: “Shift left” + automation scaling

Because throughput is higher and there are more ways to break things, Fung argues the org must double down on verification.

Shift-left principles (implied)

  • Catch issues earlier (at the source)
  • Use more automation for:
    • verification steps
    • earlier detection (before humans discover failures)
  • Maintain higher confidence regardless of contributor role (engineers, designers, PMs)

Ownership question reframed

Since “who authored the change?” is fuzzier, Fung recommends “double click”:

  • Determine what question you actually need answered:
    • Who caused the regression? (context/last touch, without blame)
    • Who is an expert for customer questions?
    • What context is missing?
  • Then automate answering that question with AI tooling and routines.

Team shape / hiring & org design tactics

Desired team profiles (Claude Code)

Fung emphasizes two engineering profiles:

  • Creative builders with product sense
    • curiosity
    • iterative delivery for delightful UX
  • Deep systems expertise
    • still essential for hard parts (e.g., distributed systems to run Claude Code remotely)

Less emphasis on:

  • raw throughput (models improve efficiency)

Org structure

  • Keep the team flat as possible to stay agile
  • Managers should start as ICs:
    • earn credibility
    • understand workflows directly
    • reduce context-switching friction using Claude

Pods with high agency

  • Mandate “must-do” team principles
  • Enable pods to adapt on:
    • triage approach
    • planning/stand-ups
    • on-call ownership
    • which workflows to Claudify first

Concrete operational examples

  • If recruiters worry managers won’t be interested in IC-first roles:
    • Fung cites dogfooding (leaders coding early, frequent product use)
  • Cross-functional content/design support:
    • Claude helped with succinct survey language when a dedicated content designer wasn’t available
    • Claude also augments designers/PMs/engineers in role-adjacent tasks

“Claudify everything” operating doctrine

Guiding principles (as stated)

  • Claudify everything you can
    • automate verification, reduce manual pipeline work
  • Explicit permission to kill old processes
    • processes don’t kill themselves; leaders should actively defragment/defund them

Example: defragmenting a meeting process

  • A large weekly “expensive review” (~50 people) with laptops down except during status
  • Fung asked why it existed; team agreed it was wasteful → meeting canceled

Metrics / KPIs to watch (business-operating signals)

Fung mentions “three general metrics” (no numeric targets, but clear directional expectations):

  1. Onboarding ramp-up time decreases
    • How quickly engineers/designers/PMs become effective
  2. PR cycle time shortens
    • Also used to identify pipeline scaling gaps (e.g., CI/infrastructure limits)
  3. Cloud-assisted commit rate increases
    • Example claim: “by default every commit is cloud-assisted”
    • Fung notes an additional bottleneck may exist elsewhere (product infra/CI) that should also scale

Additional measurement guidance

  • Don’t only measure AI throughput (e.g., “X% code generated”)
  • Also track outcome metrics aligned to product goals:
    • quality
    • reliability

Remaining questions / risks to re-evaluate

Fung lists ongoing open problems to audit:

  • Does a traditional iOS vs Android team split still make sense when engineers can flex across platforms?
  • How much should be automated review vs human verification without losing important judgment?
  • As model capabilities improve, revisit the trust/verify balance
  • With roles blurring, how to ensure everyone feels equally productive

“Noisiest workflow” improvement prompt

Action framework:

  • Identify your most annoying/expensive workflow
  • Ask: “Is it still serving its intended purpose?”
  • Either:
    • automate it, or
    • remove/cancel it if wasteful

Presenters / sources

  • Fiona Fung (presenter)
    • Leads Claude Code and Cowie engineering and product
    • Previously led/grown teams at Meta and Microsoft
  • Mentioned but not presenting in the excerpt:
    • Boris
    • Jared
    • Cat (works closely with Fiona; co-leads/partner)
    • Danella (referenced as earlier keynote speaker)
    • Kat (mentioned as giving a keynote earlier about Claude code review)
  • Product/tool context referenced:
    • Claude Code / Cowie / Claude

Original video