How Claude Code is being built
Claude Code product lead interview
One of my favorite podcasts is Peter Yang’s Behind the Craft podcast, featuring product managers from top companies. Here is a summary of the interview with the product lead working on Claude Code. It includes the Claude Code origin story, core product principles, feedback loops, and near-term vision. As usual, I’ve got the summary of the YouTube version using SpeakApp AI, the best tool to record and transcribe any audio content.
Here’s a quick high-level summary, followed by a deep dive in bullet form and closing with the key conclusions.
• Cloud Code began as an internal CLI-based AI prototype by an engineer (Boris Cherny) and grew virally through dog-fooding and org-wide use.
• The product’s minimal terminal form factor drives fast onboarding, extensibility (hooks, custom commands), and iterative design—engineers build, ship to internal users, gather negative feedback, refine, then release publicly.
• The team is small and cross-functional: product engineers own end-to-end feature delivery, the PM sets direction, pricing/packaging, and shepherds larger efforts (IDEs, SDK).
• Feedback loops run through an opt-in 1,000-member Slack, GitHub issues with thumbs-ups, and 10 close enterprise partners—negative feedback is prized.
• Documentation lives in code (MD files, cloudMD) not Google Docs; Cloud Code itself automates issue triage, docs updates, and summarization.
• Eval regimes include end-to-end SWEBench transcripts, triggering evals (e.g. web search), and ongoing work on capability-focused tests.
• Vision for the next few months: keep the CLI the most powerful coding agent, grow the SDK/ecosystem for all kinds of agents, and make core features accessible beyond the terminal.
• Closing advice: build demos not docs, treat the agent like an eager junior engineer (give feedback), invest in cloudMD, and hone your intuition for model capabilities and realistic timelines.
🚀 Claude Code Origin Story
• Boris tinkered with API-augmenting software and built a CLI prototype.
• Cat tried it during 20% time on RL environments, loved its integration with internal tools, and began sending product feedback.
• When Anthropic decided to open-source it externally, Cat joined as full-time product lead.
🎮 Viral Internal Adoption
• Early users on Boris’s team experimented, then crossed over into research, data science, product management, design.
• High “viral factor” internally—no top-down mandate.
• Hundreds to a thousand dog-fooders provided rapid feedback cycles.
🔗 CLI-Centric Design
• Terminal interface feels familiar to any dev used to GitHub CLI, Datadog CLI, etc.
• Minimalist form factor forces ruthless prioritization of features—screen real estate constraint.
• Supports plain-text I/O only (no buttons), so every new feature must justify its footprint.
📏 Core Product Principles
• Simple first, then composable: ship a minimal version with zero onboarding UX, then expand.
• Big features get hooks, custom slash commands, sub-agents to handle different dev setups.
• CLI should handle trivial tasks immediately, but allow depth for power users.
🤝 Team Workflow & Roles
• Small, strong product engineering team owns features end-to-end.
• Engineers prototype ideas, dog-food with internal users, iterate 2–3 times, then public release.
• PM role: set high-level direction (customizability bar, aspirational feature targets), shepherd large projects (IDEs, major integrations), and own pricing/packaging for AI era.
🗣️ Feedback Loops & Community
• Internal Slack channel opt-in (~1,000 members) generates feedback every ~10 minutes.
• Public feedback via 10 key enterprise customers and occasional Twitter signals.
• Negative feedback is actively solicited; thumbs-ups on GitHub issues and direct sales-team calls highlight top priorities.
🛠️ Automation & Tooling with Cloud Code
• Slack integration: query which customers requested a feature.
• GitHub automation: duplicate/close issues, generate first-draft docs.
• Updates docs via Cloud Code’s code-aware summarization within repos.
📄 Documentation Practices
• All documentation lives as markdown in repos (cloudMD files), not in Google Docs.
• cloudMD files serve as memory: repo architecture, gotchas, test instructions, personal or team context.
• PM and designers (like Megan) even contribute small code changes and doc tweaks directly via Cloud Code.
📈 Evaluation Strategies
• End-to-end evals: run SWEBench transcripts to catch regressions, though tracing root cause often requires reading raw logs.
• Triggering evals: test binary decisions (e.g. whether to use web search) by defining clear black-and-white cases.
• Capability evals: still a work in progress (e.g. data-science tasks require gold-standard answers, large data sets, complex setups).
🎉 Anecdotes & Culture
• Easter egg: if users said “swag” or “stickers,” they got mailed real stickers. That spike flooded team bandwidth.
• To-do list feature invented bottom-up by Sid to force multi-step tasks to complete—persisted in UI after internal demand.
• Team motto: build what we wish we had, ship small, learn fast.
🕵️ Hiring & Ecosystem Growth
• Hiring a PM who loves developers, ideally ex-dev or dev-tools background, to own the SDK and grow a shareable customization hub.
• Interview asks candidates to use Cloud Code hands-on, critique it, maybe prototype a mini-feature.
• Vision of a central marketplace for hooks, slash commands, status lines—one-click install.
💡 Power-User Tips
• demos not docs: prototype features with Cloud Code before writing long specs.
• treat Cloud Code like an eager junior dev: correct its missteps on the fly, it adapts.
• invest in cloudMD: capture repo memory and your personal context for frictionless onboarding.
• use plan mode when you want explicit step lists; “plan by human demand” despite core natural-language drive.
🔮 Near-Term Vision (next 3–6 months)
• Keep serverless CLI as the most powerful coding agent, with zero-friction onboarding and deep extensibility.
• Accelerate Cloud Code SDK adoption for building all kinds of agents (legal, health, EA, finance).
• Expand accessibility beyond terminal—think Slack hooks, remote notifications, mobile usage, non-technical roles.
Key Conclusions
• Rapid, user-driven iteration (prototype → dogfood → feedback → public launch) beats long-range grand plans in fast-moving AI.
• A terminal-first tool can scale internally and externally if minimal UI constraints force clarity and extensibility.
• PMs of AI products must develop strong intuition about current model limits vs. prompt tricks vs. future model roadmaps.
• Automating docs, issues, onboarding via the product itself reduces overhead and keeps source of truth in code.
• Short planning horizons (3–6 months) align with rapidly evolving model capabilities and maintain strategic focus.
You can find the original episode here: