CHAPTERS
- 0:00 – 2:00
Why this talk: lessons from scaling Claude Code & Cowork engineering
Fiona Fung introduces her role leading Claude Code and Cowork engineering/product and frames the talk around lessons learned while growing an AI-native team. She previews five themes: shifting bottlenecks, rewritten team norms, rollout tactics, success signals, and open questions to keep auditing as things change.
- •Speaker background (Anthropic, Meta, Microsoft) and scope: Claude Code & Cowork
- •Five themes: shifted bottlenecks, new norms, rollout, signals, unresolved questions
- •Emphasis on rapid change requiring continuous adaptation
- •Goal: practical takeaways for other engineering leaders/teams
- 2:00 – 4:23
The big shift: engineering bandwidth is no longer the primary constraint
Fiona argues that the historic constraint in software delivery—engineering throughput—has changed dramatically with AI assistance. She uses an industry analogy (CD-ROM era hard deadlines vs online distribution) to show that shipping norms evolve when constraints move.
- •Engineering coding throughput used to be the expensive/scarce resource
- •AI-assisted development increases output and changes what’s “hard”
- •Industry precedent: distribution changes reshaped shipping practices
- •Core mantra: what served you before may not serve you now
- 4:23 – 5:54
New bottlenecks: verification, review capacity, security, and maintenance
As teams generate more code faster, the friction relocates to validating correctness, managing reviews, coordinating cross-functional checks, and sustaining maintainability. Fiona highlights that scale in code output can amplify downstream bottlenecks and long-term costs.
- •Bottlenecks shift from writing code to verifying it
- •Code review capacity becomes a limiting factor
- •Security/trust boundaries and cross-functional reviews become critical gates
- •Maintenance cost grows as code volume increases
- 5:54 – 7:25
Processes that quietly stop working (and why they linger)
Fiona explains that processes rarely “kill themselves,” so teams tend to accumulate layers of rituals and SLAs even after the original need changes. She calls out common practices that become less effective when coding is no longer the bottleneck.
- •Process accumulation: teams layer rules rather than removing them
- •Planning norms (heavy upfront planning) can become wasteful
- •Traditional code ownership assumptions get fuzzier with AI-assisted work
- •Knowledge sharing/onboarding methods may no longer fit the new pace
- 7:25 – 8:27
Team norms to rewrite: what Claude Code had to change
She introduces the main operational areas where Claude Code rewrote norms: reviews, onboarding, planning, hiring, and org shape. This serves as a roadmap for the concrete practices she’ll detail next.
- •Norm areas: code review, onboarding, planning, hiring, org design
- •Roles are blurring across engineering and non-engineering functions
- •Need to rethink how decisions and accountability work
- •Transition from “old toolbox” management to AI-native practices
- 8:27 – 8:57
Planning becomes lighter and more just-in-time; PRs/prototypes replace docs
Fiona describes moving away from long roadmaps and frequent design docs because they become obsolete too quickly. Instead, Claude Code relies more on rapid prototypes and PR-based discussion, plus real user/internal feedback to steer decisions.
- •Six-month roadmaps decay quickly in fast-changing environments
- •“JIT planning”: do the right amount at the right time
- •Reduced “design doc before every code” ritual; discussion moves to PRs
- •Fewer heavyweight product reviews; prototype and dogfood early
- 8:57 – 11:28
Technical debates evolve: when building is cheap, arguing is expensive
She shares a refactor debate with Boris where AI enabled generating multiple viable PRs instead of prolonged whiteboarding. Comparing concrete implementations—including caller impact—shifts debates from hypothetical arguments to evidence-based evaluation, while still requiring strong alignment norms.
- •Generate multiple implementation options quickly (e.g., three PRs)
- •Debate shifts to evaluating tradeoffs and downstream impact
- •Guardrail: avoid “last check-in wins” behavior
- •Team culture becomes more important for alignment amid faster iteration
- 11:28 – 12:28
Verification and confidence: doubling down on ‘shift-left’ quality
With higher throughput and blurred roles (designers/PMs shipping code), Fiona emphasizes improving automated verification so contributors can change code with confidence. The goal is to catch issues earlier—ideally before users do—via more automation and better test/validation coverage.
- •Throughput increases create new ways to break things
- •Shift-left via automation to catch issues earlier
- •Broader contributor base (non-traditional coders) raises need for safety nets
- •Personal example: fear of regressions underscores need for confidence
- 12:28 – 13:28
Code ownership rethought: don’t ask ‘who wrote this?’—ask what you need
Because most PRs are AI-assisted, “who made this change?” becomes less informative. Fiona suggests identifying the underlying intent—finding context, locating expertise, or tracing regressions—and then using AI/routines to automate summaries and context gathering.
- •AI assistance makes authorship less useful as a proxy for knowledge
- •Double-click the real question: blame-free regression tracing, expertise, or context
- •Use automation/routines to summarize feedback and surface context
- •Keep source-of-truth close to code to reduce documentation lag
- 13:28 – 15:31
Scaling code review with Claude: what to automate vs where humans must weigh in
Fiona explains how Claude is used to handle style, linting, feedback loops, catching/fixing issues pre-commit, and adding tests. Humans remain essential for domain expertise and risk decisions—especially legal, security/trust boundaries, and product taste.
- •Claude handles routine review tasks: style, lint, common issues, tests
- •Humans stay in loop for legal review and security-sensitive code
- •Risk tolerance drives where you require human scrutiny
- •Product sense/taste still needs human judgment (ASCII art example)
- 15:31 – 17:32
Hiring and team makeup in an AI-native world: prioritize taste + systems depth
Fiona describes two engineer archetypes Claude Code hires for: creative builders with strong product sense and deep systems experts for hard infrastructure problems. She notes AI reduces the value of raw throughput alone and also helps close cross-functional gaps (e.g., content design) while enabling PMs/designers to code more.
- •Two key profiles: product-minded creative builders and deep systems experts
- •Less emphasis on raw throughput as a hiring differentiator
- •Claude helps engineers cover gaps like content design; PMs/designers ship code
- •Blurred roles change how you structure collaboration and expectations
- 17:32 – 20:33
Org shape and leadership: stay flat, dogfood, and have managers start as ICs
Fiona advocates for a flatter org to remain agile and keep leaders close to the product. She expects managers to begin as ICs to earn credibility and dogfood workflows—made more feasible by AI reducing tooling friction and ramp costs.
- •Keep org flat to maintain agility and speed of decision-making
- •Managers start as ICs first to dogfood and earn “street cred”
- •AI makes it easier for managers to stay hands-on despite context switching
- •Hiring managers into IC-first roles can be a deliberate filtering mechanism
- 20:33 – 24:05
Rolling out new norms: mandate a few principles, give pods autonomy elsewhere
She outlines how Claude Code balances standardization and local flexibility. Core principles are agreed as must-dos (everyone uses Claude Code, ‘Claudify’ work, explicitly kill old processes), while pods choose specifics for triage, planning rituals, on-call, and which workflows to automate first.
- •Align on must-dos: team-wide principles revisited regularly
- •Principles: everyone uses Claude; automate broadly; permission to remove process
- •Pods retain autonomy on day-to-day rituals and prioritization
- •Example: replacing status spreadsheets with automated standup summaries
- 24:05 – 25:36
Measuring whether it works: onboarding speed, PR cycle time, and quality outcomes
Fiona shares practical indicators that the shift is working: faster onboarding ramp, shorter PR cycles, and increased Claude-assisted commits. She cautions that raw AI code percentage isn’t the goal—teams must also track product impact, quality, and reliability.
- •Onboarding ramp time decreases as AI aids context and execution
- •PR cycle time should shorten; bottlenecks may move to CI/build capacity
- •Claude-assisted commits rise (often becoming the default)
- •Measure real outcomes too: delight, reliability, and quality—not just throughput
- 25:36 – 28:37
Ongoing audit questions and a practical takeaway: pick your noisiest workflow
Fiona closes with open questions she’s still evaluating, such as whether platform-specific mobile teams still make sense and how far to push automated review. She encourages teams to identify their most painful/expensive workflow, ask why it exists, and either automate it or remove it if it no longer serves its purpose.
- •Org design question: iOS vs Android separation in a world of higher mobility
- •Automation question: where to draw the line on fully automated review
- •Reevaluate continuously as model capabilities improve
- •Action item: identify and challenge the noisiest workflow; automate or cancel it
