How the Claude Code Team Works
Notes from Boris Cherny interview
Notes from Boris Cherny (creator of Claude Code) on the Y Combinator Light Cone podcast.
Source: Inside Claude Code With Its Creator Boris Cherny
I feel like there are so many nuggets in this interview I haven’t seen Boris share in other ones.
Product Philosophy
Build for the Model 6 Months From Now, Not Today
“We don’t build for the model of today. We build for the model six months from now.”
If you find PMF for today’s model, you’ll get leapfrogged by someone building for the next one.
New models drop every few months. Whatever scaffolding you build becomes tech debt.
The Bitter Lesson
They have a framed copy of Rich Sutton’s “The Bitter Lesson” on the wall in the Claude Code area.
Core idea: the more general model will always beat the more specific model. Never bet against the model.
They call non-model code “scaffolding.” Trade-off is always: build scaffolding now for 10-20% gain, or wait a couple months and the model just does it.
Latent Demand Drives Everything
Boris’s “single biggest idea in product.”
People will only do a thing they already do. You can’t make people do a new thing. You make the thing they’re already trying to do easier.
Plan mode: users were already prompting Claude “come up with a plan but don’t write code yet.” Boris saw this in GitHub issues and internal Slack, built it in 30 minutes on a Sunday night, shipped Monday morning.
CLAUDE.md: users were already writing markdown files and having the model read them. The team just formalized what users were doing organically.
Co-work (desktop GUI): non-technical Anthropic employees (designers, finance, data science) were jumping through hoops to install a terminal tool. So they wrapped Claude Code in a GUI.
Constant Rewriting
“There is no part of Claude Code that was around 6 months ago.”
They unship tools every couple weeks. Add new tools every couple weeks.
~80% of the codebase is less than a couple months old.
Code shelf life is very short by design.
Product Development Process
User Research
Boris literally walks around the office and stands behind people watching how they use Claude Code.
Heavy GitHub issues reader. Sunday nights reading issues, looking at what people talk about.
Internal Slack feedback channel is a primary signal source.
Dog food everything internally first, then ship to external users.
Iteration Cadence
Ship fast, get feedback, iterate. Not a master plan with features mapped out.
Example: hid file reads/searches in the UI. Dog fooded internally for a month. Shipped. GitHub users revolted (”I want to see details”). Added verbose mode. Users still unhappy. Iterated more until it was right.
Terminal spinner: ~50-100 iterations. 80% didn’t ship. Try, doesn’t feel good, move on. Whole process takes a couple hours because Claude Code writes the prototypes.
Prototyping Speed
“You can write 20 prototypes back to back, see which one you like, and ship that. The whole thing takes maybe a couple hours.”
Previously: 3 prototypes took 2 weeks using Origami or Framer.
Co-work was built in ~10 days, 100% written by Claude Code.
Dogfooding
2 days after the first prototype, Boris gave it to his team.
Robert (engineer across from Boris) was using it the next day without being asked.
Internal Anthropic usage chart went vertical. Dario asked if engineers were being forced to use it. They weren’t.
Code Review and Shipping
CLAUDE.md for the Team
Boris’s personal CLAUDE.md is only 2 lines:
Enable automerge on PRs (so accepted PRs merge immediately).
Post PRs to the internal team stamps channel (so someone can stamp and unblock him).
All other instructions live in the codebase’s shared CLAUDE.md that the entire team contributes to multiple times a week.
Catching Mistakes via CLAUDE.md
When Boris sees a PR with a preventable mistake, he literally tags Claude on the PR with “add this to the CLAUDE.md.” Does this many times a week.
CLAUDE.md Philosophy
Keep it short. Theirs is ~couple thousand tokens.
If it gets too long: delete it and start fresh.
Minimal instructions to keep the model on track. Add back a little at a time only when the model goes wrong.
With each new model, you need less in the CLAUDE.md.
PR Volume
Boris personally lands ~20 PRs per day.
Productivity measured by PRs, cross-checked against commits and commit lifetime.
Automation with Agents
Agent SDK for Dev Automation
They use the Claude Agents SDK to automate “pretty much every part of development”:
Code review
Security review
Issue labeling
Shepherding things to production
Agents talk to each other and to team members on Slack.
Agents Message Engineers Directly
Common pattern: Boris asks Claude to build something. Claude looks at the codebase, sees an engineer in the git blame, messages that engineer on Slack with a clarifying question, gets the answer, and continues.
Plugins Built by a Swarm
The plugins feature was entirely built by a swarm of agents over a weekend.
An engineer gave Claude a spec and told it to use an Asana board.
Claude created tickets, spawned agents, and agents picked up tasks independently.
Minimal human intervention. Shipped in roughly the form the swarm produced.
Sub-agents for Debugging
For hard bugs, calibrate the number of sub-agents based on difficulty.
“If it’s really hard, I’ll say use three or maybe five or even 10 sub-agents, research in parallel and then see what they come up with.”
One agent looks at logs, another at the code path, etc.
Autonomous Claude Usage
Boris’s Claude runs co-work in the background. It sometimes tweets (he deletes them, “a little cheesy”).
Internal Claudes talk to each other and to users on Slack.
Engineering Culture
Plan Mode Usage
~80% of Boris’s sessions start in plan mode.
Opens multiple terminal tabs, each starting in plan mode. When he runs out of tabs, opens the desktop app code tab.
Once the plan is good (sometimes requires back and forth), tells Claude to execute.
With Opus 4.5+, once the plan is solid, execution stays on track almost every time.
Boris thinks plan mode has “a limited lifespan.” Model will figure out when to plan on its own.
100% AI-Written Code
Boris has uninstalled his IDE. 100% Claude Code + Opus since Opus 4.5.
Anthropic overall: 70-90% AI-written depending on team, many individuals at 100%.
Dario predicted 90% of code at Anthropic would be AI-written. It’s true.
Productivity Gains
Team doubled in size last year, but productivity per engineer grew ~70%.
Since Claude Code launched, productivity per engineer at Anthropic has grown 150%.
For context: at Meta, a 2% productivity gain was a year of work by hundreds of people.
Bug Fixing Workflow
Good logging, then point Claude at the logs.
Can create production tunnels so Claude looks at production DB directly.
“Bug fixing is just going to Sentry, copy markdown.”
Memory leak example: Boris was manually doing heap dumps in DevTools. Another engineer (Chris) just asked Claude Code. Claude took the heap dump, wrote its own analysis tool, found the leak faster.
Hiring and Team Composition
What They Look For
Two types of effective engineers: extreme specialists (e.g., Jared on memory leaks, bun team on JS runtimes) and hyper generalists who span product + design, product + research, product + business.
“We love generalists.” Engineers who also do design, user research, writing specs, talking to users.
Everyone on the team codes: PMs, designers, EMs, the finance guy.
Screening Process
Asks: “What’s an example of when you were wrong?”
Looking for: can they recognize mistakes in hindsight, claim credit for the mistake, learn from it.
Values people who do “weird stuff” (previously a warning sign, now a strength).
Example: Daisy transferred onto the team after putting up a PR that, instead of just adding a feature, first gave Claude Code a tool to test arbitrary tools, then had Claude write its own tool. “Out of the box thinking.”
Beginner Mindset Over Experience
Strong opinions from senior engineers are often not relevant anymore.
“The biggest skill is people that can think scientifically and can think from first principles.”
New team members sometimes use Claude Code more effectively than veterans because they don’t have stale assumptions.
Boris: “I’m wrong probably half the time. Half my ideas are bad.”
Considering Transcript-Based Hiring
YC hosts are experimenting with letting candidates upload Claude Code transcripts as part of hiring.
Reveals: do they check logs, correct the agent, use plan mode, think about systems, include tests.
Team Structure
The Claude Code Team Specifically
Everyone on the team is a generalist who codes.
PMs code. Designers code. EMs code. Finance codes.
Multiple people contribute to the shared CLAUDE.md multiple times a week.
Boris describes himself as “a pretty average engineer” who uses VS Code (not Vim), designs for people like himself.
Operating as a Research Lab
Anthropic operates as a research lab first, product org second.
“The product isn’t the most important thing. The model is.”
Being close to the model and its development is the priority.
Design Philosophy
Build for Yourself First
“I build a tool for myself, then the team builds the tool for themselves, then for Anthropic employees, then for users.”
Terminal was chosen because it was the cheapest thing to build, not a deliberate design decision.
React terminal (Ink) for the UI. Boris came from front-end engineering and cares about delight.
UX Principles for Terminal
No established UX patterns for modern terminal apps. Had to reinvent.
Constraint: 80x100 characters, 256 colors, one font size, no mouse interactions.
Prototyped mouse interactions (clicking), felt bad because of virtualized scrolling trade-offs. Didn’t ship.
“Delight is so important. If the product is useful but you don’t fall in love with it, that’s not great.”
Don’t Over-Engineer CLAUDE.md
Do the minimal possible thing to keep the model on track.
Delete and start fresh rather than trying to compact a bloated CLAUDE.md.
What you need decreases with every new model.
Boris’s personal fave in his CLAUDE.md: “For every plan, decide whether it’s overengineered, underengineered, or perfectly engineered, and why.”