CHAPTERS
- 0:17 – 2:18
Why engineering norms must change when coding stops being the bottleneck
Fiona Fung (Engineering & Product lead for Claude Code and Cowork) frames the talk around a major shift: AI has moved the bottleneck away from writing code. She outlines five themes she’ll cover, focused on updating team norms, rollout strategy, and proof signals.
- •Engineering processes should be routinely audited for continued usefulness
- •AI changes what is scarce: less “coding bandwidth protection,” more attention elsewhere
- •Talk roadmap: shifted bottlenecks, rewritten norms, rollout, signals, team exercise
- 2:18 – 3:49
A historical pattern: bottlenecks shift with platform changes (from on-prem builds to cloud CI)
She compares today’s AI shift to earlier industry shifts, like moving from on-prem server-room builds to cloud-based continuous integration. The lesson: when constraints change, processes that optimized for the old constraint become outdated.
- •Early 2000s build pipelines were a hard bottleneck (queued merges, limited PR throughput)
- •Cloud and CI moved the bottleneck and changed how teams worked
- •AI is the next major shift—teams should expect norms to evolve again
- 3:49 – 5:21
What AI makes cheaper: tests, refactors, and “broccoli” work becomes enjoyable
Fiona explains how AI changes the cost/effort profile of tasks engineers used to avoid. She shares a personal story where test-driven development felt dramatically easier and more fun with Claude, and notes refactoring no longer requires major tradeoffs.
- •Old bottlenecks: writing code, writing tests, refactoring
- •TDD becomes less painful when AI helps generate/iterate quickly
- •Refactoring is no longer constantly deferred due to product delivery pressure
- 5:21 – 5:51
The new bottlenecks: verification, review, and long-term maintenance
With throughput rising, correctness and confidence become the limiting factors. Fiona highlights new friction points: verifying behavior, deciding who reviews, and ensuring maintainability as more people (and AI) contribute changes.
- •Verification becomes paramount as output volume increases
- •Review/ownership questions intensify when commits are frequently co-authored by Claude
- •Maintenance costs rise with accelerated shipping unless addressed deliberately
- 5:51 – 7:52
Processes that ‘quietly stopped working’: planning, ownership, reviews, team structure, knowledge sharing
She lists traditional practices that become misaligned in an AI-native environment. The team revisits planning norms, code ownership assumptions, code review mechanics, role definitions, and even the idea of documentation as the primary truth source.
- •Planning norms need rethinking when coding speed is no longer the constraint
- •Code ownership changes when contributions are AI-assisted and roles blur
- •Code review and knowledge-sharing practices need redesign
- 7:52 – 9:23
Technical debate flips: ‘code wins’ and prototyping becomes the default
Instead of long arguments or heavy design docs, the team leans on rapid implementation to explore options. Fiona shares how generating multiple PR variants enabled better technical debate than whiteboarding, and how prototypes can evolve to production faster with AI.
- •“Building is cheap, arguing is expensive” becomes an operating principle
- •Generate multiple implementation variants to compare real tradeoffs
- •Prototyping risk (shipping the prototype) is mitigated by AI-assisted iteration and scaling
- 9:23 – 10:24
Reducing heavy design docs; doubling down on ‘shift-left’ verification and automation
Claude Code discussions increasingly happen in PRs and prototypes rather than lengthy docs. In exchange, the team invests more in verification—catching issues earlier via automation to avoid customer-discovered bugs.
- •PRs/prototypes replace many long-form planning artifacts
- •Verification is the critical counterbalance to increased speed
- •Shift-left automation is better than discovering bugs internally—best is catching them at the source
- 10:24 – 11:57
Rethinking ownership questions and scaling code reviews with Claude Code Review
Fiona reframes ‘who touched this last?’ as a proxy for deeper needs like accountability, context, or debugging. She describes how Claude Code Review helps handle higher throughput while keeping humans focused on what AI can’t reliably judge.
- •Don’t stop at “who changed this”—identify the real question (regression, context, expertise)
- •Use routines (e.g., feedback summarization) to keep pace with information flow
- •Claude excels at style/lint, obvious bugs, and checking against specs committed in-repo
- 11:57 – 12:58
What still requires humans: legal risk, trust boundaries, and product taste
Even with AI review, humans must own high-stakes decisions and subjective judgment. Fiona illustrates ‘taste’ with a story about a holiday CLI design that looked like “Mr. Peanut,” showing why designers and product sensibilities remain essential.
- •Humans are necessary for legal review and risk-tolerance decisions
- •Trust boundaries require “trust but verify” with expert judgment
- •Product sense/taste can’t be automated—human feedback prevents quality regressions
- 12:58 – 13:28
Hiring for an AI-native team: creative builders with product sense + deep systems experts
As roles blur and AI amplifies output, Fiona focuses on two core profiles: builders who can iterate with strong product judgment, and specialists with deep systems knowledge to ensure robustness. She then explains how engineers can intentionally build product sense.
- •Two key profiles: product-sense builders and deep systems experts
- •AI raises the bar on judgment, not just implementation speed
- •Product sense is a learnable muscle, not a fixed trait
- 13:28 – 15:30
How to build product sense: dogfood, ship/iterate, and talk to real users (incl. small business)
Fiona emphasizes dogfooding as the foundation of product intuition, especially for managers who historically lost maker time. She shares how onboarding small businesses to Cowork exposed gaps in the flow and provided humbling, high-signal feedback.
- •Dogfooding helps you ‘feel the product in your bones’ and reconnect with user intent
- •Avoid decisions driven only by dashboards/PowerPoints by staying close to user experience
- •Direct customer onboarding (e.g., restaurants) reveals friction and opportunities
- 15:30 – 16:31
Cross-functional gaps shrink: designers ship polish, engineers get content help—verification becomes vital
Claude enables non-engineers to implement changes and engineers to cover adjacent skills like content design. This speeds iteration loops across functions, but increases the need for verification as more contributors land changes.
- •Designers can implement UX/polish fixes directly using Claude
- •Engineers can use Claude for content design and concise UX copy
- •Broader contribution increases the importance of robust verification practices
- 16:31 – 19:02
Org design changes: managers start as ICs; code becomes the source of truth (and specs should live in-repo)
Fiona describes a deliberate org choice: every manager begins as an IC to learn the codebase and the team’s real workflows. For onboarding and knowledge sharing, the codebase becomes the primary source of truth, with specs ideally checked into the repo to reduce drift.
- •Managers start as ICs to build credibility and understanding of the system
- •AI makes returning to the codebase less daunting for managers
- •Documentation drifts faster in high-throughput environments; keep specs/skills in the repo
- 19:02 – 22:04
Rolling out AI-native norms: team-wide forcing functions + pod-level flexibility
The team establishes a few non-negotiable principles while letting pods adapt workflows locally. These include using Claude Code/Cowork daily, ‘Claudifying’ tasks whenever possible, and explicitly empowering teams to delete obsolete processes.
- •Must-dos: everyone uses the product; automate/‘Claudify’ wherever possible
- •Explicit permission to kill old processes prevents process pileup
- •Pods choose how Claude shows up in triage, standups, planning rituals, and workflow priorities
- 22:04 – 26:37
Proof signals and open questions: metrics to watch + a team exercise to ‘Claudify’ the noisiest workflow
Fiona shares indicators that the changes are working (faster onboarding, reduced PR cycle time, rising AI-assisted commits) and cautions to diagnose PR cycle time by sub-stages (CI/build bottlenecks). She ends with unresolved org questions and a practical exercise: pick your most painful workflow and reassess its purpose or automate it with Claude.
- •Signals: reduced onboarding ramp time and lower burden on existing teammates
- •PR cycle time should fall, but break it down to find jams (e.g., CI/build capacity)
- •Open questions: platform org splits, how far to automate reviews, productivity amid blurred roles
- •Exercise: identify the highest-tax workflow/meeting and redesign or automate it step-by-step
