ExpertsFMInside Claude Code With Its Creator Boris Cherny
Y Combinator Startup Podcast · February 17, 2026
5 Selected Lessons:
heuristic · 3 framework · 1 case · 1
Latent demand as the core product discovery mechanism
Source
Y Combinator Startup Podcast — Inside Claude Code With Its Creator Boris Cherny (February 17, 2026) · at 6:08 ▸ · at 24:39 ▸ · at 27:51 ▸
When this applies
when deciding what feature or product to build next for any user base
The takeaway
People will only adopt a new thing if it makes an existing behavior easier; you cannot get people to adopt a wholly new behavior.
Why it works
Users already improvising workarounds (e.g., writing markdown instruction files for themselves, or chatting with Claude in a browser before coding) reveal a real unmet need; formalizing that workaround into a feature meets demand that already exists rather than creating demand from scratch.
One level up
The most reliable product ideas come from observing what users are already improvising, not from inventing novel behaviors for them.
Where it stops holding
This stops working when there is no existing user workaround or behavior to observe — i.e., for truly novel categories with no prior analog behavior to amplify.
Detail
procedure:
- Give users a minimal tool (e.g., CLI).
- Watch what workaround behaviors emerge organically (e.g., markdown instruction files, pre-planning chats).
- Formalize the workaround into a first-class feature (CLAUDE.md, plan mode).
- Ship quickly (plan mode was written in ~30 minutes after noticing the pattern on GitHub/Slack feedback).
rationale: People will only do a thing that they already do; making an existing behavior easier is a good idea, forcing a new behavior is not.
In their words
Probably the single, for me, biggest principle in product is latent demand. And just every bit of this product is built through latent demand after the initial CLA.
Build for the model six months from now
Source
Y Combinator Startup Podcast — Inside Claude Code With Its Creator Boris Cherny (February 17, 2026) · at 0:00 ▸ · at 37:36 ▸
When this applies
when building any product on a rapidly improving underlying technology (AI models, bandwidth, hardware) where today's capability ceiling is temporary
The takeaway
Target the capability frontier that is currently weak but predictably improving, not the frontier that is currently strong.
Why it works
If you build only for the current capability level, you find product-market fit for a soon-obsolete constraint and get leapfrogged by someone targeting the next capability jump.
One level up
In fast-exponential domains, positioning for where the curve is headed beats optimizing for where the curve currently sits.
Where it stops holding
This stops working when the underlying technology's improvement trajectory is uncertain, slow, or non-monotonic, making six-month-ahead bets unreliable.
Detail
rule: Don't build for the model of today, build for the model six months from now.
threshold: Target capability gaps the model is currently bad at but will predictably improve on.
rationale: Otherwise you'll find PMF for a temporary constraint and be leapfrogged by a competitor building for the next model.
In their words
At Anthropic, the way that we thought about it is we don't build for the model of today, we build for the model six months from now. That's actually like still my advice to founders that are building on LLMs.
Never bet against the model (the bitter lesson)
Source
Y Combinator Startup Podcast — Inside Claude Code With Its Creator Boris Cherny (February 17, 2026) · at 6:08 ▸ · at 37:36 ▸
When this applies
when deciding whether to invest in a workaround/custom engineering for a capability gap versus waiting for the underlying general-purpose system to absorb that capability
The takeaway
Weigh the cost of a temporary capability extension against the near-certain cost of it becoming throwaway work once the general system catches up.
Why it works
General-purpose learned systems tend to outperform hand-engineered specific solutions as they scale, so scaffolding built around a weakness has a short shelf life once the base system improves.
One level up
In domains governed by a dominant scaling trend, specific engineered solutions are transient scaffolding, not durable moats.
Where it stops holding
This stops working when there is no clear trend of the general system improving in that specific dimension, or when the scaffolding itself creates a lasting structural advantage (e.g., data/network effects) independent of model capability.
Detail
rule: Assume any scaffolding built to patch a model weakness is tech debt; either build it for a temporary gain and rebuild later, or just wait and get the capability for free.
threshold: Scaffolding might buy 10-20% performance in a domain, then gets wiped out by the next model.
rationale: The more general model will always beat the more specific model, per the Bitter Lesson.
In their words
This is this like Rich Sutton talks. Everyone should read it if you haven't. And the idea is the more general model will always beat the more specific model. And there's a lot of corollaries to this, but essentially what it boils down to is never bet against the model.
Bimodal engineering talent: hyper-specialists and hyper-generalists, not the middle
Source
Y Combinator Startup Podcast — Inside Claude Code With Its Creator Boris Cherny (February 17, 2026) · at 18:53 ▸
When this applies
when building any high-leverage small team in a fast-moving technical domain
The takeaway
In fast-moving, tool-augmented environments, prize extreme specialization or extreme breadth-plus-curiosity over conventional well-rounded competence.
Why it works
Deep specialists provide irreplaceable depth (e.g., devtools/runtime internals) while generalists span product/design/infra/business to find unconventional leverage (e.g., having the AI write its own tools); the effective middle-of-the-road generalist-specialist blend is comparatively less valuable in this environment.
One level up
AI automation shifts the value of human contribution toward the extremes of the skill distribution — deep expertise or wide synthetic creativity — rather than the median.
Where it stops holding
This stops working when the team's work doesn't benefit from either extreme — e.g., highly standardized operational work where consistent competence matters more than specialization or novelty.
Detail
rule: Look for extreme specialists or extreme generalists who 'do weird stuff' spanning multiple functions.
rationale: Example: engineer Daisy, instead of implementing a feature herself, built Quad a tool to test tools and had Quad write its own tool — unconventional thinking that's hard to screen for traditionally but highly valuable now.
In their words
I think when I look at engineers on the team that I think are the most effective, there's essentially two. It's very bimodal. There's one side where it's extreme specialists
Anthropic's measured productivity gains from AI-assisted coding
Source
Y Combinator Startup Podcast — Inside Claude Code With Its Creator Boris Cherny (February 17, 2026) · at 40:02 ▸
When this applies
when trying to quantify the real impact of an internal tool rollout rather than relying on anecdote or hype
The takeaway
When evaluating a tool's impact, normalize for scale (e.g., per-engineer, not total) and cross-check with multiple metrics before trusting a dramatic number.
Why it works
Measuring productivity via a simple, cross-checked metric (pull requests, cross-checked against commits and commit lifetime) before and after a tool's adoption isolates the tool's effect from team growth, since team size alone could confound raw output.
One level up
Extraordinary productivity claims warrant triangulating multiple measurable proxies rather than resting on a single headline statistic.
Where it stops holding
This stops working when the proxy metrics themselves are gameable (e.g., more, smaller PRs) or don't capture quality/value, only volume.
Detail
situation: Anthropic's engineering team doubled in size over a year.
decision: They measured productivity per engineer via pull requests, cross-checked against commits and commit lifetimes.
outcome: Productivity per engineer grew ~70% year-over-year, and 150% since Claude Code's launch — compared to a 2% gain Boris previously considered a major achievement at Meta after a year of work by hundreds of people.
lesson: AI coding tools can produce productivity gains an order of magnitude beyond what was historically considered a major org-wide win.
In their words
I think the team doubled in size last year, but productivity per engineer grew something like 70%