Lenny's Newsletter

▶ YouTubecompleted
Back to results

Lenny's Podcast · Jun 21, 2026

What happens after coding is solved? | Fiona Fung (Claude Code & Cowork)

AI-accelerated engineeringengineering productivitycode review automationagent workflowsproduct quality frameworksorg designrole blurringlatent demandmanager as ICasync agentsAI team cultureverification at scaleClaude Code

Fiona Fung, head of Claude Code and Co-work at Anthropic, argues that coding is no longer the bottleneck — the new constraint is ambition, verification, and accountability. The episode covers concrete practices her team uses to manage 8x productivity increases: async agent routines, spec-driven code review, bad/sad quality frameworks, and manager-as-IC onboarding.

Watch on YouTubePartial match

Topics (10)

Coding is No Longer the Bottleneck — Ambition Is

9:00

AI coding tools have made writing software fast enough that the new bottleneck is the ambition and vision of the person directing the work.

How it works

  • Engineers at Anthropic ship 8x more code per quarter than in 2021–2025, meaning throughput is no longer scarce.
  • Non-engineers (PMs, designers) now commit code, further removing the implementation gap.
  • The ceiling on what a single person can build has lifted — cross-platform, cross-discipline work is now accessible without deep expertise in each area.
  • The question shifts from "can we build this?" to "how big should we think?"
  • Why you should care

    As a PM, your ideas are no longer gated by engineering bandwidth. This means the quality of your product thinking — not your ability to get things on the roadmap — becomes the primary constraint. Teams that don't raise their ambition will under-use their new capacity.

    Think of it like...

    It's like switching from hand-mixing concrete to a cement truck: the pour speed is no longer the problem — now you need a bigger blueprint.

    Spec-Driven AI Code Review

    15:15

    Instead of relying on human reviewers to hold the quality bar, you write down what "good" means as a spec in the repo, and the AI validates every PR against it automatically.

    How it works

  • Write explicit standards — design language, content guidelines, architectural rules — as documents committed to the repository.
  • Configure Claude Code Review to check new code and content against those committed specs.
  • Keep the specs updated alongside the code so they don't drift.
  • This is the AI-era evolution of Test-Driven Development: define success criteria first, then let automation enforce them.
  • Why you should care

    At high velocity (8x code output), human reviewers become a bottleneck for quality, not just throughput. This approach lets quality scale with output without proportionally scaling reviewer headcount. For a PM, it also forces the team to make implicit standards explicit — a governance benefit.

    Think of it like...

    It's like a linter, but instead of syntax rules, you're enforcing product and design principles.

    Bad vs. Sad Quality Framework

    45:25

    Instead of tracking raw performance numbers, teams classify every quality issue as either 'bad' (irrecoverable, e.g., crash) or 'sad' (recoverable but painful, e.g., flicker) to make cross-team quality conversations tractable.

    How it works

  • Each team defines what constitutes a 'bad' and a 'sad' for their specific surface (CLI crash = bad; UI flicker = sad).
  • Accumulated 'sads' are tracked as a leading indicator — a pile of sads can trend toward bad.
  • This gives a consistent abstraction across very different product surfaces without forcing them all onto the same raw metric.
  • Teams set their own thresholds and goals within this shared framework.
  • Why you should care

    In a high-velocity environment with many surfaces, dashboard numbers without context are hard to interpret. This framework lets leadership zoom out and see the overall experience health without drowning in metric debates. It also gives each team ownership (high agency) while maintaining a common language.

    Think of it like...

    It's like a hospital's triage system: not every problem needs immediate surgery, but the nurses all use the same severity scale.

    Async Agent Routines as Management Infrastructure

    13:18

    Instead of a manager manually scanning Slack channels and dashboards each morning, a scheduled agent does it overnight and delivers a curated summary plus draft fixes ready for review.

    How it works

  • A 'routine' is a prompt-generating agent that runs on a schedule (like a cron job, but with LLM reasoning).
  • It monitors configured sources: feedback Slack channels, PR activity, incident logs.
  • It can spawn sub-agents to investigate themes and generate PRs for polish fixes.
  • The manager wakes up to outputs — summaries, flagged issues, ready-to-review PRs — rather than raw inputs.
  • Why you should care

    At 8x code throughput, a manager physically cannot review everything manually. This is how you stay informed without becoming the bottleneck. For product leaders in complex orgs, this pattern generalizes: any recurring information-gathering ritual is a candidate for automation.

    Think of it like...

    It's a night-shift analyst that reads everything while you sleep and leaves a briefing on your desk.

    High Agency + High Accountability as a Paired Principle

    0:23

    Freedom to build anything must be matched by personal ownership of whether it actually worked — the two are non-negotiable as a pair.

    How it works

  • Engineers are empowered to identify problems and pursue solutions without waiting for permission (high agency).
  • Each initiative requires a stated hypothesis: what problem does this solve, and how will you know it worked? (high accountability).
  • This prevents 'token maxing' or shipping activity that isn't connected to outcomes.
  • The pairing avoids the failure mode where agency leads to motion without progress.
  • Why you should care

    In AI-accelerated teams, the risk isn't under-shipping — it's shipping a lot of the wrong things fast. This principle is a lightweight governance mechanism that scales better than process-heavy review gates. As a PM, this is how you maintain strategic coherence without micromanaging.

    Think of it like...

    It's like giving someone the keys to the company car — but only after they've filed where they're going and why.

    Manager-as-IC Onboarding Ramp

    50:52

    New managers join as ICs first, building real product knowledge and team rapport, before picking up their management responsibilities.

    How it works

  • During the IC period, the new manager has no direct reports or performance obligations — just deep work on the product.
  • They learn the codebase, tools, and culture from the inside, as a peer.
  • This naturally builds credibility and rapport with the team before the power dynamic of management kicks in.
  • Once comfortable, they transition into the management role with first-hand context.
  • Why you should care

    In AI-accelerated engineering orgs, a manager who can't evaluate code quality or understand the product deeply is flying blind. This practice ensures managers can do meaningful verification work — not just status meetings. It also signals to the team that leadership is earned through contribution, not title.

    Think of it like...

    It's the chef who works every station in the kitchen before becoming head chef — they earn the title by knowing the work.

    Latent Demand as a Product Discovery Signal

    32:52

    When people jump through hoops to use your product in a way you didn't design for, that workaround is a product roadmap item in disguise.

    How it works

  • Monitor usage patterns for behavior that wasn't designed — e.g., non-coders using Claude Code for knowledge work.
  • Identify the friction ('jumping through hoops') as a gap between what users need and what you offer.
  • Treat the workaround behavior as a validated hypothesis: if people do this despite friction, demand is real.
  • Build a smoother, purpose-built experience for that use case.
  • Why you should care

    Latent demand signals are pre-validated — users are already spending effort on the behavior without being asked. For a PM in a fast-moving space, these signals are higher-confidence than surveys or interviews. Co-work (Claude's knowledge work product) was reportedly discovered this way.

    Think of it like...

    It's like finding a desire path in a park — the worn grass where people cut across tells you where the real path should be paved.

    Don't Forsake Motion for Progress (Output vs. Outcome)

    41:29

    High output metrics — code shipped, tokens consumed, PRs merged — can all be moving fast while the product is going nowhere meaningful.

    How it works

  • Activity metrics (tool usage, commit count, lines of code) measure motion, not direction.
  • The equivalent trap in AI tooling is 'token maxing' — maximizing AI usage as a proxy for productivity.
  • The correct question is: what outcome are we trying to achieve, and is this activity causally linked to it?
  • Metrics need to be periodically revisited because the landscape changes — what was a good proxy may no longer be.
  • Why you should care

    This is a direct challenge to how most teams are currently measuring AI ROI. If your engineering productivity dashboard tracks PR velocity or AI tool adoption rates, you may be measuring the wrong things. The Facebook Marketplace anecdote (number of sellers vs. power sellers) is a concrete illustration of how proxy metrics drift from outcomes.

    Think of it like...

    It's like measuring a sales team by calls made instead of deals closed — busy, but possibly going nowhere.

    Pairwise Programming Lunches as Loneliness Antidote

    56:39

    When every engineer works solo with their own AI agent all day, team knowledge stops flowing — scheduled pair sessions are a structural fix.

    How it works

  • Engineers at Anthropic noticed that deep individual agent use was reducing organic collaboration and creating isolation.
  • The team introduced regular lunchtime pair programming sessions — not to ship a specific feature, but to learn from each other.
  • Because everyone uses Claude Code differently, observing a colleague's workflow teaches techniques you'd never discover alone.
  • Hackathons serve a similar function: forcing collaborative, in-person building.
  • Why you should care

    This is an early signal of a new management problem: AI-accelerated teams may ship more but lose the informal knowledge transfer and social cohesion that previously happened naturally around shared code. As an engineering leader or PM, this is a culture and retention risk, not just a productivity concern.

    Think of it like...

    It's like reinstating the office water cooler after everyone went remote — the work still gets done, but the side-channel learning disappears without a structural replacement.

    Role Blurring: Engineers as PMs, PMs as Engineers

    1:00:32

    AI tools are erasing the functional separation between engineering and product, making every team member responsible for both building and thinking about impact.

    How it works

  • PMs at Anthropic now commit code when engineering bandwidth is the constraint.
  • Engineers are expected to develop product sense and own the success of what they ship, not just the implementation.
  • The verification burden (is this right? does it work? did it have impact?) increasingly falls on whoever shipped it, regardless of role.
  • 'Role' is becoming a probabilistic description: what is the highest percentage of what you do?
  • Why you should care

    This has hiring and org design implications. The clean separation of PM/Engineering/Design that most enterprise orgs rely on is being disrupted. Your next team structure may need to optimize for product engineers and creative builders rather than functional specialists. It also changes what skills to screen for in interviews.

    Think of it like...

    It's like the difference between a restaurant with strict kitchen stations vs. a food truck where everyone does everything.

    Why this matters to you

    Your team is about to 8x its output — are you ready for what breaks next?

    The bottleneck has shifted from shipping code to verifying it, directing it, and measuring whether it mattered. If your processes (code review, quality monitoring, roadmap prioritization) were designed for human-speed output, they will not survive AI-speed output.

    The role of PM is being redefined in real time at the most AI-native company on earth.

    PMs at Anthropic now commit code. Engineers own product outcomes. This is not a future prediction — it is current practice. The skills, hiring profiles, and org structures this implies are directly applicable to B2B and enterprise product teams building with AI.

    The social and cultural consequences of AI-first engineering are arriving before anyone has solutions.

    Isolation, skill atrophy, and metric drift are emerging problems on the team that builds Claude Code. The patterns Fiona describes — pairwise lunches, IC onboarding, spec-driven review — are early experimental responses worth adapting before the problems arrive in your org.

    Relevant transcript passages (6)
    0:10
    Everything is now possible in theory. Now, it's about how ambitious can you be?

    Crystallizes the central thesis of the episode in one sentence — the constraint has shifted from capability to vision.

    41:29
    don't forsake motion for progress. Um because if you're measuring like, you know, like tool user usage, then you're you're measuring the action, but is it really making whatever the end outcome of yours like important?

    Direct challenge to how most teams are currently measuring AI ROI — highly relevant for anyone building AI productivity cases for stakeholders.

    0:23
    we say with high agency is also high accountability. So, it's all about making sure folks have that freedom to code. But, then it's also like, okay, what's the accountability for it? What's the hypothesis of what you're trying to solve?

    The most operationally concrete org principle in the episode — applicable directly to team operating models.

    56:39
    it could start being a lonely experience cuz we all started just working with our agent so much. And on the Claude Code team, recently, we started up pair-wise programming lunch.

    First-hand evidence of a new cultural failure mode in AI-first teams, with a concrete mitigation — not theoretical.

    43:45
    whatever metric whether for productivity or even for product, always keep an eye and make sure that you're not just having blinders on that's blindly following a metric that used to make sense cuz sometimes the landscape can change so fast.

    Applies equally to product metrics and AI productivity metrics — warning against metric inertia in fast-changing environments.

    15:15
    the more that we can automate to almost check in the framework for what good looks like. Claude is very good when you give it a framework to validate against those frameworks.

    The core insight behind spec-driven AI review — actionable immediately for any team using AI-assisted code review.

    Key Insights (10)
    • Coding throughput at Anthropic has increased 8x per engineer per quarter since 2021–2025 — the constraint is now ambition and verification, not implementation speed.
    • Specs committed to the repo function as scalable quality enforcement: Claude Code Review validates PRs against explicit standards, evolving test-driven development for the AI era.
    • Async agent routines replace manual daily management rituals — scheduled agents monitor feedback channels and surface summaries + draft PRs overnight.
    • High agency must be explicitly paired with high accountability (stated hypothesis + owned outcome) to prevent high-velocity teams from shipping motion instead of progress.
    • Role blurring is already happening: PMs commit features, engineers own product metrics, and 'role' is converging toward 'what you do most' rather than a job title.
    • AI-only work is creating a loneliness and knowledge-transfer problem on engineering teams — deliberate pair programming sessions and hackathons are structural mitigations, not optional culture initiatives.
    • Latent demand — users working around your product's limitations in unintended ways — is the highest-confidence discovery signal because it requires no prompting.
    • Proxy metrics for AI productivity (tokens used, PRs merged, lines of code) are the new 'lines of code' trap — outcome metrics need to be revisited as the landscape changes.
    • Manager-as-IC onboarding builds the verification competence and team credibility that pure management hires in AI-accelerated teams will lack.
    • The 'bad vs. sad' quality framework gives cross-surface teams a shared severity language without forcing different product areas onto incompatible raw metrics.
    Action Items (8)
    • Audit your current code review process: identify which quality standards exist only in people's heads and write them down as committed specs so AI review can enforce them.
    • Map your recurring daily or weekly information-gathering rituals (feedback scanning, incident review, metric checks) and evaluate which ones could be replaced with async agent routines.
    • Revisit your AI productivity metrics: if you're tracking tokens used, PRs merged, or tool adoption rates, replace at least one with a direct outcome metric tied to user or business value.
    • Run a 'latent demand audit': look at your product analytics for usage patterns you didn't design for — treat the top three workarounds as potential roadmap items.
    • Introduce a bad/sad quality classification to at least one product surface — start by having the team define what 'bad' and 'sad' mean for their specific area.
    • If you manage engineers, schedule one pairwise working session per month where team members code together with their AI tools visible — the knowledge transfer from different workflows is disproportionately high.
    • For your next engineering manager hire, consider a structured IC period before they take on reports — define the duration and what 'ramped' looks like before the role starts.
    • If you are a PM who has not yet committed a feature end-to-end using AI coding tools, do it once — the verification instinct and product empathy it builds is not accessible from the outside.
    Skip if: You are already deeply familiar with AI-native team operating models and are looking for architectural or model-level content — this episode is almost entirely about org design, team culture, and product management practice, not AI/ML technical depth.