ExpertsFMHead of Claude Code: What happens after coding is solved | Boris Cherny
Lenny's Podcast: Product | Career | Growth · February 19, 2026
5 Selected Lessons:
framework · 2 heuristic · 2 reasoning_pattern · 1
Latent demand discovery
Source
Lenny's Podcast: Product | Career | Growth — Head of Claude Code: What happens after coding is solved | Boris Cherny (February 19, 2026) · at 47:23 ▸ · at 51:55 ▸
When this applies
when deciding what to build next for any product with an active user base
The takeaway
Watch for users misusing or straining a product to do something it wasn't built for — that strain reveals a demand you can serve directly with much higher leverage.
Why it works
Users under pressure will hack an existing product to satisfy a need it wasn't designed for; the friction they tolerate is a strong signal that a dedicated product targeting that need will be a hit with far less friction.
One level up
The clearest roadmap signals come from what users are already fighting to do, not from what you intended them to do.
Where it stops holding
This stops working when the 'misuse' is a tiny, idiosyncratic edge case rather than a repeated pattern across many users, or when building a dedicated product for it cannibalizes a more valuable, intended use case.
Detail
procedure:
- Observe how people are bending or abusing your product to do something it wasn't designed for (e.g., 40% of Facebook group posts were buy/sell; data scientists using a coding terminal for SQL analysis).
- Recognize that the friction they tolerate to do this signals strong latent demand.
- Build a dedicated, easier product for that specific use case (e.g., Marketplace, Dating, Cowork).
- Apply a second, model-centric version: watch what the model itself 'wants' to do (stays on-distribution) rather than only what users want, and build minimal scaffolding around that.
benchmarks: {"facebook_marketplace":"~40% of group posts were buy/sell behavior before the product existed","facebook_dating":"~60% of profile views were cross-gender, non-friend views"}
rationale: People jumping through hoops to misuse a tool is the strongest available signal of where to build next.
In their words
So when you see people abusing the product in this way, using it in a way that it wasn't designed in order to do something that is useful for them, it's just such a strong indicator that you should just build a product and people are going to like that.
Three-layer AI safety verification
Source
Lenny's Podcast: Product | Career | Growth — Head of Claude Code: What happens after coding is solved | Boris Cherny (February 19, 2026) · at 51:55 ▸ · at 54:30 ▸ · at 57:08 ▸
When this applies
when verifying that any increasingly autonomous or powerful system (AI, automated trading system, autonomous process) is safe to deploy
The takeaway
Verify a powerful autonomous system at three nested levels — internal mechanism, controlled synthetic testing, and real-world monitored deployment — because safety at one level doesn't guarantee safety at the next.
Why it works
Each layer catches different failure modes: internal mechanisms (alignment/interpretability) catch what the system 'is', lab tests (evals) catch synthetic edge cases, and real-world observation catches behaviors that only emerge under the full diversity of real use — a system can pass the first two and still fail the third.
One level up
Confidence in a system should be built in layers of increasing realism, never from a single test type alone.
Where it stops holding
This stops working when real-world deployment itself carries catastrophic, irreversible risk such that even an early/limited release is too dangerous to run as a 'research preview.'
Detail
procedure:
- Layer 1: Alignment and mechanistic interpretability — inspect internal neuron-level representations (e.g., deception-related neurons) during training.
- Layer 2: Evals — test the model in controlled, synthetic ('Petri dish') scenarios to check alignment and safety.
- Layer 3: Real-world behavior — release early/internally first, observe behavior in actual diverse use, since a model can look good on layers 1-2 but reveal problems only here.
rationale: Claude Code was used internally for 4-5 months before external release specifically to study real-world safety; Cowork was released as an explicit 'research preview' for the same reason.
In their words
And then the third layer is seeing how the model behaves in the wild. And as the model gets more sophisticated, this becomes so important because it might look very good on these first two layers, but not great on the third one.
Historical analog reasoning for disruptive technology (printing press)
Source
Lenny's Podcast: Product | Career | Growth — Head of Claude Code: What happens after coding is solved | Boris Cherny (February 19, 2026) · at 32:39 ▸ · at 38:23 ▸
When this applies
when trying to forecast the impact of a technology that democratizes a previously scarce, specialized skill
The takeaway
When facing an unprecedented technological shift, search history for a prior case where a similarly scarce, specialized skill became cheap and widely accessible, and reason from how that shift unfolded (speed of change, disruption, eventual unlocking of new capability).
Why it works
By finding a prior technology that also collapsed the cost of a scarce specialized skill (scribal literacy -> printed literacy), one can borrow its pattern — rapid volume increase, slow but eventual mass skill diffusion, large unforeseen downstream effects (the Renaissance) — as a scaffold for reasoning about an otherwise unprecedented present situation.
One level up
Novel situations are best understood by finding the closest structural analog in history, not by reasoning from scratch.
Where it stops holding
This stops working when the analogy is superficial and the actual causal mechanisms differ enough that the borrowed pattern (e.g., timelines, winners/losers) misleads rather than informs.
Detail
approach: Identify a historical technology that also made a scarce specialized skill cheap/common; study how fast volume changed, how slowly skill diffusion followed despite falling cost, and what new possibilities emerged afterward that were unimaginable beforehand.
signals:
- A previously rare skill (literacy, coding) concentrated in a small professional class (scribes, engineers).
- A technology that collapses the cost of producing the skill's output (printing press, Claude Code) by orders of magnitude almost immediately.
- A slower, multi-decade lag before mass adoption/skill diffusion follows the cost collapse.
- The admission that nobody at the time of the shift can predict exactly what gets unlocked next.
rationale: Printed material volume exceeded 1000 years of prior output within 50 years post-Gutenberg, printing cost fell ~100x, and literacy took ~200 years to reach ~70% globally — illustrating both fast supply-side change and slow adoption-side change.
In their words
I think the thing that's come closest for me is the printing press.
Build for the model six months out
Source
Lenny's Podcast: Product | Career | Growth — Head of Claude Code: What happens after coding is solved | Boris Cherny (February 19, 2026) · at 1:03:22 ▸ · at 1:06:37 ▸ · at 15:02 ▸
When this applies
when building a product on top of a rapidly improving underlying technology (model, platform, infrastructure)
The takeaway
When the core technology you depend on is on a steep improvement trajectory, architect your product for its near-future capability, not its current capability, and tolerate weak product-market fit in the interim.
Why it works
Because the underlying capability curve is steep and predictable in direction (even if timing is uncertain), designing for where capability will be rather than where it is lets the product 'click' the moment the capability arrives, instead of needing a redesign.
One level up
Bet on the trajectory of an exponential, not its current position.
Where it stops holding
This stops working when the improvement trajectory is uncertain or non-monotonic, or when the business can't survive the uncomfortable period of weak product-market fit before the capability catches up.
Detail
rule: Build for the model (or platform) roughly six months out from release, accepting weak initial product-market fit.
threshold: Claude Code wrote only ~20% of Boris's code at launch (Feb), ~30% by May, and crossed 100% only in November — a multi-month gap between bet and payoff.
rationale: Building for current capability locks you into limitations that disappear with the next model, wasting the investment.
In their words
It's going to be uncomfortable because your product market fit won't be very good for the first six months. But if you build the model six months out, when that model comes out, you're just going to hit the ground running and the product is going to click and start to work.
Use the most capable model, not the cheapest
Source
Lenny's Podcast: Product | Career | Growth — Head of Claude Code: What happens after coding is solved | Boris Cherny (February 19, 2026) · at 1:08:39 ▸
When this applies
when choosing between a cheaper, weaker tool/resource and a more expensive, more capable one for a task requiring judgment
The takeaway
Compare options on total cost-to-completion (including rework and correction), not sticker price, when capability differences are significant.
Why it works
A less intelligent option often requires more total correction, retries, and hand-holding to reach the same outcome, so its lower sticker price can translate into a higher total cost once rework is counted.
One level up
Cheapness measured only at the unit level can be a false economy once total cost of achieving the outcome is counted.
Where it stops holding
This stops working when the task is simple enough that the cheaper option reliably succeeds without extra correction, making its lower unit cost a true saving.
Detail
rule: Default to the most capable model available; it's often cheaper overall than a less capable one because it needs less correction and fewer tokens to finish the task.
threshold: Boris runs with 'maximum effort' enabled always.
rationale: Intelligence reduces total token/time cost by cutting down on retries and hand-holding.
In their words
Often it's actually cheaper and less token intensive if you use the most capable model because it can just do the same thing much faster with less correction, less hand holding and so on.